Programowanie ARM, nauka, środowiska programistyczne IDE

[SQ8MVY]

Witam.....

wszystkich zapaleńców programujących, chcących rozwijać umiejętności programowania, całkowicie początkujących..........

Od jakiegoś czasu prowadzimy z Adamem SP5FCS intensywną dyskusję na temat zebrania grupy zapaleńców, którzy chcą zacząć zabawę w programowanie procesorów ARM z rodziny M (0....7). Mile widziani są Ci co dopiero chcą wkroczyć w świat ARM-ów, jak i Ci, którzy mają już jakieś doświadczenie....

Wiadomo, w grupie postępy w nauce są dużo szybsze niż w pojedynkę....

Środowisko IDE........

Tu jest i chyba zawsze będzie problem. Dlaczego ? Każdy ma jakieś swoje ulubione. Niestety, ale wiele osób pracuje na Linuksie, w tym ja, Mac, a jeszcze więcej na Windowsie.

Aby grupa jakoś się rozwijała trzeba wybrać wspólne środowisko IDE, które będzie dostępne pod wszystkie wymienione systemy, a co najważniejsze - będzie darmowe do celów hobbystycznych bez ograniczenia długości kodu.
Nie jest tych środowisk wiele, które mają wersją pod różne systemy.

Jednym z nich jest OpenSTM - potocznie nazwane AC6. Jest wersja Windowsowa jak i Linuks-owa. Jest to środowisko wydane przez STM, przeznaczone do pracy z mikrokontrolerami od STM-a. Oparte jest na Eclipse - wydanie Luna. Nie stoi nic na przeciwko, aby zintegrować środowisko STM-a z najnowszą wersją Eclips-a poprzez pluginy, które również są udostępnione przez STM. Eclipse natomiast napisany jest w Javie. Nie posiada ograniczenia długości kodu.

Kolejnym środowiskiem jest środowisko od Seggera. Chyba wielu z Was, firma Segger kojarzy się z doskonałymi programatorami J-Link. Fakt, J-Link jest drogi niesamowicie, ale wersja z licencją do zastosowania hobbystycznego już dostępna jest za około 220 zł - J-Link EDU. Nie jest to żadna reklama. Srodowisko nazywa się Segger Embedded Studio. Dla zastosowań hobbystycznych jest całkowicie darmowe. Nie posiada ograniczenia długości kodu. Dostępna jest pod 3 systemy operacyjne Windows, Linuks, Mac. Wspiera wiele mikrokontrolerów od STM, NXP, Freescale, Silicon Labs, Texas Instruments. Współpracuje oczywiście z ich autorskim J-Linkiem

Kinetis Design Studio - od NXP. Dostępne również pod 3 systemy Windows, Linux, Mac. Wspiera mikrokontrolery od NXP. Jest oczywiście w pełni darmowy, bez ograniczenia długości kodu. Co do programatora - nie mam pojęcia jaki jest obsługiwany, bo nie miałem przyjemności się nim bawić. Oparty również jest, tak jak AC6 od STM-a, na Eclipse Luna.

Attolic Studio, podają, że jeszcze w tym roku ma wyjść również wersja pod Linuksa oraz MAC.

Nie przedstawiłem tu pozostałych środowisk, które są w wersjach tylko pod Windows-a.

Osobiście mam styczność z AC6 - od STM-a, oraz ostatnio, dzięki informacji od Adama SP5FCS, z Segger Embedded Studio.
IDE Seggera jest dużo szybsze od AC6 STM-a. Nie mam tu na myśli czasu kompilowania programu, tylko szybkość pracy samego środowiska - edytora.

Sam osobiście skłaniał bym się w stronę środowiska Seggera. Co do programatora - nie trzeba kupować go od razu. Jest możliwość przeflaszować programator ST-Link na J-Link-a. Postanowienia licencji jasno mówią, że można to zrobić z ST-Link-ami wbudowanymi w płytki rozwojowe (Nucleo, Discovery). Taki przerobiony ST-Link na J-Link-a obsługuje TYLKO mikrokontrolery od STM-a. Należy o tym pamiętać.

Kwestię środowisk jakoś troszkę jest przedstawiona, teraz jaki hardware..... ?

Stawiał bym na STM-a. Jest tego dużo do wyboru - do koloru w przyzwoitych cenach. Od prostych płytek Nucleo, poprzez bardziej rozbudowane Discovery, aż do zestawów uruchomieniowych np. od WaveShare z serii Open429I-C, Open 7xxI-C.

Tylko, czy są/będą chętni ? Odzew mile widziany.....

[SP5FCS]

1/ Środowisko
Jakiś czas temu Piotr SP9FKP polecił mi IDE EM_blocks pod Windows na którym zacząłem pierwsze próby z modułem Discovery STM32F407. Jedną z zalet tego środowiska jest łatwy import projektów z innych środowisk. Niestety nie pracowałem w innych środowiskach i trudno mi je porównywać. W środowisku dla mnie najistotniejsza jest prostota instalacji i konfiguracji, to aby środowisko się rozwijało pod nowe procesory i aby poprawnie współpracowało z programatorem, debuggerem. Propozycja Seggera jest bardzo ciekawa chociaż pozostaje obawa jak długo będzie dostępna darmowa wersja EDU.

2/ Procesor
Zdecydowanie popieram wybór procesorów STM ze względu na ich dużą popularność, dostępność tanich modułów startowych i dostępność wielu projektów z kodem źródłowym. Szczególnie interesujące są procesory STM32F429 oraz STM32F746 posiadające wbudowane sterowniki matrycy wyświetlacza TFT.

3/Moduł startowy
Najtaniej i najłatwiej jest zacząć od jakiegoś modułu z procesorem i programatorem ST-link
np. STM32F429-dicovery
Przy minimalnych nakładach mamy gotowy sterownik z wyświetlaczem do prób i nauki oprogramowania. Wadą modułów discovery jest zablokowanie części pinów procesora poprzez akcesoria umieszczone na module. Czasem konieczne jest wylutowanie zbędnego "balastu".
Ciekawym rozwiązaniem są moduły Core429. Moduł posiada tylko procesor, pamięć SDRAM, port USB i złącze do programatora. Zaletą takiego modułu jest to, że możemy go przekładać pomiędzy różnymi płytami bazowymi. wadą jest oczywiście większy koszt początkowy, ponieważ do pracy powinniśmy dokupić moduł bazowy i programator.

4/ Biblioteki
Dla mnie ten temat jest najtrudniejszy do ogarnięcia. W moich projektach wszytko pisałem sam od podstaw bez korzystania z "gotowców" (oprócz funkcji języka C). A tu jakieś CMSIS, SPL-e, HAL-e, libopencm3, itd. ,chyba łatwiej nauczyć się assemblera STM-a niż ogarnąć te tysiące zmiennych i funkcji. Wiem, że początki są trudne i dobrze jest korzystać z gotowych funkcji ale niektóre proste funkcje są "mocno zakręcone". Nie mogę pojąć po co mi funkcja ustawiania pinu na porcie kiedy mogę to zrobić prostym makrem ?

Fajnie byłoby rozwinąć na naszym forum szerszą dyskusję na ten temat, wymienić się własnymi doświadczeniami a być może również zrobić wspólnie jakiś ciekawy projekt.

[SP4EJT]

Nareszcie ktoś się za to wziął
Inicjatywę popieram jak również słowa Adama o bibliotekach ... o tym żeby wcale ich nie używać lub w najmniejszym możliwym/koniecznym stopniu. Mam niewielkie doświadczenie w tym i chciałbym pociągnać dalej myśl Adama bo uważam że to najważniejszy aspekt całego przedsięwzięcia. Jaki program i na jakim systemie operacyjnym to będzie hulało to sprawa drugorzędna.
Sam używam bibliotek bo po prostu uczyłem się ze źródła wiedzy "skażonego" przez autora bibliotekami ( kupiłem kiedyś zestaw uruchomieniowy i książkę dedykowana do tego zestawu ... wraz ze spora kolekcją przykładów ).
Zauważyłem jednak to co Adam. Funkcje w bibliotekach są podobno po to żeby pomóc. Ale "rozkminiając" jak działają te funkcje to włos się jeży.
Ten sam skutek można osiągnąć na dwa sposoby:
1. poprzez zmianę wartości jednego rejestru ... czyli jedna linijka kodu w C lub ASM
lub
2. wypełnić/zmienić wartości w funkcji biblioteki zajmującej często po 5, 6, 7, nieraz więcej linijek i potem wywołać tę funkcję ... to dodatkowa linijka kodu.
Ciągle w tym co robię też mam "bibliotekowe kody" ale to co mnie najbardziej drażniło pozamieniałem już na ludzki kod.
O ile nic nie pokręciłem przedstawia sie to tak - jeden i drugi kod robi to samo (to ze starego przykładu i może być niewielka różnica ale nie o to chodzi tylko o to aby naświetlić wam jaka jest różnica w kodzie "bibliotecznym" i "normalnym" ).
przykład bibliotekowy :

Kod:

SPI_InitTypeDef   SPI_InitStructure;

  SPI_InitStructure.SPI_Mode = SPI_Mode_Master;                      //tryb pracy SPI
    SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;         //transmisja z wykorzystaniem jednej linii, transmisja jednokierunkowa
  SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;                //16-bit ramka danych
  SPI_InitStructure.SPI_CPOL = SPI_CPOL_Low;                        //stan sygnalu taktujacego przy braku transmisji - niski
  SPI_InitStructure.SPI_CPHA = SPI_CPHA_1Edge;                      //aktywne zbocze sygnalu taktujacego - 1-sze zbocze
  SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;                         //sprzetowa obsluga linii NSS (CS)
  SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_32;//prescaler szybkosci tansmisji  36MHz/256=140.625kHz
  SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;                //pierwszy bit w danych najbardziej znaczacy
  SPI_Init(SPI2, &SPI_InitStructure);                               //inicjalizacja SPI                              

  SPI_Cmd(SPI2, ENABLE);      // Wlacz SPI

przykład normalny

Kod:

SPI2->CR1  =  SPI_CR1_MSTR | SPI_CR1_BR_0 | SPI_CR1_SSM | SPI_CR1_SSI;
SPI2->CR1 |= SPI_CR1_SPE;

Tak więc jeśli "nauczyciel" poprowadzi Nas za ręke bez bibliotek to będzie mógł być dumny ze swoich wysiłków a my będziemy szczęśliwi że mamy ludzko przedstawiona wiedzę ... no i takiego nauczyciela oczywiscie
Z niecierpliwością czekam na rozwój sytuacji.

[SP9FKP]

Jak dla mnie czytelność kodu zwycięża (przykład 1). W zasadzie komentarz z boku nie jest potrzebny bo kod sam się dokumentuje. Jeśli do tego dodać autouzupełnianie, to nie jest to takie straszne. Kwestią zasadniczą jest jakość kompilatora czyli jak ten kod rozwinie w instrukcje asemblerowe. Nie czuje się kompetentny by to rozstrzygać ale czasem warto popatrzeć jak to robi kompilator i co można zmienić.

[SP5FCS]

Stosowanie gotowych funkcji typu SPL czy HAL przy inicjowanie zasobów procesora nie jest aż tak dużym błędem, kod jest czytelny a proces inicjowania wykonuje się najczęściej raz co ma niewielki wpływ na funkcjonowanie całego urządzenia. Niestety kod programu szybko rośnie.

Dramat z tymi funkcjami zaczyna się w wątkach które są bardzo często obsługiwane (przerwania, obsługa ADC, UART, SPI, I2C, TFT, sterownie pinami). Samo wywołanie funkcji, przekazanie parametru a na koniec powrót do miejsca wywołania pochłania kilkanaście razy więcej czasu procesora niż właściwa operacja na rejestrze (np. ustawianie pinu na porcie). Generalnie często wykonywane fragmenty programu należałoby pisać jako funkcje inline, działać bezpośrednio na rejestrach lub robić wstawki w assemblerze. Wszelkie nadmiary kodu ładnie widać na rozwinięciach kodu asm.

[SP9FKP]

I tu pełna zgoda, optymalizacja kompilatora a napisanie krytycznych fragmentów kodu w czystym asemblerze to dwie rożne kwestie. To już jest wyższa szkoła jazdy wymagająca sporej wiedzy i doświadczenia.
Wracając do tematu: optuję za płytką STM32F429DISCO ze względu na przystępną cenę, wbudowany programator, mały ale czytelny wyświetlacz LCD z TP i duża pamięć SDRAM do kontrolera wyświetlacza. W sieci jest sporo przykładów z użyciem tego modułu więc jest co ćwiczyć i wiele kodu da się wykorzystać. W szczególności ten projekt mógłby posłużyć jako baza ćwiczebna bowiem nawet w razie porzucenia nauki, da się wykorzystać zakupiony moduł w naszym hobby (np. podłączając go do pośredniej 465 kHz).

[SQ6DGT]

Witam,

to jest mój pierwszy post na forum, choć jestem biernym użytkownikiem już od dłuższego czasu :-)

Od jakiegoś czasu bawię się w projekty na ARM Cortex-M3 i w tej chwili pracuję pod Eclipse (wersja Mars zdaje się aktualnie), mam doinstalowany plugin GNU Arm Eclipse, toolchain z GNU ARM Embedded Toolchain + OpenOCD. Przy tworzeniu nowego projektu generuje mi poprawny szkielet programu ze zintegrowaną SPL. Sprzęt do programowania jaki używam w tej chwili to STLink/V2 poprzednio generyczny programator na chipsecie FTDI (firmy KrisTech). Wszystko działa łącznie z debugowaniem i semihostingiem, można też łatwo przełączyć między debugowaniem w RAM i we Flash co się czasem przydaje. W tej chwili wydaje mi się to najbardziej wygodne ale zastanawiam się nad zakupem J-Linka EDU i pracą pod SES.

Jako, że pracuję na Mac-u miałem ograniczone możliwości jeśli chodzi o software, choć z roku na rok jest lepiej. Poprzednio używałem Ride7(Win) razem z STM Primer, następnie CrossWorks (byłem całkiem zadowolony), potem generyczny projekt z makefile a jako edytora używałem QtCreator, był to całkiem fajny set-up. Ostatecznie jednak zostałem przy Eclipse, ma dobry edytor, czasem nawet działa refactoring nazw symboli :-) i do tego jak robię coś na AVR-ach to nie muszę się przestawiać bo do nich też mam plugin pod Eclipse. Co do sprzętu to teraz używam takich tanich modułów z STM32F103C8T6, kosztują na A... 23zł, mają wygodne wyprowadzenia i jak na razie dają pełną satysfakcję.

Czy ktoś ma może doświadczenia z SES (Segger Embedded Studio) ? działa tam przyzwoicie refactoring nazw np. funkcji, tak, że jak zmienię nazwę to wszystkie użycia w projekcie zostaną zaktualizowane ?

Interesująca jest też dyskusja nt. SPL/HAL vs bezpośrednia praca z rejestrami MCU i ewentualnie CMSIS tylko. Sam się nad tym zastanawiam, z jednej strony czasem czytelniej jest poustawiać porty i komponenty MCU za pomocą SPL, z drugiej strony SPL/HAL trzeba się też nauczyć i może lepiej od razu nauczyć się korzystać bezpośrednio ze sprzętu, który nie będzie się zmieniał tak często jak biblioteki. Czy ktoś przesiadał się z SPL na HAL ?

Pozdrawiam

[SQ8MVY]

Witam,

Jeżeli kolega pracował pod CrossWorks ARM i byłeś zadowolony, to z SES również. Będziesz w takim samym stopniu zadowolony. SES w całości to jest CrossWorks, tyle że okrojony z obsługi wielu programatorów. Obsługuje jedynie J-Linka i Symulator programowy ARM. Również posiada mniej paczek umożliwiających zbudowanie szkieletu projektu dla dedykowanego modelu mikrokontrolera. Debugger oczywiście jest pełny i działa wyśmienicie.

Jeśli masz ST-Linka to łatwo możesz go przerobić na J-Linka. Tylko pamiętaj, że licencja mówi, że przeflashowaniu mogą być poddane ST-Linki, które są zintegrowane na pcb zestawów uruchomieniowych.

W przygotowaniu jest mały dodatek do SES-a, tylko czasu ciągle brakuje...

[SP9FKP]

Witam Robert i cieszę się, że dołączyłeś do grona autorów tego Forum. Nie chcę domyślać się co Cię skłoniło by napisać w tym wątku, bowiem sądzę, że i w innych miałbyś sporo do dodania. Dobrze, że poznaliśmy Twoją opinię a czytający będą mogli dołożyć ją do innych i mozaika zacznie się wypełniać.
Właśnie ograniczenia (licencyjne, techniczne czy zwyczajnie finansowe) stoją za wyborami, które trzeba dokonać bo jak do tej pory, każdy z nas trochę się już naszarpał w pojedynkę i może pora najwyższa wybrać coś wspólnie.
Może jeszcze ktoś się przełamie i podzieli z nami swoją opinią?

[SQ6DGT]

Na forum jest wielu naprawdę dobrych specjalistów w swoich dziedzinach, moje skromne doświadczenia w budowaniu układów radiowych czy ogólnie elektronicznych są znacznie skromniejsze, nie miałem wiele do dodania i nic nie pisałem :-)

Jeśli chodzi o STM32 to mam trochę doświadczeń bo przebijałem się przez różne środowiska głównie z powodu tego, że pracuję na Mac-u. Do niedawna nie było tam zbyt różowo jeśli chodzi o darmowe środowiska, CrossWorks był ale płatny po okresie ewaluacyjnym. Teraz jest znacznie lepiej.

Aktualnie mam na warsztacie projekt analizatora antenowego na STM32, a od strony komputera program w Javie do sterowania i wizualizacji, w Javie programuję zawodowo stąd ten wybór. Połączenie jest interfacem szeregowym, software w Javie działa wszędzie więc rozwiązanie powinno być przenośne i proste bo po stronie mikrokontrolera jest minimalistycznie. Mam mikrokontroler, dwie sondy: logarytmiczną i liniową oraz VFO na AD9851, działa mi przemiatanie częstotliwości i mam dosyć elastyczny protokół komunikacyjny między desktopem i MCU. Załączam obrazki z mojego warsztatu oraz zrzut ekranu dla małej (auto) prezentacji :-) DDS podłączony do sondy logarytmicznej bezpośrednio, widać jak siada mocno powyżej 60MHz. Wszystko w wersji mocno alfa, do tego MCU na etapie wkładania do obudowy. Dziękuję za zachętę, kiedy tylko będę miał coś konstruktywnego napewno będę aktywny :-)