AVR: Ist PORTx |= atomar?

[Gerd (Gast)]

Kann man bei den AVR-Mikrocontrollern PORTC |= xx, PORTC &= xx und PINC 
= xxx (Toggle) schreiben, wenn Interrupt-Code im Programm ist, der 
gleichzeitig andere Bits in PORTC ändert?

Es ginge nicht, wenn dieser C-Befehle zu zwei Befehlen führen (Port 
lesen und schreiben), aber das ist nicht der Fall, oder?

[Writer (Gast)]

Gerd schrieb:
> PORTC |= xx, PORTC &= xx

Wie soll das bitte funktionieren ohne den Port vorher zu lesen? Atomar 
wäre nur PORTC = xx.

[Sebastian S. (amateur)]

Falls der Zäh-Compiler diese Befehle "richtig" umsetzt, sollte es gehen.
Schau doch mal in die Befehlsreferenz zum AVR um zu sehen, was geht.

So weit mir bekannt, gehen ?= mit einem Register und einer Konstanten. 
Wie die Werte aber in das (Vergleichs-)Register kommen ist eine andere 
Sache.

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

Jein. Bei Ports 0..31 und festem Einzelbit ist &= und |= atomar, sonst 
nicht.

[Einer K. (Gast)]

Gerd schrieb:
> Es ginge nicht, wenn dieser C-Befehle zu zwei Befehlen führen

Das kannst du im Assemblerlisting überprüfen und dir so selber 
beantworten.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Gerd schrieb:
> Es ginge nicht, wenn dieser C-Befehle zu zwei Befehlen führen
Er führt sogar zu noch viel mehr Befehlen, weil nach dem Lesen und vor 
dem Schreiben der Wert noch Verändert werden muss: Read-MODIFY-Write.

A. K. schrieb:
> Bei Ports 0..31 und festem Einzelbit ist &= und |= atomar, sonst nicht.
Das wird dann umgesetzt mit den Befehlen sbi und cbi

[Bla bla (Gast)]

Wie soll ein Compiler die die Grenzen eines AVR sprengen?

Wir wissen nichtmal, um welches AVR es geht. Jedoch werden die Ports 
über Adressregister auf dem Datenbus angesprochen. Es gibt zwar SBR und 
CBR Maschinenbefehle (einzelnes Bits setzen), die jedoch nur für 
Register in der CPU wirken.

Man muss die Ports immer erst auslesen, Bit ändern und das Ergebnis 
zurückschreiben.

Zumindest ist das bei einem Atmega8 etc. so.

[c-hater (Gast)]

Gerd schrieb:

> Es ginge nicht, wenn dieser C-Befehle zu zwei Befehlen führen (Port
> lesen und schreiben), aber das ist nicht der Fall, oder?

Kommt (mindestens) auf den Port und den Controller an. Bei Hochsprachen 
auch noch auf die Intelligenz des Codegenerators.

Hast du uns alles nicht verraten, also musst du die Datenblätter selbst 
lesen. Also das tun, was du sowieso hättest tun sollen, bevor du 
wildfremde Leute mit solchen Trivialitäten behelligst...

[Gerd (Gast)]

Ich verstehe keinen Assemböer. Hier der Code, wenn jemand helfen möchte. 
Es geht um PORTC vom ATMega1284: An dem läuft Software-SPI (s.u.) und 
andere Bits werden in Interrupts geändert. Im C-Code für SPI verändern 
die Makros SOFTSPI_SCK_TOGGLE(), SOFTSPI_MOSI_HIGH(), SOFTSPI_MOSI_LOW() 
den PORTC. CLI() notwendig?

Disassembly of section .text.softspi_write_byte:

00000000 <softspi_write_byte>:
   0:  98 2f         mov  r25, r24
   2:  2f b7         in  r18, 0x3f  ; 63
   4:  f8 94         cli
   6:  87 ff         sbrs  r24, 7
   8:  00 c0         rjmp  .+0        ; 0xa <softspi_write_byte+0xa>
   a:  41 9a         sbi  0x08, 1  ; 8
   c:  00 c0         rjmp  .+0        ; 0xe <softspi_write_byte+0xe>
   e:  41 98         cbi  0x08, 1  ; 8
  10:  81 e0         ldi  r24, 0x01  ; 1
  12:  86 b9         out  0x06, r24  ; 6
  14:  88 b1         in  r24, 0x08  ; 8
  16:  8c 7f         andi  r24, 0xFC  ; 252
  18:  88 b9         out  0x08, r24  ; 8
  1a:  96 ff         sbrs  r25, 6
  1c:  00 c0         rjmp  .+0        ; 0x1e <softspi_write_byte+0x1e>
  1e:  82 e0         ldi  r24, 0x02  ; 2
  20:  86 b9         out  0x06, r24  ; 6
  22:  81 e0         ldi  r24, 0x01  ; 1
  24:  86 b9         out  0x06, r24  ; 6
  26:  88 b1         in  r24, 0x08  ; 8
  28:  8c 7f         andi  r24, 0xFC  ; 252
  2a:  88 b9         out  0x08, r24  ; 8
  2c:  95 ff         sbrs  r25, 5
  2e:  00 c0         rjmp  .+0        ; 0x30 <softspi_write_byte+0x30>
  30:  82 e0         ldi  r24, 0x02  ; 2
  32:  86 b9         out  0x06, r24  ; 6
  34:  81 e0         ldi  r24, 0x01  ; 1
  36:  86 b9         out  0x06, r24  ; 6
  38:  88 b1         in  r24, 0x08  ; 8
  3a:  8c 7f         andi  r24, 0xFC  ; 252
  3c:  88 b9         out  0x08, r24  ; 8
  3e:  94 ff         sbrs  r25, 4
  40:  00 c0         rjmp  .+0        ; 0x42 <softspi_write_byte+0x42>
  42:  82 e0         ldi  r24, 0x02  ; 2
  44:  86 b9         out  0x06, r24  ; 6
  46:  81 e0         ldi  r24, 0x01  ; 1
  48:  86 b9         out  0x06, r24  ; 6
  4a:  88 b1         in  r24, 0x08  ; 8
  4c:  8c 7f         andi  r24, 0xFC  ; 252
  4e:  88 b9         out  0x08, r24  ; 8
  50:  93 ff         sbrs  r25, 3
  52:  00 c0         rjmp  .+0        ; 0x54 <softspi_write_byte+0x54>
  54:  82 e0         ldi  r24, 0x02  ; 2
  56:  86 b9         out  0x06, r24  ; 6
  58:  81 e0         ldi  r24, 0x01  ; 1
  5a:  86 b9         out  0x06, r24  ; 6
  5c:  88 b1         in  r24, 0x08  ; 8
  5e:  8c 7f         andi  r24, 0xFC  ; 252
  60:  88 b9         out  0x08, r24  ; 8
  62:  92 ff         sbrs  r25, 2
  64:  00 c0         rjmp  .+0        ; 0x66 <softspi_write_byte+0x66>
  66:  82 e0         ldi  r24, 0x02  ; 2
  68:  86 b9         out  0x06, r24  ; 6
  6a:  81 e0         ldi  r24, 0x01  ; 1
  6c:  86 b9         out  0x06, r24  ; 6
  6e:  88 b1         in  r24, 0x08  ; 8
  70:  8c 7f         andi  r24, 0xFC  ; 252
  72:  88 b9         out  0x08, r24  ; 8
  74:  91 ff         sbrs  r25, 1
  76:  00 c0         rjmp  .+0        ; 0x78 <softspi_write_byte+0x78>
  78:  82 e0         ldi  r24, 0x02  ; 2
  7a:  86 b9         out  0x06, r24  ; 6
  7c:  81 e0         ldi  r24, 0x01  ; 1
  7e:  86 b9         out  0x06, r24  ; 6
  80:  88 b1         in  r24, 0x08  ; 8
  82:  8c 7f         andi  r24, 0xFC  ; 252
  84:  88 b9         out  0x08, r24  ; 8
  86:  90 ff         sbrs  r25, 0
  88:  00 c0         rjmp  .+0        ; 0x8a <softspi_write_byte+0x8a>
  8a:  82 e0         ldi  r24, 0x02  ; 2
  8c:  86 b9         out  0x06, r24  ; 6
  8e:  81 e0         ldi  r24, 0x01  ; 1
  90:  86 b9         out  0x06, r24  ; 6
  92:  00 00         nop
  94:  88 b1         in  r24, 0x08  ; 8
  96:  8c 7f         andi  r24, 0xFC  ; 252
  98:  88 b9         out  0x08, r24  ; 8
  9a:  2f bf         out  0x3f, r18  ; 63
  9c:  08 95         ret

-----------

// A6: chip select
// A7: miso
// C0: clock
// C1: mosi

#define SOFTSPI_SCK_HIGH()     PORTC |=  BITMASK0
#define SOFTSPI_SCK_LOW()      PORTC &= ~BITMASK0
#define SOFTSPI_SCK_TOGGLE()   PINC   =  BITMASK0    /* setting a bit in PINx (like this, not |=) toggles corresponding bit in PORTx */
#define SOFTSPI_CS_HIGH()      PORTA |=  BITMASK6
#define SOFTSPI_CS_LOW()       PORTA &= ~BITMASK6
#define SOFTSPI_MOSI_HIGH()    PORTC |=  BITMASK1
#define SOFTSPI_MOSI_LOW()     PORTC &= ~BITMASK1
#define SOFTSPI_MOSI_TOGGLE()  PINC   =  BITMASK1    /* setting a bit in PINx (like this, not |=) toggles corresponding bit in PORTx */
#define SOFTSPI_MISO_READ()    PINA   &  BITMASK7
#define SOFTSPI_SCK_MOSI_LOW() PORTC &= ~(BITMASK0 | BITMASK1)

// send one byte using software SPI, unrolled (clock polarity: low when idle; phase: sample on rising edge of clock)

void
softspi_write_byte(uint8_t out)
{
  // port c (CLK, MOSI) shared with interrupt code

  uint8_t sreg =  SREG;

  cli();

  // SCK and /CS must be low when arriving here (setup by caller)

  // bit 7

  if (out & 128)
    SOFTSPI_MOSI_HIGH();
  else
    SOFTSPI_MOSI_LOW();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  SOFTSPI_SCK_MOSI_LOW();

  // bit 6

  if (out & 64)
    SOFTSPI_MOSI_TOGGLE();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  SOFTSPI_SCK_MOSI_LOW();

  // bit 5

  if (out & 32)
    SOFTSPI_MOSI_TOGGLE();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  SOFTSPI_SCK_MOSI_LOW();

  // bit 4

  if (out & 16)
    SOFTSPI_MOSI_TOGGLE();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  SOFTSPI_SCK_MOSI_LOW();

  // bit 3

  if (out & 8)
    SOFTSPI_MOSI_TOGGLE();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  SOFTSPI_SCK_MOSI_LOW();

  // bit 2

  if (out & 4)
    SOFTSPI_MOSI_TOGGLE();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  SOFTSPI_SCK_MOSI_LOW();

  // bit 1

  if (out & 2)
    SOFTSPI_MOSI_TOGGLE();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  SOFTSPI_SCK_MOSI_LOW();

  // bit 0

  if (out & 1)
    SOFTSPI_MOSI_TOGGLE();

  SOFTSPI_SCK_TOGGLE();                                // clock now high

  DELAY_50NS();

  SOFTSPI_SCK_MOSI_LOW();                              // this wil puit the first bit on MISO line

  SREG = sreg;
}

[Johann L. (gjlayde)]

Gerd schrieb:
> Kann man bei den AVR-Mikrocontrollern PORTC |= xx, PORTC &= xx und PINC
> = xxx (Toggle) schreiben, wenn Interrupt-Code im Programm ist, der
> gleichzeitig andere Bits in PORTC ändert?

SFR = val

ist atomar falls SFR ein 8-Bit SFR ist, unabhängig von Optimierungsstufe 
und Adresse des SFR.

PORTC |= xx
PORTC &= xx

Notwendige Bedingungen, dass das atomar ist (avr-gcc):

* PORTC ist ein 8-Bit SFR mit einer Adresse von __AVR_SFR_OFFSET__ bis 
__AVR_SFR_OFFSET__ + 0x1f, und die Adresse muss zur Compilezeit bekannt 
sein. (__AVR_SFR_OFFSET__ ist ein Built-in Makro von avr-gcc.) 
Alternativ kann PORTC eine Deklaration mit Attribut io_low sein.

* xx ist zur Compilerzeit bekannt, und xx ist exakte 2-er Potenz von 
0x1..0x80 (Fall |=) oder das 1-er Komplement einer solchen 2-er Potenz 
(Fall &=).

* Optimierung ist nicht -O0 oder -Og.

Es gibt jedoch ältere Compilerversionen, wo dies nicht hinreichend 
ist, z.B. wird bei 2× hintereinander SFR &= 0x7f das 0x7f erst in ein 
Register geladen, was dann zu LDI + 2*(IN+AND+OUT) führt.

Bei aktuellen Versionen (ab ca. 4.7) hab ich das noch nicht beobachtet, 
aber generell ist das nicht definitiv auszuschließen.

Eigentlich müsste sich mal jemand die Mühe machen, entsprechende atomic 
Built-ins zu implementieren, die dann ggf. LAS, LAT verwenden oder 
Interrupts temporär deaktivieren falls eine der obigen Bedingungen nicht 
erfüllt ist, z.B. xx keine 2-er Potenz ist oder Werte nicht zur 
Compiletime bekannt sind.

[Bla bla (Gast)]

Es ist unsauberer Stil, wenn du in einem Interrupt auf eine 
Hardwareressource schreibend zugreifst, welche auch im normalen 
Programmfluss verändert wird.

Wenn du sämtlichen hardwarezugriff im Interrupt verhinderst, bist du aus 
der Sache raus. oder aber der Hardwarezugriff auf diese Ressource 
passiert ausschlißelich im Interrupt.

[Johann L. (gjlayde)]

Gerd schrieb:
> ... Makros ...
> CLI() notwendig?

Ja, sieht so aus.  Denn xx ist nicht das 1-er Komplement einer 2-er 
Potenz, eine der o.g genannten notwendigen Voraussetzungen:

>   14:  88 b1         in  r24, 0x08  ; 8
>   16:  8c 7f         andi  r24, 0xFC  ; 252
>   18:  88 b9         out  0x08, r24  ; 8

0xFC = 0b11111100 ist nicht darstellbar als 0xff ^ (1 << n).

Die Makro-Definitionen wurden nicht genannt.

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

Bla bla schrieb:
> Es ist unsauberer Stil, wenn du in einem Interrupt auf eine
> Hardwareressource schreibend zugreifst, welche auch im normalen
> Programmfluss verändert wird.

Sind mehrere Portpins mit völlig verschiedener Funktion verschiedener 
Module eine gemeinsame Ressource? Alternative?

[LinTau (Gast)]

>Das kannst du im Assemblerlisting überprüfen und dir so selber
>beantworten.
Das würde ich so nicht unterschreiben, Du hast damit nur einen 
speziellen Fall geprüft.
Vor 5-10 Jahren. Kundenprojekt Microchip PIC + HiTech C-Compiler. Ein

BitStructIrgendwas.Bit42 = 1;

Wurde vom Compiler IM GLEICHEN Programm auf 4 verschiedenen Arten 
umgesetzt.

Dabei war sowohl ein:

assembler_bit_set byte007.4

als auch ein:

assembler_byte007 = 0;
assembler_byte007 |= 0x10;

Beim Setzen wurde also das Bit kurzzeitig sogar rückgesetzt. Was dazu 
führte, dass auf dem LIN Bus (Treiber lief im Interrupt) hin und wieder 
eine 0 gesendet wurde.

[c-hater (Gast)]

A. K. schrieb:

> Sind mehrere Portpins mit völlig verschiedener Funktion verschiedener
> Module eine gemeinsame Ressource?

Kommt 'drauf an. Nämlich im Kern exakt darauf, ob sie sich atomar 
ansteuern lassen. Der TO hat hier also durchaus eine wunden Punkt 
gefunden. Naja, nicht einen wirklich neuen...

Wer auf Nummer sicher gehen will/muss, nimmt halt einfach an, das es 
eine gemeinsame Resource ist und trifft die nötigen Vorkehrungen gegen 
unerwünschte Beeinflussungen.

Wer 100% sicher sein kann, dass er atomar zugreifen kann (Asm rules!), 
der kann darauf verzichten und den dadurch möglichen Speedup nutzen. And 
again: Asm rules...

C/C++ stinks...

[Johann L. (gjlayde)]

Gerd schrieb:
> #define SOFTSPI_SCK_MOSI_LOW() PORTC &= ~(BITMASK0 | BITMASK1)

Besser so:

#define SOFTSPI_SCK_MOSI_LOW()  \
    do {                        \
        PORTC &= ~(BITMASK0);   \
        PORTC &= ~(BITMASK1);   \
    } while (0)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

LinTau schrieb:
> BitStructIrgendwas.Bit42 = 1;
> Wurde vom Compiler IM GLEICHEN Programm auf 4 verschiedenen Arten
> umgesetzt.
>
> Dabei war sowohl ein:
>
> assembler_bit_set byte007.4
>
> als auch ein:
>
> assembler_byte007 = 0;
> assembler_byte007 |= 0x10;
Sehen allesamt korrekt aus.
Woher soll der Compiler wissen, dass du ihm per Interrupt in die Suppe 
spuckst und dort Daten aus dem Struct abholst?
Oder andersrum: Wenn Daten im Struct konsistnet sein sollen, dann muss 
diese Semaphore so gesteuert werden, dass während der Manipulation kein 
anderer Zugriff erlaubt wird.
Im einfachsten Fall geht das, indem man eine lokale Kopie anlegt, und 
dort drin herumrechnet. Wenn alles fertig berechnet ist, wird 
schlussendlich das lokale Abbild bei gesperrtem Interrupt auf den 
globalen Sendepuffer kopiert.

Oder kürzer: man sollte nicht dem Compiler die Schuld für ein falsches 
System-/Softwaredesign geben.