ARM'y i pytanie, którego nie lubicie.

Na to pytanie musisz sobie odpowiedziec sam.

Jesli brac pod uwagę liczbę widomości na grupach dyskusyjnych poswieconych w/w mikrokontrolerom to Philipsy są znacznie popularniejsze niż Atmele.

LPC148 ma USB 2.0 full speed. W przyszłym roku mają być dostępne ARMy Philipsa z Ethernetem. Atmel ma w ofercie AT91SAM7X z Ethernetem. Do tych które nie maja kontrolera Ethernet zawsze można dołaczyc przykladowo CS8900 i odpalic uIP.

Za jakis czas bedziemy miec plytki rozwojowe z LPC2294 z 4MB SRAM i 4MB Flash z supportem dla uCLinux.

Atmel'e AT91SAM7S też.

Tylko czy to będą "tanie" modele (jak np. LPC2138/48), czy tylko drogie procesory w BGA z tysiącami nóżek ? ;)

Wiem, ale nie znalazłem pod nie żadnej płytki do eksperymentów w sensownej cenie, poza tym trzeba by to ściągać z zagranicy.

I właśnie nad taki rozwiązaniem narazie myślę, chociaż CS8900 to

10Megabitowy staroć.

A orientacyjnie kiedy można się ich spodziewać ? Obecnie rozpatruję m.in. "promocyjne" płytki pod ARM'y z Waszej oferty (o ile znowu będą w magazynie), i nie wiem, czy warto czekać ? Będą miały ethernet ?

Dzięki za podpowiedź, i nadal czekam na wszelkie sugestie od innych.

W styczniu 2006.

Tak beda w przeciagu 2-3 tygodni.

Wg mnie lepiej wejść w technologię Atmela. Zabawę możesz zacząć od małych procków (na przykład AT91SAM7S64) a jako że apetyt rośnie w miarę jedzenia - warto nie zamykać sobie w przyszłości drogi do większych konstrukcji. Chociażby takiego całkiem udanego AT91R40008 (256KB RAMu na pokładzie) albo wielkiej kobyły w stylu AT91RM9200 jeżeli będzie trzeba (obsługa SDRAM, Ethernet 10/100, USB host i slave). Ostatnio Atmel rozbudowuje rodzinę małych procesorków AT91SAMxx - jeżeli masz taką potrzebę, możesz kupić mikrokontroler ze sprzętowym wspomaganiem szyfrowania DES i AES (AT91SAM7XC256). Poza tym warto też poznać jądro 920T a nie tłuc ciągle od lat 7TDMI. Atmel to umożliwia (AT91RM9200 i najnowszy AT91SAM9261, pracujące z zegarami do 200 MHz).

Ostatnio człowiek od nas z firmy był na seminarium Philipsa. Widać było wyraźnie, że Philips w dziedzinie ARMów jest duży krok za Atmelem. Największe obecnie produkowane ARMy Philipsa mają tylko 64KB RAMu (przy

128KB Flash'a) lub 512KB Flash'a ale wtedy tylko 32KB pamięci RAM. Największy procek bez Flash'a ma tylko 64KB RAMu, w Atmelu bez problemu 256KB (a są takie z Flashem 1 MB). To ważne, bo przy pracy w trybie ARM każdy głupi NOP zajmuje 4 bajty więc pamięć szybko sie zużywa. Porażką jest też max. wydajność (75 MHz jedynie LPC2290, pozostałe max. 60 MHz). Dla porównania Atmelowy AT91RM9200 wyciąga bez problemu 180 MHz, ma jądro 920T ze sprzętową ochroną pamięci (MMU), USB i MAC Ethernet 10/100 a kosztuje zaledwie 100 zł.

Sam sobie porównaj możliwości i ilość obecnie produkowanych procków z jądrem ARM ze stajni Philipsa:

Atmela: BTW: ARMy Atmela są do kupienia np. w

Dziękuję za wyczerpującą odpowiedź. Spotkałem się z opiniami (np.

że atmele mają problemy z wydajnością w trybie 32bit z powodu wolnego flash'a. Czy rzeczywiście tak jest ? I jeszcze jedno pytanie - czy różne ARM'y, czy to philipsa, czy atmela są identyczne w programowaniu ? Oczywiście pomijam takie rozszerzenia jak usb czy ethernet, ale czy na przykład standardowa aplikacja komunikująca się z czymś poprzez standardowe porty IO będzie wyglądała identycznie dla mikrokontrolerów różnych producentów ?

[...]

Rzeczywiście procesory z rodziny AT91SAM7Sxx mają wolny Flash i mogą pracować z pełną wydajnością do max. 30 MHz. Jeżeli chcesz szybciej (np. do obsługi USB wygodny zegar 48 MHz) to trzeba włączyć 1 waitstate dla Flash'a. Niezłym rozwiązaniem jest kompilacja programu w trybie Thumb - wtedy procesor pracuje z pełną prędkością przy szybkim zegarze (1ws dla Flasha pozostaje ale procesor pobiera paczki 32-bitowe a rozkazy mają 16 bitów), do tego dodatkowo program robi się krótszy. Wystarczy włączyć opcje dla kompilatora i linkera -mthumb (ew. dodatkowo -mthumb-interwork jeżeli część kodu chodzi w trybie ARM).

"Gołe" jądro ARM jest dobrze wyspecyfikowane tyle że samo z siebie niewiele może. Ale już operacje na portach I/O zależą od konkretnych rozwiązań sprzętowych i miganie bitem I/O obsługuje się różnie w różnych ARMach. Atmel udostępnia wygodne pliki .h z definicjami adresów rejestrów i funkcjami inline do dostępu do nich. Philips pewnie też (nie sprawdzałem). AFAIR Philipsy mają problem ze zmianą stanu portów I/O z pełną prędkością pracy - był o tym problemie nawet artykuł w EP.

I jeszcze moje pytanie - moze nieco lamerskie - czy w Philipsach nie jest tak, ze maja tylko GPIO a nie maja wyprowadzonej magistrali danych ? Kiedys przegladalem katalog i to mi w glowie utknelo.

Mnie się też atmele bardziej podobają, ale to jest nadużycie ;-)

no właśnie, a porównujesz go do rdzenia ARM7 w philipsach Procesory oparte o ten rdzeń atmel również robi w podobnych szybkościach Poza tym do AT91RM9200 trzeba jednak troche dobudować a AT91SAM7x może być prawie "goły" - to są chyba układy do zupełnie innych celów.

Od siebie dodam że faktycznie AT91SAM7XC256 wygląda naprawdę nieźle i pewnie za jakiś czas wymieni atmege128 w moich projektach.

pozdawiam

LPC21XX nie mają magistrali, natomiast LPC22XX mają.

To już jest przeszlość. Nowe ARMy Philipsa np. LPC2148 mają szybkie I/O (15MHz bez problemu wyciągniesz).

Porównujesz mikrokontrolery z dwoma różnymi rdzeniami. Mikrokontrolery z rdzeniem ARM7 wypadają podobnie jeśli chodzi o maksymalną częstotliwość taktowania zarówno w przypadku Atmela jak i Philipsa. Z tego co wiem Philips ma zamiar wprowadzić nową rodzinę LPC3000 z rdzeniem ARM9. Przykładowo LPC3136 • ARM926EJ-S, 220 DMips • 32k I & 32k D caches • Vector Floating point Co CPU • MMU • USB Host/OTG • 7 Uarts…

Zeby nie było że faforuzuję Philipsy mi osobiście podobają się zarówno ARMy Philipsa jak i Atmela, tylko staram się aby dyskusja była w miarę obiektywna.

Wydaje mi się, że obniżona o połowę wydajność w trybie 32 bit to naprawdę ogromny minus Atmeli, w końcu nie po to kupuję procesor

32-bitowy, aby działać w trybie 16 bit i utrzymywać, że wszystko jest ok. Wygląda na to, że konkurencyjny lpc2148 jest 2x szybszy ! Chyba, że zbytnio upraszczam sprawę, ale AFAIK w przypadku mikrokontrolerów z wbudowaną pamięcią można prosto stwierdzić, że 2x większy clock daje 2x większą wydajność ..

Nawet jeżeli popędzasz program z pamięci RAM albo weźmiesz inny procesor i jedziesz z pełną częstotliwością zegara, warto zainteresować się trybem Thumb. Kod wynikowy wychodzi mniejszy o kilkanaście-kilkadziesiąt procent a spowolnienia praktycznie nie czuć. Gdy program chodzi z zewnętrznej pamięci przy magistrali 16-bitowej albo właśnie z tego badziewnego atmelowego Flasha 1ws - to przejście na kod 16-bitowy skutkuje znacznym przyrostem wydajności. Co ciekawe, procesor cały czas operuje na rejestach 32-bitowych a tylko kody rozkazów mają 16 a nie 32 bity. Jednak asembler Thumb wprowadza trochę ograniczeń (warunkowo wykonywać można tylko skoki a nie większość rozkazów, korzystanie z górnej połówki rejestrów jest utrudnione) więc kod nie wychodzi automatycznie 2x krótszy niż skompilowany w trybie ARM.