Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Computer ControlsComputer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Przykłady dla STM32 + STM32F10x Standard Peripherals Library

14 Sty 2012 18:31 9378 39
  • Specjalista - Mikrokontrolery
    Zapraszam zainteresowanych do przejrzenia nowego artykułu opisującego jak połączyć moje przykłady ze (znienawidzoną przeze mnie [; ) biblioteką Standard Peripheral Library dla STM32 (;

    http://www.freddiechopin.info/index.php/pl/ar...-stm32-stm32f10x-standard-peripherals-library

    Wszelkie uwagi - pod artykułem, przez formularz kontaktowy strony lub w tym temacie.

    4\/3!!
  • Computer ControlsComputer Controls
  • Poziom 28  
    Koniec świata :D Freddie i FWLib :D
    A tak na serio, to mnie najbardziej interesowałaby opcja opisana na ostatniej stronie jako "najbardziej interesująca", a więc wykorzystanie startupa i skryptów linkera (i tylko tych plików) dostarczanych razem z biblioteką (w połączeniu z "pierdołami" typu sbrk, malloc itp itp). Bo nie po to w końcu producent procka dostarcza pliki supportowe aby przepisywać je potem na nowo. Zwłaszcza, że coraz to nowsze rodziny uC wychodzą i skorzytanie z supportu od producenta znacznie upraszcza sprawę.
  • Poziom 19  
    Tyle tu o FWLib, ale jak dobrze kojarzę to NXP też wypuścił coś bardzo podobnego, tyle co mi się rzuciło na pierwszy rzut oka to nie mają assertów. One nie są znienawidzone ;]? Czy to wyniki raczej z większej popularności STM nad LPC?
  • Specjalista - Mikrokontrolery
    Pituś Bajtuś napisał:
    A tak na serio, to mnie najbardziej interesowałaby opcja opisana na ostatniej stronie jako "najbardziej interesująca", a więc wykorzystanie startupa i skryptów linkera (i tylko tych plików) dostarczanych razem z biblioteką (w połączeniu z "pierdołami" typu sbrk, malloc itp itp)

    No ale tu nie ma co opisywać, bo to będzie generalnie identycznie jak w opcji 2.

    Pituś Bajtuś napisał:
    Bo nie po to w końcu producent procka dostarcza pliki supportowe aby przepisywać je potem na nowo

    Nie wiem co chcesz przepisywać... Startup zawsze jest taki sam, a w skrypcie linkera zmieniasz rozmiar pamięci. Tutaj nie ma w ogóle co "przepisywać". Przeglądałem te skrypty linkera dostępne w bibliotece i generalnie są tak lewe, że zostanę przy swoich (m.in. dlatego nie opisuję jak to zrobić, bo najpierw musiałbym te pliki poprawiać, żeby się do czegoś nadawały) [; Jedyne co się może niby zmienić to tablica wektorów, tyle że ona występuje dla STM32F1 w 2 wariantach, więc - ponownie - gdzie jest problem?

    4\/3!!
  • Poziom 28  
    Freddie Chopin napisał:
    więc - ponownie - gdzie jest problem?

    Życie nie kończy się na STM32F1. Chociaż po głębszym przemyśleniu faktycznie problemu nie widzę.
  • Poziom 32  
    A ja dzisiaj rozprawiłem się z JTAG-lock-pickiem, toolchainem i przykładowymi projektami i miałem napisać i wysłać uwagi na ich temat. Rozniosłeś mi całą koncepcję maila, którego miałeś dostać. Ładnie to tak? ;)
  • Poziom 38  
    Pituś Bajtuś napisał:
    Freddie Chopin napisał:
    więc - ponownie - gdzie jest problem?

    Życie nie kończy się na STM32F1. Chociaż po głębszym przemyśleniu faktycznie problemu nie widzę.


    Freddie się pomylił bo te skrypt/startupy można użyć na wszystkich CM-3 i CM-0 (po drobnych modyfikacjach) być może i na CM-4 ale tego nie wiem.
  • Poziom 32  
    Przetestowałem właśnie z opcją numer dwa. Macha pinem jak należy.

    Skoro już w tym temacie jesteśmy, to moja mała uwaga do przykładów dla STM32. Przydałby się trochę dokładniejszy opis do nich, a konkretniej krótkie wyjaśnienie przeznaczenia tych plików, które należy po prostu umieścić w projekcie przy tworzeniu własnego i ew. co w nich zmienić (np. rozmiary pamięci w skrypcie linkera), a które są częścią migania diodą. Oraz jakaś wzmianka o FWlib i że go w przykładach nie używasz. Jakby też do tego dorzucić jakiś miniporadnik, w którym byłyby wymienione podstawowe dokumenty na podstawie których sobie można radzić bez bibliotek, to już by było idealnie. Nie mam tu na myśli pisania pełnego tutoriala programowania STM32, tylko takiego punktu zaczepienia do dalszej pracy.

    W skrócie cieszę się z tego, co opublikowałeś do tej pory, ale czuć, że trochę brakuje. ;)

    Mi po szczegółowym przestudiowaniu tego przykładu udało się zorientować, co skopiować i ew. jak wyedytować, żeby zacząć od podstaw własny projekt, ale sumując to z przekopywaniem dokumentacji od ST zszedł mi na to wszystko cały dzień.

    PS.
    Kiedy ceny AVRów osiągnęły kosmiczne poziomy, to dziwiłem się, dlaczego hobbyści nie uciekli do ARMów. Teraz już wiem, dlaczego. :P
  • Computer ControlsComputer Controls
  • Poziom 38  
    Problemy biorą się stąd, że mało kto tak naprawdę wie jak przebiega cały proces kompilacji. Albo często po prostu wystarczy użyć googli, w końcu nie każdy musi to wiedzieć. Bo problemem widzę jest dodanie ścieżki wyszukiwania nagłówków, skompilowanych plików etc. Przecież jest makefile, z ładnym miejscem do wypełnienia na te ścieżki.

    Zajrzenie w skrypt linkera też nie boli. Nie trzeba być super znawcą żeby zauważyć jak są definiowane rozmiary pamięci oraz ich adresy.

    W startupie grzebać nie trzeba.

    Nie wspomnę już o tym, że dokumentację to chyba 5% osób na tym forum czytało.

    Z całym szacunkiem, ale dla mnie tutoriale Freddiego już są jak dla ociemniałych, ktoś kto korzysta z tych szablonów mógłby powiedzieć "dziękuję Kamilu" a nie mówić, że brakuje opisu jak machać diodą. Cały sęk tych artykułów chyba w tym, żeby dostarczyć template do pracy a potem to już hulaj dusza :) Bo ktoś zaraz napisze "Fajnie by było jakbyś wrzucił taki szablon z FreeRTOSem bo nie każdy wie jak go postawić, z komentarzem do każdej linijki żeby przechodzeń z ulicy nie używający nigdy uC mógł swobodnie korzystać z mutexów".

    Miniporadnikiem jak radzić sobie bez bibliotek jest chroniony w podziemnej krypcie rękopis RM0008. Informację o położeniu tejże krypty zna tylko magiczny rycerz gugl :)

    I nie żebym był złośliwy - ale trochę chęci i inicjatywy.
  • Specjalista - Mikrokontrolery
    Pituś Bajtuś napisał:
    Życie nie kończy się na STM32F1.

    Jeśli masz na myśli inne STM32, to nie pisałem o nich, bo ich nie znam jeszcze, ale nie sądzę aby nagle ST zaczęło robić układy które mają 10 wersji tablicy wektorów i 10 zupełnie różnych układów pamięci [;

    Cytat:
    Chociaż po głębszym przemyśleniu faktycznie problemu nie widzę.

    Znaczy się, że się zgadzamy, czy coś innego wydedukowałeś?

    gaskoin napisał:
    Freddie się pomylił bo te skrypt/startupy można użyć na wszystkich CM-3 i CM-0 (po drobnych modyfikacjach) być może i na CM-4 ale tego nie wiem.

    Hę? Generalnie akurat startup dla CM-0 musi być inny niż dla CM-3, dla CM-4 może być taki sam jak dla CM-3, nie wiem czy cokolwiek można tam poprawić w związku z kilkoma nowymi rozkazami, nie sądzę. Nie wiem czy nie zginęło Ci po prostu słówko "nie" <:

    McMonster napisał:
    Przydałby się trochę dokładniejszy opis do nich, a konkretniej krótkie wyjaśnienie przeznaczenia tych plików, które należy po prostu umieścić w projekcie przy tworzeniu własnego i ew. co w nich zmienić (np. rozmiary pamięci w skrypcie linkera), a które są częścią migania diodą.

    Wiadomo, że wiele rzeczy by się przydało, ale dzień ma wciąż tylko 24h <:

    McMonster napisał:
    W skrócie cieszę się z tego, co opublikowałeś do tej pory, ale czuć, że trochę brakuje.

    Bo w miarę jedzenia apetyt rośnie <;

    McMonster napisał:
    Kiedy ceny AVRów osiągnęły kosmiczne poziomy, to dziwiłem się, dlaczego hobbyści nie uciekli do ARMów. Teraz już wiem, dlaczego.

    Nie przesadzajmy, ja do wszystkiego jakoś doszedłem, więc to nie jest wiedza tajemna... Trzeba jednak trochę zaangażowania włożyć, bo nie ma samouczka na co drugiej stronie internetowej i w każdej gazecie...

    EDIT:
    gaskoin napisał:
    ktoś kto korzysta z tych szablonów mógłby powiedzieć "dziękuję Kamilu" a nie mówić, że brakuje opisu jak machać diodą

    Ujawniłeś właśnie tajne dane... (;

    4\/3!!
  • Poziom 32  
    gaskoin napisał:
    Problemy biorą się stąd, że mało kto tak naprawdę wie jak przebiega cały proces kompilacji. Albo często po prostu wystarczy użyć googli, w końcu nie każdy musi to wiedzieć. Bo problemem widzę jest dodanie ścieżki wyszukiwania nagłówków, skompilowanych plików etc. Przecież jest makefile, z ładnym miejscem do wypełnienia na te ścieżki.

    Zajrzenie w skrypt linkera też nie boli. Nie trzeba być super znawcą żeby zauważyć jak są definiowane rozmiary pamięci oraz ich adresy.

    W startupie grzebać nie trzeba.

    Nie wspomnę już o tym, że dokumentację to chyba 5% osób na tym forum czytało.

    Z całym szacunkiem, ale dla mnie tutoriale Freddiego już są jak dla ociemniałych, ktoś kto korzysta z tych szablonów mógłby powiedzieć "dziękuję Kamilu" a nie mówić, że brakuje opisu jak machać diodą. Cały sęk tych artykułów chyba w tym, żeby dostarczyć template do pracy a potem to już hulaj dusza :) Bo ktoś zaraz napisze "Fajnie by było jakbyś wrzucił taki szablon z FreeRTOSem bo nie każdy wie jak go postawić, z komentarzem do każdej linijki żeby przechodzeń z ulicy nie używający nigdy uC mógł swobodnie korzystać z mutexów".

    Miniporadnikiem jak radzić sobie bez bibliotek jest chroniony w podziemnej krypcie rękopis RM0008. Informację o położeniu tejże krypty zna tylko magiczny rycerz gugl :)

    I nie żebym był złośliwy - ale trochę chęci i inicjatywy.


    W sumie się z powyższym zgadzam. Moje uwagi do przykładów i poradnika wzięły się właśnie z tego, że dzisiejszy dzień poświęciłem na odnalezienie tych informacji i sprawdzenie działania i/lub przeznaczenia niektórych plików z przykładu. Nie kryje się za nimi wiele więcej, niż sugestie dalszego ulepszania tych opisów, które już są. No i sam autor zachęca do komentowania w ostatnim zdaniu poradnika.

    Wybrałem po prostu to, czego najdłużej się naszukałem. Wbrew pozorom nawet znalezienie RM0008 nie jest takie proste, jeśli się nie wie, czego szukać, AVR ma wszystko w każdym datasheecie. ;)

    Freddie Chopin napisał:

    gaskoin napisał:
    Freddie się pomylił bo te skrypt/startupy można użyć na wszystkich CM-3 i CM-0 (po drobnych modyfikacjach) być może i na CM-4 ale tego nie wiem.

    Hę? Generalnie akurat startup dla CM-0 musi być inny niż dla CM-3, dla CM-4 może być taki sam jak dla CM-3, nie wiem czy cokolwiek można tam poprawić w związku z kilkoma nowymi rozkazami, nie sądzę. Nie wiem czy nie zginęło Ci po prostu słówko "nie" <:


    A to sobie chyba z ciekawości sprawdzę, mam płytkę Discovery dla F4 (i osobnego JTAGa).

    Cytat:
    McMonster napisał:
    Przydałby się trochę dokładniejszy opis do nich, a konkretniej krótkie wyjaśnienie przeznaczenia tych plików, które należy po prostu umieścić w projekcie przy tworzeniu własnego i ew. co w nich zmienić (np. rozmiary pamięci w skrypcie linkera), a które są częścią migania diodą.

    Wiadomo, że wiele rzeczy by się przydało, ale dzień ma wciąż tylko 24h <:


    Doskonale znam ten problem. Ale jakbyś znalazł chwilę, to się nie krępuj. :>

    Cytat:

    (...)
    McMonster napisał:
    Kiedy ceny AVRów osiągnęły kosmiczne poziomy, to dziwiłem się, dlaczego hobbyści nie uciekli do ARMów. Teraz już wiem, dlaczego.

    Nie przesadzajmy, ja do wszystkiego jakoś doszedłem, więc to nie jest wiedza tajemna... Trzeba jednak trochę zaangażowania włożyć, bo nie ma samouczka na co drugiej stronie internetowej i w każdej gazecie...
    (...)


    To był po trochę żart, ale jak się tak zastanowić... W sumie to stworzyłeś chyba jedyny (pomijam wszystko opierające się w pełni na komercyjnych środowiskach) użyteczny i kompletny ciąg poradników do rozpoczęcia z ARMem, podczas gdy do AVR są ich miliony i to nie wspominając nawet o całym Arduino. Wiedza tajemna to faktycznie nie jest, ale ilu "afałerowiców" słyszało np. o Makefile? Mnie ratuje wcześniejsza wiedza z programowania aplikacji pecetowych, ale dla większości to czarna magia jednak jest. Większość jednak woli mieć wszystko na tacy.

    Na koniec to zapomniałem tylko o "dziękuję Kamilu". Więc dziękuję Kamilu. :P
  • Poziom 11  
    Na początku podziękuję za dobry tutorial. A teraz mam prośbę. Próbowałem odpalić przykład z biblioteki STM32_USB-FS-Device_Lib_V3.3.0 (Virtual_COM_Port). Po pewnych bojach udaje mi się wszystko skompilować, natomiast po uruchomieniu program staje w nieskończonej pętli w funkcji static void __Default_Handler(void) z pliku vector.c.

    Czyli w tym pliku brakuje odpowiednich wektorów przerwać od USB?
    Skąd wytrzasnąć odpowiednią tablicę wektorów przerwań, lub jak ją zmodyfikować?
  • Specjalista - Mikrokontrolery
    Przydałoby się więcej szczegółów... No i upewnij się, że po drugim odpaleniu debuggowania (może być bez programowania) problem występuje nadal - czasem za pierwszym razem się sypie (wiem czemu, ale trochę długo by to opisywać [; ).

    4\/3!!
  • Poziom 26  
    NSCNT sprawdź czy masz dobry wektor przerwania w swoim programie w pliku main.c (czy nazwa jest zgodna z tym co znajdziesz w pliku vectors.c) tam raczej jest błąd.
  • Poziom 11  
    @Freddie: problem występował nadal, przy kolejnych próbach debugowania.
    @Krauser: faktycznie przerwanie nazywało się USB_LP_CAN1_RX0_IRQHandler, i USB_LP_CAN_RX0_IRQHandler w pliku vector.c Dopisałem 1 w pliku vector.c i coś ruszyło - PC rozpoznał wirtualny COM.

    Natomiast teraz (w mniej więcej losowych momentach - przeważnie niedługo po inicjalizacji USB) program utyka w HardFault_Handler(void).

    Jakieś pomysły co może być źle?
  • Poziom 11  
    Dzięki za pomoc. No to pięknie... Znalezienie błędu tego typu w tym kilkudziesięcioplikowym projekcie wydaje się nie do zrobienia w rozsądnym czasie... Ta biblioteka jest nieludzka, żeby odpalenie byle przykładu wymagało takich machinacji...

    Czy ma ktoś może zrobioną obsługę USB w projekcie, który da się odpalić w Eclipsie jakoś po ludzku?
  • Poziom 38  
    Jak znajdę czas to wrzucę w osobnym temacie :)
  • Specjalista - Mikrokontrolery
    No a może tam jest więcej przerwań ze złymi nazwami? Sprawdź co wywołuje HardFaulta, potem obsłuż to przerwanie i jeśli będzie to zapis pod nieistniejący adres, to można zrobić breakpointa na zapis pod adres.

    4\/3!!
  • Poziom 11  
    Elektronika to jest jednak działo szatana ;]

    Okazuje się, że program nie łapie HardFaulta, tylko po bardzo specyficznej sekwencji działania:
    gdy zmienię plik vector.c tak żeby nazwa przerwania była niewłaściwa, skompiluję, wgram do procka, następnie poprawię plik vector.c, skompiluję, i wgram i uruchomię - jest OK.

    Jeśli zresetuję - już nie śmiga, jeśli wgram na nowo (to samo) - też nie. Jeśli powtórzę magiczną sekwencję powyżej - działa.

    Nie ogarniam. Odnoszę wrażenie, że w tym układzie siedzą krasnoludki i sobie ze mnie jaja robią ;]
  • Specjalista - Mikrokontrolery
    Popatrz co ciekawego można przeczytać w skrypcie linkera

    Code:

    /*
    +=============================================================================+
    | stacks sizes
    +=============================================================================+
    */

    /* Handler mode (core exceptions / interrupts) can use only main stack */
    /* Thread mode can use main stack (default) or process stack - selected in CONTROL special register */

    __main_stack_size = 0;
    __process_stack_size = 1024;

    PROVIDE(__main_stack_size = __main_stack_size);
    PROVIDE(__process_stack_size = __process_stack_size);


    4\/3!!
  • Poziom 38  
    NSCNT napisał:
    Nie ogarniam. Odnoszę wrażenie, że w tym układzie siedzą krasnoludki i sobie ze mnie jaja robią ;]


    Po części masz rację, niżej w pliku, który przytoczył Freddie można właśnie je znaleźć:

    Code:
       /* DWARF debug sections.
    
       * Symbols in the DWARF debugging sections are relative to the beginning
       * of the section so we begin them at 0. */
       /* DWARF 1 */
       .debug            0 : { *(.debug) }
       .line            0 : { *(.line) }
       /* GNU DWARF 1 extensions */
       .debug_srcinfo      0 : { *(.debug_srcinfo) }
       .debug_sfnames      0 : { *(.debug_sfnames) }
       /* DWARF 1.1 and DWARF 2 */
       .debug_aranges      0 : { *(.debug_aranges) }
       .debug_pubnames      0 : { *(.debug_pubnames) }
       /* DWARF 2 */
       .debug_info         0 : { *(.debug_info .gnu.linkonce.wi.*) }
       .debug_abbrev      0 : { *(.debug_abbrev) }
       .debug_line         0 : { *(.debug_line) }
       .debug_frame      0 : { *(.debug_frame) }
       .debug_str         0 : { *(.debug_str) }
       .debug_loc         0 : { *(.debug_loc) }
       .debug_macinfo      0 : { *(.debug_macinfo) }
       /* SGI/MIPS DWARF 2 extensions */
       .debug_weaknames   0 : { *(.debug_weaknames) }
       .debug_funcnames   0 : { *(.debug_funcnames) }
       .debug_typenames   0 : { *(.debug_typenames) }
       .debug_varnames      0 : { *(.debug_varnames) }
  • Poziom 11  
    Dzięki za chęć pomocy mi, ale chyba nie jestem w stanie tego ogarnąć.

    Pozostaje mi liczyć, że kolega Gaskoin znajdzie czas na wrzucenie projektu, albo powrót do Atmeli.
  • Specjalista - Mikrokontrolery
    NSCNT napisał:
    Dzięki za chęć pomocy mi, ale chyba nie jestem w stanie tego ogarnąć.


    No ale czego? Jak mają Ci działać przerwania, skoro rozmiar stosu dla nich wynosi 0 bajtów? Tu nie ma co ogarniać tylko trzeba przeczytać ze zrozumieniem komentarze.

    4\/3!!
  • Poziom 11  
    No jasne, że tak. Od razu zmieniłem rozmiar stosu.

    Niestety dalej miałem hardfault\system nie rozpoznał urządzenia.
    Próbowałem podmieniać jeszcze skrypty linkera na te od ST i nie podołałem.

    Zmiana rozmiaru stosu powinna wystarczyć? To jeszcze jutro popróbuję to ruszyć.

    EDIT:
    OK, jednak działa. Wiara w elektronikę przywrócona. Czy w eclipsie jest jakiś sposób na wymuszenie zapisywania edytowanych plików przed kompilacją? Prawdopodobnie to kosztowało mnie kilka ładnych zmarnowanych godzin i trochę frustracji.

    Trochę mogę też zwalić na zworkę w makiecie :]
  • Specjalista - Mikrokontrolery
    NSCNT napisał:
    Zmiana rozmiaru stosu powinna wystarczyć?

    To jeszcze zależy na jaką wartość zmieniłeś, bo może jest zbyt mało. <;
    NSCNT napisał:
    Czy w eclipsie jest jakiś sposób na wymuszenie zapisywania edytowanych plików przed kompilacją?

    Jest to gdzieś w opcjach, pozatym dobrze zapamiętać skrót Ctrl+Shift+S (save all) oraz Ctrl+B (build all).

    4\/3!!
  • Poziom 28  
    NSCNT napisał:
    Czy w eclipsie jest jakiś sposób na wymuszenie zapisywania edytowanych plików przed kompilacją?


    Preferences -> General -> Workspace -> "Save automatically before build".