Ringbuffer - In Pointer Überlauf

[Thomas R. (Gast)]

Servus zusammen!

Habe ein Problem mit meinem Ringbuffer.

Die RX Interrupt Routine greift auf den Buffer schreibend zu.

Die main methode "pollt" den Buffer und fragt ab ob ein element 
vorhanden ist, wenn ja dann decodiert sie dieses Zeichen. Das 
funktioniert auch in etwa. Aber ich habe mir auf der Hostseite ein prg. 
geschrieben dass mit bytes zum testen schickt. Irgendwann verläuft sich 
der Outpointer ins "nirvana"-> d.h. er nimmt werte an die größer als der 
buffer sind.

Der Code befindet sich im Anhang.


Wo liegt hier mein denkfehler????

Vielen Dank im Voraus Für die Hilfe

lg
Thomas

[Rainer (Gast)]

Hallo Thomas!

Du solltest auch versuchen, beim Lesen aus dem Ring-Puffer Interrupts zu 
verbieten. Ich bin den Code zwar nicht genau durchgegangen, aber mit 
Sicherheit lässt sich hier eine Ablaufreihenfolge finden, mit der sich 
der Outpointer ins Nirvana schicken lässt.

Grüße,
Rainer

[Rainer (Gast)]

Und noch etwas, was vielleicht vom Compiler abhängt: Wird die Struktur 
vorher überhaupt initialisiert? Implizit vom Compiler zur Startzeit?

[Thomas R. (Gast)]

danke für deinen Beitrag.
Ja die Struktur wird initialisiert.

Auch wenn ich die Int aus und einschalte beim lesen, läuft immer so ca. 
beim 400ten Element dass ich in den Buffer geschrieben habe der INPTR 
ins nirvana. Nie der Outptr.

Wer kann mir das Erklären?

Kann das einen grund haben dass die Pos Variablen 16 bit lang sind der 
speicher selbst aber nur ein 8 bit speicher ist?

Oder liegt das problem in der main wo ich ja dauernd abfrage ob im 
puffer elemente sind, wenn ja dann lese daraus. Diese abfrage dürfte ja 
auch keine Probleme machen oder?

Was mache ich da falsch - Bin für jeden tipp dankbar

VIELEN Dank im Voraus

[Karl H. (kbuchegg)]

Grundsätzlich solltest du alle Zugriffe auf diese Struktur
gegeneinander verriegeln. NumElements fungiert schon so
einigermassen als diese Verriegelung. Lediglich beim
Schreiben würde ich die Zuweisung des Fehlercodes noch
vor die Erhöhung des NumElements ziehen, sodass die Erhöhung
bzw. Verringerung von NumElements immer die absolut letzte
Operation an der Struktur ist. Hat aber, wenn ich richtig
gedacht habe, nichts mit deinem Problem zu tun.
In der Leseroutine musst du klarerweise auch die Interrupts
disablen. Es ist wichtig, dass sich immer nur eine Funktion
an der Struktur vergreift und sie modifiziert, egal wie die
Interrupts auftreten. Dürfte aber auch nichts mit deinem
Problem zu tun haben.

Dann bleibt nur noch die Brechstange: Könnte es sein, dass dein
Problem gar nicht in diesen Strukturen und den Funktionen
zu finden ist? Da InPtr ganz am Anfang der Struktur liegt
und du nur bei deisem Member seltsame Effekte siehst (denn
eigentlich kann der InPtr nicht überlaufen), dass du ein
vällig anderes Array überläufst und dadurch den InPtr
zerstörst?

[Thomas R. (Gast)]

wow vielen dank für deine Tipps.

Habe das problem glaube ich mittlererweile in den griff bekommen. InPtr 
und OutPtr sind ja die Indexe des Array's das als Buffer dient. Habe die 
jetzt auch als 8bit unsigned deklariert. nun funktionerts..... (Ich 
vermute dass es vielleicht hier zu einer "ungewollten" optimiertung des 
compilers gekommen ist)

Vielen dank an alle

[Wolfram (Gast)]

>..zu einer "ungewollten" optimiertung des compilers gekommen ist

Sowas passiert, wenn man das kleine Wörtchen "volatile" nicht benutzt.
Kritisch ist alles wo du von 2 Seiten schreibend zugreifst, solange du 
von einer Seite liest und der anderen schreibst gibt es kein Problem.

buff->NumOfElements ist auch kritisch, hier kann während des decrements 
in
"readFromBuffer" ein Increment kommen. Die Nummer der Elemente im Puffer 
kannst du über den Abstand der 2 Zeiger  buff->OutPtr,buff->InPtr 
ermitteln.
Wenn die Zeiger 8Bit sind, ist auch die maximale mögliche Anzahl der 
Elemente
8bit.