GPIOR1,2,3 beim tiny gar nicht über IO erreichbar?

[Jan (Gast)]

Nabend.

Ich glaub ich steh grad auf dem Schlauch.... aber beim attiny88 ist zwar 
der GPIOR0 via sbi und cbi erreichbar, aber die höheren sind es nicht. 
WTF? Wie soll ich die denn da oben elegant für Flags benutzen? Bei den 
anderen tinys und megas, die ich so kenne, sind alle 4 im IO-Space.

[Jan (Gast)]

Damit ist gemeint, dass man sie mit sbi/cbi/sbic/sbis ansprechen kann.

[Rolf M. (rmagnus)]

Laut Datenblatt liegt GPIOR0 an I/O-Adresse 0x1E, GPIOR1 auf 0x2A und 
GPIOR2 auf 0x2B. Wie kommst du darauf, dass die letzteren beiden nicht 
per sbi erreichbar seien?

[(prx) A. K. (prx)]

Weil diese Bitbefehle nur die I/O-Adressen 0x00..0x1F (Datenadressen 
0x20..0x3F) ansprechen können. Und da liegt eben nur GPIOR0 drin. IN/OUT 
haben 6 Adressbits, die Bitbefehle aber nur 5.

[Rolf M. (rmagnus)]

(prx) A. K. schrieb:
> Weil diese Bitbefehle nur die Datenadressen 0x20..0x3F bzw I/O-Adressen
> 0x00..0x1F ansprechen können.

Hmm, stimmt. Das war mir gar nicht bewusst. Ich dachte immer, dass die 
den ganzen I/O-Bereich abdecken. Dann sind GPIOR1/2 tatsächlich recht 
sinnlos, und das Datenblatt ist diesbezüglich fehlerhaft. Das behauptet 
nämlich, dass das mit allen GPIORs ginge:

"ATtiny48/88 also contains three general purpose I/O registers that can 
be used for storing any information. See GPIOR0, GPIOR1 and GPIOR2 in 
“Register Summary” on page 277. These general purpose I/O registers are 
particularly useful for storing global variables and status flags, since 
they are accessible to bit-specific instructions such as SBI, CBI, SBIC, 
SBIS, SBRC, and SBRS."

[(prx) A. K. (prx)]

Jan schrieb:
> Bei den
> anderen tinys und megas, die ich so kenne, sind alle 4 im IO-Space.

In der Entwicklung der AVRs galt anfangs ziemlicher Wildwuchs, was die 
Adressbelegung im I/O-Bereich anging. Die war bei jeder Baureihe anders. 
Irgendwann fand Atmel es bei den Megas passend, den Adressraum über die 
verschiedenen Typen hinaus zu vereinheitlichen.

Und so hat eben der ATmega88 die gleiche Adressbelegung wie der 
ATmega2561. Und folglich riesige Löcher im bitadressierbaren Bereich, 
während beim dicken Kollegen alles mit mit seinen vielen Ports, Timern 
und Interrupts vollgestopft ist.

Die meisten Tinys blieben davon verschont, auch neuere. Der ATtiny88 ist 
allerdings nur dem Namen nach ein Tiny, technisch jedoch ein 
funktionsreduzierter ATmega88.

[Peter D. (peda)]

Ich überlasse es einfach dem Compiler, wie er bool Variablen anlegt und 
benutzt.
Ob man mit viel Aufwand und deutlich schlechterer Wartbarkeit des Codes, 
ein paar ppm Laufzeit einsparen könnte, merkt der Benutzer eh nicht.

[Stefan F. (Gast)]

Nutzt der gcc überhaupt einzelne Bits für bool Variablen? Ich dachte die 
kleinste nutzbare Einheit seien 8 bit.

[(prx) A. K. (prx)]

Peter D. schrieb:
> Ich überlasse es einfach dem Compiler, wie er bool Variablen anlegt und
> benutzt.

CBI/SBI sind immerhin atomar. Der Ersatz ist es nicht. Aber defensiv 
programmiert sollte man solche Tricks nur dann nutzen, wenns wirklich 
brennt.

[Oliver S. (oliverso)]

Stefan ⛄ F. schrieb:
> Nutzt der gcc überhaupt einzelne Bits für bool Variablen?

Macht er natürlich nicht, und schon gar nicht in irgendwelchen 
IO-Registern.

Oliver

[Jan (Gast)]

sbic
rcall

Auf dieses elegante Konstrukt verzichtet man in C? lol.

[foobar (Gast)]

Aus

  int foo()
  {
      PORTB |= 8;
      if (PORTB & 64)
          bar();
  }

macht der gcc:

  foo:
        sbi 0x5,3
        sbic 0x5,6
        jmp bar
        ret

[Jan (Gast)]

Es geht hier aber nicht um Port-Bits, sondern um Flags. Damit meine ich 
selbstredend "custom user data" flags.

[Jan (Gast)]

Aber nagut, ich gehe davon aus, dass PORTB durch GPIOR0 substituierbar 
ist.