Was könnte Atmel beim Mega88 (und ähnliche) bewogen haben, die GPIOR1 und GPIOR2 Register im IO-Bereich >1FH anzusiedeln? Deren Stärke ist doch gerade der schnelle Bitzugriff via CBI/SBI! Statt dessen gähnende Leere auf 0-2, CH-15H, 18-1AH = "Reserved". Na prima. Muß mich eben ärgern weil im Glauben an Atmels Vernunft deshalb soeben ein fertiges Programm Makulatur geworden ist :-((
Max schrieb: > weil im Glauben an Atmels Vernunft deshalb soeben > ein fertiges Programm Makulatur geworden ist :-(( Sicher, daß schon 3 zusätzliche Zyklen Deine CPU völlig überlasten? Dann war aber Dein Konzept schon vorher knirsch auf knack.
Peter Dannegger schrieb: > Max schrieb: >> weil im Glauben an Atmels Vernunft deshalb soeben >> ein fertiges Programm Makulatur geworden ist :-(( > > Sicher, daß schon 3 zusätzliche Zyklen Deine CPU völlig überlasten? > Dann war aber Dein Konzept schon vorher knirsch auf knack. Ja Peter, das ist aber jetzt auch nicht gerade eine Erklärung...
Max schrieb: > Ja Peter, das ist aber jetzt auch nicht gerade eine Erklärung... Die Erklärung ist, Atmel versuchte wohl nachträglich das IO-Register Chaos etwas entwirren. Und daher haben sie diesen Platz für die Portpins der höherbeinigen AVRs reserviert (ATmega164 .. ATmega2560).
Peter Dannegger schrieb: > Und daher haben sie diesen Platz ... > reserviert (ATmega164 .. ATmega2560). Toll. Interessiert eigentlich wenig, was für irgendwelche anderen Controller reserviert wird. Zumal wenn sowieso das Register-Chaos regiert. Peter Dannegger schrieb: > Dein Konzept schon vorher knirsch auf knack. Nee, kurz und knapp! Schöner Asm-Code wärs gewesen. Den eigentlichen Daseinszweck "Flagregister" muß man GPIOR1 und 2 hier leider absprechen- sinnlos entwertet auf dem Alltar zukünftiger Reservierungen. Zum Glück ist das bei den 16 der Xmegas anders.
Max schrieb: > Nee, kurz und knapp! Schöner Asm-Code wärs gewesen. In Assembler kannst Du doch einfach CPU-Register für Bitvariablen verwenden (R16..31).
Register? Die sind alle fix vergeben... Ist jetzt alles kein Drama, mich hat nur interessiert was Atmel zu derart praxisfremden Entscheidungen treibt. Daß es dafür wohl keine vernünftigere wie Deine Begründung zuvor gibt hatte ich aber schon befürchtet.
Max schrieb: > Register? Die sind alle fix vergeben... Ist jetzt alles kein Drama, mich > hat nur interessiert was Atmel zu derart praxisfremden Entscheidungen > treibt. Das ist ein keiner Art und Weise praxisfremd. Es ist nun mal das von Atmel deutlich ausgedrückte Konzept der Modularität. Was du beschreibst ist das Resultat dieser Politik. Das hat sein Vorteile und Nachteile. Wenn du das nicht möchtest, dann musst du dir einen Mikrocontroller-Hersteller wählen der eben nicht dezidiert auf diese Konzept setzt. Eben aus dem von dir kritisierten Grund sind die Atmel so beliebt in der Hobbyszene. Man kann sehr einfach auf einen anderen (größeren) Mikrocontroller portieren.
>Max schrieb: >> Nee, kurz und knapp! Schöner Asm-Code wärs gewesen. >>In Assembler kannst Du doch einfach CPU-Register für Bitvariablen >>verwenden (R16..31). Nein, eben nicht, ein SBI, CBI und so geht nur fuer die unteren Register. fuer die oberen muss man andere Konstrukte verwenden.
hilfe ein wahnsinniger schrieb: > Nein, eben nicht, ein SBI, CBI und so geht nur fuer die unteren > Register. Na und? In R16..R31 nimmst du statt sbic, sbis, sbi und cbi halt sbrc, sbrs, sbr und cbr. Die brauchen alle genau dieselben Takte wie ihre jeweiligen Pendants für den IO-Bereich. Der einzige Unterschied ist die erweiterte Semantik von sbr und cbr, aber die ist eher von Vorteil als von Nachteil. Der einzige substantielle Nachteil ist halt ein wenig mehr Schreibarbeit bei diesen Befehlen, statt cbi reg,bit muß man halt cbr reg,1<<bit schreiben. Und wenn einen das zu sehr nervt, dann schreibt man sich halt seine eigenen Befehle, die Verhalten und Schreibweise von cbi/sbi exakt nachahmen, aber letztlich cbr und sbr benutzen. Macros machen's möglich: .macro bset sbr @0,1<<@1 .endmacro .macro bclr cbr @0,1<<@1 .endmacro Und schon hast du zwei neue Befehle, die in einem CPU-Register zwischen R16 und R31 genau dasselbe tun und genauso lange dauern wie sbi/cbi in einer IO-Adresse unter $20. Ein besonders fähiger Asm-Programmmierer bist du irgendwie nicht. Aber das wird vielleicht irgendwann noch...
@EE Ach was. Was spricht denn dagegen die GPIORs auf sinnvolle Adressen zu legen? Nicht mehr, nicht weniger. Ich gehöre auch zu den AVR Fans, aber solche Entscheidungen kann ich nicht nachvollziehen. Was ist denn daran Konzept- bedingt?
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.