Programowanie ARM, nauka, środowiska programistyczne IDE

[SP6VGX]

Ok a ja zapytam sie troche inaczej... bo troche dyskutujemy o roznych technicznych sprawach, a to ma byc kurs.

Teraz moze pytanie ile osob bylo by chetnych, oraz warto by ustalic od jakiego poziomu strartujemy. Natomiast jak nie bedzie zbyt duzo chetnych na typowy kurs od podstaw to mozna wystartowac z czyms bardziej zaawansowanym - a tutaj juz dorga otwarta co to bedzie...

[SQ6DGT]

Trzeba by ustalić kto będzie na kursie przyswajał wiedzę, a kto ewentualnie mógłby ją przekazać. Zależy to od poziomu kursu :-) Może ja napiszę co wiem/zrobiłem a co mógłbym/chciałbym się dowiedzieć:

1. wiem/zrobiłem:
- przetestowałem kilka środowisk IDE oraz "gołe" budowanie z makefile przy pomocy edytora z pakietu Qt (QtCreator), teraz lubię jednak jakieś IDE, Eclipse+GNUArm czy CrossWorks/Segger może być, byle chodziło na Mac-a

- wykorzystuję SPL, choć uważam, że bez niego byłoby chyba lepiej. Od gołych rejestrów odrzuca mnie np. konfiguracja USART i przeliczanie prędkości :-) Można, ale łatwo się pomylić i to trochę "orka na ugorze"

- napisałem protokół komunikacyjny z CRC, do wymiany danych binarnych z desktopem, bazujący na USART, z timeoutami, nie zawieszający się :-) Część desktopowa w Javie (przenaszalne, komponent komunikacyjny JSSC)

- wykorzystuję przerwania do mierzenia czasu, timer do pomiaru częstotliwości, przetworniki ADC w tym przez DMA, czyli takie podstawy, wszystko z wykorzystaniem SPL. W ograniczonym stopniu wykorzystywałem SPI do komunikacji z innymi modułami (akcelerometr LISL)

- napisalem obsluge ad9850/51 w spl, banalne wykorzystanie GPIO

- C/C++ znam w miarę, może nie biblioteki typu boost czy smartpointery z C++ (dosyć dawno produkcyjnie programowałem w C/C++) ale poza tym ok, zresztą zawsze można się doszkolić.

w tym co powyżej mogę w miarę skromnych mozliwości dopomóc, pomóc zrobić jakiś kod szkoleniowy itd. Przy SPL się nie upieram, jeśli celem kursu ma być mistrzowskie opanowanie rdzenia i peryferii i wszyscy tego chcą to kim jestem by się sprzeciwiać ;-) Jednak użycie biblioteki w stylu openstm32 mogłoby być dobrym kompromisem.

2. czego nie wiem/nie robiłem/chętnie bym się nauczył:
- implementacja wirtualnego portu com na usb czysto programowo, żeby nie musieć kupować dongla USB/RS232, który nie jest drogi ale jeśli można łatwo w programie to czemu nie

- wykorzystywanie bibliotek innych niż SPL/HAM, integracja z projektem bazującym na makefile. To żeby być maksymalnie elastyczny jeśli chodzi o IDE/edytor oraz zewnętrzne biblioteki dla ułatwienia sobie pracy

- Integracja modułów sprzętowych (np. typowo radiowych) z wykorzystaniem SPI, I2C, wykonanie jakiegoś DSP programowo, itd.

- wykorzystanie przerwan i usart wspomagany przez dma oraz pozostale bardziej zaawansowane techniki mozliwe na cortexie

- ... coś o czym jeszcze nie wiem ale napewno by mi się spodobało :-)

Jak każdy zainteresowany potencjalnym kursem napisałby co wie a co chciałby się dowiedzieć to moglibyśmy ustalić jakiś plan kursu, wspólny warsztat roboczy i skład "uczniowski" oraz grono "nauczycielskie" :-) na każdym etapie.

Takie moje luźne przemyślenia nt. warsztatu pracy:
- środowisko dostępne na wszystkich platformach za darmo, może faktycznie SES skoro st-linka można reflashować na j-linka. Albo Eclipse ? Alternatywa to czysto makefilowy projekt i każdy sobie ustawia środowisko sam, jednak dla początkujących to byłby problem.

- praca bez SPL/HAL na początek

- zastanowiłbym się nad enkapsulacją podstawowych rzeczy w formie takiej mikro-biblioteczki. Celowo podałem kod w formie obiektowej, ale można by np. zrobić strukturę w C++ z funkcjami, alokowaną nie na stercie przez new ale normalnie na stosie lub jako globalna zmienna. Wtedy narzut byłby minimalny a czytelność o wiele większa jak można wywołać funkcję jako komponent struktury. To IMHO oczywiście i zależy od tego jakie mają być założenia kursu i może faktycznie wynika z mojego przyzwyczajenia do dektopowego kodu.

Tyle ode mnie :-)

[SP9FKP]

Ok, to i ja przedstawię swoją wizję tego co mielibyśmy wspólnie zrobić.
1. Po co?
Po pierwsze dlatego, że jesteśmy ciekawi techniki, otwarci na nowe wyzwania, lubimy się uczyć i poznawać nowe technologie.
Po drugie, trend do cyfryzacji wszystkiego jest nieodwracalny. Nie można udawać, że się tego nie widzi bo za chwilę okaże się, że idziemy pod prąd.
Po trzecie wreszcie, nowe umiejętności są nam niezbędne by wnieść coś nowego do konstrukcji amatorskich a nie tylko powielać cudze rozwiązania, choć nie ma w tym nić złego. To taki trochę wyższy stopień wtajemniczenia.
2. Dla kogo?
Raczej nie dla tych co nie wiedzą jaka jest różnica między "a=b" a "a==b". Zakładam, że wiemy z grubsze co to kompilator, linker i debugger ale nie wiemy jak to zastosować.Można przy okazji prezentacji jakiegoś kawałka kodu szczegółowo go skomentować tytułem wyjaśnienia składni C ale raczej po naukę pisania w C trzeba będzie sięgnąć do innych źródeł. I tradycyjny podział na "nauczycieli" i "uczniów" zamieniłbym na "jeśli coś wiem to dodam" bo sam chętnie czegoś się nauczę. Taka wzajemna samopomoc w poznawaniu zawiłości technologii cyfrowych.
3. Jak?
Widziałbym to w postaci kursu opartego o pisany skrypt zamieszczany i aktualizowany na bieżąco w wątku z przykładami do ćwiczeń. Ćwiczenia z kolei zawierałyby kompletne i działające programy budowane w standardowym środowisku, wybranym wspólnie i uruchamiane na wspólnie wybranym module testowym. Jeśli ktoś chciałby robić coś "po swojemu" może ale nie będzie to uwzględniane w kursie chyba, że wspólnie zdecydujemy inaczej Chodzi o to by trzymać się jakiegoś przyjętego wcześniej porządku. Każde ćwiczenie będzie uwzględniało jeden konkretny aspekt ćwiczebny np. interfejs USART i miało swój konkretny kod gotowy do skompilowania i uruchomienia w formie archiwum.
4. Czym?
I tu jest największy dylemat. Po wielu dyskusjach z kolegami na temat ich preferencji dochodzę do wniosku, że aby uniknąć wyborów między "młotkiem z zieloną lub niebieską rękojeścią" najlepiej kompilować projekty w linii poleceń "z palca". Jeśli ktoś chce i ma swoje ulubione środowisko, będzie wiedział (lub będzie musiał się dowiedzieć) jak to zrobić inaczej. Wybór wspólnego modułu testowego jest istotny ze względów praktycznych i nie będzie trudny.
Standardowe narzędzia GNU ARM GCC powinny wystarczyć, umówimy się tylko co do wersji i różnic wynikających z systemów operacyjnych na naszych komputerach.
Pozostaje jeszcze kwestia bibliotek. Nie sądzę aby celowe było szczegółowe wyjaśnianie działania poszczególnych peryferii, co do każdego rejestru i zawartych w nim bitów. Można pokazać jak odczytać to z manuala bo prędzej czy później trzeba będzie do niego sięgać ale raczej skupiłbym się na praktycznych aspektach wykorzystania gotowych funkcji jakie by one nie były. Ew. szczegółowo je skomentować.
Spróbuję określić podstawowe ramy skryptu i napisać spis treści. Potem go przedyskutujemy i jeśli nadal będą chętni, zaczniemy.

[SQ6DGT]

(01-07-2016 8:20)SP9FKP napisał(a):  I tradycyjny podział na "nauczycieli" i "uczniów" zamieniłbym na "jeśli coś wiem to dodam" bo sam chętnie czegoś się nauczę.

dokładnie o to mi chodziło, dlatego te role były w cudzysłowie :-)

[SP6VGX]

Ja mysle ze co do IDE nie bedzie jakiegos wielkiego problemu, ja moge zrobic opis polaczenia Eclipse z gcc pod OS X i Win. Tutaj tylko mala uwaga aby nie uzywac na chwile obecna najnowszej wersji tj. Neon. Nie jest ona do konca kompatybilna z starszymi wersjami i jest problem np. z pluginem EmbSys Registers. Tak samo nie wiem jak bedzie pod Linuxem + KDE, ze wzgledu na to ze Eclipse uzywa GTK. Przynajmniej pod Arch Linuxem + Plasma musialem sporo walczyc aby ustawic jakos sensownie kolory, np. niektore podswietlenia i informacje byly nieczytelne ot czarna czcionka i czarne tlo itd.

Piotr natomiast ma opanowane EmBitz czyli Code::Blocks i tutaj tez mozna to zapewne dostosowac.

To jest w zasadzie tylko IDE wiec nie bedzie kolidowac z tym co robimy.

Ja w sumie uzywam eclipse jeszcze z powodu dostepnosci pluginu StateViewer:
https://www.highintegritysystems.com/dow...r-plug-in/

Mimo ze Eclipse to kobyla w Javie ktora do najszybszych moze nie nalezy, ale na moim niezbyt szybki Mac-u z Core2Duo da sie pracowac...

Odnosnie wersji toolchaina to tutaj tez nie bedzie jakis wiekszych problemow z wyborem, dla prostych rozwiazani mozna wybrac linaro https://launchpad.net/linaro-toolchain-binaries czy tam https://launchpad.net/gcc-arm-embedded Ja bym sie sklanial przy tym drugim...

Do tego jak to zostalo wspomniane makefile ktore daja mozliwosc i kompilacji z reki i podpiecie pod IDE. Na poczatku moze wydawac sie to straszne, ale w wiekszych projektach latwiej jest dodac cos do plku edytorem tekstu niz wyklikac w IDE - np. jak chcemy czesc spraw kompilowac jako biblioteki czy uzywac jakis skryptow.

Odnosnie SPL to juz wspomnialem to wydaje sie na poczatku latwe, ale potem staje sie to upierdliwe - zwlaszcza jak chcemy w jakis nietypowy sposob konfigurowac peryferia. Trzeba wtedy samemu analizowac kod SPL-a, a na wiekszosci boardow jak zadamy pytanie to dostaniemy za zwyczaj odpowiedz - jak uzywasz SPL-a to sie mecz dalej i sam poszukaj co jest nie tak

Akurat te wzory do UART-u to nie jest to jakas tragedia i w AVR-ach to jest z tym ze dodana jest jeszcze tabelka z wartosciami jakie wpisac do rejestrow.

Natomiast co do USB to na pewno w pozniejszym terminie, bo tutaj trzeba bedzie sie zapoznac z podstawami jak dziala ten interfejs. Choc niektore osoby moze mialy szanse odpalac USB na AVR-ach np. Mega32U4... choc tam jest to troche mniej skomplikowane ze wzgledu na mocno uproszczone peryferia USB.

Ja w sumie pierwszy raz wlasnie odpalalem USB na AVR i ze wzgledu na to ze wszystkie gotowe bibloteki to byly ogromne kobyly, to przebijamem sie przez specyfikacje USB aby napisac cos prostego. Potem na ARM przez to polecialo juz z gorki, a pisanie sowjej obslugi wynikalo znowu z problemow jakie mialem uzywajac biblioteki aby zaimplementowac cos niestandardowego. Zreszta nawet odpalanie czegos prostego jest tam dosc zawile i wielu moze zniechecic...

Choc tutaj na poczatku mozna uzyc gotowca bez wnikania w to jak to dziala od strony USB to bedzie raczej potrzebne tym ktorzy chca aby odpaloic jakas nietypowa komunikacje, a to zwiazane jest znowu z pisaniem wlasnych sterownikow. Przy uzywaniu HID, witrualnego COM itp. mozna spokojnie uzywac tego co juz ktos napisal.

Calosc "kursu" owszem najlepiej zrealizowac tak jak opisal to Piotr, zreszta ze mnie raczej kiepski nauczyciel - wiec taka forma lepiej sie sprawdzi

Poczatek to bedzie wlasnie np. przygotowanie sobie srodowiska do pracy itd.

[SP6IFN]

W całej rozciągłości przychylam się do tego co napisał Piotr. Jak na razie jestem najsłabszym ogniwem w tym przedsięwzięciu, ale odpowiadając na to co napisał Piotr

Cytat:Raczej nie dla tych co nie wiedzą jaka jest różnica między "a=b" a "a==b".

odpowiadam: wiem co to są OPERATORY, do czego służą i jak się pośród nich poruszać. A jeśli czegoś do tej pory nie spamiętałem, to mam odpowiednie podręczniki i mogę do nich w każdej chwili zaglądnąć. Ponadto okazało się, że z Robertem SQ6DGT znam się osobiście i nawet pomieszkujemy w sąsiednich dzielnicach. Tak więc jestem dobrej myśli, bo będę miał możliwość otrzymania niezbędnej pomocy w razie pilnej potrzeby. Oceniając sam siebie dodam że bawiłem się Arduino, a obecnie przesiadłem się na czysty język "C" i czegoś tam już się nauczyłem, powinienem więc za Wami nadążyć. Zdaję sobie jednak sprawę że pisanie oprogramowania opierającego się na "prawdzie i fałszu" to spore wyzwanie, i że bez znajomości architektury procesora jest to praktycznie niemożliwe. Do tego doszedłem dotychczasową samodzielną nauką, którą pragnę nadal kontynuować z Waszą Panowie pomocą, bo to jest niepowtarzalna okazja, nie można jej zmarnować.
Jak do tej pory, jedynie ja odważyłem się tu coś napisać jako ten najsłabszy, ale zauważyłem po ankiecie na wstępie wątku, że skrytoczytaczy jest więcej, apeluję więc by inni początkujący też się dołączyli do kursu, będzie nam wszystkim raźniej.
Rysio!

[SQ6DGT]

(01-07-2016 21:48)SP6IFN napisał(a):  Ponadto okazało się, że z Robertem SQ6DGT znam się osobiście i nawet pomieszkujemy w sąsiednich dzielnicach. Tak więc jestem dobrej myśli, bo będę miał możliwość otrzymania niezbędnej pomocy w razie pilnej potrzeby.

Myślę, że zbyt skromnie oceniasz swoje możliwości , ale jesli zajdzie taka potrzeba i moja ograniczona wiedza wystarczy to jak najbardziej slużę pomocą.

---

Na elektrodzie znalazłem darmowy poradnik "Mikrokontrolery STM32, poradnik dla początkujących", napisany przez autora "szczywronek", nie-fachowca jak sam o sobie pisze, moim zdaniem bardzo fajna pozycja. Napisana z prespektywy kogoś kto Cortex-y dopiero zgłębiał i na co się natknął oraz co było jego zdaniem najważniejsze. Wklejam link do PDF-a z elektrody:

http://www.elektroda.pl/rtvforum/downloa...1702a1d727

oraz erraty:

http://www.elektroda.pl/rtvforum/downloa...1702a1d727

w razie problemów ze ściągnięciem dokument główny mam.

[SP5FCS]

Długo nie mogłem znaleźć wystarczającej motywacji aby przejść na procesory 32 bitowe. Praktycznie wszystko co dotychczas robiłem (nawet złożone sterowniki z kilkoma procesorami i rozbudowanym softem) dało się zrealizować na 8 bitach. Nowe czasy to nowe wyzwania: USB, wyświetlacze graficzne, karty SD, pendrive, DSP to tematy coraz trudniejsze dla małych procesorów. To właśnie powyższe tematy oraz eksplozja popularności procesorów ARM przekonały mnie że to właśnie ten moment. Być może kilka lat za późno dlatego dla mnie istotna jest duża intensywność kursu. Mimo posiadania podstawowej znajomości języka C / w latach 90-ych kilka programów DOS-owych, ostatnio dwa sterowniki na Xmegach/ często irytują mnie "zakręcone" struktury danych czy kod z niejednoznaczną składnią. Warto tak pisać kod aby uczeń nie analizował tydzień co autor miał na myśli. Ciągle mam mentalność programisty asemlerowego, który najwyżej ceni czas procesora i wielkość generowanego kodu, potem wygodę i łatwość pisania a na wygląd wcale nie zwracam uwagi. Kodu wgranego do procesora nikt nie będzie podziwiał liczy się efekt działania urządzenia.
Wiele kursów koncentruje się na opisie języka np. C, uruchomieniu podstawowych zasobów procesora zapominając o istocie: technice programowania. Nawet najlepsza znajomość środowiska, języka i procesora nie pozwala na pisanie dobrych programów.

Próbowałem darmowej wersji Segger-a oraz EMBitz-a pod Windowsem. Osobiście bardziej podoba mi się praca pod EMBitz-em:
- prosta instalacja pod windowsem;
- pełna wersja bez ograniczeń kodu i czasu;
- prosty import projektów z innych środowisk;
- przyzwoity edytor z możliwością zwijania boków kodu pomiędzy klamrami;
- dość dobra szybkość pracy.

Na tą chwilę mam środowisko, Discovery_F407, Discovery_F429, programator J-link EDU. Oba moduły łatwo i prosto dają się przeprogramować na J-linka bez potrzeby kupowania J-linka EDU. W tej chwili całość jest gotowa do pierwszych prób.

Z001 (pierwsze zadanie): "puść do mnie oko" - mruganie LED-em na disco_F429

[SP6IFN]

W poście #35 Tomek wypowiedział się:

Cytat:Piotr natomiast ma opanowane EmBitz czyli Code::Blocks i tutaj tez mozna to zapewne dostosowac.

rozumiem więc że o to środowisko chodzi:
http://www.codeblocks.org/downloads/26#windows
Uczyłem się C+ na wersji 10.05, nic więc nie stoi na przeszkodzie by ją zmienić na najnowszą, jak w linku powyżej. Czy dobrze to zrozumiałem? Pobrałem już wersję

Cytat:codeblocks-16.01mingw-setup.exe

no i czekam na opinię czy instalować?
Rysio!

[SQ8MVY]

Witaj,

EmBitz jest zbudowane na bazie CodeBlocks. EmBitz ma zawarte w sobie pluginy do obsługi/budowania projektów typowo pod mikrokontrolery w tym STM32. W CodeBlocks całą konfigurację środowiska trzeba robić ręcznie dla każdego projektu.

Do CodeBlocks jest w fazie deweloperskiej plugin do STM32. Niestety aby go użyć należy przekompilować C::B z nałożoną łatką. Sam plugin jest na tyle fajny, że potrafi integrować z projektem pakiety MiddleWare zawarte w firmware pobieranym przez Stm32CubeMx.

Ryszardzie, jeśli pracujesz pod windowsem to pobierz EmBitz....