Unsinnige IO-Locations für GPIOR!

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...

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.

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?