Programowanie ARM, nauka, środowiska programistyczne IDE

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