C# mono Projekt Unterschied Debug und direktes Ausführen

  • Hallo zusammen,
    ich bin gerade bei meinem ersten Raspi Projekt. Und zwar baue ich dieses hier nach:

    hdo26
    13. Oktober 2014 um 09:35

    Ich habe einen Raspberry Pi 3 mit Raspbian Jessie light und mono-complete.
    Einer der einzigen Unterschiede zu dem Projekt ist, dass ich ein 4*20 LCD Display habe. Habe den Code so umprogrammiert, dass ich jetzt mehr Zeilen/Spalten schreiben kann.

    Das Projekt ist ja in C# geschrieben. Um das Projekt remote debuggen zu können, benutze ich Xamarin Studio.
    Ich starte das Projekt auf dem Pi mit folgendem Befehl:

    Code
    sudo mono --debug --debugger-agent=transport=dt_socket,address=0.0.0.0:12345,server=y Jukebox/Jukebox.Runtime.exe

    Wenn ich jetzt das Projekt im Xamarin Studio starte, kann ich alles debuggen. Es läuft auch alles. Besonders auch die Anzeige auf dem LCD.
    Nun wollte ich das Projekt das erste mal "normal" starten. Also habe ich die beiden folgenden Befehle eingegeben:

    Code
    sudo chmod +x Jukebox/Jukebox.Runtime.exe
    sudo mono Jukebox/Jukebox.Runtime.exe

    Leider werden auf dem Display jetzt fast nur kryptische ASCII Zeichen angezeigt. Man kann zwischendurch mal ein bisschen was vom normalen Text, der dort eigentlich stehen sollte, sehen. Auch ist der Text oft z.B. in der falschen Zeile. Der Rest (Buttons etc.) scheint zu funktionieren.

    Warum funktioniert die Ansteuerung des LCD im Debug Modus, aber nicht im "normalen" Modus?

    Hoffe jemand kann mir da helfen.

    Vielen Dank für eure Antwort im Voraus!

    Mfg KAMPI

    P.S. mod: Hoffe es ist der richtige Forenteil für die Frage, sonst bitte verschieben

  • C# mono Projekt Unterschied Debug und direktes Ausführen? Schau mal ob du hier fündig wirst!

  • Hallo kampi,

    ich verstehe deine Fehlerbeschreibung nicht ganz genau, daher wollte ich noch einmal nachhaken:
    Die UI wird ganz normal dargestellt, einzig die Text-Komponenten haben ein eigenartiges Verhalten (also auch die auf den Buttons etc.) oder spinnt die ganze UI?

    LG
    Renão

    .NET-, Unity3D-, Web-Dev.
    Mikrocomputer-Hobbyist.

  • klingt nach Race conditions. Die treten dann im Debugger nicht auf, weil da ddas Programm langsamer abläuft. Ich würde mal alles was Threads benutzt darauf abklopfen.

  • Erst mal Danke für eure Antworten.

    Renão: Ich habe mal zwei Bilder gemacht, die das Problem vielleicht etwas deutlicher machen:

    So sieht es im Debug Modus aus:
    https://www.dropbox.com/s/njsabqfocnk5x6p/IMG_6181.JPG?dl=0

    So sieht es im "normalen" Modus aus:
    https://www.dropbox.com/s/p2t4a8ksmj68akp/IMG_6182.JPG?dl=0

    @deets: Können Race-Conditions denn, die in den Bildern zu sehenden, Sachen auslösen? Ich schaue mir die Threads mal an.

    Schon mal danke für weitere Ideen.

    Mfg KAMPI

    Einmal editiert, zuletzt von kampi (18. Januar 2017 um 13:47)

  • Ja, Sowas kann von Sowas kommen. Es ist zu viel Code um da mal eben selbst durch zu wuseln, mehr kann ich da also nicht zu sagen.

  • Also es scheint was mit der Schnelligkeit der WriteLine Befehle vom LCD zu tun zu haben.
    Habe mal ein bisschen mit Sleeps rumgespielt.

    Hier der Code:

    Mit Sleeps ist es schon besser. Aber das Phänomen ist erst fast weg, wenn ich wirklich an die angezeigten Stellen 500 bis 1000 Millisekunden Sleeps reinpacke. So viel schneller kann das Programm ohne Debugger ja aber garnicht sein. Habe im Debbuger auch mindestens jede Sekunde (das habe ich wegen der Sekundenanzeige des Liedes gesehen) ein Update des Displays bekommen. Die Zeilen ändern sich eh nur höchstens sekündlich. Ansonsten werden die eh nicht geschrieben. Ein wenig komisch finde ich das schon.
    Werde morgen mal weiterforschen.

    Mfg KAMPI

  • Die von __deets__ genannte Racecondition scheint mir auch am naheliegendsten zu sein. Wie verhält sich denn ein DEBUG-Build, bei dem die Compileroptimierung eingeschaltet ist bzw. ein RELEASE-Build, bei dem sie ausgeschaltet ist? Vielleicht bringen Dich ja diese Erkenntnisse auch weiter...

  • schnasseldag: Werde ich nachher mal ausprobieren. Aber noch als Info: Das Verhalten zeigt sich auch, wenn ich das gleiche Debug-Build "normal" starte. Zwischen der funktionierenden Ansteuerung im Debug Mode und dem nicht funktionierenden Ansteuern beim normalen starten ändere ich nichts am Code bzw. benutze genau das gleiche Build/Compilat.
    Aber auch in einem Realease Build funktioniert es nicht, wenn ich es normal starte.

    Mfg KAMPI

    P.S. LCD ist übrigens ein HD44780

  • Na was macht denn dein debugger? Der klemmt sich an den Prozess & verlangsamt dessen Ausführung - so wie deine sleeps.

    Ich hatte nach kurzem überfliegen eine Stelle gesehe, wo was mit tasks gemacht wurde. Diese und andere sind von Interesse.

  • Erst mal noch mal ein dickes Danke für eure Ratschläge und Bemühungen. Sehr nett von euch. Versuche die ganze Zeit das Problem einzukreisen.

    Aber er kommt trotz der Sleeps noch durcheinander.
    Habe das mal in eine Logdatei geschrieben. Da sieht man, wann er welche Zeile schreibt und wann er Garnichts schreibt und die Anzeige einfach so lässt wie sie ist.

    Ohne Sleeps hat er mit Debugger die ersten drei Zeilen immer mit einem Abstand von 5ms geschrieben und das alle 2 Sekunden. Ohne Debugger mit einem Abstand von 1ms und das alle 2 Sekunden. Habe gedacht daran könnte es liegen. Ist ja schon signifikant schneller.

    Jetzt habe ich nach jeden WriteLine einen Sleep von 100ms eingebaut. (Mit 5ms hat es im Debugger-Modus ja geklappt, dann müsste es mit 100ms erst recht gehen).
    Im Debugger schreibt er die Zeilen jetzt in einem Abstand von 105ms und ohne Debugger im Abstand von 101 ms. (Siehe unten).

    Es scheint wohl schon mit an der Zeit zu liegen, aber ganz beheben tut es das Phänomen nicht. Komisch ist, dass im normalen Modus, wenn das LCD zwischen durch wieder ASCII Zeichen schreibt, dass Display auf einmal Garnichts mehr anzeigt. Nach ein paar Sekunden dann wieder anfängt was anzuzeigen.

    Hier die Logs mit Sleep im Debug:

    Und hier ohne Debugger:

    Meine Update Display Funktion sieht im Moment so aus:

    Wie man sieht habe ich es auch mal testweise mit sehr hohen Sleeps vor nach dem setzen der Position versucht. Ausserdem auch ohne setzen der Position. Hat auch nichts gebracht.

    Mfg KAMPI

  • Hallo kampi,

    es scheint so, als hättest du irgendeine Asynchronität in deinem Programm - sei es durch den WriteLine Befehl oder durch wiederholtes Aufrufen der UpdateDisplay Methode.

    Ich könnte mir nämlich vorstellen, dass sich im Ablauf deines Programms die WriteLine-Befehle nämlich nach und nach überlagern und sich dadurch dieses Kauderwelsch an Buchstaben ergibt.

    Da ich jetzt nicht die komplette Aufrufhirarchie deines Codes kenne, würde testweise einfach mal die Schreibaufrufe künstlich synchronisieren.

    Also bspw. über ein einfaches Flag in der Klasse:


    Und dann ansonsten auf diese Art und Weise die Schreibzugriffe immer etwas mehr 'Einkesseln'.


    Sind die Ergebnisse denn okay, wenn du den Lauftext quasi deaktivierst und den Content-Skip rausnimmst?
    Dann könnte man nämlich ziemlich genau sagen können, dass die Schreibzugriffe sich da irgendwie gegenseitig beeinflussen, da diese in diesem Fall ja sowieso alle dasselbe Schreiben und daher ein konstantes Ergebnis zu erwarten wäre.

    .NET-, Unity3D-, Web-Dev.
    Mikrocomputer-Hobbyist.

  • Renão: Ohne Lauftext ist es das gleiche. Dann kommt es halt nicht so häufig vor, weil der Text ja immer nur geschrieben wird, wenn er sich ändert. Dann ändert er sich z.B. in Zeile drei nur bei einem Liedwechsel. In Zeile vier im Modus "Play" alle Sekunde wegen der Anzeige der aktuellen Zeit des Liedes.
    Wegen der Überlagerung versuche ich deinen Ansatz mal aus. Obwohl man von einer Überlagerung eigentlich auch was in den Logs sehen müsste, oder nicht?

    Melde mich nachher, wenn ich es ausprobiert habe.

    Danke auf jeden Fall!

    VG KAMPI
    Automatisch zusammengefügt:
    Habe es ausprobiert. Bringt keinen Unterschied. Habe auch ein Log geschrieben, wenn er in die neue Funktion reinkommt, wie da der Status des "es wird geschrieben" ist. Er war immer false. Also kommt er da nicht doppelt rein bzw. überholt sich nicht. Eigentlich ist das ganze Programm auch ein Cycle ohne verschiedene Threads. Kann also auch eigentlich nicht sein. Aber ausprobieren ist immer besser. Werde nachher mal weiterschauen.

    Was mir auch noch aufgefallen ist, dass er manchmal nur noch die 1. und 3. Zeile anzeigt, dafür die Helligkeit der Pixel sehr zunimmt. Schaue mal ob da irgendwas mit der Spannung der Displayversorgung ist. Obwohl ich nicht weiss, ob die anderes sein kann, als wenn das Programm im Debug Modus läuft.

    VG KAMPI

    Einmal editiert, zuletzt von kampi (19. Januar 2017 um 11:53)

  • Nicht unbedingt.

    Es kann sein, dass die Aufrufe

    * _lcdConnection.SetCursorPosition(int)
    * _lcdConnection.WriteLine(string)

    nicht wirklich synchron ablaufen, soll heißen es wird einfach nur extern ein Positionierungs-/Schreibvorgang angestoßen, aber nicht gewartet, bis dieser beendet ist und dadurch 'überholt' dein Code dann die Schreibvorgänge.

    .NET-, Unity3D-, Web-Dev.
    Mikrocomputer-Hobbyist.

  • Habe es jetzt mal ohne SetCursor gemacht, sondern nur dieses hier (Versuche mit 1000ms Sleep, mit 10ms, ohne Sleep und mit/ohne Clear). Immer das gleiche.

    Code
    _lcdConnection.Clear();
      Thread.Sleep(10);
    _lcdConnection.WriteLine(line1);
     Thread.Sleep(10);
    _lcdConnection.WriteLine(line2);
     Thread.Sleep(10);
    _lcdConnection.WriteLine(line3);
     Thread.Sleep(10);
    _lcdConnection.WriteLine(line4);

    Habe mal ein python Script probiert, welches ich im Netz fürs Display gefunden habe. Das funktioniert auch einwandfrei, wenn ich die Anzeige alle 10ms ändere.
    Habe mir auch von Githib die neusten Raspberry.IO dlls kompiliert.

    Mfg KAMPI

    Einmal editiert, zuletzt von kampi (19. Januar 2017 um 14:04)

  • Generell sollte es ja auch ohne Sleeps funktionieren. Eigentlich.

    Sprichst du direkt mit der API des LCDs oder einer bestimmten Bibliothek und handelt es sich um dieselbe(n) in Python und C#? Ich möchte nur verhindern, dass falsche Eindrücke entstehen, falls die beiden Programme "unten drunter" anders funktionieren.

    Bzw. kannst du der Einfachheit halber ggf. noch schreiben, um welches LCD es sich genau handelt?

    .NET-, Unity3D-, Web-Dev.
    Mikrocomputer-Hobbyist.

  • Hallo zusammen, habe heute wieder ein bisschen Zeit gefunden rumzutesten.
    Habe folgendes Script, welches man vielfach im Netz findet, etwas angepasst, damit man über Argumente Sachen in eine bestimmte Zeile schreiben kann. Dabei ist mir folgendes aufgefallen. Wenn ich z.B. in Zeile 1 zwanzig Einsen schreibe und dann danach das Programm wieder aufrufe und in Zeile 2 zwanzig Zweien, dann hat das Auswirkungen auf die erste Zeile. Manchmal verschwinden dort mal ein paar Zeichen (meist 4 am Stück) oder werden durch Zweien ersetzt. Das führt sich dann fort. Wenn ich was in die dritte Zeile schreibe ändert sich auch was in den beiden vorhergehenden. Die Zeile, welche ich aktuell schreibe, wird immer richtig dargestellt. Was läuft da falsch? Ich habe schon gedacht, dass das Display einen Schuss weg hat und habe ein neues gekauft. Aber bei dem ist es das gleiche.

    Hier der Code:

    Hier meine Aufrufe:
    Zum clearen des Bildschirms:

    Code
    sudo python WriteLinesOnLCD2.py 0


    Schreiben Zeile 1:

    Code
    sudo python WriteLinesOnLCD2.py 1 '11111111111111111111'


    Schreiben Zeile 2:

    Code
    sudo python WriteLinesOnLCD2.py 2 '22222222222222222222'


    Schreiben Zeile 3:

    Code
    sudo python WriteLinesOnLCD2.py 3 '33333333333333333333'


    Schreiben Zeile 4:

    Code
    sudo python WriteLinesOnLCD2.py 4 '44444444444444444444'


    Danke für eure erneute Hilfe im Voraus!

    VG KAMPI

    Einmal editiert, zuletzt von kampi (25. Januar 2017 um 10:28)

  • So, habe jetzt durch weitere Test rausgefunden, was das Problem mit dem Python Script bzw. dessen Aufruf ist. Der komische Zeichenversatz kommt von den ersten beiden Zeilen der Initialisierungsroutine im Script. Seitdem ich die rausgenommen habe, passiert das nicht mehr.
    Für mein Projekt habe ich es nun folgendermassen gelöst:
    Beim Programmstart lasse ich durch das Pythonscript einmal das LCD initialisieren (damit es funktioniert, wenn es mal stromlos war) und danach nicht mehr. Dann kann ich das Script sooft aufrufen wie ich will und alles wird sauber dargestellt.

    Warum das Ansteuern des Displays in C# und Mono nur im Debugger klappt und ohne nicht (was ja die eigentliche Frage in dem Thread von mir war) habe ich noch nicht herausgefunden und durch meine Lösung mit dem Python Script ist es jetzt auch nicht mehr nötig.

    Ich danke allen, die mir hier mit Rat zur Seite gestanden haben!! Sehr nett von euch.

    VG KAMPI

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!