Atmel ARM9 - ktos juz dlubie ?

In the darkest hour on Tue, 7 Mar 2006 11:39:16 +0100, Pelos snipped-for-privacy@pelos.pl screamed:

Zamierzam. Jak tylko okiełznam ARM7. <:

Pelos napisał(a):

Bardzo fajny. Niezła wydajność jak za tą cenę, można podczepić tani SDRAM. Wykorzystujemy w firmie do niego gcc (pakiet gnuarm) kompilując kod jak dla 7tdmi.

Niezla maszynka :-) Jak rozumiem, trzeba do niego podlaczyc zewnerzna pamiec programu, zeby moc go uruchomic? Co jest zatem w tych 128kB ROM'u?

Pomyslec, ze ja sie męczę z napisaniem glupiego programu obslugi np. UART'a do LPC - a co dopiero musi byc przy takim wypasie i tych peryferiach :-)

Jack Houseman napisał(a):

Tak, trzeba doczepić na zewnątrz pamięć programu i RAM (w środku jest tylko 16KB na potrzeby bootloadera oraz cache). Może być SRAM albo SDRAM. W ROMie siedzi bootloader, który może zabootować procesor: z Flasha równoległego, szeregowego (DataFlash), z USB, z USARTu i chyba jeszcze czegoś. Najfajniejsze rozwiązanie to DataFlash, bo w 8-pinowej kostce można zmieścić 512KB czyli całkiem pokaźny program. Bootloader tą pamięć (lub jej część) przepisuje do RAMu i stamtąd odpala.

Można oczywiście wcisnąć soft do RAMu przez JTAG jeżeli ktoś tak lubi i olać bootloader.

Akurat UART w różnych ARMach Atmela obsługuje się praktycznie identycznie (porównywałem AT91RM9200 i AT91SAM7S256) więc po napisaniu jednego drivera można się spokojnie przesiąść na inny procesor. Chociaż pewnie w sterowaniu UARTem ARMy Atmela i Philipsa się jakoś znacząco nie różnią - no bo co tam można wymyślić inaczej. Inne rejestry, inne maski przerwań, ale zasada musi pozostać ta sama. Zabawa jest dopiero z napisaniem sterownika USB. A w AT91RM9200 mamy USB host. :)

No wlasnie to mialem na mysli - UART to pryszcz przy obsludze wlasnie np. USB czy ethernet, czy innych peryferiow jakie tam siedza....(choc i uarta tez trzeba przegryzc - co prawda przykladow na niego to chyba jest najwiecej :-)) Takie pytanko przy okazji dla tych co sa juz dalej w temacie. Gdzie sie wlasnie zaczynaja te najwieksze schody? Bo z jednej strony jest obsluga peryferiow - transmisji itd...bardziej sprzetowe rzeczy (czytaj duzo rejestrow, ktore trzeba odp. ustawiac i przegryzac sie przez tony literatury zeby to zrobic) czy tez moze bardziej problemowo/software'owe rzeczy? (nie wiem - obsluga jakiejs kompresji w locie czy jakies obliczenia matematyczne?). Bo tak na pierwszy rzut oka to programista systemow embedded to walczy glownie z tym, zeby udalo mu sie nawiazac komunikacje ze sprzetem :-) Natomiast sama logiczna warstwa programu wydaje sie przechodzic na drugi plan ;-)

Najgorszy to chyba jest ubytek czasu jaki trzeba poswiecic na opanowanie tematu, zanim zacznie sie z niego efektywnie korzystac. A jednoczesnie postep jest na tyle szybki, ze moze sie okazac, ze przez ten czas powstaly nowe rzeczy, ktorych powinno sie juz uczyc :-) Co prawda zauwazam, ze wiedza wyniesiona z poprzednich tematow sprawia, ze latwiej jest przegryzc nowe rzeczy - na zasadzie analogii i poznania tylko nowej specyfiki.

In the darkest hour on Fri, 10 Mar 2006 10:52:14 +0100, Jack Houseman snipped-for-privacy@chello.pl screamed:

Zmieniając procesor na większy dochodzisz do punktu, w którym możesz skorzystać z czegoś większego, gdzie te rzeczy już są zaimplementowane -

- np. z Linuksa.

Cholercia, ja zawsze musze byc krok do tylu :-) Ja dopiero mysle o RTOSie na zwyklego LPC...:-) A wracajac do linuksa - o ile dobrze rozumiem, to musi on miec juz wbudowana obsluge tych wszystkich peryferiow czyli byc portem pod konkretny procesor (rodzine). Samo Arm Core chyba nie zalatwi sprawy? Czy wszystkie peryferia sa tak samo sterowane we wszystkich producenckich odmianach procesorow?

Adam Dybkowski napisał(a):

Niestety roznia sie sporo :( Philips ma standartowy '550, z FIFO, a Atmel ma swoj z PDC.

Pozdr AK

Pelos napisał(a):

Nie trzeba - juz jest, poszukaj na

Pozdr AK

In the darkest hour on Fri, 10 Mar 2006 15:02:49 +0100, Jack Houseman snipped-for-privacy@chello.pl screamed:

(: zobacz uClinuxa w takim razie.

Nie, ale wpisując w google "linux <nasz-cpu>" zazwyczaj trafiamy na stonę kogoś, kto zrobił to już za nas. <:

Pelos napisał(a):

Nie widzę problemu - zabawę w firmie z AT91RM9200 zaczynaliśmy właśnie od starterkitu z domyślnie wgranym Linuxem. Pewnie da się ściągnąć odpowiednio przygotowane źródła z Sieci, w każdym razie były dołączone do starterkitu na CD.

Jack Houseman napisał(a):

W obrębie procków tego samego producenta jest identycznie albo bardzo podobnie. Ostatnio porównywałem AT91RM9200 z AT91SAM7S256 - UART identyczny, USB slave również (jedyna różnica 4 lub 8 endpointów).

In the darkest hour on Tue, 7 Mar 2006 12:34:19 +0100, Pelos snipped-for-privacy@pelos.pl screamed:

Ok. Będzie to z założenia połączenie ARM9 + FPGA. Jak przygotuję schemat zarysowy to podeślę...

In the darkest hour on Tue, 7 Mar 2006 15:07:43 +0100, Mister <wojpie@wywal_to.poczta.onet.pl> screamed:

Droga? Nie przesadzaj. Taniej podobnego zestawu nie kupisz. No - wyjątkiem są tutaj płyty routerowe, ale za dużo pinów marnuje się w nich na wzielo- krotnione porty eth. AT91RM9200 - 100zł, XC3S200 - 150zł, dotego odrobinę flasha i ramu dla obu + duperele typu trafo, max322 i można zrobić już w miarę ładną i uniwersalną podstawkę.