Jakie modele ARM najczęściej wybierają polscy konstruktorzy elektroniki?

Thu Dec 16, 2010 9:13 pm   

Dnia 2010-12-09 06:05, Użytkownik max441 napisał:

AK

Fri Dec 17, 2010 10:00 am   

Pomoglibyście mi wybrać rodzinę ARM, gdybym
podał moje potrzeby?

R.

Fri Dec 17, 2010 10:51 am   

W dniu 2010-12-17 10:00, Robbo pisze:

Dawaj, może ktoś pomoże.


--
Pozdrawiam
MD

Fri Dec 17, 2010 7:21 pm   

Witam ponownie,

Prośba o nakierowanie mnie na jakąś rodzinę ARM, w którą mógłbym wejść i
pozostać na lata.
Do tej pory programowałem mikrokontrolery Atmel AVR ATmega8/16/32. Używałem
WinAVR. Mam doświadczenie w programowaniu AVR32 (60MHz).
Do mikrokontrolera podłączam wyświetlacze LCD znakowe (będę chciał także
niewielkie monochromatyczne graficzne). Steruję różnymi urządzeniami (np.
kluczuję tranzystorami bądź tyrystorami w falownikach z relatywnie dużą
częstotliwością). Korzystam z PWM, UART, przetworników A/C, timerów,
przerwań sprzętowych wyzwalanych sygnałami zewnętrznymi bądź wyzwalanych
tikami trzech zegarów. Podłączam przyciski i przełączniki. Zapisuję
wprowadzone przez użytkownika ustawienia urządzenia w nieulotnej pamięci
EEPROM.

Chciałbym, aby wybrana rodzina ARM umożliwiała mi to wszystko co powyżej, a
ponadto oferowała większą moc oraz spełniła jakieś moje potrzeby w
przyszłości (może USB, może kiedyś Ethernet, może kolorowy wyświetlacz).

Moje potrzeby:
- taktowanie od 60MHz do kilkuset MHz (teraz chciałbym mieć ze 100MHz, a w
przyszłości 200-300MHz byłoby OK; ew. łatwość migracji od wolniejszych do
tych szybszych, w obrębie produktów danego producenta; do jednego projektu
może mi starczy 60MHz, a do innego chciałbym 200MHz -- chciałbym wtedy po
prostu kupić szybszy procek, ale o tym samym sposobie programowania)
- rozwojowa platforma (aby po roku inwestycji w jedną platformę nie okazało
się, że świat poszedł w zupełnie innym kierunku
- możliwość pracy w środowisku przemysłowym (zakłócenia falowników itp.)
- będę raczej programował "goły" uC (bez systemu operacyjnego, ale kto wie,
co będzie za 2-3 lata)
- wszystko co możliwe w jednym układzie, tak jak to było w AVR (tylko kwarc
i jedziemy; bez konieczności podłączania zewnętrznych pamięci;
kilkanaście/kilkadziesiąt kilobajtów mi starczy)
- pamięć nieulotna na zmienne (coś jak EEPROM znany z AVR) kilka kilobajtów
- ważne: dostępność najlepiej w Polsce minimodułów (płytka z uC, kwarcem,
kondensatorami, rezystorami), abym nie musiał lutować SMD (chodzi mi o tego
rodzaju płytki: http://www.kamami.pl/index.php?ukey=product&productID=26118
http://www.kamami.pl/index.php?ukey=product&productID=20934)
- dostępność zestawów uruchomieniowych
- dostępność tutoriali, przykładowych programów, dokumentacji
- UART, być może CAN, kilka PWM, z 8 przetworników A/C, ze 3 zegary, co
najmniej 40 linii I/O (to i tak trochę mało; wolałbym 64 linie), SPI,
przetwornik C/A byłby super, kontroler przerwań, na plus byłyby operacje
zmiennoprzecinkowe
- do AVR używałem WinAVR; do AVR32 używałem AVR32 Studio; chciałbym aby
programowanie ARM w miarę możliwości odbywało się przy wykorzystaniu
podobnych narzędzi...
- kawy i herbaty nie musi robić ;)

Reasumując, chciałbym prawie taki AVR ATmega, ale o wiele szybszy i z
większą ilością pamięci

Mam nadzieję, że ktoś pomoże mi dokonać wyboru, bo jak na razie to po całym
dniu czytania o tym głowa mnie boli od mnogości możliwości.

R.

Fri Dec 17, 2010 11:46 pm   

W dniu 2010-12-16 11:37 Robbo napisał(a):


Aby nie płacić licencji ARMowi od każdego procka. Wymyślili swojego
własnego 32-bitowego RISCa i próbują namówić świat na kupowanie go.

Podobnie zresztą postąpił Microchip z serią PIC32, tyle że AFAIR zamiast
wymyślać procek od zera wzięli sprawdzoną konstrukcję jądra firmy MIPS.
Pewnie tańszą niż ARM. Zresztą same procki z jądrem MIPS są popularne
m.in. w routerach a kiedyś też były stosowane w PDA równolegle z ARMami.
Teraz w urządzeniach przenośnych są stosowane prawie wyłącznie ARMy.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Sat Dec 18, 2010 12:02 am   

W dniu 2010-12-17 19:21 Robbo napisał(a):


No to tutaj mamy pierwszy problem - bo im szybszy procek tym (zwykle)
bardziej skomplikowane jądro, brak wewnętrznej pamięci Flash oraz dużego
RAMu (jest tylko cache). Przy 200MHz nie ma co liczyć na coś mniejszego
niż 926EJ-S (np. ze stajni Atmela AT91RM9200 czy AT91SAM9261). Mocno
zintegrowane układy za to (np. 512KB Flash + 64KB RAMu w środku) są dużo
wolniejsze (np. atmelowy AT91SAM7S512 chodzi na 48MHz). Może ktoś poda
przykłady innych producentów ale nie liczyłbym na dobrze zintegrowanego
ARM7TDMI szybszego niż 60-80 MHz.


Jak na razie ARMy dobrze się trzymają. Conajwyżej przeskoczysz tylko do
innego producenta (przerobisz tylko sterowniki I/O a reszta kodu
pozostanie taka sama).


Małe szanse nawet z prostymi ARMami. Z obsługą przerwań czy USB tyle się
narobisz, że od razu lepiej pomyśl chociaż o małym darmowym systemie.
Nawet gdyby miał tam działać tylko 1 wątek. Polecam zainteresować się
np. Nut/OS lub FreeRTOS.


A no właśnie. Ale nawet tych kilkudziesięciu KB RAMu nie mają procki, od
których wymagasz 200 czy 600 MHz. Zresztą przy ARMach zajętość pamięci
szybko rośnie i szybko stwierdzisz, że zamiast 32 wolałbyś jednak mieć
512 KB RAMu.


W Atmelach nie znam (za to procek może sam programować swój Flash i tam
od biedy emulować niby EEPROM). Może ktoś podać przykłady od innych
producentów?


No to większy wybór chyba tylko NXP (LPCxxx) oraz Atmela (AT91xxx).
Innych producentów procków ARM (ST, TI) znajdziesz conajwyżej pojedyncze
płytki.


Są od wszystkich producentów. Ale często ceny fabryczne bardzo nie
zachęcają.


Jest do wszystkiego.


A tu jest akurat pełna zgodność i do wszystkiego pasuje gcc. Podstawowe
instalacje pecetowe to Yagarto oraz gnuarm+Cygwin. Można do tego
podczepić Eclipse, bardzo wygodne debugowanie przez JTAG (jak w AVR
Studio dla AVRków z JTAGiem).


No to do rozpoczęcia zabawy z ARMami polecam jakiś zestaw startowy z
AT91SAM7S256. Sam procek kosztuje ze 30 zł (tyle co ATmega128) a ma
256KB Flasha i 64KB RAMu oraz USB. Śmiga na 48 MHz (a gdy nie używasz
USB to do 55MHz), wystarczy do wielu zastosowań gdzie ATmedze nie
starcza RAMu lub po prostu brakuje wydajności.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Sat Dec 18, 2010 12:36 am   

W dniu 2010-12-18 00:02, Adam Dybkowski pisze:


Kolega nie zauważył chyba Cortexów M4. Choćby od Freescale
(180 MHz)i NXP (150 MHz).


Do nowych projektów nie polecałbym przestarzałej rodziny 7 TDMI. Lepiej
od razu pójść w Cortex M3

Sat Dec 18, 2010 12:41 am   

LPC17xx pracuje do 120MHz ale EEPROMu też nie ma.

--
Piotrek.
http://www.pitlab.pl

Sat Dec 18, 2010 9:34 am   

W dniu 2010-12-18 00:02, Adam Dybkowski pisze:


gnuarm - ostatni news z 2006-08-01. Bawisz się w archeologię?

Mon Dec 20, 2010 12:50 am   

W dniu 2010-12-18 09:34 Zbych napisał(a):


Nie wiedziałem, że go nie rozwijają. Od ponad roku nie używam.
Yagarto rzeczywiście było lepszym przykładem. Ostatnio z kompilatora
ARMa korzystam tylko w Android NDK.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Mon Dec 20, 2010 3:56 pm   

Robbo wrote:




pracuje z zegarem ~150MHz -> LPC4310FET100
USB, Ethernet i cale stado innych peryferii na pokladzie.


eCOS ->http://ecos.sourceware.org/
OS dostarczy Ci wymagana warstwe abstrakcji separujac aplikacje od platformy
sprzetowej - dostep do sprzetu nastepuje przez standardowe API OSa. W ten
sposob unika sie modyfikacji aplikacji podczas migracji miedzy platformami
(oczywiscie teoretycznie)
Co do wielowatkowosci jak juz ktos sugerowal nikt nie kaze z tego
dobrodziejstwa korzystac. W przypadku eCos scheduler jest jedna z opcji
konfiguracyjnych systemu i mozna jak najbardziej uzywac tego RTOS bez
wielowatkowosci - typowa mikrokontrolerowa petla glowna w mainie i
odpytywanie podprogramow.

(...)


jest calkowicie wystarczajce.

pozdrawiam

Mon Dec 20, 2010 11:51 pm   

On 2010-12-20 00:50, Adam Dybkowski wrote:

http://www.codesourcery.com/sgpp/editions.html. Oczywiście wybieramy
bezpłatną wersję lite ponieważ jako IDE używamy Eclipse'a. Yagarto
też jest oczywiście OK. Poza tym w razie potrzeby można sobie
własnoręcznie skompilować tool chain, tzn. gcc & co. Nawet pod Windows -
trzeba tylko zainstalować MinGW/MSYS i poczytać trochę dokumentacji.

Tue Dec 21, 2010 12:14 pm   

Dziękuję Ci oraz innym za nakreślenie
mi sprawy ARM-ów.
Na razie zainteresowałem się układami
Cortex M4.

R.

Tue Dec 21, 2010 10:08 pm   

W dniu 2010-12-20 15:56, brak pisze:

A czemu nie FreeRtos?

--
Pozdrawiam
MD

Thu Dec 23, 2010 12:43 am   

W dniu 2010-12-21 22:08 Mario napisał(a):


AFAIR FreeRtos jest bardzo ubogi w standardowo dostarczane sterowniki.
Czy coś się może zmieniło w tym temacie w ciągu ostatniego roku czy
dwóch? No i co ma FreeRtos gotowego dla Cortexów M4 od NXP?

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.