In den letzten Tagen beschäftige ich mich mit AVR-Mikrocontrollern. Um genau zu sein habe ich hier einen Atmega328p. Nun sagt dessen Datenblatt (in 8.5, I/O Memory, S.20), dass der Zugriff auf den gesamten I/O-Adressraum mit den Load- bzw. Store-Befehlen möglich ist. Zusätzlich kann eine Untermenge davon mit den I/O-spezifischen Befehlen IN und OUT angesprochen werden. Die Bit-Instruktionen lasse ich jetzt mal außen vor. Nun frage ich mich, wenn ich doch alles auch mit 'normalen' Load-/Store-Befehlen machen kann, warum den Befehlssatz mit 'special case' I/O-Befehlen verschandeln? Da ich mal davon ausgehe, dass die Atmel-Engineers schon einen Grund dafür gehabt haben, war mein erster Tipp, dass der I/O-Zugriff mittels Load/Store bei früheren/anderen AVR-Prozessoren vielleicht nicht möglich war und die In-/Out-Befehle daher im Befehlssatz vorhanden sind. In der Tat scheint das Instruction Set Manual das zu bestätigen: > For parts with SRAM, the data space consists of the Register File, I/O > memory and internal SRAM (and external SRAM if applicable). For parts > without SRAM, the data space consists of the Register File only. (aus der Befehlsbeschreibung für LD, S.87) Demnach nehme ich an, dass die I/O-Befehle auf AVR-Controllern ohne SRAM benötigt werden. Was mich jedoch verwundert, ist die Tatsache, dass diese Befehle auch vom Compiler (avr-gcc) generiert werden. Kein Compilerentwickler würde sich die Unterstützung der ausgiebigen Nutzung von irgendwelchen Spezialbefehlen antun, wenn diese keinen Vorteil brächten. Google ist leider nicht sonderlich hilfreich. Eine zufriedenstellende Antwort konnte ich so nicht finden, nur tonnenweise Tutorials und nutzlose Forenbeiträge. Vielleicht kann die Frage ja einer der AVR-erfahrenen Leute hier beantworten.
Oh, anscheinend habe ich was eigentlich offensichtliches übersehen: die Anzahl der zur Abarbeitung nötigen Takte. Hier unterscheiden sich die beiden Befehlsklassen (1 vs. 2 Takte). Ok, das ist ja schonmal was. Gibts weitere Unterschiede?
working directory schrieb: > Nun frage ich mich, wenn ich doch alles auch mit 'normalen' > Load-/Store-Befehlen machen kann, warum den Befehlssatz mit 'special > case' I/O-Befehlen verschandeln? Weil da der seperate address-lade-befehl entfällt und es somit für assembler-programmierer einfacher ist (AVR ist primär für Assembler gedacht)
Nein nicht ganz, AVR ist für Hochsprachen optimiert worden, doch AVR sollte trotzdem einfach in Assembler zu programmieren sein. 8051 wurde für Assembler optimiert.
working directory schrieb: > Gibts weitere Unterschiede? Die Länge der Befehle: 1 Wort vs 2 Worte. Das dürfte auch der Grund für die unterschiedliche Laufzeit sein.
Dr. Sommer schrieb: > Weil da der seperate address-lade-befehl entfällt und es somit für > assembler-programmierer einfacher ist (AVR ist primär für Assembler > gedacht) Hmm, gibt's dafür nicht den STS-Befehl der Form 'sts Konstante, Register'? Analog mit LDS. Aber ok, hier weist das ISM gleich daraufhin, dass die nicht auf allen MCUs existieren. Ich seh gerade, dass es sogar eine 16-Bit-Form von LDS/STS gibt, die eine 7-Bit-Adresse enthält und somit wie die I/O-Befehle auch nur einen Takt benötigt.
Hi >Weil da der seperate address-lade-befehl entfällt und es somit für >assembler-programmierer einfacher ist ... Welcher 'seperate address-lade-befehl'? >(AVR ist primär für Assembler gedacht) Das sieht Atmel aber anders: http://www.atmel.com/Images/doc1497.pdf MfG Spess
working directory schrieb: > Ich seh gerade, dass es sogar > eine 16-Bit-Form von LDS/STS gibt, die eine 7-Bit-Adresse enthält und > somit wie die I/O-Befehle auch nur einen Takt benötigt. Auf den Zwerg-AVRs mit erheblich reduziertem Befehls- und Registersatz und entsprechend kleinem Adressraum. ATtiny4 oder so.
Ok STS/LDS hab ich vergessen. spess53 schrieb: >>(AVR ist primär für Assembler gedacht) > > Das sieht Atmel aber anders: Jaa. Deswegen hat AVR auch so tolle Offset-Adressierungen, Barrel-Shifter, einheitlichen Adressraum (für einfache Pointer), einen Adressraum dessen Pointer in ein Register passen, etc... Die behaupten ja auch: > Optimized to speed time-to-market, they [AVR] are based on the industry's > most code-efficient architecture for C and assembly programming. No other > microcontrollers deliver more computing performance with better power > efficiency.
Dr. Sommer schrieb: > Jaa. Deswegen hat AVR auch so tolle Offset-Adressierungen, > Barrel-Shifter, einheitlichen Adressraum (für einfache Pointer), einen > Adressraum dessen Pointer in ein Register passen, etc... Nu bleibt auf dem Teppich. AVR stammt aus den 90ern. Nenn ein paar Architekturen dieser Zeit, die deinen Wünschen entsprach, und die in der Chipfläche vergleichbar zu AVR war. Heute zieht dieses Argument nicht mehr so recht, aber damals waren die Chipstrukturen etwas grösser als heute.
A. K. schrieb: > Nu bleibt auf dem Teppich. AVR stammt aus den 90ern. Ist ja schön, aber Atmel behauptet das jetzt, und jetzt gibt es da schon andere Kandidaten...
Dr. Sommer schrieb: > Ist ja schön, aber Atmel behauptet das jetzt, und jetzt gibt es da > schon andere Kandidaten... Na was sollen die denn sagen? Leute kauft nicht bei uns, kauft bei der Konkurrenz? Sowas wie "most code-efficient architecture for C" ist natürlich Quark, aber so redet man im Marketing eben.
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.