ARM Daten Hilfe

Wie schnell so ein ARM im Vergleich zum AVR ist hängt (natürlich)
von der Anwendung ab. Wenn die Aufgabe im Wesentlichen darin
besteht IO-Pins zu toggeln, ist ein ARM nur dann schneller wenn
er seine höhere mögliche Taktfrequenz ausnutzt. Die 32Bit nutzen
ihm da nichts.

Der ARM7 ist ein echter 32Bit Prozessor. Die 16/32Bit beziehen sich
wohl auf die beiden Befehlssätze (Thumb/ARM). Im Thumb-Mode ist
jeder Befehl wie auch beim AVR 16Bit breit. Die CPU arbeitet dann
aber trotzdem mit 32Bit. Die Befehle sind nur etwas weniger
leistungsfähig und man braucht daher oft mehr davon als es bei den
32Bit ARM-Befehlen nötig wäre um eine Operation durchzuführen.
Unterm Strich spart man aber etwas Programmspeicher ein.

Punkten kann ein ARM gegenüber dem AVR wenn viele 16/32/64Bit
Operationen durchgeführt werden oder große Datenmengen von A nach B
geschoben werden sollen.

Zu den Grenzen erstmal eine Gegenfrage: Wo liegen deiner Meinung
nach die Grenzen des dir schon bekannten AVR?
Einen 60MHz ARM7 kann man noch als MP3 Player verwenden. D. h. ohne
externen Dekoder.
Für Linux ist mir der ARM7 etwas zu schwach. Das wird imho erst auf
einem ARM9 mit zusätzlicher MMU interessant. Wegen des schon zwingend
erforderlichen externen Speicher ist auch der Aufwand für einen ARM7
zu groß.

Die JTAG Adapter können afaik alle ARM7/9 programmieren. Ich würde
dir aber empfehlen mit einem ARM7 wie dem SAM oder dem LPC2000 zu
beginnen. Für die Teile gibt es reichlich Beispiele im Netz und
wenn dir die Leistung für irgendetwas nicht reicht kannst du dann
immer noch auf den ARM9 gehen.

Dann ist da noch der 'ARM7 Nachfolger' Cortex-M3. Luminary und ST
bieten Controller mit diesem Kern an. NXP soll angeblich im Laufe
des Jahres folgen. Der M3 hat einige Vorteile gegenüber dem ARM7,
insbesondere beim Interrupt Handling und er kann in Hardware
dividieren. Ich arbeite privat und beruflich seit knapp einem
Jahr mit dem ARM7. Die meiner Meinung nach eher kleinen Vorteile
des M3 rechtfertigen zur Zeit keinen Wechsel. Zumal die neuen Chips
sich ersteinmal bewähren müssen. In diesem Jahr wird das sicher
nichts mehr. Aber da du ja noch nichts mit dem ARM7 zu tun hattest
sind die ja vielleicht etwas für dich?

Wegen dem AT91SAM: Lass dich nicht davon beirren das Atmel
so tolle 8Bit Controller baut. Der SAM ist ein ganz anderes
Kaliber der mit dem AVR nichts zu tun hat. Orientiere dich lieber
an den Datenblättern/Erratas verschiedener Hersteller (v.a. NXP) und
den verfügbaren Beispielprogrammen. Vergleiche die Peripherie
(verfügbare IO Leitungen), überlege dir ob du jede Schaltung mit
dem JTAG Adapter programmieren willst und wie die Alternative aussieht.

Danke für deine Antwort. Worin für mich die Grenzen eines AVR liegen ist 
zum beispiel ein sehr einfaches Fernsehbild in s/w oder wiedergabe von 
midi dateien. Er kann einfach zu wenig mit seinen 16 MHz.

mit einem ARM könnte ich doch z.B. ein Farbbild erzeugen, einen MP3 
Player auf Software bauen, USB Schnittstelle benützen, etc. etc.

Mal so ganz nebenbei, wo kauft ihr denn eure ARM µCs, in Österreich 
lassen sich die Dinger nicht so gut finden

>Die meiner Meinung nach eher kleinen Vorteile des M3
>rechtfertigen zur Zeit keinen Wechsel.


Hmmmm, vernünftiger Interruptcontroller mit fester Latenz von 12 Zyklen 
anstatt Ärger mit spurious Interrupts und variablen Latenzen von 24 - 42 
Zyklen, Bitbanding für schnelles I/O anstatt Load/Store sind also 
"kleine Vorteile"?

Für mich sind das massive Vorteile.
Einziges Argument für den ARM7 ist die Tatsache, daß bei ihm mehr Fehler 
bekannt sind, da er länger auf dem Markt ist.
Für den Umstieg vom AVR auf den ARM ist der Cortex ansonsten sicherlich 
wesentlich besser geeignet.

Thumb2 kommt erst im Mainline erst mit GCC4.3, aktuell ist aber noch 
GCC4.2(.2). In der Codesourcery Toolchain ist der Thumb2 Support 
allerdings schon eine ganze Weile enthalten, und sollte damit auch mehr 
als ausreichend stabil sein.

@ Dieter:
Die Interrupt Latenz dürfte für einen überwältigenden Anteil der User 
ziemlich egal sein, und wer schnelles Bitbanging braucht sollte wohl 
eher einen anderen uC verwenden, der die gewünschte Funktionalität in 
Hardware mitbringt. Der Cortex-M3 ist "nett", in meinen Augen aber v.a. 
eine Möglichkeit für ARM, neue Lizenzen zu verkaufen - ein schlagendes 
Argument, die bewährten ARM7 zugunsten eines Cortex-M3 aufzugeben sehe 
ich bisher nicht.

@Stark Arm
MP3 in Software dürfte einen 50MHz ARM7 ziemlich auslasten (ein 70MHz 
Modell hat dann also noch einige Prozent Reserve). Auf einem ARM9 mit 
180MHz bleibt wohl eine Last von 20-30% übrig. Ein ARM9E mit seinen DSP 
Befehlen schneidet dann nochmal ein Stück besser ab.

"USB Schnittstellen" in Form eines USB Hosts findest du nur bei größeren 
ARMen, z.B. AT91RM9200 (ARM920T), EP93xx (ARM920T) oder AT91SAM926x 
(ARM926EJ-S). Aber auch die sind allesamt Full-Speed, also maximal 12 
Mbps.
Eine Ausnahme bildet da der LPC24xx (ARM7TDMI-S), der einen USB 
Controller mit Device, Host und OTG Funktionalität mitbringt (auch nur 
Full-Speed). Hier bleibt aber die Frage, welche Funktionalität sich 
sinnvoll in dem ARM7 integrieren lässt - USB Speichersticks wären sicher 
möglich.

Ein Farbbild zu generieren ist sicherlich möglich, die Frage ist, worauf 
du das Bild anzeigen möchtest. LCD Displays gibt es mit einer Vielzahl 
unterschiedlicher Interfaces, für VGA wirst du um einen zusätzlichen 
Chip kaum herumkommen. Einige ARM uCs bringen integrierte LCD Display 
Controller, teilweise gehen die aber zu Lasten der Systemperformance 
(StrongARM war da ein unrühmliches Beispiel). Wenn's bewegte Bilder sein 
sollen steigen die Anforderungen nochmals gewaltig an.

Gruß,

Dominic

Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau 
doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU).

MP3 in Software wurde schon mit verschiedenen ARM mit < 50 realisiert.

Ich kenne mich mit AT90Sam und LPC oder diesen M3 nicht so gut aus. Mir 
geht es vor allem um möglichst viele MIPS, gute und schnelle 
Interruptsteuerung und schnelle IO. Welcher Controllertyp ist da am 
besten von denen geeignet?

< 50 MIPS meine ich

@Dieter:
Das sind alles Gründe den M3 anstelle eines 8Bit µCs einzusetzen.
Derzeit besteht ja noch eine beachtliche Kluft zwischen den 8Bittern
und dem ARM7. Einen ARM nimmt man ja üblicherweise dort wo viele
Daten bewegt werden müssen oder man eine relativ hohe Komplexität in
der Software hat (z.B. Maschinensteuerung mit RTOS). Latenzen und
primitive IO werden da immer unbedeutender.
Sicher wird es dünn für den ARM7: Von unten kommt der M3 (obwohl der ja
an sich nicht auf einfache Anwendungen beschränkt ist) und von oben der
ARM9. Wer allerdings bereits den ARM7 einsetzt kann Stand heute aber
dabei bleiben. Zunächst sind es Microchip, Atmel und die diversen 8051
Hersteller die den M3 fürchten müssen.

@Stark Arm:
Prinzipiell ist der M3 dem ARM7 gerade in diesem Bereichen überlegen.
Schau dir aber die Datenblätter von den Controllern an und Vergleiche
die Peripherie. Der Kern ist nicht alles.
Für den Einstieg in die M3 Welt finde ich das LM3S6965 Eval-Board
von Luminary recht interessant. Dieser STM32-Primer ist auch witzig.
Doch ich habe auch so schon genug zu tun ;)

Danke für die vielen Infos, ich weiß noch immer nicht wirklich mit 
welchen ARM ich weitermachen soll. Am liebsten würde ich bei ATMEL 
bleiben, weil ich auch viel mit AVR gemacht habe und ATMEL Produkte gut 
kenne. Reizen würde mich aber die LPC Reihe.

@Dominic R.: Ich weiß, mit einem ARM9 wird man niemals eine PS2 machen 
können. Das Beispiel war mehr als Vergleich gedacht. Schau dir mal den 
Sprung von PS1 zu PS2 und den Unterschied zwichen PS2 und 3 an. Da ist 
das zweitere schon viel gewaltiger. Aber sowas wie eine PS1 sollte schon 
drin sein, auch wenn man einen zusätzlichen Farbsignal IC verwenden muss

> Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau
> doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU).

Man kann Prozessoren nicht einfach nach der Taktrate beurteilen, denn es 
spielt eine große Rolle, was der Prozessor pro Takt erledigt.
Bei der Emotion Engine der PS2 handelt es sich um einen MIPS R5900 Kern 
(sowas ähnliches wurde früher in Workstations eingebaut und hat mit 
Embedded nicht allzuviel zu tun) mit FPU und zusätzlichen 
Vektoreinheiten, wie Dominic schon erwähnt hat. Die CPU ist also 
hochgradig superskalar, was ein Embedded-Prozessor von der Stange 
üblicherweise nicht ist.
Dazu kommt, daß die CPU bei aktuellen Spielekonsolen sich ohnehin nur um 
den generellen Ablauf, Künstliche Intelligenz und einen Teil der 
Berechnungen kümmert (bei der PS2 mehr als bei anderen). Die PS2 hat für 
die Grafik noch den sog. Graphics Synthesizer, bei dem das VRAM über 
eine 2560-Bit Bus (kein Tippfehler!) angebunden ist.

Auch die alte Playstation hat mit einem 30 MHz MIPS R3000A nicht gerade 
die schnellste CPU, aber sie muß überwiegend die ganzen Spezialchips 
steuern:
- SPU kümmert sich um den Ton
- GTE macht geometrische Berechnungen
- GPU rendert und schickt das ganze an den Fernseher

Ohne solche Spezialchips bekommst du bestenfalls Grafik in der Art vom 
alten Pac-Man, Spaceinvaders oder Atari VCS. Selbst der C64 konnte nur 
über den (für damalige Verhältnisse) sehr guten VIC-II bessere Grafik 
darstellen.

Sehr interessant, solche Dinge wusste ich gar nicht. Woher denn, wenn 
man die ganze Zeit nur mit 8 Bit bei 16 Mhz beschäftigt ist.