Asynchroner Datenaustausch in C

Nehmen wir an, du willst ein Array aus einer ISR an die main übergeben, 
dann könntest du zwei globale Bits erstellen: bReading, bWriting.

ISR:

while(bReading); // wait while reading from main is finished
bWriting = 1;
copyFromISR();
bWriting = 0;


main:

while(bWriting); // wait while writing from ISR is finished
bReading = 1;
copyToMain();
bReading = 0;

Die Methode mit Schattenregister (also faktisch double buffering) ist 
gängig. Man kann das auch recht einfach zu einem Ringpuffer mit 
FIFO-Semantik aufbohren. Das habe ich so schon häufiger genutzt. 
Interrupts ausschalten würde ich nur im Notfall machen. Manche CPUs 
haben Instruktionen für atomare komplexe Operationen, die sind ggf. 
nützlich als Alternative dazu.

C Programmierer schrieb:
> Nehmen wir an, du willst ein Array aus einer ISR an die main übergeben,
> dann könntest du zwei globale Bits erstellen: bReading, bWriting.

Und dann hast du einen Spinlock im IRQ. Halte ich tendenziell für 
gefährlich! Dann doch lieber Interrupts einfach deaktivieren, oder?

Erfahrungsgemäß die beste Variante -- erst mal nachdenken, ob sich 
Semaphore und FIFO vermeiden lassen. Oder ob man da überhaupt eine ISR 
braucht.

C Programmierer schrieb:
> ISR:
>
> while(bReading); // wait while reading from main is finished

Klasse Beispiel für einen perfekten deadlock:-)

C Programmierer schrieb:
> // wait while reading from main is finished

Irgendwelche Waits in der main zu haben ist nicht gut.
Warum soll ich auf einen Subtask warten, wenn ich was besseres zu tun 
habe.
Wenn in der main nix zu tun ist, dann legt man sich schlafen oder 
übergibt an den Idle-Task. Beim AVR meistens sleep.

UART-I/O kann man immer asynchron machen und die main via signale
über den aktuellen Zustand informieren.

Ich mache das schon immer so, dass ich einen Sende- und einen 
Empfangsringpuffer für den UART habe. Die ganze UART-Abwicklung macht 
die
zugehörige ISR. Jeweils eine für TX, RX und evt. UART_ERROR_HANDLING.

Viele habe damit ein Problem, weil sie sich nicht "virtuelle, 
asynchrone"
Abläufe vorstellen können.
Als Anregung kann ich nur jedem empfehlen sich mal mit einem "echten" 
RTOS
zu beschäftigen und die darin verankerte "Quasiparallelität" anzueignen.

Noch einer schrieb:
> Oder ob man da überhaupt eine ISR
> braucht.

Was ein Quark! Tja, wenn man von Interrupts keine Ahnung hat, dann 
kommen solche Empfehlungen heraus. -Gähn-

> Was ein Quark!

Recht nettes Beispiel ist das SD-Card Zeug aus der das alten PIC 
Library. main() ruft regelmässig AsyncWriteTasks() auf. Das schaut nach, 
ob die SPI Hardware inzwischen das Interrupt-Flag gesetzt hat. ISR wird 
nicht aktiviert.

Noch einer schrieb:
> alten PIC
> Library.

Man beachte "alten"!

Ja, Saubande! Bei der Portierung auf die neuen XC Compiler haben diese 
Knaller die Hälfte weggelassen. Benutzt nur Hardware, für die es ein gcc 
gibt.

Falk Brunner schrieb:
> Siehe Interrupt.
Darin sehe ich am ehesten den Abschnitt "UART mit Interrupts" als 
relevant an und das Beispiel dort empfinde ich als relativ speziell. 
Speziell deswegen, weil vorausgesetzt wird, dass man sein Protokoll 
selbst definieren kann (\0 am Ende). Wenn dies aber nicht der Fall 
ist...?
Der Mechanismus an sich ist aber natürlich anpass- und übertragbar.

Micha schrieb:
> Speziell deswegen, weil vorausgesetzt wird, dass man sein Protokoll
> selbst definieren kann (\0 am Ende).
Natürlich funktioniert das auch nicht wenn \0 ein gültiges Datum ist.