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
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
Und noch etwas, was vielleicht vom Compiler abhängt: Wird die Struktur vorher überhaupt initialisiert? Implizit vom Compiler zur Startzeit?
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
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?
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
>..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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.