Posts by kampi

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!


    Habe es gerade selber rausgefunden. Hatte nicht drauf geachtet, als was die m3u Dateien gespeichert waren. Sie waren als "ANSI" gespeichert. Habe sie nun geöffnet und dann als "UTF-8" neu gespeichert. Dann funktioniert es natürlich auch mit dem Laden der Playlist im MPC.


    Mfg KAMPI

    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

    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

    Ich habe mal eine Frage:
    Bei mir läuft der MPD sauber, ich habe nur ein Problem beim laden von Playlisten mit dem Befehl "mpc load 'Playlistname'". Wenn in den Einträgen (Liste von MP3s) in der Playlist Umlaute vorkommen lädt er die Playlist nicht. Die Name der Playlist selber kann Umlaute enthalten. Auch kann ich die MP3s, welche Umlaute im Dateinamen haben mit "mpc add 'Dateiname.mp3'" ohne Probleme laden und abspielen. Es muss also an den Einträgen in der Playlist liegen.
    Die Playlisten sind m3u Dateien und in der mpd.conf ist UTF-8 eingestellt.


    Danke für eure Antworten im Voraus.


    VG Christian

    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

    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:[hr]
    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

    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

    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

    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

    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

    Hat sich erledigt. Habe mit folgenden Befehlen Erfolg gehabt. Nun kann das Programm ohne Probleme auf den MPD zugreifen.


    Code
    sudo /usr/bin/mpd --stdout --no-daemon --verbose
    
    
    sudo systemctl stop mpd.socket


    Jetzt funktioniert soweit alles inkl. Buttons, RFID, LCD, etc.
    Ein Problem habe ich jetzt aber noch. Vielleicht kann mir da wer weiterhelfen.


    http://www.forum-raspberrypi.d…g-und-direktes-ausfuehren


    Vielen Dank im Voraus.


    Mfg KAMPI


    P.S. Mit sonix Genehmigung kann ich gerne meinen veränderten Quellcode für das Projekt zur Verfügung stellen, wenn alles läuft.

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


    http://www.forum-raspberrypi.d…nder?pid=175963#pid175963


    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

    Hallo zusammen,
    habe mich auch mal an den Bau einer Jukebox gemacht. Habe das Projekt von sonix nachgebaut.
    Ich habe nur ein Problem mit seinem C# Programm. Wenn ich irgendwelche Befehle an den MPC schicke, passiert gar nichts. Ich kann auf einer SSH Console ganz normal den MPC bedienen. Auch mit einem Windows Programm geht das.
    Ich habe mal mit dem Xamarin Studio remote debugged und er läuft eigentlich sauber durch alle Funktionen durch.
    Hat dazu jemand eine Idee?
    MPD Version ist die 0.19.0


    Danke für eure Antwort und Hilfe im Voraus.


    VG Christian