[ARM] Jak zacząć - rozwiązanie

Jeszcze tylko podziel się schematem dla tych, co nie wiedzą co i jak podczepić.

Naniosę poprawki na wersje elektroniczną PCB, i wszystko postaram się udostępnić.

Co do środowiska, jeśli kupiłbyś całą płytę prototypową Atmela (w JM cena rzędu 1000PLN), dostałbyś w komplecie płytę, programator J-Link USB (szybki!) i startowe oprogramowanie IAR umożliwiające nielimitowane pisanie aplikacji, jedyne ograniczenie to rozmiar kodu wynikowego 32kB. Środowisko to jest naprawdę wygodne, ma optymalny kompilator. Niesamowicie przydatny jest debugger - umożliwia śledzenie programu wykonującego się w docelowym układzie, instrukcja po instrukcji i grzebanie w całej przestrzeni adresowej. Na początek naprawdę warto.

Paweł

Paweł Cern napisał(a):

Odnośnie debugowania w CrossStudio, to równieże ma te same funkcje co oprogramowanie IAR (według tego co piszesz). Odnośnie prędkości debugowania to niewidze zbytniej różnicy między debugowaniem aplikacji pisanej na PC-ta a debugowanej na ARM-ma po JTAG-u, więc po co mi szybciej. Zapewne w darmowym środowiku będzie podobnie. Oczywiście rozumię że lepiej byłoby zakupić orginalną płytę prototypową, ale cena żędu 1000PLN jest astronomiczna dla elektronik-hobbisty.

Za 1000PLN to ja bym już polecił płytkę KB9202

tej cenie nie dają żadnego środowiska, ale jest kilka pożytecznych opisów Mnie się udało w kilka dni odpalić linuxa, skompilować Hello World i generalnie jestem zachwycony jak to działa. A no i zapomniałbym że procek w tej płycie to jednak kombajn (w porównaniu do np AT91SAM7S64) a nie zawsze tyle potrzeba

pozdrawiam Paweł

Użytkownik "Paweł Cern" snipped-for-privacy@surname.neostrada.pl> napisał w wiadomości news:dd6rr0$fo7$ snipped-for-privacy@nemesis.news.tpi.pl...

Ja się przymierzam do zakupu w jabliższym czasie zestawu w

Co prawda nie AS91 tylko STR7, ale ceny wydają mi się bardzo przyjemne.

Co do oprogramowania, to fakt, że jest ono znacznie droższe niż elektronika. Jednak w przypadku takim jak mój, gdzie kupuję zabawkę, która nie będzie wykorzystywana komercyjnie, nic nie usprawiedliwia wydania 1k plnów na debugger, bez znaczenia jak dobry on będzie.

No cóż. 32KB kodu wynikowego w ARMie daje wciągnięcie bibliotek do malloc'a, printf'a i napisanie naprawdę małego kawałka. Takie ograniczenie jest po prostu śmieszne i bardzo ogranicza. Szczególnie tam, gdzie głupi NOP ma 4 bajty.

Napisałem oprogramowanie do rastrowej drukarki termicznej z USB które już działa i zajmuje około 4kB. A trywialne nie jest. Podczas debugowania kiedy korzystałem z printf, było tylko trochę więcej.

Zresztą to ograniczenie dotyczy chyba samego kodu (nie wiem, nie przekroczyłem :D), niezależnie można doklejać do obrazu dane binarne które zresztą w wielu projektach stanowią większość kodu.

Paweł

Czasami 2 :)

Debugowanie w ARM-ie ma zaletę - możesz grzebać sobie w rejestrach peryferiów. Możesz na bieżąco obserwować zachowanie układu. A z tym ARM-em będziesz miał jeszcze schody - ja do tej pory namierzyłem problem z przełączaniem zegara (jest już umieszczony w erracie), problemy z timerami (Compare B nie zawsze działa) i nieudokumentowane tryby pracy SSC (można taktować tylko bity danych - tryb 2(!)).

Apropos, gdzie jest darmowa wersja tego CrossWorks? Producent daje wersję

30-dniową za darmo, pełna kosztuje.

Hmm, może rzeczywiście to zależy od zastosowania, ale ARMy widzę raczej jako środowisko do odpalania większych programów niż hello-world. Do małego i mniej wydajnego kodu IMHO są AVRy.

Ale wystarczy używać arm-elf-gcc (gnuarm), a wszystkie problemy i ograniczenia znikają. Używamy w firmie gcc na ARMy tworząc całkiem niemałe projekty (kilkaset KB kodu wynikowego, pewnie kilkanaście procent tego to teksty i stałe tablice). Wystarczy dorzucić ulubiony edytor, menadżer plików, CVS, odpowiednią strukturę plików makefile i sukces zapewniony. Pracuje się wygodnie i nie potrzeba żadnego IDE.

Niestety nie mogłem znaleźć AVR-a z odpowiednim wyposażeniem (peryferiami) :( A chodziło o RAM conajmniej 16kB, synchroniczny interfejs szeregowy, mechanizm DMA i rozbudowane timery.

Ale to nie jest jedyna argumentacja co do wyboru układu. Otóż ze względu na popularność jądra ARM, mikrokontrolery ARM robią się coraz tańsze, czasami nawet tańsze niż np. AVR czy '51 o zbliżonych możliwościach. Natomiast kod C/C++ bardzo ładnie kompiluje się na ARM-a (mały rozmiar wynikowy) w porównaniu np. do '51 (uważam że łączenie C/C++ i '51 to jedno wielkie nieporozumienie).

Jednak jeśli chodzi o ARM7, bez MMU podejrzewam że trochę niewygodnie jest używać go w dużych projektach, z systemem operacyjnym. Jest dobry do, powiedzmy, "małych i średnich" projektów.

Zapewne. Dla mnie jako studenta (w zasadzie już nie, bo to jest moja praca magisterska a wykłady już się skończyły) ważne było szybkie i bezbolesne zapoznanie się z narzędziami. Tu mam wszystko w jednym. Naciskam jeden guzik i mój kod jest kompilowany, linkowany, ładowany do mikrokontrolera w płycie prototypowej i uruchamiany. Poza tym bardzo doceniam sobie możliwości kompilatora i linkera które od razu rzuciły mi się w oczy (zapewne inne kompilatory też to mają), a mianowicie możliwość wybrania różnych technik optymalizacji dla szybkości lub rozmiaru (np. użycie instrukcji THUMB), usuwanie nieużywanego kodu, zarówno napisanego przeze mnie jak i zawartego w bibliotekach, możliwość dołączania do obrazu wynikowego plików binarnych, jeśli przypisane im symbole są używane w programie (sprawa istotna, jeśli np. potrzebujemy w drukarce umieścić czcionkę czy skompresowany obrazek strony testowej).

Pozdrawiam

Paweł Cern

Brakuje podstawy czyli debuggera podłączonego do JTAG.

Podstawowe problemy na etapie tworzenia systemu operacyjnego dały się wyjaśnić w ARMulatorze. A po przejściu na wyższy poziom abstrakcji jakoś nie brakuje mi emulatora JTAG. Wstawienie printf'ów w kilku kluczowych miejscach jest często bardziej skuteczne niż śledzenie programu krok po kroku, gdy cała reszta stoi. A że system działa w czasie rzeczywistym (realizowana jest m.in. transmisja przez ISDN) to zatrzymanie debuggerem spowodowałoby kompletną wywałkę. JTAGa używamy do pierwszego programowania ARMów - wgrania naszego bootloadera. I do tego celu w zupełności wystarcza home-made kabelek a'la Altera ByteBlaster za kilka zł.

Maksymilian Dutka napisał(a):

Możesz coś więcej opowiedzieć o płytkach i o problemie. Jakim sposobem je robiłeś?