C++ Port für RP6 Lib

[Lurchi]

Hallo,

ich habe die RP6 Base Lib in C++ portiert. IDE ist Eclipse. Das ganze kompiliert und linkt. Auch ein erster Funktionstest mit den LEDs ist erfolgreich. Soweit ist alles gut.
Grundlage ist die aktuelle RP6 Lib, deren Funktionen ich in einem ersten Schritt nur in Klassen gruppiert habe. Die Funktion an sich blieb erhalten - also sollte grober unfug vermieden sein.

Leider habe ich wenig Schwierigkeiten mit den ISR Routinen. Offensichtlich steigt nach ca. 100ms (1000 Durchläufen der ISR) irgendwas aus.

Weiss jemand wie die ISR Routinen genau arbeiten? Was passiert, wenn eine ISR ihre Aktionen innerhalb der konfigurierten Timerinterruptzeit von 99us nicht beendet hat? Wird die ISR trotzdem nochmal aufgerufen?
Gibt es im winavr mutexe implementierungen oder kann ich "gefahrlos" mit globalen (volatilen) flags syncronisieren?

Wie kann man denn sowas sinvoll debuggen - den gdb kann ich ja wohl schlecht auf dem RP6 zum laufen bringen und den output via UART auf ein terminal geben - oder etwa doch?

Muss ich evtl. dem Compiler noch ein spezielle switches oder defines mitgeben?

Grüße

Lurchi

[Lurchi]

OK, eine Frage hat sich geklärt: https://www.roboternetz.de/wissen/in...gcc#Interrupts

"Dauert die ISR zu lange und wird sie nochmals von ihrem eigenen IRQ unterbrochen, stürzt man ab. "

Bleibt noch die Frage, wie ich feststelle, ob ich mich wirklich in dieser ISR selber überhole...

[thewulf00]

Mit volatilen Flags kannst Du gefahrlos synchronisieren.
Wenn Du sicherstellen kannst, dass die ISR von keinem weiteren IRQ unterbrochen wird (cli), geht nichts kaputt, aber Du verlierst evtl. Interrupts.

Debugging auf Embedded Systemen ist immer ein Problem.
Aber Du kannst die Zeit Deines ISRs ganz einfach messen:
Am Anfang der ISR einen PIN auf High und am Ende den gleich Pin wieder auf Low. Jetzt mit dem Oszi messen.

[SlyD]

Wie ist denn die Optimierung des Compilers eingestellt?
Sollte mindestens -O1 sein. Beim RP6 wird immer -Os (Programmgröße) verwendet. Komplett ohne Optimierung kann der Code schonmal länger brauchen...

MfG,
SlyD

[Lurchi]

Hallo,

im Moment arbeite ich komplett ohne Optimierungen - ich habe die Hoffnung nicht auch noch C++ Compiler Probleme zu bekommen. Der C++ Compiler ist für Embedded Systeme nicht sonderlich beliebt... Liegt wohl an den alten Vorurteilen gegenüber C++.

Mittlerweile habe ich den Fehler eingegrenzt... (Mit Hilfe von Debugcode - LED nach 1000 durchläufen ein nach weiteren 1000 wieder aus.)
Es war ist ein Fehler im Code und kein Timingproblem.

Hat eigentlich jemand Interesse an der LIB mitzubauen? Gemeinsam macht das wesentlich mehr spaß.

Lurchi