C: Assignment discards 'volatile' qualifier.

[Walter T. (nicolas)]

Guten Morgen,

ich habe den folgenden Quelltext, und frage mich, warum gewarnt wird: 
"warning: assignment discards 'volatile' qualifier from pointer target 
type":

#define RINGBUFFER_NBYTE 128

typedef struct Ringbuffer_s
{
    uint8_t rawdata[RINGBUFFER_NBYTE+4]; 
    uint8_t *data;                       
    int16_t first;
    int16_t last;
}
Ringbuffer_t;


volatile Ringbuffer_t Ringbuffer;


void ringbuffer_init(void)
{
    Ringbuffer_t volatile *Rb = &Ringbuffer;
    Rb->first = 0;
    Rb->last = 0;
    Rb->data = Rb->rawdata+2; // <== Warnung

    ...
}

Ringbuffer ist volatile. *Rb ist Zeiger auf ein volatile struct. 
Rb->rawdata ist ein Zeiger auf ein Array in einem volatilen struct. 
Rb->data ist ein Zeiger auf einen Zeiger in einem volatilen struct. Wo 
wird ein "volatile" verworfen? Wo liegt mein Denkfehler?

[DPA (Gast)]

Nunja, das

uint8_t rawdata[RINGBUFFER_NBYTE+4];

Ist wegen dem "volatile Ringbuffer_t Ringbuffer;" effektiv ein "volatile 
uint8_t[RINGBUFFER_NBYTE+4];" (Die Arrayelemente sind teil des Struct, 
deshalb sind diese auch volatile.). Das "uint8_t*" wird aber zu 
"uint8_t*volatile", nicht zu "volatile uint8_t*" (nur der Pointer ist 
teil des Structs, deshalb volatile.).

[Basic Programmierer (Gast)]

Das sind Stolperfallen, da kann man einem Compiler (-Bauer)
nur dankbar sein!

[Walter T. (nicolas)]

Hallo DPA,

danke! Das hatte ich übersehen. Manchmal hilft der zweite Blick.

Basic Programmierer schrieb:
> Das sind Stolperfallen, da kann man einem Compiler (-Bauer)
> nur dankbar sein!

Stimmt. Ohne die Warnung hätte ich das glatt übersehen. In der Hinsicht 
hat sich der GCC echt gut gemacht.

[Niklas G. (erlkoenig)]

Die Frage ist, ob man so eine komplexe Struktur wie einen Ringpuffer 
wirklich komplett "volatile" machen möchte. Das könnte ziemlich 
ineffizienten Code bewirken. Dass der Compiler die Schreib-und 
Lesezugriffe nicht wegoptimiert hilft dir bei gleichzeitigen Zugriffen 
aus ISR und mainloop sowieso nicht, weil die Variablen zwischendurch in 
inkonsistenten Zuständen sein können - das bringt nur was bei einzelnen 
Variablen, sofern die Plattform sie "atomic" behandelt (bei ARM: 
1/2/4-Byte-Variablen).

Vielleicht wäre es da sinnvoller, die Interrupts während der Zugriffe 
auf die Pointer/Zähler komplett zu sperren, und dann vor der Freigabe 
mit einer Optimization Barrier den Compiler dazu zwingen, sie 
herauszuschreiben:

__disable_irq ();
... Zeiger/Zähler bearbeiten ...
__asm__ volatile ("": : :"memory");
__enable_irq ();

Durch clevere Zugriffsalgorithmen kann man das Lesen/Schreiben der 
eigentlichen Daten außerhalb dieser Sperre vornehmen, und die 
geschriebenen/frei gewordenen Bereiche danach mittels Anpassung der 
Zähler/Zeiger (unter Interruptsperre) herausgeben:

__disable_irq ();
... Bereich zum Schreiben reservieren ...
__asm__ volatile ("": : :"memory");
__enable_irq ();

... Daten in Puffer schreiben ...

__disable_irq ();
... Soeben beschriebenen Bereich zum Lesen freigeben ...
__asm__ volatile ("": : :"memory");
__enable_irq ();

Das funktioniert so natürlich nur auf Single-Core-Controllern zur 
Synchronisation zwischen mainloop und ISR (oder verschachtelten ISR). 
Ansonsten wären noch Cache-Maintenance und/oder Mutexe oder Atomics 
nötig, was man dann das (RT)OS machen lässt.

Wenn die mainloop sowieso leer ist und der ganze Programmcode sich in 
ISRs befindet, welche nicht verschachtelbar sind (bzw. die 
verschachtelten Interrupts nicht auf den Ringpuffer zugreifen), ist das 
sowieso egal und man kann das volatile ganz weglassen; der Compiler 
sorgt dafür dass vor der Rückkehr aus der ISR alles zurückgeschrieben 
wird.

[Nick M. (Gast)]

Mir kommt die ganze Konstruktion schon äusserst suspekt vor!
Wozu gibt es überhaupt das "uint8_t *data". Eigentlich sollte das doch 
wohl in das array rawdata zeigen. Aber dafür hast du doch wohl das 
"first" als index. Mit dem *data musst du dann zwei Werte synchron 
halten.

Und so völlig suspekt wird es in der Funktion "ringbuffer_init". Warum 
nimmst du von der globalen "Ringbuffer" die Adresse und dereferenzierst 
sie immer wieder?
Prinzipiell ordentlich wäre es, den zu initialisierenden Ringpuffer an 
"ringbuffer_init" zu übergeben. Dann taugt die Funktion auch für einen 
zweiten Ringpuffer (Rx und Tx).

Wenn mir jemand so einen Code vorlegen würde, hätte er erheblichen 
Erklärungsbedarf! Massiv erheblich!

Nick