Skocz do zawartości

[Kurs] Kurs programowania procesorów ARM (LPC21xx)

Elvis

Przez Elvis,
w Artykuły użytkowników

 Udostępnij

Pomocna odpowiedź

  • Popularny post
Elvis Lokalny Mentor

Elvis

Napisano
  • Popularny post
Napisano

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:

* https://www.forbot.pl/forum/topics20/jak-rozpoczac-przygode-z-arm-ami-wersja-szybka-choc-droga-vt2258.htm

* https://www.forbot.pl/forum/topics20/jak-rozpoczac-przygode-z-arm-ami-cz2-wersja-tansza-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.eu/product_info.php?cPath=21_26&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/acrobat/usermanuals/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/acrobat/erratasheets/ES_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ą:

IO0DIR |= _BV(24);

Makro _BV() definiujemy jak dla AVR, bardzo ułatwia programowanie, szczególnie, gdy mamy 32 bity zamiast 8.

#define _BV(x)       (1<<x)

Gdy mamy już linię ustawioną jako wyjście możemy zacząć nią sterować. W przypadku AVT było łatwo, mieliśmy rejestr PORTx i gotowe. W przypadku LPC21xx za obsługę I/O odpowiada kilka rejestrów. Możemy użyć rejestru IO0PIN lub IO1PIN. Działają jak PORTx w AVR, czyli kod IO0PIN |= 1 ustawia zero na wszystkich liniach poza pierwszą. Niestety w przypadku tak wielu linii, takie programowanie nie jest dobrym pomysłem.

Producent dodał więc 2 rejestry. Jeden do ustawiania bitów, drugi do kasowania. W obu przypadkach, gdy wpisujemy 0 nie zmieniamy nic, a tam gdzie wpisujemy 1 ustawiamy lub kasujemy wartość.

Do ustawiania bitów służy rejestr IO0SET / IO1SET. Przykładowo kod:

IO0SET = _BV(8);

Ustawi 1 na 8 bicie w porcie 0. Pozostałe linie nie będą zmienione.

Odpowiada to kodowi AVR:

PORTA |= _BV(8);

Do kasowania służy rejestr IO0CLR / IO1CLR. Kod:

IO0CLR = _BV(8);

Kasuje (ustawia na 0) ósmy bit portu, pozostałe zostają bez zmian. Odpowiada to:

PORTA &= ~_BV(8);

Pozostaje wykorzystać nową wiedzę do sterowania diodą modułu LPC-H2138. Zapalamy led-a:

IO1CLR = _BV(24);

Pamiętamy, żeby nie wstawiać |=

A później gasimy

IO1SET = _BV(24);

Przykładowy kod znajduje się w pliku Led_v1.zip. Program cyklicznie zapala i gasi diodę (jeśli chcemy, aby program uruchamiał się po reset wybieramy konfigurację ARM Release Flash).

Teraz czas na przetestowanie linii I/O jako wejścia. Do programowania przez RS-232 potrzebowaliśmy switch zwierający linie 0.14 podczas resetu procesora. Gdy switch jest zwarty podczas resetu, procesor uruchamia tzw. bootloader – program pozwalający na zaprogramowanie przez łącze szeregowe (jest wgrywany przez producenta do pamięci flash każdego procesora).

Później switch nie jest używany. Możemy go wykorzystać do uruchamiania i zatrzymywania naszego robota.

Aby odczytać stan pinu używamy rejestru IO0PIN lub IO1PIN.

Interesuje nas stan linii P0.14. Odczytanie 0 oznacza zwarcie do masy, czyli wciśnięcie przycisku.

Po odczycie powinniśmy chwilę odczekać, ponieważ switche mają tendencję do drgania i po zmianie stanu przez kilkadziesiąt ms potrafią naprzemiennie dawać odczyt 0 / 1.

Do obsługi robota będziemy potrzebowali program, który wykryje przyciśnięcie przycisku, a następnie poczeka na jego zwolnienie.

#define P0_SWITCH                 _BV(14) 

void switch_delay() 
{ 
 volatile int i; 
 for (i=0;i<100000;i++) 
   ; 
} 

unsigned char switch_pressed() 
{ 
 if ((IO0PIN & P0_SWITCH)==0) { 
   switch_delay(); 
   while ((IO0PIN & P0_SWITCH)==0) 
     ; 
   switch_delay(); 
   return 1; 
 } 
 return 0; 
}

Funkcja switch_delay() daje opóźnienie niezbędne na pozbycie się drgań. Warunek 

  ((IO0PIN & P0_SWITCH)==0)

sprawdza, czy aktualnie jest przyciśnięty switch.

Cała funkcja zwraca 0 jeśli switch nie jest naciśnięty.

Gdy wykryje przyciśnięcie przycisku, czeka na jego zwolnienie, po czym zwraca 1.

Wypada jeszcze wspomnieć, że opisany sposób sterowania (tzn. użyte rejestry) to nieco przestarzała metoda. Tak sterowane były pierwsze układy LPC-213x. Niestety, niedoskonałość w projekcie procesora sprawia, że maksymalna prędkość sterowania w ten sposób to ok. 4,5MHz. W nowszych procesorach zastosowano te rejestry, aby zapewnić kompatybilność oraz dodano nowe, dzięki którym operacje I/O są ok. 3,5 raza szybsze i pozwalają osiągnąć ok. 15MHz. Ogólnie sterowanie jest podobne, zaimiast IO0SET używamy FIO0SET itd. Zainteresowanych zachęcam do lektury dokumentacji producenta.

2. UART (RS232)

Do programowania przez RS-232 zmontowaliśmy konwerter napięć niebędny do podłączenia modułu od PC. Teraz będziemy mogli ten układ wykorzystać do komunikacji PC ↔ ARM. Przyda nam się to do wysyłania komunikatów testowych, np. odczytów z czujników TCRT5000.

Konfiguracja modułu UART wygląda następująco:

#define _SEL(pin, f)   (f << ( pin * 2)) 

#define BAUDRATE                  9600
#define BAUDRATEDIVISOR           (1875000/BAUDRATE) 

 PINSEL0 |= _SEL(0, 1); 
 PINSEL0 |= _SEL(1, 1); 

 U0FCR = U0FCR_FIFO_Enable; 
 U0LCR |= U0LCR_Divisor_Latch_Access_Bit; 
 U0DLL = BAUDRATEDIVISOR & 0x00ff; 
 U0DLM = (BAUDRATEDIVISOR >> 8) & 0x00ff; 
 U0LCR = 0x03;

Gdy omawialiśmy linie I/O wspomniałem o możliwości użycia linii do obsługi innych modułów. Rejestr PIN0SEL, PIN1SEL oraz PIN2SEL definiują, które linie procesora pracują jako zwykłe I/O, a które wykorzystują inne funkcje. Większość linii jest konfigurowana za pomocą 2 bitów (czyli są dostępne 4 opcje). Makro definiujące _SEL() pomaga w ustawieniu rejestrów. Po resecie większość pinów ma wybraną domyślną funkcję 0, czyli port I/O. Teraz dla linii P0.0 i P0.1 wybieramy UART0, czyli możliwość komunikacji po RS-232. Więcej informacji w dokumentacji procesora.

Aby skonfigurować komunikację definiujemy stałe:

#define BAUDRATE                  9600
#define BAUDRATEDIVISOR           (1875000/BAUDRATE)

BAUDRATE to prędkość komunikacji, można zmienić na inną 🙂

Konfigurujemy rejestry:

  U0FCR = U0FCR_FIFO_Enable; 
 U0LCR |= U0LCR_Divisor_Latch_Access_Bit; 
 U0DLL = BAUDRATEDIVISOR & 0x00ff; 
 U0DLM = (BAUDRATEDIVISOR >> 8) & 0x00ff; 
 U0LCR = 0x03;

Pozostaje oprogramować samą transmisję. Najlepiej będzie zaprogramować funkcje putchar() oraz getchar(). Dzięki temu standardowe funkcje C printf oraz scanf będą korzystać z RS-232.

Funkcje mają postać:

int putchar(char c) 
{ 
 while (!(U0LSR & U0LSR_THRE)); 
 U0THR = c; 
 return c; 
} 

int getchar(void) 
{ 
 while (!(U0LSR & U0LSR_RDR)); 
 return U0RBR; 
}

Możemy napisać testowy program, który odczytuje przysłany kod, i odpowiada komunikatem:

while (1) { 
   scanf("%c", &c); 
   printf("Nacisnięto: %c\r\n", c); 
 }

Pozostaje podłączyć konwerter na RS232 do komputera PC i uruchomić program do obsługi portu szeregowego. Ja używam i polecam putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html , ale wystarczy zwykły hyper-terminal dostępny w każdym windows.

Po uruchomieniu obu programów testujemy wysyłając znaki do modułu ARM, i wpisujac „test” obserwujemy wyniki:

Nacisnięto: t

Nacisnięto: e

Nacisnięto: s

Nacisnięto: t

W załączniku do artykułu możemy pobrać przykładowy projekt Uart.zip z opisamym programem.

3. ADC

Mamy już gotowową obsługę procesora, wiemy jak się z nim komunkować. Teraz podłączamy 3 czujniki TCRT5000. Sygnał z czujników doprowadzamy do przetworników ADC. Przetworniki są 10-bitowe, więc wartość 0 dopowiada absolutnej bieli, 1023 absoulutnej czerni.

Wszystkie czujniki są podłączone do przetwornika ADC1, więc możemy napisać funkcję:

unsigned int adc_read(unsigned int channel) 
{ 
 unsigned int val; 
 AD1CR = AD1CR_PDN|0x700|(1<<channel); 
 AD1CR |= _BV(AD1CR_START_BIT); 
 while (((val=AD1GDR) & AD1GDR_DONE)==0) 
   ; 
 AD1CR &= ~_BV(AD1CR_START_BIT); 
 return (val>>6) & 0x3ff; 
}

Warto wyjaśnić skąd wyrażenie AD1CR = ...|0x700|... Jak wiemy częstotliwość układów peryferyjnych wynosi 30MHz. Przetwornik ADC potrzebuje zegara o częstotliwości mniejszej niż 4,5MHz. Wybieramy więc dzielnik 7, czyli 30MHz / 7 = 4,286 MHz.

Aby przetestować działanie programu, pieszemy wersję, która przez RS-232 wysyłają wartości odczytane z czujników.

  while (1) { 
   printf("ADC1.0=: %d  ADC1.2=: %d  ADC1.3=: %d\r\n", adc_read(0), adc_read(2), adc_read(3)); 
 }

Sprawdzamy, jak odczyty wykrywają czarną linię.

W pliku ADC.zip znajduje się projekt z przykładowym programem.

Testujemy sygnał z przetworników 1.0, 1.2, 1.3 (zgodnie ze schematem).

Funkcja adc_read() jako parametr przyjmuje numer kanału przetwornika, czyli 0 dla 1.0, 2 dla 1.2 itd. Dla ułatwienia dalszego programowania możemy dodać stałe dla kierunków przetworników.

L - left

C - center

R - Right

#define ADC_L                     2
#define ADC_C                     0
#define ADC_R                     3

4. PWM

Do sterowania prędkością ruchu robota najlepiej użyć PWM. Nie będę wyjaśniał, co ten skrót znaczy, ani jak to działa. Mam nadzieję, że wszyscy znają PWM z AVR.

Procesor LPC2148 ma aż 6 wyjść PWM. Możliwości konfiguracji jest całkiem sporo, rozdział 16 dokumentacji procesora omawia możliwości tego układu.

My potrzebujemy tylko 2 kanałów. Dla lewego i prawego silnika.

Wejście 1-2EN układu L293 jest podłączone do pinu P0.7 procesora, a wejście 3-4EN do P0.8. Na tych liniach będziemy chcieli uruchomić PWM.

Pin P0.7 ma alternatywną funkcję PWM2 (czyli drugi kanał pwm), natomiast P0.8 może pracować jako PWM4.

PWM podłączamy do wyprowadzeń kodem:

  PINSEL0 |= _SEL(7, 2); 
 PINSEL0 |= _SEL(8, 2);

Teraz musimy skonfigurować sam moduł PWM. Najpierw zdecydujemy jaką częstotliwość chcemy uzyskać. Ja wybrałem >20kHz, aby wyjść poza akustyczną. Do sterowania silnikami lepiej sprawdzają się niższe częstotliwości, więc może okazać się konieczna zmiana programu.

Standardowo PWM pracuje na zegarze peryferiów, czyli 30MHz. Rejestr PWMMR0 przechowuje wartość do jakiej zlicza PWM. Jeśli lubimy 8-bitowy pwm z AVR to możemy ustawić:

PWMMR0 = 0xff

Czyli 0 będzie oznaczało wypełnienie 0%, 127 – 50%, a 255 – 100%.

Przy takim ustawieniu PWM pracowałby z częstotliwością 30MHz / 256, czyli ~117kHz. Jest to za wysoka częstotliwość, możemy wykorzystać dzielnik ustawiany rejestrem PWMPR. Do PWMPR wpisujemy wartość dzielnika pomniejszoną o jeden. Czyli PWMPR=0 oznacza brak dzielnika, PWMPR=1 to podział częstotliwości przez dwa.

Chcemy uzyskać częstotliwość ~20kHz, więc obecne 117kHz podzielimy przez 5. 

PWMPR = 4;

Pełny kod uruchamiający PWM wygląda następująco:

#define PWM_MAX	0xff

 PWMPR = 4; 
 PWMPCR = PWMPCR_PWMENA2|PWMPCR_PWMENA4; 
 PWMMCR = PWMMCR_PWMMR0R; 
 PWMMR0 = PWM_MAX; 
 PWMMR2 = 0; 
 PWMMR4 = 0; 

 PWMTCR = PWMTCR_Counter_Reset; 
 PWMTCR = PWMTCR_PWM_Enable|PWMTCR_Counter_Enable;

Wypełnienie PWM ustawiamy rejestrami PWMMR2 i PWMMR4.

Jeśli zmienimy wypełnienie podczas pracy pwm (a to właśnie będziemy chcieli robić), kod np. PWMMR2=127 nie da spodziewanego efektu.

Zamiast do prawdziwego rejestru wartość zostanie wpisana do jego kopii (tzw. shadow). Musimy ustawić bit informujący procesor, że powinien skopiować wartość cień do prawdziwego rejestru. Dzięki temu zmiana wartości nastąpi po zakończeniu cyklu PWM.

Kod ustawiający wypełnienie pwm:

  PWMMR2 = speed; 
 PWMLER |= PWMLER_Enable_PWM_Match_2_Latch;

Jeśli ktoś ma chęć poeksperymentować (i najlepiej ma pod ręką oscyloskop), w pliku PWM.zip znajduje się prosty program przykładowy.

5.Sterowanie silnikami

Do sterowania mostkiem L293D wykorzystujemy 2 kanały pwm (omówione poprzednio) oraz 4 linie I/O. Wybrane linie (P1.17, P1.19, P1.21 i P1.23) należą do portu 1, a ich maski zdefiniowane są jako:

#define P1_M1                     _BV(23) 
#define P1_M2                     _BV(21) 
#define P1_M3                     _BV(19) 
#define P1_M4                     _BV(17)

Ponieważ silnikami sterujemy niezależnie, przydadzą nam się dwie funkcje. Pierwsza sterująca lewym, druga prawym silnikiem. Są prawie identyczne (wykorzystują inny pwm i piny), więc omówię tylko jedną.

Funkcja ma sygnaturę:

void lmotor_set(unsigned char dir, unsigned int speed)

Pierwszy parametr ustala kierunek pracy silnika. Podanie 0 oznacza jazdę do tyłu, inna wartość, do przodu.

Drugi parametr to wypełnienie PWM, czyli prędkość. Przyjmowany zakres wynosi od 0 (zatrzymany silnik) do PWM_MAX (pełna prędkość). PWM_MAX to wcześniej zdefiniowana stała, równa 255.

6.Algorytm

Robot posiada 3 czujniki odbiciowe typu TCRT5000. Sygnał z nich podłączony został do przetworników ADC, więc wykrywamy nie tyle linię, co mierzymy jasność (zdolność do odbicia podczerwieni) podłoża.

Takie rozwiązanie ma kilka zalet:

1) Nie musimy kalibrować poziomu zadziałania komparatorów

2) Robot może jeździć po podłożach o różnej, nawet zmiennej jasności

3) Możemy wykrywać nie tylko obecność linii, ale nawet w jakim stopniu linia jest pod czujnikiem (częściowe przesłonięcie)

Aktualna wersja programu działa bardzo prosto. Obserwując wyniki z przetworników wyraźnie widać, że czujnik, pod którym znajduje się linia daje odczyt o wyższej wartości.

Program wykrywa jedynie, czy lewy lub prawy czujnik daje taki właśnie odczyt.

Jeżeli wykryje, że lewy czujnik daje znacznie wyższy wynik niż pozostałe, skręca w lewo. Analogicznie dla prawego czujnika.

W pozostałych przypadkach robot jedzie przed siebie.

Działa więc trochę jak światłolub (właściwie to cieniolub).

Program realizujący ten algorytm:

    adc_l = adc_read(ADC_L); 
   adc_c = adc_read(ADC_C); 
   adc_r = adc_read(ADC_R); 

   new_dir = DIR_C; 
   if ((adc_l>=adc_r+ADC_DELTA)&&(adc_l>=adc_c+ADC_DELTA)) 
     new_dir = DIR_L; 
   else if ((adc_r>=adc_l+ADC_DELTA)&&(adc_r>=adc_c+ADC_DELTA)) 
     new_dir = DIR_R;

Aby uniknąć ciągłego skręcania robota odczyt musi być wyższy od pozostałych o ADC_DELTA. Im większa jest wartość tego parametru, tym mniej dokładnie jedzie robot, ale i rzadziej dokonuje korekty trasy.

W zmiennej new_dir przechowywana jest podjęta decyzja, w którą stronę ma jechać robot. Dalsza część programu steruje silnikiem zgodnie z podjętą decyzją.

7.Podsumowanie

Gotowy program zajmuje ok. 4kB pamięci Flash, więc <1% !

Zastosowany procesor jest niewątpliwie za silny dla tego robota. Byłby odpowiedniejszy dla zaawansowanego robota sumo, niż prostego LineFollowera.

LineFollower.zip

main.c

Led_v1.zip

Uart.zip

ADC.zip

PWM.zip

LineFollower_src.zip

  • Lubię! 6
  • 2 miesiące później...
  • 2 tygodnie później...
profesorek Entuzjasta

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 Lokalny Mentor

Elvis

  • Autor tematu

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.

  • Lubię! 1
Sabre Inspirator

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.

Elvis Lokalny Mentor

Elvis

  • Autor tematu

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.

  • Lubię! 1
Sabre Inspirator

Sabre

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

Masz rację, tego nie wiem, ale wywnioskowałem to z zadawanych przez ciebie pytań, w jednym z postów sam napisałeś, że jesteś początkującym. Ja widzę, że nie potrafisz nawet korzystać z dokumentacji układów dostępnych ogólnie na necie. Z mojego punktu widzenia nie poradzisz sobie z programowaniem ARM'ów ani z obsługą gotowej płytki ewaluacyjnej. Na tym forum było już wielu "krzykaczy", którzy próbowali zwrócić na siebie uwagę poprzez pisanie podobnych tematów, czy twierdzeniu, że zrobią super, hiper robota. Według mnie jesteś właśnie taką osobą. Chciałbym abyś mnie mile zaskoczył i udowodnił mi, że jednak się mylę.

profesorek Entuzjasta

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?

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
 Udostępnij
Przejdź do listy tematów
×
×
  • Utwórz nowe...