Debug Output auf UART

[markus]

Hi,

jetz hab ich den SIxO mal mit DEBUG übersetzt und das Kabel drangelassen... er hat mich nett begrüßt



Aber irgendwas mach ich falsch - mein Debug-Output kommt nicht ...

In main.c wird ja

Code: Alles auswählen

DebugSetFilterDetails(gDebugFilter, gDebugDetails)

aufgerufen, gDebugFilter und gDebugDetails scheinen aus den globalen Settings zu kommen (EPROM?).
Wie setzt man die?
Ich hab auch probiert, DebugSetFilterDetails mit fixen Parametern aufzurufen.

Oder anders gefragt: ich hab z.B. geschrieben

Code: Alles auswählen

ODS2(DBG_MEAS, DBG_INFO, "MonitorSetVehicleState(%s, %d)", szParm, dState)

aber es kommt nix...

Heißt das jetzt wirklich, dass er an dem Aufruf nie vorbeikommt, oder mach ich da was falsch?

Danke
Markus

[Ralf]

Hi Markus,

schön, dass das DebugOut bei dir funktioniert, ohne mag ich eigentlich garnicht mehr testen.

Wichtige Frage: Ich hoffe, dein Log geht noch weiter? Wenn nach deinem ScreenDump nichts mehr kommt, liegt da was im Argen!

> gDebugFilter und gDebugDetails scheinen aus den globalen Settings zu kommen (EPROM?).
Richtig, die DebugSettings werden als EepromSettings gepflegt (2 Bytes mit diversen Flags), die aut. im Eeprom geupdated werden, wenn du sie zur Laufzeit (DebugSetFilterDetaills) veränderst. Beim Booten werden sie einmalig aus dem Eeprom geladen.

> Wie setzt man die?
Du kannst die Settings mit DebugSetFilterDetaills() setzen/verändern wann/wie du willst, deine Einstellungen setzen sich immer durch. Der Aufruf in derInit-Phase in main() steht da nur, damit du es für dich anpassen kannst.

> Aber irgendwas mach ich falsch - mein Debug-Output kommt nicht ...
Lt. deinem Log sind alle Debug Features enabled (alle 4 Device-Filter, alle 4 Levelfilter), damit solltest du alles sehen können (und das Log zeigt es ja auch!).

> ODS2(DBG_MEAS, DBG_INFO, "MonitorSetVehicleState(%s, %d)", szParm, dState)
Hmm, der Aufruf sieht auch ok aus.

Ich kann keinen Fehler erkennen. Wenn du den ODS() Aufruf mit Paste&Copy entnommen hast, das File mit DEBUG compiliert hast (hast da ja wohl über die globalen TM30 C-Flags definiert) und sonst auch Ausschriften dieses Debug-Levels (DBG_FATAL: höchste, DBG_INFO niedrigste) siehst, kann es eigentlich nur noch daran liegen, dass der Code nicht aufgerufen wird.

Aus ISRs heraus sollten ODS() Makros übrigens möglichst nicht aufgerufen werden, da sie wg. des Uarts langsam sind und auch Ausschriften anderer Module stören würden.

Mein Vorschlag: Prüf doch mal, ob die Codezeile passiert wird, in dem du direkt vor dem ODS() eine LED aufflammen lässt.

Ralf

[markus]

Hi Ralf,

ersma Danke für Deine Antwort!

Verstehn tu ich da aber was noch nicht ganz... wenn ich einmal DebugSetFilterDetails mit fixen Parametern aufrufe, dann merkt er sich die Parameter als die globalen Debug-Einstellungen im EEPROM?

D.h. theoretisch könnte ich den Aufruf einmal mit reincompilieren, laufen lassen, und dann wieder rausnehmen

Deinen Tip mit der LED werd ich mal probieren, danke. Ist schon komisch, da muss er schon vorbeikommen. Sonst hätt ich auch keine vernünftigen Werte für Temperatur und Spannung. Hmm. Schau ma mal na seng ma's scho (würde der Kaiser sagen )

Gruß
Markus

[Ralf]

wenn ich einmal DebugSetFilterDetails mit fixen Parametern aufrufe, dann merkt er sich die Parameter als die globalen Debug-Einstellungen im EEPROM?

Richtig. Das betrifft prinzipiell alle Eeprom/NVRAM-Parameter: Damit nicht alle möglichen SW-Module gleichzeitig oder womöglich noch innerhalb einer ISR auf dem (langsamen) I²C-Bus 'herumrödeln', gibt es für alle globalen Parameter ein Arbeitskopie im RAM. Diese kann man benutzen/verändern etc. wie man will.

Das sysparam-Modul überwacht all diese Arbeitskopien und aktualisiert sie im Umlauf (insgesamt ca. 2 Sek. für alle Parameter), immer nur einen Parameter pro 100 ms. Du kannst das an den DebugOuts erkennen, wenn du z.B. den Gesamtkilometerstand änderst oder DebugFlags: Die Änderungen landen ohne dein Zutun automatisch - aber leicht zeitversetzt - im Eeprom/NVRAM.

Zweck der Aktion ist es, die Gesamtperformance nicht unter permanenten I²C-Bus Zugriffen leiden zu lassen und trotzdem ein möglichst glattes Interface für alle 'System-Parameter' für alle Module zu haben. Alternative wäre gewesen, alle globalen Parameter ausschliesslich über Funktionsinterfaces abzufragen/zu setzen. Aber das wollte ich mir damals (vor 2 jahren) nicht antun (heute evtl. eher).

Debug-Parameter werden jedoch über eine Interfacefunktion gesetzt.

D.h. theoretisch könnte ich den Aufruf einmal mit reincompilieren, laufen lassen, und dann wieder rausnehmen

Richtig. Gedacht war diese Möglichkeit fürs Debuggen während der Fahrt , zum Konfigurieren des DebugOuts am Motorrad über einen Dialog (Debug Out in ein spezielles 'Device', mit Scrollen auf dem Display, etc.) für Fehler, die im Labor nicht so richtig zu reporduzieren sind.

Bye, Ralf

[markus]

geht immer noch nicht...

Folgendes hab ich probiert, und zwar in main():

Code: Alles auswählen

[...]
Error = ParInitSystemPar();
Error = DebugSetFilterDetails(DBG_MEAS | DBG_INFO, DBG_UART); /* valid after ParInitSystemPar() */
Error = DisplInit();            /* prepare lcd output & clear screen */
[...]

Der letzte Output ist das ODS Statement vom Auslesen der Display Flags; danach liest er die Debug-Einstellungen, schreibt sie in die globalen Puffer, und Ende mit Debug Output... ich hab auch DBG_ALL statt DBG_MEAS | DBG_INFO als Filter versucht. Ging auch nicht.

Ich brauch ne Anleitung für Dummies!

[Ralf]

Dat is ja alles sehr komisch!!! Da weiß ich so aus der Entfernung auch nicht weiter, was ich vergessen haben könnte, in meinen Erklärunen. Hmmm...
g
Am besten, du zipst deine SW mal eben so wie sie is und mailst sie mir. ich schmeiß sie mal auf meinen SIXO und dann schau ich, wos klemmt. Das kann ich mal zwischendurch machen

Ok?