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

FreeRTOS demo na STM32L-Discovery

Tytus Kosiarski 15 Lis 2015 09:53 6087 7
  • FreeRTOS demo na STM32L-Discovery


    Witam wszystkich

    Tym razem lekki projekt, który w moim zamyśle ma być wstępem do zapoznania się z FreeRTOS-em oraz późniejszego, poważniejszego zajęcia się nim. Projekt ten, to demo chodzące pod kontrolą systemu operacyjnego FreeRTOS v7.3.0 dostosowanego do mikrokontrolera STM32L152, które wykorzystuje elementy sterująco-wizualizujące zainstalowane na płytce STM32L-Discovery do prezentacji swojego działania.

    Działanie programu demonstracyjnego po uprzednim skonfigurowaniu potrzebnych peryferiali:
    - miganie niebieskim LED-em z częstotliwością 0.5Hz,
    - prezentacja na LCD wartości licznika zwiększanego niebieskim przyciskiem USER oraz odpowiednie sterowanie zielonym LED-em (LED świeci, gdy nieparzysta wartość licznika, LED zgaszony w przeciwnym razie),
    - odpowiednie sterowanie bargrafem na LCD w reakcji na dotyk panela dotykowego (zapalenie dolnego paska, gdy dotknięte lewe skrajne pole panela; zapalenie wszystkich pasków, gdy dotknięte skrajne prawe pole panela; stany pośrednie są również wykrywane i prezentowane; przesuwanie palcem po panelu powoduje płynny wzrost lub spadek słupka bargrafu).

    Stosy dla tasków tworzone są w 5kB obszarze heap pamięci RAM przy wykorzystaniu funkcji z pliku heap_3.c. Ponadto potrzebny jest 512B stos dla całego programu.

    Program wykorzystuje biblioteki: SPL, Touch Sensing Driver oraz pliki stm32l_discovery_lcd.c i h firmy STMicroelectronics, które były dołączone do materiałów, które dostałem na szkoleniu z tego mikrokontrolera.

    Paczkę z FreeRTOS-em pobrałem w postaci pliku FreeRTOS v7.3.0 port.zip ze strony http://interactive.freertos.org/entries/22640...RTOS-v7-3-0-CrossWorks-v2-3-STM32F4-discovery

    Przy pisaniu programu, bardzo pomocnym dla mnie źródłem wiedzy, oprócz przykładów dołączonych do paczki z FreeRTOS-em (stamtąd pochodzi też część komentarzy w j. angielskim w moim programie), był PDF z materiałów do ćwiczeń z Techniki Mikroprocesorowej na Wydziale EAIiE Akademii Górniczo Hutniczej dostępny tutaj: http://student.agh.edu.pl/~franczyk/mikro/lab10/TuP10_1011L.pdf

    Program napisałem w IDE Rowley Crossworks ver. 2.1.0. Do skompilowania potrzebna jest paczka STMicroelectronics STM32 CPU Support Package w wersji 2.27, do pobrania z www.rowley.co.uk

    Pozdrawiam, KT



    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz pendrive 32GB.
  • CControls
  • #2 15 Lis 2015 11:50
    323493
    Użytkownik usunął konto  
  • CControls
  • #3 15 Lis 2015 12:37
    pheonix
    Poziom 13  

    Mictronic napisał:
    Moglby kolega przedstawic przykladowe zalety stosowania systemu na mikromotrolerze? Co to praktycznie daje by zachecic niskopoziomowcow do stosowania takich rozwiazan.


    Proszę :
    Link

  • #4 15 Lis 2015 13:20
    Tytus Kosiarski
    Poziom 14  

    Pierwszą rzeczą, jaka mi się pozytywnie rzuciła w oczy, to brak konieczności stosowania debouncingu dla przycisku, co widać w ciele funkcji increment_from_interrupt_PA0 (main.c) oraz funkcji EXTI0_IRQHandler (ISR.c).
    W procedurze obsługi przerwania od przycisku EXTI0_IRQHandler następuje odblokowanie semafora, pozwalając na wykonanie funkcji increment_from_interrupt_PA0. Natomiast funkcja increment_from_interrupt_PA0 ponownie blokuje semafor i zwiększa wartość zmiennej o 1. W efekcie każdorazowe naciskanie przycisku powoduje jednokrotne wykonanie funkcji increment_from_interrupt_PA0.

    Drugą rzeczą jest widoczna tutaj niezależność czasowa wykonywania zadań przez RTOS. Czas wykonania jednego zadania nie wpływa na moment rozpoczęcia i czas wykonania następnego zadania. Pisząc program na piechotę, trzeba by nad tym posiedzieć, by uzyskać taki efekt.

    Następną rzeczą (bardziej wrażeniem) jest bardziej uporządkowany, czytelniejszy kod.

    Natomiast wadą według mnie jest duża zajętość pamięci, jak na taki prosty programik. Można oczywiście optymalizować zajętość pamięci (użyłem domyślnych wartości), niemniej jednak jest to bardzo widoczne.

  • #5 15 Lis 2015 21:24
    tadzik85
    Poziom 38  

    Mictronic napisał:
    Moglby kolega przedstawic przykladowe zalety stosowania systemu na mikromotrolerze? Co to praktycznie daje by zachecic niskopoziomowcow do stosowania takich rozwiazan.


    źle zadanie pytanie, niskopoziomowiec a zastosowanie RTOSa to lekko odmienne kwestie.

    Szkoda tylko ze ten przykład napisano w egzotycznym środowisku i nadal z SPLem.

    Czyszczenie flagi NVICa w przerwaniu, po co?

  • #6 16 Lis 2015 19:40
    leonow32

    Poziom 30  

    Ma to bardzo dużo zalet. Kiedyś robiłem dość zaawansowany układ pomiarowy i synchronizacja zadań była elementem kluczowym w projekcie. Dla utrudnienia - niektóre zadania wykonywały się regularnie co jakiś czas, inne tylko w pewnych warunkach, niektóre na życzenie użytkownika, a były też takie zadania, które uruchamiały szereg kolejnych i czekały, aż tamte zwrócą jakieś dane. Niesamowicie wygodna okazała się możliwość podzielenia projektu na poszczególne części i łatwość w ich debugowaniu. Bez systemu operacyjnego byłoby to wyważanie otwartych drzwi. Może i cały program zajmował więcej niż bez RTOS, ale i tak w procesorze zostało mi 20kB wolnej pamięci :)

  • #7 16 Lis 2015 19:46
    tadzik85
    Poziom 38  

    leonow32 napisał:
    Ma to bardzo dużo zalet. Kiedyś robiłem dość zaawansowany układ pomiarowy i synchronizacja zadań była elementem kluczowym w projekcie. Dla utrudnienia - niektóre zadania wykonywały się regularnie co jakiś czas, inne tylko w pewnych warunkach, niektóre na życzenie użytkownika, a były też takie zadania, które uruchamiały szereg kolejnych i czekały, aż tamte zwrócą jakieś dane. Niesamowicie wygodna okazała się możliwość podzielenia projektu na poszczególne części i łatwość w ich debugowaniu. Bez systemu operacyjnego byłoby to wyważanie otwartych drzwi. Może i cały program zajmował więcej niż bez RTOS, ale i tak w procesorze zostało mi 20kB wolnej pamięci :)


    To wstęp do uzasadnienia RTOS, gdy program jest tak naprawdę dwoma w jednym.

    Widzę minusy mi się sypią, dziękuje uprzejmie. Człowiek o pewnej ilości szarych komórek docenia konstruktywną krytyką. Tyle podsumowaniem.

  • #8 22 Lis 2015 21:14
    Tytus Kosiarski
    Poziom 14  

    Witam ponownie

    Przeportowałem projekt dema na (może mniej egzotyczne) IDE Keil uVision 5. Port ten da się też skompilować i uruchomić w demonstracyjnej wersji Keila z ograniczeniem do 32kB kodu. Trochę to trwało, gdyż port nie ograniczył się tylko do utworzenia nowego projektu w Keilu, skopiowania plików źródłowych, skompilowania projektu i wgrania kodu wynikowego do mikrokontrolera, ale... No właśnie, gdy doprowadziłem już projekt do etapu, gdy kompilował się bez błędów i ostrzeżeń oraz uporałem się z nastawami debuggera, to próba wgrania kodu wynikowego do mikrokontrolera na PCB i uruchomienia go, nie dawała oczekiwanego rezultatu.
    Pierwszym objawem był kompletny brak reakcji na wgrany kod. Próba manewru rozmiarami heapu i stacka - bez efektu. Próba debugu - program w ogóle nie wchodził do funkcji main(), tylko po wykonaniu Keilowego startupa "szedł w maliny". Znalazłem na stronie Keila ( http://www.keil.com/support/docs/3614.htm ) opis tego problemu wraz z ilustracjami identycznego, jak u mnie, objawu. Po dograniu pliku retarget.c do projektu i odpowiedniej jego edycji (jak opisano w 1. sposobie tego opisu), program zaczął się prawie dobrze wykonywać. Prawie, bo wystąpił drugi problem, który objawiał się brakiem przełączania tasków przez planistę FreeRTOS-a (wykonywał się ciągle tylko jeden task). Przyczyną tego była błędna moja wcześniejsza modyfikacja funkcji xPortSysTickHandler w pliku port.c (z podkatalogu RVDS, dostosowanego do Keila). Problem ustąpił po poprawnej modyfikacji tego pliku: w wierszu 419 zakomentowałem wywołanie funkcji xTaskIncrementTick() (w używanej przeze mnie wersji FreeRTOs-a nie zaimplementowano tej funkcji - błąd linkera "Undefined symbol xTaskIncrementTick"). Zamiast tego dopisałem w wierszu 421 wywołanie funkcji vTaskIncrementTick(), gdyż nie było problemów z kompilacją tegoż w Keilu, a działa dobrze w tym IDE, jak i w CrossWorksie (GCC).

    Potem wystąpił jeszcze jeden problem, który powodował wyświetlanie zbędnych segmentów na 5. i 6. znaku LCD. Wizualnie wyglądało to jak "krzaki". Nawet wpisywanie spacji na te pozycje nie powodowało wygaszenia tych segmentów. Okazało się, że po kilkukrotnej zmianie wysokości słupka bargrafu, zbędne segmenty na tych pozycjach wygaszały się. Przyczyną takiego zachowania był brak kwalifikatora static przed deklaracją tablicy bar w tasku display_bars w pliku main.c. Po poprawieniu cały program zaczął chodzić, jak należy. Co ciekawe, projekt w CrossWorksie chodzi jednakowo dobrze zarówno przy obecności kwalifikatora static przy deklaracji tej tablicy, jak i przy braku tegoż.

    Do kolegi tadzik85 - rzeczywiście, zbędne jest kasowanie flagi EXTI w NVIC. Usunąłem i program też dobrze chodzi.

    Pozdrawiam.