[Elvis]

Kurs jest kontynuacją artykułów „Jak rozpocząć przygodę z ARM-ami”. W dalszym ciągu przykłady będą realizowane z użyciem modułu LPC-H2148. Z poprzednich artykułów można dowiedzieć się, jak zainstalować środowisko programistyczne, skompilować i wgrać pierwszy program.
Linki do artykułów:
* http://www.dioda.com.pl/f...roga-vt2258.htm
* http://www.dioda.com.pl/f...nsza-vt2265.htm

W tym kursie postaram się opisać praktyczną stronę programowania ARM-ów. Celem będzie przygotowanie programu dla prostego robota typu LineFollower.
Na początek, dla niecierpliwych, opis robota:
* mostek L293D
* 3 czujniki TCRT-5000
* procesor LPC-2148 (60Mhz, 512KB Flash, 40KB RAM)

Poniżej zamieszczam zdjęcia wykonanego prototypu oraz schemat, a na końcu artykułu kod programu.

0. Wstęp

Na początek, podam gdzie można uzyskać więcej informacji. Pierwsze źródło informacji to niewątpliwie strona o module LPC-H2148.
Warto przeczytać informacje na stronie sklepu (szczególnie schemat modułu oraz schemat wyprowadzeń):
http://www.shop.kristech....&products_id=87
oraz na stronie producenta:
http://olimex.com/dev/index.html
O samym procesorze należy szukać na stronie producenta, czyli NXP:
http://www.nxp.com/pip/LPC2141_42_44_46_48_4.html
Dla poznania procesora najważniejszy jest dokument:
http://www.nxp.com/acroba...s/UM10139_1.pdf – czyli user manual, jednak w przypadku tego procesora są w nim informacje, których można spodziewać się po datashee-cie.
Poza manualem, warto przeczytać tzw. datasheet oraz informacje o błędach w procesorze:
http://www.nxp.com/acroba...S_LPC2148_3.pdf

Gdy poznamy nieco procesor oraz moduł warto wrócić do poznania kompilatora.

W poprzedniej części kursu pominięte zostało wyjaśnienie, co wygenerowało za nas środowisko, czyli pliki: crt0.s oraz Philips_LPC210X_Startup.s.
W plikach tych znajduje się kod (w asemblerze), który uruchamiany jest przed kodem funkcji main (tak właśnie jest, program w nie zaczyna się funkcją main).
Kod ten wykonuje za nas sporo pracy. Obsługuje m.in. wektor przerwań, zeruje pamięć oraz konfiguruje pętlę PLL.
Tutaj małe wyjaśnienie. W procesorach AVR zegar pracuje z częstotliwością rezonatora. Jeśli podłączymy kwarc 20MHz to procesor pracuje na 20MHz. W przypadku ARM częstotliwość kwarca jest wewnętrznie powielana. I tak przy zewnętrznym kwarcu 12MHz otrzymujemy częstotliwość taktowania 60MHz (dokładnie jest to 5*12MHz).
CrossStudio wykonało wszystko za nas, wystarczyło wybrać częstotliwość oscylatora 12MHz i gotowe. Konfiguracja odbywa się właśnie w pliku Startup.s, a ustalona częstotliwość przechowywana jest w stałej OSCILLATOR_CLOCK_FREQUENCY.
Kolejnym ustawianym parametrem jest częstotliwość zegara peryferiów. W procesorach ARM układy peryferyjne mogą działać wolniej niż sam rdzeń. Domyślnie częstotliwość peryferiów wynosi połowę częstotliwości zegara, czyli 30MHz (będziemy potrzebowali tej wartości później).

Kod w pliku wykonuje za nas jeszcze jedną ważną rzecz. Wspomniałem wcześniej, że czasem nasz program może uniemożliwić przeprogramowanie przez JTAG. Aby nie spowodować problemów, kod domyślnie nie startuje po włączeniu zasilania.
Zamiast wywoływać funkcję main() (czyli nasz program) wchodzi w nieskończoną pętlę. Daje to czas JTAG-owi na przejęcie sterowania i przekierowanie programu. Dzięki temu nawet jeśli nasz program może zawieszać procesor, nadal będzie możliwe jego przeprogramowanie.
Niestety efekt jest taki, że jeśli naciśniemy reset, czy zaprogramujemy procesor przez RS-232 nasz program nie zacznie działać.
Aby program działał bez JTAG-a, można zmienić kod w pliku Startup.s, albo co niewątpliwie jest lepszym rozwiązaniem zdefiniować stałą STARTUP_FROM_RESET. Kod Startup.s, gdy wykryje ją, nie będzie wchodził w nieskończoną pętlę.
CrossStudio może kompilować programy w różnych konfiguracjach. Aktualną konfigurację możemy wybrać w miejscu zaznaczonym na obrazku:


Podczas kompilacji możemy wybrać konfigurację. Nas interesują dwie z nich:
ARM Flash Release – wersja docelowa, czyli skompilowana i zoptymalizowana
ARM Flash Debug – wersja do debugowania, idealna podczas tworzenia programu (jeśli mamy JTAG)

Pozostałe konfiguracje pozwalają na uruchamianie programu z pamięci RAM (działa tylko jeśli nasz program się w tej pamięci mieści). Możliwe jest również tworzenie programów w trybie 16-bitowym, tzw. thumb. Na razie zostaniemy przy pełnym trybie 32-bitywym, czyli ARM.

Aby nasz program w wersji docelowej startował samoczynnie, a jednocześnie pozwalał nam na bezpieczne tworzenie (i debugowanie) dodamy stałą STARTUP_FROM_RESET do konfiguracji „Release”.
W tym celu w oknie Project Explorer wybieramy konfigurację „Release”


Następnie w oknie „Properties” wyszukujemy grupę „Preprocessor Options”, a w niej „Preprocessor Definitions”.

Edytujemy zdefiniowane stałe i dodajemy STARTUP_FROM_RESET.

Po kompilacji program powinien uruchamiać się sam po wykonaniu reset-u.
Jeśli będziemy mieli problem z konfiguracją, zawsze możemy wykorzystać projekt umieszczony w załączniku.

1. Porty I/O

Procesory LPC2148 są wyposażone (jeśli wierzyć producentowi) w 45 linii I/O. Linie te mogą pełnić też inne funkcje, np. przetwornika analogowo-cyfrowego. O konfiguracji portów, więcej można przeczytać w rozdziale 7 dokumentacji procesora.
My zajmiemy się stroną praktyczną. Po resecie większość linii jest skonfigurowana jako I/O i są gotowe do użycia.
Wyprowadzenia procesora grupowane są w porty, nazywane PORT0 oraz PORT1. Porty są, aż 32 bitowe, więc jeden port może obsługiwać do 32 linii. W rzeczywistości do portu podłączone jest mniej.
Przetestujemy je na przykładzie diody (jest w module LPC-H2148) oraz switcha (podłączonego na płytce robota).
Najpierw testujemy wyjście, sterowanie diodą. Na schemacie modułu widać, że anoda diody LED jest podłączona do zasilania, katoda do wyjścia 1.24. Oznacza to, że wysterowanie pinu 1.24 logiczną 1 gasi diodę, 0 zapala.
Do konfiguracji kierunku działania linii służy rejestr IO0DIR oraz IO1DIR (odpowiednio dla portu 0 i 1). Ustawienie 1 w rejestrze sprawia, że linia jest wyjściem. Po resecie linie pracują jako wejścia.
Zmieniamy 1.24 w wyjście instrukcją:

[profesorek]

W jakim języku został zaprogramowany ten robot?

[olimek]

Składnia wygląda na C .

[Elvis]

C, kompilowany pod CrossStudio. Więcej informacji w artykule dostępnym tutaj: http://www.dioda.com.pl/f...roga-vt2258.htm

[profesorek]

Arm które są w artykule to arm7 czy arm9? Ponieważ chcę sobie kupić książkę o ARM i dlatego pytam chodzi mi o moduł jaki jest w nim rodzaj ARM?

[Nawyk]

ARM7

[profesorek]

To czym się różni ARM7 od ARM9 i od STM32 przecież wszystkie są 32 bitowe?

[ Dodano: 15 Lis 09 01:32 ]
Czego najlepiej uczyć się programować ARM7 czy ARM9 czy może STM32 proszę o rade?

[Elvis]

W największym skrócie, różnice między ARM7 i ARM9 są bardzo duże. ARM7 mają prędkości do ok. 70MHz, ARM9 - 150MHz. Poza tym ARM9 są bardziej mikroprocesorami niż mikrokontrolerami. Mają wbudowany układ MMU, pozwalają na uruchomienie na nich systemu operacyjnego (np. linux, windows ce). ARM7 są mniejsze, tańsze i pobierają mniej prądu. Służą raczej do budowy prostych urządzeń/sterowników. ARM7 można porównywać do AVR, natomiast ARM9 bardziej przypomina procesor np. Intel Pentium, niż mikrokontroler.
Natomiast Cortex-M3, którego przykładem są układy STM32 to nowa wersja rdzenia armów. Pod wieloma względami jest to uproszczony ARM7, jednocześnie działający szybciej i z bardziej rozbudowanymi peryferiami.
ARM9 to raczej nie jest procesor dla początkującego elektronika, radzę więc wybierać ARM7 lub Cortex-y. Parametry obu są dość podobne, jednak obecnie widać tendencję do tworzenia nowych mikrokontrolerów z rdzeniem cortex, więc prawdopodobnie w przyszłości będzie on popularniejszy niż ARM7.

[profesorek]

Jak duże różnice są w ARM7 a STM32 czy jak kupię tą książkę http://www.btc.pl/?id_prod=10296000 i co jeszcze możecie mi polecić na naukę jakis zestaw czy dobry jest ten na naukę http://www.kamami.pl/inde...productID=93172 ?

[Sabre]

profesorek, ty nie zrobiłeś nawet jednego układu na AVR'ze a chcesz się brać za ARM'y? Chyba nie do końca rozumiesz jakie są to różnice w układach i programowaniu.

[profesorek]

Sabre a skąd wiesz czy zrobiłem czy nie?

[Elvis]

Jak chodzi o książkę i płytkę, to rozdawali takie na szkoleniach ostatnio Książki jeszcze nie miałem czasu przeczytać, ale wydaje się bardzo ciekawa. Jest od podstaw, aż do uruchamiania FreeRTOS-a.
Natomiast co do płytki, to nie wiem, czy to dobry wybór. Jest tania, ale na tym kończą się zalety.
Za 150zł dostajesz 2 diody, joystick, łącze usb i procesor. To raczej niewiele, żeby nauczyć się jak procesor działa. Zostaje dołączyć coś własnego. I tutaj pojawia się problem - kto wymyślił taki kształt płytki(motylek) ???
Ja bym radził albo droższą płytkę ewaluacyjną (z większą liczbą układów na niej), albo tani układ, np. http://www.propox.com/products/t_174.html i samemu płytkę zrobić.
Wszystko zależy na jakim jesteś poziomie z elektroniki.
Ale płytka motylek to nieporozumienie.

[feriar]

a mozna wykorzystac do tego porojektu czuniki CNY70 ? ;]

[Sabre]

[profesorek]

Teraz zapytam się ta Czego nie da się zrobić na avr w przeciwieństwu do ARM?
Czy ARM można programować tylko w aksambleże i C czy da się jeszcze w jakimś języku jeśli tak to w jakim? Czy Prawdą jest że w Bascomie nie zaprogramuje ARM?

[Nawyk]

Po 1) nie "aksambler" tylko asembler (asm)
po 2) BASCOM to środowisko programistyczne dla AVRów (i niektórych uC z rodziny tzw. '51)
po 3) regulamin, punkt 3a

[Sabre]

Widzisz profesorek, i ty się chcesz brać za ARMy jak ty nawet nie wiesz do czego służy Bascom. Naucz się może najpierw jednego z najprostszych języków czyli właśnie Bascoma, jak go poznasz i zaczniesz robić urządzenia, dla których Bascom już nie będzie wystarczał, wtedy przesiądziesz się na ARM'y i inne języki programowania np asemblera czy C.

[Elvis]

Co do języków programowania, to na ARM-y na pewno da się pisać w C++. Na ARM9 można uruchomić linux-a, a wtedy już pełna gama programów, nawet serwer www+php. Jednak raczej nie o to w mikrokontrolerach chodzi.
Pierwsze pytanie jest trudniejsze. Teoretycznie wszystko co można zrobić na ARM-ie można też zrobić na AVR. ARM9 ma MMU i to jest istotna różnica. ARM7 i cortex raczej nie mają "czegoś", co by je istotnie różniło od AVR.
Główna różnica to 32-bitowa architektura, większa pamięć i szybkość.
Pamięć można podłączyć (zewnętrzną) i do AVR, programowo można działać na dłuższych danych niż 8-bitów. Więc jedyne w czym AVR niewątpliwie przegrywa to szybkość wykonywania programów.
Gdyby porównywać mikrokontrolery do mikroprocesorów, to pytanie byłoby jak: co można zrobić na najnowszym Core Duo, a nie da się na 386.
Jeśli zaczynasz przygodę z elektroniką, to AVR w zupełności wystarczą. Są łatwiejsze do nauki i tańsze. ARM to temat raczej dla bardziej zaawansowanych.

[zaquadnik]

Z tym, że uC z rdzeniem ARM9 to nie uC, a bardziej procesory się nie zgodzę, wystarczy spojrzeć na rodzinę STR91x z STM =] To są mikrokontrolery "pełną gębą" i spokojnie można je oprogramowywać jak takowe, a stopień trudności pisania na nie programów wcale nie jest większy niż na ARM7. Tyle, że ARM9 jest rdzeniem wydajniejszym.

[swierkdeck]

http://en.wikipedia.org/w...cture#ARM_cores

Tutaj znajdziecie podstawowe info o każdym rdzeniu ARM, jaki występuje (oraz jego popularne aplikacje).