Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

STM32F3 - BlackBOX v1,0 Rejestrator lotu rakiety. Projekt PCB i programowanie.

SeerKaza 08 Mar 2013 16:09 6987 38
Tespol
  • #1
    SeerKaza
    Level 20  
    Witam.

    Stosunkowo niedawno wziąłem się za Cortexy i chciałbym na nich oprzeć swój projekt. I potrzebuje kilku rad odnośnie projektowania płytki pod te procesory (STM32F372CCT6 /LQFP48). Niestety w datasheecie prócz tego jak podłączyć zasilanie innych pomocy nie znalazłem i mam kilka pytań.

    1. Co zrobić z wejściem kwarcu dla RTC jak nie mam zamiaru z niego korzystać.
    2. Jakie polecilibyście kondensatory przy kwarcu zewnętrznym 8 MHz i czy macie jakieś porady odnośnie prowadzenia do niego ścieżek
    3. Co zrobić z pinem Vbat jak nie chce używać podtrzymania bateryjnego.
    4. Które piny wyprowadzić by zaprogramować go przez SWD programatorem który jest w STM32f4discovery.

    plus byłbym wdzięczny za wszelkie porady odnośnie projektowania płytki pod ten procesor.

    Plus mam jedno pytanko odnośnie programowania jak bardzo i który przykładowy projekt freddiego muszę przerobić by oprogramować ten procek, Wiem że w linkerze muszę zmienić wielkość flash oraz inicjowanie PLLa ale co jeszcze.

    Wersja 1.0 tego rejestratora ma być dość prosta procek, akcelerometr lis331hh plus 2 kości po 4 Mb pamięci flash i wyjście usarta. 2 flashe (60 i jeden wolniejszy) i akcelerometr podłączone pod osobiste SPI. plus wyjście USART by po locie przesłać wszystko na komputer. w wersji następnej v1.1 będę chciał dodać przeliczanie przyśpieszenia na prędkość i drogę dlatego wybieram wersje procka z FPU.
  • Tespol
  • #2
    BlueDraco
    MCUs specialist
    Po prostu skopiuj co się da np. z projektu płytki STM32F3DISCOVERY. Na schemacie znajdziesz odpowiedzi na prawie wszystkie Twoje pytania.

    Nieużywane wyprowadzenia zostaw wiszące, ew. XTALIN połącz z masą, żeby nie dzwoniło.

    Dlaczego chcesz mieć w urządzeniu dwie różne pamięci Flash po 4Mib? Nie lepiej wziąć jedną o właściwej pojemności?

    Połączeniu z komputerem łatwiej jest zrobić na USB, chociażby jako VCOM albo MSD. Po co każesz użytkownikowi targać ze sobą przejściówkę USB-RS232?

    Z danych z akcelerometru nie wyznaczysz wiarygodnie nawet prędkości, a o drodze możesz z całą pewnością zapomnieć - błąd podwójnego całkowania.
  • #3
    piotrva
    VIP Meritorious for electroda.pl
    ad. 1. Jak widzisz funkcja taktowania RTC za pomocą tam podpiętego kwarcu jest funkcją alternatywną - więc możesz je pozostawić połączone tak jak pozostałe nieużywane piny.
    ad. 2. Albo takie jak zaleca producent kwarcu (możesz użyć też generatora lub kwarcu ze zintegrowanymi kondensatorami).
    ad. 3. Podpiąć do VCC
    ad. 4. To sprawdź sobie wg. schematu i informacji poniżej:
    http://www.rlocman.ru/i/File/dat/STMicroelectronics/Microcontrollers_MCU/STM32F373CCT6.pdf (strony 68 - kwarc, 50 - zasilanie, wyszukaj w dokumencie "SWD" i znajdziesz informacje dot. podłączenia programatora, które możesz porównać ze schematem discovery)

    Dodano po 1 [minuty]:

    A co do pomiarów - jak napisał kol. BlueDarco - akcelerometr nie jest najlepszym urządzeniem do wyliczania prędkości i/lub drogi.
  • #4
    SeerKaza
    Level 20  
    BlueDraco wrote:
    Z danych z akcelerometru nie wyznaczysz wiarygodnie nawet prędkości, a o drodze możesz z całą pewnością zapomnieć - błąd podwójnego całkowania.


    Rozmawiałem specjalnie w tej sprawie z profesorem od technik obliczeniowych i metod numerycznych. Z informacji od niego dowiedziałem się że różniczkowanie jest obarczone ogromnym błędem jednak przy całkowaniu odpowiednią metodą można uzyskać zadowalające wyniki. Więc to że całkowanie tworzy ogromne błędy to mit. I najprawdopodobniej na tym rejestratorze tylko odpowiednio rozwiniętym uda mi się napisać prace inżynierską. Wiec proszę mi nie zapeszać podzielę się potem wynikami prać. Ja jednak myślę że mi się uda. :)

    PS. ta całka jest bardzo prosta przy wykorzystaniu najprostszej metody prostokątów jest to wymnożenie przyśpieszenia razy okres czasu miedzy kolejnymi próbkami do kwadratu i sumowanie tego. A można wykorzystać i inne bardziej wyrafinowane metody.
  • Tespol
  • #5
    BlueDraco
    MCUs specialist
    Rozumiem, że ten profesor ma praktykę w liczeniu prędkości i drogi z odczytów akcelerometru MEMS? No to chylę czoła i życzę sukcesów. Jak się to dobrze zrobi, to w krótkim czasie (np. jednej minuty) jest szansa na zejście z błędem pomiaru drogi poniżej 100%, o ile obiekt będzie się poruszał w miarę szybko.

    Pomyśl raczej o zastosowaniu żyroskopu interferencyjnego... ;) Kosztuje co prawda kilkadziesiąt tys. zł, ale daje dobry odczyt prędkości i drogę daje się z tego policzyć z dokładnością lepszą niż 1/100000.

    A tak na poważnie - żeby coś z tego wyszło, potrzebujesz kilku akcelerometrów albo żyroskopów żyroskopów MEMS. Bez żyroskopów/zwielokrotnionych akcelerometrów jesteś bez szans.
  • #6
    SeerKaza
    Level 20  
    BlueDraco wrote:
    Rozumiem, że ten profesor ma praktykę w liczeniu prędkości i drogi z odczytów akcelerometru MEMS? No to chylę czoła i życzę sukcesów. Jak się to dobrze zrobi, to w krótkim czasie (np. jednej minuty) jest szansa na zejście z błędem pomiaru drogi poniżej 100%, o ile obiekt będzie się poruszał w miarę szybko.


    Wcześniej czepiałeś się o całkowanie a teraz o dane z czujnika. Z profesorem rozmawiałem na temat błędów powstałych w wyniku całkowania numerycznego

    BlueDraco wrote:
    Jak się to dobrze zrobi, to w krótkim czasie (np. jednej minuty) jest szansa na zejście z błędem pomiaru drogi poniżej 100%, o ile obiekt będzie się poruszał w miarę szybko.


    Pierwszy lot ma się odbyć na małej rakiecie szacunkowy czas pionowego lotu w górę 15s wysokość około 1 km ilość próbek 15000 na oś. Myślę że starczy by w miarę to policzyć i przybliżyć tematykę. Jest to pierwsza wersja w kolejnych planuje powiększyć "arsenał"czujników. Pomiar drogi jest potrzebny by szacunkowo określić wysokość do wystrzelenia spadochronu margines błędu może wynosić 100m grunt by nie za nisko i nie tuż po zatrzymaniu silników.

    EDIT

    Rozumiem że liczenie drogi przy małej dynamice jest bezsensowne jednak to będą krótkie dynamiczne loty w których myślę da się z zadowalająca dokładnością policzyć droge
  • #7
    BlueDraco
    MCUs specialist
    Pomyśl: jeśli błąd przyspieszenia wynosiłby np. 0.01 m/s2 (a jest sporo większy), to jaki będzie błąd drogi po 10 sekundach? Całkowanie w takim przypadku potęguje błędy pomiaru. Samo całkowanie może być idealnie dokładne, ale to NIC nie daje, gdy funkcja pod podwójną całką ma "lekko błędne" wartości. To się właśnie nazywa "błędem podwójnego całkowania", a nie błędną implementację samej operacji całkowania.

    Zwielokrotnienie akcelerometrów, w tym w konfiguracji "żyroskopowej" umożliwia częściową detekcję i kompensację błędów. Słowem kluczowym jest tu "częściowa".

    Błąd 100 m na 100 m drogi powinno dać się osiągnąć dość łatwo w czasie ruchu. Gorzej będzie ze stanem spoczynkowym. :)
  • #8
    SeerKaza
    Level 20  
    BlueDraco wrote:
    omyśl: jeśli błąd przyspieszenia wynosiłby np. 0.01 m/s2 (a jest sporo większy), to jaki będzie błąd drogi po 10 sekundach? Całkowanie w takim przypadku potęguje błędy pomiaru. Samo całkowanie może być idealnie dokładne, ale to NIC nie daje, gdy funkcja pod podwójną całką ma "lekko błędne" wartości. To się właśnie nazywa "błędem podwójnego całkowania", a nie błędną implementację samej operacji całkowania.


    Zamiast myśleć można policzyć. Jeśli a to zmierzona wartość to
    a = a0 + deltaa.
    a0 to wartość dokładna a deltaa to błąd pomiaru. Przyjmując że czas mamy dokładny to
    s0 + deltas = a0 * t^2 + deltaa *t ^2 oraz
    s0 = a0 * t^2
    to podkładając do równania i skracając wychodzi nam
    deltas = deltaa *t^2

    Mając jedną próbkę i błąd podany przez ciebie to błąd pomiaru wyniósł by 1m przy 15 s 1.5m pruwnując do 1 km to nic. W moim przypadku na te 10 s będe miał 10000 próbek a całkowanie to suma więc błędy rosnął powoli nie namnażając się a przy błędach w różnych znakach się kompensują

    Z nudów policzyłem dalej przy błędzie pomiaru 10% i najgorszym przypadku nakładania się błędów (nie uwzględniłem bo nie mam na razie za bardzo jak błędów zaokrągleń) to przy 1 minutowym locie błąd wyniesie 1,64m. Mając próbki o częstotliwości 1kHz
  • #9
    nproton
    Level 12  
    Z samego akcelerometru niewiele odczytasz, przydał by się do tego żyroskop i najlepiej jeszcze GPS. Wtedy stosując np filtry Kalmana jesteś w stanie wyznaczyć dokładną drogę. Akcelerometry mają bardzo duży szum a żyroskopy dryft.
  • #10
    BlueDraco
    MCUs specialist
    Przy nierealistycznie małym błędzie 0.01 m/s2 po 10 sekundach Twój stojący w miejscu akcelerometr jedzie z prędkością 0.1 m/s. Zanim rakieta wystartuje, już będzie się poruszała i to całkiem szybko. ;)

    Zresztą - zmontuj to, oprogramuj i zacznij robić pomiary suwając płytkę po biurku, wtedy pogadamy o błędach. Bez żyroskopu lub akcelerometrów w konfiguracji "żyroskopowej" nie da rady.
  • #11
    Piotr Piechota
    Level 21  
    BlueDraco wrote:
    (...)
    Z danych z akcelerometru nie wyznaczysz wiarygodnie nawet prędkości, a o drodze możesz z całą pewnością zapomnieć - błąd podwójnego całkowania.(...)


    Witam
    Zależy co się chce osiągnąć.
    W swojej pracy zawodowej mierzę przyspieszenia boczne naczyń wyciągowych (górnictwo). W celu określenia miejsc powstawania największych bocznych przyspieszeń mam na naczyniu zamocowany akcelerometr mierzący również pionowe przyspieszenie. Znam dokładnie całkowitą drogę jaką naczynie przebywa i mogę błędy całkowania skompensować. Uzyskuje dokładność odwzorowania drogi na poziomie kilku metrów na kilometrze.
    Oczywiście wyznaczanie drogi w czasie rzeczywistym to inna bajka i bez żyroskopu laserowego nie można liczyć na sensowne pomiary. Robiłem kiedyś eksperymenty z żyroskopem MEMS i robotem do koszenia trawy. Udawało mi się dobrze utrzymywać wyliczony 'kurs' ale pozycja odpływała po kilku sekundach.

    Powodzenia
  • #12
    SeerKaza
    Level 20  
    nproton wrote:
    Z samego akcelerometru niewiele odczytasz, przydał by się do tego żyroskop i najlepiej jeszcze GPS. Wtedy stosując np filtry Kalmana jesteś w stanie wyznaczyć dokładną drogę. Akcelerometry mają bardzo duży szum a żyroskopy dryft.


    Tak jak pisałem wcześniej kolejne wersje będą doposażone. Ta wersja to taki wstęp by wiedzieć czego się spodziewać od rakiety. O GPSie też myślałem by wraz z GSMem zrobić system lokalizujący rakietę po spadku.

    BlueDraco wrote:
    Zresztą - zmontuj to, oprogramuj i zacznij robić pomiary suwając płytkę po biurku, wtedy pogadamy o błędach. Bez żyroskopu lub akcelerometrów w konfiguracji "żyroskopowej" nie da rady.


    Właśnie w takim celu w tym momencie programuje stm32df4iscovery z o wiele słabszym akcelerometrem
  • Helpful post
    #13
    User removed account
    Level 1  
  • #14
    SeerKaza
    Level 20  
    Dzięki za wszystkie porady na pewno je wykorzystam. Dlatego zaczynam od akcelerometru bo mając wybrać jeden czujnik z wielu wybrałem akurat ten. Czemu ktoś zapyta się jeden czujnik. A dlatego jak już wcześniej pisałem dopiero wchodzę w tę tematykę i cortexa i zbierania danych z taką rozdzielczością. Wole mieć dane z jednego czujnika niż niemieć żadnych bo program mi się gdzieś wykrzaczy w locie. Oczywiście żyroskop jest planowany za waszą namową spróbuje opiekuna koła namówić na dodatkowy wydatek. Może uda mi się to oprogramować. Tak wiem że pamieć masowa na USB jest szybsza i lepsza. Ale powtarzam na razie nie umiem tego oprogramować. A by się tego nauczyć potrzeba trochę czasu. A ja chce jak najszybciej posiadać minimalne dany by wiedzieć w jakim kierunku podążać. Dla mnie ta tematyka jest nowa dla was nie wiem ale myślę że jest różnica miedzy pojazdem na płaszczyźnie jadącym 130km/h a rakietą która mknie niemal w linie prostej. I tutaj kilka komentarzy:

    Marek_Skalski wrote:
    Akcelerometr jest w miarę dobry, jeżeli masz powtarzalny ruch (drgania, wahnięcia) na określonej drodze i najlepiej w jednym kierunku. Jeżeli chcesz rejestrować tor ruchu obiektu w przestrzeni o 6 stopniach swobody, to już w pierwszych sekundach błędy będą powyżej granicy przyzwoitości.


    Najbardziej znacząca będzie 1 oś Z. z założenia rakieta gdy posiada odpowiedni ciąg leci pionowo do góry. osie X i Y będą tylko pilnować ewentualnych odchyleń.

    Marek_Skalski wrote:
    Do tego zakładasz, że pomiary będą z f=1kHz, zapominając chyba o tym, że MEMSy dają wtedy najwyżej 8-bitowe wyniki.

    Niestety datasheet stm o tym nie wspomniał wiec nie wiedziałem o tym i jakoś średnio chce mi się wierzyć że tak rozdzielczość spada oni deklarują 12-16bit

    Marek_Skalski wrote:
    . Mówisz o wykorzystaniu GPS, a czy wiesz z jaką częstotliwością i dokładnością działa ten system? Dane są odświeżane co 1,000000s, a dokładność pozycji typowego modułu to 2,5m, dokładność wysokości... no cóż, tutaj jest znacznie gorzej... 20..50m.


    Celem GPSa ma być lokalizacja rakiety po wylądowaniu.

    Marek_Skalski wrote:
    Z jakiegoś powodu upierasz się przy stosowaniu 2 osobnych pamięci danych, których pojemność jest śmiesznie mała w porównaniu do tego ile danych chcesz zebrać, zamiast np. zapakować kartę pamięci (2GB z FAT16 co by łatwiej było) i łączyć się przez USB w trybie pamięci masowej, co jak zauważysz znakomicie ułatwia zarówno rozwój projektu jak i korzystanie z niego.


    No własnie w tym kierunku też się powoli edukuje . Niestety jestem człowiekiem który nie przepada za metodą programowania w stylu kopiuj/wklej kawałki kodu i przynajmniej w minimalnym stopniu chce zrozumieć co się dzieje.

    Marek_Skalski wrote:
    Jeżeli chcesz, mogę się podzielić moimi niewielkimi doświadczeniami w zakresie realizacji podobnych projektów, chociaż to była zupełnie inna platforma i poruszała się po ziemi z prędkością do 130km/h.


    Bardzo chętnie skorzystam z twojego doświadczenia. Choć podejrzewam że rzędy prędkości będą zupełnie inne.

    Marek_Skalski wrote:
    BTW. Myślałeś jak filtrować zakłócenia od drgań? Znalazłeś udaną działającą implementację filtru H-inf, albo chociaż Kalmana? Podpowiem, że ST ma fajny pakiet softu, ale niestety bardzo trudno go uzyskać zarówno jako os. fiz. jak i jednostka edukacyjna.

    Bardzo chętnie spróbuje zaimplementować któryś z tych filtrów jednak jak powtarzam pierwszej próby nie chce nazbyt komplikować.

    Plus wyjaśnienie celu BlackBOXa 1.0 Po prostu zebranie danych wejściowych do projektu rejestracji i sterowania lotu rakiety(dane dotychczasowe to kilka filmów plus informacje z internetu gdzie ktoś lot rejestrował iphonem). Rejestracja przyśpieszenia ma jeszcze jeden cel ważniejszy od pomiaru drogi lotu. Jest to mianowicie pomiar właściwości zainstalowanego silnika. Czyli tutaj przyśpieszenie jest najważniejszym parametrem. Jak rakieta przyśpiesza a następnie jak jest hamowana przez pęd powietrza po wyłączeniu silnika. Wysokość jest sprawą mniejszej wagi i dokładność 100m jest dokładnością wystarczającą.
  • #15
    SeerKaza
    Level 20  
    Witam ponownie

    Mam problem z tworzeniem projektu od zera w Eclipsie.

    Otóż robię tak:

    1. Tworze projekt: New/ C Project/Makefile Project/Empty Project/Other Toolchain
    2. Kopiuje pliki z przykładu Freediego Makefile (zmieniam w nim tylko nazwę projektu) vectors, startup, main , config, gpio, include , hdr.
    3.Dodaje w C generals/Paths and Symbols. I w zakładce include te same co są w przykładach freediego tylko że nie do G++ ale do bleeding edge.

    I dzieją się takie numery że wszystko kompiluje i debuguje ale...

    1. Nie działają wszystkie podpowiedzi np do funkcji __enable_irq() podczas pisania wywala błąd ctrl space niepodpowiada tego jeśli jednak napisze już całe to daje spokój
    2. W perspektywie debugowania zniknął mi ten pasek z resume pause stop jak chce je znowu załączyć pojawia mi się komunikat "Debug cannot be made visible because all of its children are in unavailable command groups. Jednak jak prawym kliknę na proces to działają te komendy. Program normalnie działa i się debuguje.

    Robię cały projekt od nowa by się nauczyć samemu a nie tylko ciągły import przykładu freediego. Pozatym w przykłądach frediego jest linkowany g++ a ja chce przejść już na bleeding edge
  • #16
    Freddie Chopin
    MCUs specialist
    Zaimportuj projekt i zmień sobie w nim nazwę. W projektach przykładowych nie ma nawet pół litery która powstrzyma Cię od używania bleeding-edge-toolchain - to który zostanie faktycznie użyty zależy TYLKO od tego który kompilator jest pierwszy w PATH, Eclipse nie ma z tym nic wspólnego.

    4\/3!!
  • #17
    SeerKaza
    Level 20  
    I tylko małe pytanko gdy chce przejść na F3

    stm32f4xx.h
    system_stm32f4xx.h

    te 2 pliki musze zmienić oraz dane w makefile i linkerze tak ??

    O to jaki kompilator będzie użyty chodziło mi że w includes są scieżki do g++ i jeśli będzie kompilować się w edge to nie będzie żadnych komplikacji ??

    Rename projektu skonczyło się na tym że kod popodkreślał się na czerwono.
    Nie zna wielu funkcji i definicji includy zostały dla starej sciezki w workspace. Czyli chyba jeśli chce by projekt inaczej się nazywał muszę to zrobić ręcznie w pliku projektu a potem zaimportować. Eclipse krzyczy ze nie zna nazw rejestrów itd ale się kompiluje
  • Helpful post
    #18
    alagner
    Level 26  
    Ustaw/sprawdź discovery options, zrób clean a potem build.

    Rebuild index też może pomóc.

    Zresztą jak chcesz mrugajkę diodą dla F3 to mam zrobioną jakąś prostą na podstawie projektów Freddiego.
  • #19
    SeerKaza
    Level 20  
    Robię od nowa workspace bo wszystko mi się już posypało, nic niedziała

    alagner wrote:
    Zresztą jak chcesz mrugajkę diodą dla F3 to mam zrobioną jakąś prostą na podstawie projektów Freddiego.


    Ja nie chce tylko kopiować chce załapać o co w tym chodzi.
  • Helpful post
    #20
    Freddie Chopin
    MCUs specialist
    SeerKaza wrote:
    te 2 pliki musze zmienić oraz dane w makefile i linkerze tak ??

    W Makefile to za dużo zmian nie będzie (może jakieś nazwy plików), więc głównie linker i tablica wektorów.

    SeerKaza wrote:
    O to jaki kompilator będzie użyty chodziło mi że w includes są scieżki do g++ i jeśli będzie kompilować się w edge to nie będzie żadnych komplikacji ??

    Te ścieżki są wykrywane automatycznie przez Eclipse. To co tam Eclipse "znajdzie" zależy właśnie od tego który kompilator jest pierwszy w PATH.

    alagner wrote:
    Ustaw/sprawdź discovery options, zrób clean a potem build.

    Rebuild index też może pomóc.

    To są kluczowe rzeczy w Twoim obecnym problemie - wszystko jest w Discovery Options, jak zmieniasz kompilator (poprzez zmianę kolejności/dostępności w PATH), to po prostu trzeba aktualne Discovery Options wyczyścić (gdzieś tam jest taki przycisk), skompilować projekt i odbudować index.

    4\/3!!
  • #21
    SeerKaza
    Level 20  
    Dzieki wielkie za rady. Przepraszam że tak późno odpisuje ale mnie lekki wk**w złapał i musiałem to wszystko na kilka dni zostawić. Teraz wróciłem zrobiłem całe środowisko od nowa bo tak w starym namieszałem że już zupełnie nic nie działało. Na tworzenie nowego projektu zadziałało rename i clean z rebuild discovery option . Zmieniłem także kolejność patch że łapie teraz bleeding edge. Dzięki za pomoc jutro wracam do walki z przerwaniami. Bo chce ustawić żeby mikro kontroler odbierał dane jak przyjdzie przerwanie z czujnika ale czujnik chyba nie chce tych przerwań wysyłać. W poniedziałek na uczelni muszę go pod oscyloskop podłączyć. Na starym zrypanym środowisku jak chciałem przetestować funkcje to zamiast przerwania exti uruchamiał się default handler.

    Tak wygląda ten zrypany program jutro na spokojnie od nowa go odtworzę od nowa. Mi pewnie zajmie pół dnia a ktoś z bardziej doświadczony może znaleśc problem w sekunde więc wklejam poniżej kod. Program miał zebrać 1000 próbek a później wysłać je po uarcie. Celem programu miało być sprawdzenie współpracy przerwań z LISa jednak jak nie chciało działać ustawiłem na przerwania z przycisku niestety po naciśnięciu uruchamiał się defauld zamiast exti handler

    Code: c
    Log in, to see the code
  • #22
    Freddie Chopin
    MCUs specialist
    SeerKaza wrote:
    static void EXTI0_IRQHandler(void) __attribute__ ((interrupt));

    Po pierwsze nie ma najmniejszego sensu deklarować wcześniej funkcji przerwania, bo przecież nigdzie jej nie wywołujesz. Proponuję tego nie robić. To w sumie mało istotne, ale... (;

    Po drugie - i to jest problemem - funkcje "globalne", a taką funkcją JEST przerwanie - N-I-E mogą być static. Jak zrobisz ją lokalną, to już nie jest żadne przerwanie, tylko ot taka sobie lokalna funkcja, której nazwa zostanie zmanglowana aby nie było konfliktu, a co za tym idzie NIE zostanie umieszczona w tablicy wektorów (nawet jakby nie była zmanglowana to też nie zostałaby umieszczona, bo nie jest exportowana).

    4\/3!!
  • #23
    SeerKaza
    Level 20  
    static dodałem jak już nic innego nieprzychodzilo mi do glowy wczesniej było bez statica .
    Freddie Chopin wrote:
    Po pierwsze nie ma najmniejszego sensu deklarować wcześniej funkcji przerwania, bo przecież nigdzie jej nie wywołujesz. Proponuję tego nie robić. To w sumie mało istotne, ale... (;


    Czyli co wystarczy że włącze przerwanie i wstawię w mainię funkcje

    void EXTI0_IRQHandler() i już ?? Funkcje deklarowałem bo gdzieś znalazłem na forum taki komplet deklaracja plus funkcja i myślałem że to jest potrzebne.
  • #24
    Freddie Chopin
    MCUs specialist
    SeerKaza wrote:
    Czyli co wystarczy że włącze przerwanie i wstawię w mainię funkcje

    Akurat _w_ main() to raczej średnio Ci się uda (;

    SeerKaza wrote:
    Funkcje deklarowałem bo gdzieś znalazłem na forum taki komplet deklaracja plus funkcja i myślałem że to jest potrzebne

    Chodzi o to, że __attribute__ lepiej wygląda jak jest osobna deklaracja [; Ja to robię zwykle tak:

    Code: C
    Log in, to see the code


    Na STM32F4 atrybut przerwania jest zbędny, więc deklaracja też.

    Jeśli całość kompilujesz kompilatorem C++, to funkcje przerwań muszą być extern "C" (jeśli akurat tablica wektorów jest kompilowana kompilatorem C, albo gdy jest w assemblerze).

    4\/3!!
  • #25
    SeerKaza
    Level 20  
    Freddie Chopin wrote:
    SeerKaza napisał:
    Czyli co wystarczy że włącze przerwanie i wstawię w mainię funkcje

    Akurat _w_ main() to raczej średnio Ci się uda (;

    Chodziło mi o plik main

    Freddie Chopin wrote:
    Jeśli całość kompilujesz kompilatorem C++, to funkcje przerwań muszą być extern "C" (jeśli akurat tablica wektorów jest kompilowana kompilatorem C, albo gdy jest w assemblerze).

    I teraz nie wiem co mam zrobić. Przerabiam twój przykład i używam EDGE. Czy coś mam dopisywać przed funkcją przerwania,umieszczać ją innym pliku czy co mam zrobić z tą zacną informacją??
  • #26
    Freddie Chopin
    MCUs specialist
    Jeśli nie jest to plik C++ lub jeśli nie kompilujesz go arm-none-eabi-g++ (w odróżnieniu od ...-gcc), to nic nie rób. Na pewno bez static i upewnij się, że nazwa przerwania się zgadza z tym co jest w tablicy wektorów.

    EDIT: A tak w ogóle to jak przerabiasz przykład (zakładam że ten dla STM32F4), to poprawiłeś już tablicę wektorów tak żeby pasowała do STM32F3? Bo raczej nikłe szanse żeby była taka sama, a jakbyś miał ją niewłaściwą to właśnie taki objaw będzie.

    4\/3!!
  • #27
    SeerKaza
    Level 20  
    Tool chain editor used tools:
    Cross GCC Compiler
    Cross G++ Compiler
    Cross GCC Linker
    Cross G++ Linker
    Cross GCC Archiver
    Cross GCC Assembler

    A w zakładce discovery option compiler invocation command to
    arm-none-eabi-gcc wiec chyba korzystam z C

    Dodano po 1 [minuty]:

    Freddie Chopin wrote:
    EDIT: A tak w ogóle to jak przerabiasz przykład (zakładam że ten dla STM32F4), to poprawiłeś już tablicę wektorów tak żeby pasowała do STM32F3? Bo raczej nikłe szanse żeby była taka sama, a jakbyś miał ją niewłaściwą to właśnie taki objaw będzie.


    Narazie robię i testuje na stmf4 bo nie mam gotowego układu dla f3 . Jak polutuje układ wtedy będę się przeprowadzał

    EDIT
    Przed coreutilis wiedziałem jaką ścieżkę wybieram teraz to jest chyba z automatu i nie jestem pewien gdzie czego szukać. To moje pierwsze środowisko na eclipsie (AVR też zrobiony krok po kroczku z turtorialu ale tam nie trzeba nic przerabiać) i temu mam kłopoty nie tak z samym pisaniem programów jak opanowaniem środowiska (no przerwania to inna bajka :] )
  • #29
    alagner
    Level 26  
    Freddie Chopin wrote:

    EDIT: A tak w ogóle to jak przerabiasz przykład (zakładam że ten dla STM32F4), to poprawiłeś już tablicę wektorów tak żeby pasowała do STM32F3? Bo raczej nikłe szanse żeby była taka sama, a jakbyś miał ją niewłaściwą to właśnie taki objaw będzie.
    4\/3!!

    Ja przerabiałem, sporo się nawet pokrywa.
  • #30
    SeerKaza
    Level 20  
    Te przerwania to najgorsza rzecz do ogarnięcia. Odbudowałem program fragmentami ze starego i na początek dałem proste krótkie przerwanie by jak nacisnę przycisk wysłało byle co po usarcie. No i działa ALE na którym for się zatrzyma w głównej pętli programu gdy wywołam pierwszy raz przerwanie to na tej już zostaje i nie chce jej opuścić ale jak wywołuje kolejne przerwania to one działają po prostu główny program nie idzie już dalej.

    Code: c
    Log in, to see the code


    Zmieniłem trochę interrupta by do usarta wysyłał dane otrzymane z akcelerometru

    Code: c
    Log in, to see the code


    Tak wygląda funkcja do czytania danych z LISa ona na pewno działa bo wcześniej działała

    Code: c
    Log in, to see the code


    I w funkcji dla LISa znowu zatrzymuje się na pętli for. Ogólnie jak po wywołaniu interrupta. Żadna pętla For nie chce działać