Programowanie ARM, nauka, środowiska programistyczne IDE

[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.