Graphlcd-base st7565r Treiber hinzufügen - Proportionen verkehrt

    Moin,

    ich versuche aktuell mein altes Reelbox Gehäuse ,Frontpanel sowie das Display unter MLD (5.4 testing) zum Laufen zu bekommen. Hierzu hatte ich beits im MLD Forum meine Zwischenschritte dokumentiert.

    Ziel ist es den älteren st7565R Reel Treiber lauffähig zu bekommen.


    Nach Recherchen hier im Forum gab es schon vor einger Zeit von einem User den Versuch den Treiber zu aktualisieren, scheinbar ist das im Sand verlaufen.

    Die Basis des alten Reel Treibers ist wohl der simlcd Treiber, also habe ich versucht die Änderungen von dem Graphld-Base Release 0.1.3 zum aktuellen Stand auf den Reel Treiber zu Übertragen.


    Zuerst gab es keine Anzeige im VDR Betrieb, dann wurde wenn der VDR nicht aktiv war die Uhrzeit angezeigt. mit den letzten Änderungen von heute wird auch im VDR Betrieb mittlerweile etwas angezeigt, aber dei Proportionen sind nicht korrekt, die einzelnen Elemente werden zu groß dargestellt.


    Aktuell sieht die Anzeige so aus

    Ich bin un alles andere als ein C/C++ Experte,daher die Bitte ob sich jemand meine Anpssungen anschauen kann und evtl. das Problem findet.

    Im Anhang sind der Ur-treiber sowie der aktuelle Stand als auch die eingesetzte graphlcd.conf


    Danke im Voraus

    So ich habe nun etliche Variationen durchgetestet leider alle ohne Erfolg.

    Die Funktion setpixel, mach nicht das was sie tun sollte. Hat Irgendwer einen Tipp, warum die dortigen Bitmanipulation nicht das gewünschte Ergebnis liefert ?

    Puhh, so mittlerweile läuft es.

    Das Bild wirkt ein klein wenig gestaucht, kann mich aber auch täuschen.

    Ich räume den Code ein wenig auf und lade den Code später hoch.


    Hi,

    Würde nicht ein pull request in wastls Repo Sinn ergeben?

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

    Mal sehen. Vielleicht komme ich dazu mir das im laufe des Wochenendes mal genauer anzuschauen. Dann passe ich mir offensichtlich auffallendes entsprechend an und packe das in einen vorläufigen "Test-Branch".


    Was mir sofort auffällt:

    Was hat es denn mit "display mode" und "clock" auf sich? Hat Reel da einen eigenen Mikrocontroller davor und zeigt im "Standby" die Uhrzeit an? Kann ja kein Feature vom LCD-Controller selbst sein.


    ATS Was hat du rumliegen? Betriebsbereits LCD? Ich war vorhin am Überlegen ob man das nicht im Prinzip mit einem FT232RL an USB hängen könnte. Setzt natürlich voraus, dass das LCD entweder einen 3,3V oder 5V-Pegel am seriellen Port will. Eine anständige Doku zum Anschluss konnte ich aber auch noch nicht finden.


    Edit: Scheint mir langsam so, dass das ganze Ding "Reel-Proprietär" ist. Scheinbar kann das LCD "nur" SPI. Vermutlich hat Reel da einen Microcontroller davor, der vom PC via UART angesteuert wird. Dieser steuert das LCD dann via SPI an. Es dürfte also nicht möglich sein einfach ein "loses" LCD-Modul mit dem ST7565R-Controller zu kaufen und direkt an einen FT232RL zu hängen. Man müsste da selber einen Mikrocontroller zwischenschalten und zumindest ich sehe da weniger Reiz darin sowas anzugehen. Das lohnt doch eher für "größere" LCDs: https://github.com/M-Reimer/usbserlcd/


    Ändert aber nichts daran, dass es natürlich sinnvoll ist, den Treiber direkt im "offiziellen" graphlcd-base zu haben. Auch wenn er dann nur mit Reel-Hardware funktioniert. Reel-Frontpanels finden sich bei ebay durchaus. Müsste man dann halt trotzdem auf USB adaptieren. Ich passe mal das an was ich für richtig halte und melde mich dann wieder hier.

    Hi,

    ja das mit den Warnings ist aus den Tests, ich hab auch eine Fassung wo

    char buf[]={0xa5,0x09,m};
    dann zu

    char buf[]={'\xa5','\x09',m};

    dann benötigt es nicht den Schalter im Makefile.

    Ist im hier im Thread im ersten Posting. Kannn ich aber wieder auf den alten Stand bringen.


    Bzgl. der Nummerierung, da hab ich mich an die letzten commits gehalten, dort wurde im master

    https://projects.vdr-developer…df29047b6b38acd11f8274862

    der Treiber auf 23 gesetzt, da ich Touchcol genommen hatte (nutzt MLD) habe ich dieses Verfahren übernommen und es ist bei 23 geblieben.


    port.c, schaue ich mir an.


    Ja Reel nutz einen Controler und im Standby kann die Uhrzeit angezigt werden.

    Ich habe aus einem Umbau (auf OLED) noch das original Display hier liegen, wie das beschaltet ist kann ich leider nicht sagen, wenn nach der Bezeichnung (ES13BB0FLW) gehe, dann findet man

    http://www.panelook.com/ES13BB…9_LCM_overview_20097.html

    http://www.panelook.com/ES13BB…_LCM_parameter_20097.html

    sowie

    https://shop.chipcad.hu/tartal…/adatlapok/ES13BB0FLW.pdf

    Im letzteren sind mehr Details.


    Was die Ansteuerung angeht habe ich zum Verständniss (treiber) von hier bekommen

    https://edeca.net/pages/the-st7565-display-controller/

    ich kann Dir auch Reel Fronpanel inkl. Display zusenden.


    Bzgl. USB unterstützung das wäre sinnvoll, habe ich mich aber bisher noch nicht damit beschäftigt.

    Bitte ausprobieren:

    https://projects.vdr-developer…e.git/log/?h=st7565r-reel

    Ich habe den Treiber bewusst "st7565r-reel" genannt. Eventuell kann darauf basierend später tatsächlich ein "genereller" st7565r gebaut werden. Ich denke da vor allem an Embedded-Linux (die Displays gibt es zuhauf. Zum Beispiel bei Reichelt. Raspberry und Co. haben SPI onboard und könnten das LCD direkt treiben). Das LCD selber ist aber nicht "seriell" im Sinne von "Serieller Port am PC" sondern nutzt SPI. Die Wandlung am Reelbox-Frontpanel macht ein AVR-Mikrocontroller --> Reel-Proprietär.

    Gute Frage wo das herkommt. Eigentlich sollte mit dem LCD garnichts gemacht werden. Die Idee ist eigentlich, dass der alte Stand stehen bleibt.


    Kannst du mal eines der bei graphlcd mitkommenden Tools (z.B. showpic) nutzen und testen ob das Bild dann am LCD stehen bleibt? Wenn nein, dann ist das *nicht* das erwünschte Verhalten. Macht ja keinen Sinn ein Bild zum LCD zu senden und dann stattdessen ein weißes LCD zu bekommen.


    Füge mal auf Verdacht hier:

    https://projects.vdr-developer…reel.c?h=st7565r-reel#n84

    (Zeile 84)

    noch folgendes ein:


    Code
    port->DisableHangup();


    Eventuell erkennt die Display-Firmware, dass der Port "geschlossen" wurde und reagiert darauf. Das ist aber eigentlich unerwünscht.


    Uhrzeit via Skript aktivieren scheint mir auch am sinnvollsten. Im Prinzip gehört auch schon das "Nachführen" der Zeit nicht wirklich in den graphlcd-Treiber. Prinzipiell wäre es sinnvoller hier ein Programm zu haben, das erst die Zeit (einmalig) ins Display schreibt und dann auf "Uhrzeit" umschaltet. Dann könnte man sich auf graphlcd-Seite ganz auf die reine Display-Ausgabe beschränken. Wenn du da was bauen würdest (und das entsprechend Open-Source wäre) würde ich den graphlcd-Treiber hier nochmal anpassen. Auf dein Repository würde ich dann in der Treiber-Doku verlinken. Also für den vermutlich eher unwahrscheinlichen Fall, dass jemand tatsächlich diese Dokus liest :P


    Sobald dieser neue Treiber sauber ist, würde ich meinen Branch wieder auf "master" zusammenführen und dann einfach mal diesen Stand zur "Version 1.0" erklären und das im Git dann auch so taggen. Steht dann den Distributionen frei ob sie auf diesen Stand umstellen wollen oder weiterhin die Git-Version nutzen.

    HI,

    sowowhl mit der Änderung (in Zeile 84) als auch ohne bleibt bei showpic das Bild im Display. beim beenden von VDR das unveränderte Bild mit dem gefüllten Display


    Ich hab ja einige Befehle in u.a. (clear_display) im Deinit auskommentiert, sonnst kam es beim Bildwechsel (showprogress, Einzelbilder beim boot) quasi zu einem Flackern.


    Ohne das Auskommentieren führte der Aufruf von Showpic zu folgender Sequenz:

    Code
    displaymode.
set_clock cmd.
Clear.
refresh.
refresh.
clear_display cmd.
displaymode.
deint.

    Die wiederrum führte daszu, das kurz das Bild und gleich danach wieder die Uhrzeit eingelendet wurde. Vermutlich reicht es wenn ich nur den Displaymode weglasse, ich teste das nacher nochma.


    Was das Setzen der Uhrzeit etc. angeht. liegst Du absolut richtig, unter reel als auch bei mir erledigt dies reelfpctl, meine angepasste Version muss ich noch ein wenig aufräumen, dann kommt sie ins git.

    Hier kann man via -setclock, displaymode 1 usw. entsprechende Aktionen auslösen.


    -showpnm hat die obige Problematik im Vergleich zu showpic nicht, aber ich hab mir das noch nicht näher angesehen.


    Also nochmals ich teste bzgl. dem gefüllten Display und stelle dann noch das passende reelfpctl sowie reelbox-ctrld in meinem git bereit und dann sollte wie von Dir vorgeschlagen in der Doku darauf verlinkt werden, macht am meisten Sinn.

    So im Deinit wieder

    Code
    clear_display();

    aktiviert, dann wird beim VDR stop, das Display sauber geleert, allerdings führt das auch dazu, das ein showpic Aufruf nur kurz das Bild anzeigt und dann sofort das Display geelert wird.

    "clear_display" darf da nicht stehen. "showpic" sollte für alle Treiber gehen, weil einige sich damit sowohl "Boot-Logos" als auch "Shutdown-Logos" auf's LCD senden.


    Ich glaube aber den Fehler gefunden zu haben. Tausche mal in dieser Zeile:

    https://projects.vdr-developer…eel.c?h=st7565r-reel#n159

    (Zeile 159) das "GRAPHLCD_White" durch eine "0" (Null) und teste nochmal. Das VDR-Plugin sendet ein "Clear" an den Treiber wenn der VDR beendet wird. Mit obigem Fehler wird das LCD aber nicht "geleert" sondern "gefüllt".

    Hi,


    Treffer, das war das Problem. Für mein Verständniss, beim Ur-Reel Treiber wurde simlcd als Vorlage genommen, beim Portieren auf den aktuellsten Stand habe ich dies vom simlcd übernommen. Verstehe ich das richtig, das hier der simlcd quasi "invertiert", d.h. statt nichts an zu zeigen wird die Fläche gefüllt ?

    Gruß

    "Simlcd" arbeitet komplett anders. Hier wird eine Datei geschrieben die anscheinend eine Art "spezielle Bitmap" ist. Schöner wäre hier eigentlich gewesen direkt ein Bildformat zu schreiben. Dann könnte man sich das entsprechende "Anzeigeprogramm" auch schenken.


    Das zeigt allerdings, dass im "st7565r-reel"-Treiber da noch ein paar Kleinigkeiten anzupassen sind. Scheint mir so als würde unnötig viel Speicher verbraucht. Das Array müsste nur "unsigned char" speichern und auch nur ein Byte pro 8 Pixel. Scheint mir so als müsste ich da den Code von Reel nochmal genauer anschauen um zu sehen wie die das umgesetzt haben. Komme aber erst am Wochenende wieder dazu. Dann würde ich auch das Zeit-Setzen und die Funktion "clear_display" komplett raushauen.

    HI,

    Ich hab mich etwas missverständlich ausgedrückt, da der simlcd eine "Bitmap" schreibt, wird beim deinit eine "gefüllte" Bitmap erstallt, statt einer leeren.

    Dirty pages will ich mir nochmal anschauen, dabei werden nur die geänderten Pages übertragen.

    Der "Simlcd" schaltet beim "Clear" alle Pixel weiß. Mit dem Anzeigeprogramm würde man dann ein weißes Bild sehen. Ich gehe mal davon aus, das das so geplant ist, dass "Schwarz auf Weiß" gezeichnet wird.


    Simlcd arbeitet anders wie die Treiber die direkt mit Hardware sprechen. Bei Simlcd ist jedes Element im "zweidimensionalen Array" auch einem Pixel zugewiesen. Bei den meisten "Hardware-LCDs" ist aber jedes Element zuständig für 8 Pixel (ein Byte, 8 Bit). Wenn hier ein Bit gesetzt ist, dann "ist das Pixel an".


    Hier müsste die Logik vom "Original-Reel-Treiber" zumindest zum Teil wieder rein. Ich gehe davon aus, dass die ein "char-Array" genutzt haben.

    Bitte nochmal testen. Der jetzt hochgeladene Stand dürfte sauber sein. Ich hoffe ich habe das mit dem Display-Aufbau richtig interpretiert. Nicht das wir jetzt Segmentation-Faults bekommen weil nicht reservierter Speicher genutzt wird.


    Welches Tool (zum Setzen der Uhr) soll ich verlinken?


    Ich würde das dann, wenn alles funktioniert, nach "master" zurückmergen.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login