Hallo, mittlerweile kann ich ungefähr einschätzen, wieviel Code (per GCC compiliert) man in einen AVR mit z.B. 16kb Flash reinkriegt. Gibt es sowas wie einen Faktor, mit dem man ungefähr abschätzen kann, wieviel Flash man in einem ARM benötigt, damit man ungefähr gleich viele C-Befehle erreicht? Ich weiß schon - ist eine merkwürdige Frage. Aber ich hab keinen Anhaltspunkt ob mir jetzt ein SAM7S32 reicht oder ich gleich einen SAM7S256 benötige ... Mfg Thomas Pototschnig
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?
Öö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
Hi das dürfte stark von der Applikation abhängen. Bei viel 32 Bit Arithmetik dürfte der ARM-Code sogar kleiner sein als der des AVR. Bei 16 Bit würde ich den ARM etwas im Nachteil sehen bei reiner 8 Bit Rechnerei mit viel Stringverarbeitung würde ich den AVR deutlich vorne sehen. Matthias
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.