Code-Dichte von ARM7 vs AVR

Ich habe etwas gesucht. Von der Leistung hören sich die Teile ja recht
fett an. 94I/O und 50Mips sind fast 3mal Mehr, als man bei einem
kleinen ATmega hat und damit kann man sicher schon etwas
Datenverarbeitung hinbekommen und zwischen Festplatten kopieren usw.
Besonders integrierte USB2.0 Funktionen hören sich cool an.

Woher bekommt man die aber? Wie teuer sind solche coolen chips, die
auch wirklich Leistung haben als Grafikkarte zu fungieren und wo man
nicht wie bei einem Atmel höchste Geschwindigkeitsprobleme hat?

Abo vergessen ;-)

Ööh ... das war jetzt aber nicht wirklich eine Antwort auf meine Frage
^^

Egal - dann versuch ich mal deine Fragen zu beantworten:
>Woher bekommt man die aber?
>Wie teuer sind solche coolen chips, die [...]
Die dürfte es in der Zukunft vermutlich überall dort geben, wo es auch
die AVRs gibt. Der SAM7S werden übrigens auch von ATMEL hergestellt.
Das Interessante ist, dass die auf den 8Bit-Markt abzielen. Ich hatte
mal ein Angebot eingeholt, bei dem der SAM7S64 nur ca. 3,50EUR gekostet
hätte bei einer Abnahme von 5 Stück.

>[...] auch wirklich Leistung haben als Grafikkarte zu fungieren und wo
man
>nicht wie bei einem Atmel höchste Geschwindigkeitsprobleme hat?

Dafür gibt es wieder neue Anwendungsbereiche, bei denen man wieder
sofort Geschwindigkeitsprobleme hat. Ich denke da an Audio und Video
Applikationen.

Als Grafikkarte würde ich einen ARM7 auch nicht benutzen - sowas macht
man doch mit FPGAs (siehe meine Seite:
http://www.oxed.de/index.php?open=2&sub=3&side=pal/overview.html)

So im Großen und Ganzen sind die ARM7 schon wirklich sehr nett und
gerade die SAM7-Familie von Atmel hat wirklich brauchbare Peripherie
drin. Support von GCC ist natürlich selbstverständlich. Programmiert
werde die über UART oder USB. Dazu haben die einen Bootloader schon
dabei ... usw ...

Mfg
Thomas Pototschnig

Interessante Frage (der Vergleich der Code-Groesse)

Da für beide frei GCC existieren, sollte das recht "einfach" zu
untersuchen sein. Interessant ist dann auch, den ARM und Thumb mode mit
zu betrachten....

abo

zur verfuegbarkeit: ich werde meine bei csd bestellen...

Kleine Programme, die sehr dicht an den I/O-Registern hängen, dürften
beim ARM tendenziell deutlich grösser ausfallen. Allein schon aufgrund
der häufigen 32bit-Adressen der I/O-Register, gegenüber vielen
6-Bit-Adressen beim AVR. Die grössere Wortbreite bringt da nur selten
einen Vorteil.

Und der ARM will initialisiert werden. Einiges davon wird beim AVR
schon durch Fuses festgelegt, z.B. die Taktung, beim ARM durch Programm
(wer mal beim M32c reingeschmeckt hat, der kennt das schon). Allein der
Startup- und Verwaltungskram für Taktung, Speichersteuerung, Thumb-Mode
Interrupt Dispatch usw, kann durchaus auf 500-1000 Bytes kommen.

Wer also partout einen 2K-Tiny2313 durch einen ARM ersetzen will, der
wird kaum unter 8K glücklich werden.

Anders dürfte es aussehen, wenn man ein 50-100KB AVR-Programm portiert.
In dem der meiste Code nicht direkt I/O nutzt, sondern wenige
I/O-Routinen nutzt. Und man erhebliche Mengen Daten im ROM hat - die
sich beim AVR nur umständlich verwenden lassen (erst recht beim GCC).
Da wäre ich nicht erstaunt, wenn der Grössenunterschied bei Thumb-Code
eher gering ausfällt.

@thomas: Danke. Ich habe hier schon einen FPGA herumliegen, aber bis ich
etwas sinnvolles damit machen werde ist es noch besser als mein TV- test
AVR mit 256 Farben. Wobei das mit 32 Bit schon wieder so ist, dass ich
da wieder shiften müsste, es sei denn, ich mache Farbwerte...
Wenigstens für kleine SW-Displays kann man mit so viel Power viel mehr
machen. Da stört das >4* mehr Shiften sicher auch nicht so viel man hat
ja auch viel mehr Power :-)

Ich denke so wie so eher an andere Dinge.