Beiträge von M-Reimer

    da stellt sich für mich noch die frage welches denn das beste ist .. also auch support von graphlcd aus .. ohne patches usw .. wäre ja schön wenn es dann einfach geht

    Mir ging es um diese IPS Displays mit USB Anschluss:

    https://www.amazon.de/dp/B0BCGFWMN8/


    Der Gedanke war dann erstmal Support für das "fertige LCD" in graphlcd nachzurüsten. Dann hätte man wieder was fertiges das mit graphlcd funktioniert. Und wenn man dabei schon lernt wie das Protokoll funktioniert könnte man auch irgendwelche Arduino TFTs nutzbar machen. Passende wären dann aber erstmal zu finden, denn 3,5" sind mir einfach zu klein.


    Aber alles nicht relevant für deinen Fall. Was da als Protokoll vermutlich am besten passt ist mein schon erstelltes "usbserlcd" Protokoll. Fehlt "nur" die komplette Umsetzung auf dem Arduino um von usbserlcd auf deine VFDs zu sprechen.

    Hi,

    Und warum nicht gleich die damals schon angesprochenen Displays in Farbe mit dem ili Chipsatz nutzen, gab ja verschiedene Größen. Hatte ich ja damals mal bestellt. Das eine sehr günstige war Müll ohne Controller, aber die anderen dürften gehen und sind ja für Arduino schon supported. Das dürfte den Aufwand ja senken.

    MfG Stefan

    Im Prinzip sicher machbar. Bei mir scheitert es daran das ich nicht nochmal ein Protokoll erfinden wollen würde. Ich hatte ja ein fertiges USB LCD verlinkt. Dessen Protokoll würde ich nachbauen wollen. Aber woher die Zeit nehmen. Zu viele Projekte.

    Sehe jetzt erst das mehr oder weniger die gleiche Anfrage vor längerer Zeit schonmal gestellt wurde:


    Die Situation wird sich da so schnell nicht ändern.

    Faktisch ist (mit wenigen Ausnahmen im High-Speed-Bereich) alles was "parallel" kommuniziert eigentlich veraltet. Ähnlich gebaute LCD gibt es heute dann eher mit I2C oder SPI, also serielle Kommunikation.


    Zumindest für T6963C gibt es da aber tatsächlich wieder preislich attraktiven Nachschub. Falls hier noch jemand gerne ein LCD basteln will:

    240x128 LCD-Anzeige lcm240128a-v2. 5 t6963c uci6963 3,0*144mm - AliExpress 502
    Smarter Shopping, Better Living! Aliexpress.com
    de.aliexpress.com


    "Echter Parallelport" über USB ist für LCDs vermutlich schwierig. Ich hab vorhin mal bisschen drüber nachgedacht. Im Vergleich zur Implementierung des Protokolls direkt im Mikrocontroller muss man so grob über den Daumen 6 mal mehr Daten über den USB schaufeln. Das an sich ist noch realistisch, denn so sehr viele Pixel müssen ja nun auch nicht aufgebaut werden. Für T6963C habe ich 150kBaud und in anderen Projekten fahre ich ohne Probleme 1MBaud. Datentechnisch also machbar. Richtig schwierig wird es aber bezüglich Timing. Nur weil man auf PC-Seite ein paar Nanosekunden Pause einbaut heißt nicht das das dann am "USB-Parallelport" auch so ankommt. Die Bytes, die man schicken will, landen am PC erstmal in einem Ausgangsbuffer und werden am Mikrocontroller vor der Verarbeitung in einem Eingangsbuffer gesammelt. Dabei verschwimmt sämtliches Timing.


    Die saubere Lösung wäre das Protokoll, welches deine VFD sprechen, auch wieder im Mikrocontroller aufzubauen. Da schafft man es dann auch ein datenblattkonformes Timing hinzubekommen und zum USB hin dürfte man dann wieder mit 150kBaud auskommen für anständig schnellen Bildaufbau.

    Meine Firmware geht ausschließlich für T6963C. Auf dem Arduino findet dabei die komplette T6963C Protokollkommunikation statt. Vom PC kommt nur die Startadresse und dann immer 8 Pixel pro Byte.


    Für andere Controller wäre es dann sinnvoller ein eigenes Arduino Projekt draus zu machen. Das Protokoll in Richtung graphlcd kann dann unter Umständen gleich bleiben oder braucht nur minimale Anpassung.

    But just requesting doesn't help. To be honest: I don't plan to accept PKGBUILDs anymore without any previous attempt to create something by the person requesting the PKGBUILD.

    VDRVERSION und APIVERSION immer gleich, da es in der Vergangenheit immer wieder zu Problemen/Missverständnissen gekommen ist, wenn sie unterschiedlich waren. Ausserdem sind die Rechner heutzutage deutlich schneller als vor zwanzig Jahren, da macht es nicht viel aus, bei einer neuen VDR-Version auch die Plugins neu zu übersetzen.

    Fände ich schade. Für den Nutzer der nur ein paar Plugins hat sicher kein Thema aber vdr4arch komplett dauert bei mir Stunden.

    Allerdings finde ich nur Infos, das es mit dem vdr-plugin-iptv geht, das plugin unter Debian 12 aber nicht mehr verfügbar ist und vdr-plugin-iptv gar nicht mehr entwickelt wird.

    Ähnliche Situation hatten wir mit dem sat-ip Plugin. Man kann wohl davon ausgehen das alle "rofafor-Plugins" aktuell nicht weiter entwickelt werden. Auf meine, allgemein formulierte, Anfrage habe ich bis heute keine Antwort: https://github.com/rofafor/vdr-plugin-satip/issues/86


    Wenn aber der Bedarf besteht kann ich das gerne auf "vdr-projects" übertragen damit nötige Fixes wo hingehen können.

    Ich hab selbst einen Usermode Treiber geschrieben der genau das macht. Die Nullen stören nur wenn man das Resultat tatsächlich als String nutzt. Von der Idee her ist std::string nur ein Byte Buffer. Die Nullen sind auch nur Bytes.

    So wie ich es verstanden habe war der letzte Vorschlag von wirbel genau das: Ein Vorschlag. Getestet hat das bisher keiner und da ich selbst bis heute nicht dazu gekommen bin das zu testen kann man das selbstverständlich auch nicht einfach so übernehmen.


    Was mich aktuell daran noch am meisten stört ist dieser Block (der eigentlich ähnlich ein zweites mal drin ist):

    Wenn auf "Objektorientierung und C++" dann bitte, wenn irgendwie möglich, raus mit dem Pointer-Low-Level-Kram. Eine Google-Suche hatte zumindest Ansätze gegeben wie man einem "Vector" gleich mehrere Elemente auf einmal zufügt. Es muss also irgendwie gehen, aber ich bin da noch zu weit weg.


    Im Prinzip spricht auch technisch nichts dagegen std::string zu verwenden: https://stackoverflow.com/ques…-avoid-manual-dynamic-mem

    Allerdings stimme ich da schon zu das ein "Vector" vermutlich "sauberer wäre". Aber wenn der "std::string" es einfacher macht eine aufeinander folgende Bytekette zu verwalten ohne dann doch wieder mit Pointern zu jonglieren, dann würde ich persönlich das vorziehen. Lieber std::string als wieder Low-Level-Zeugs. Und bei einem std::string weiß ich halt das ich ein 4 Byte Integer einfach auf "char" casten kann um es als "String der Länge 4" hinten anzuhängen. Habe ich selbst schon gemacht. Funktioniert einwandfrei.


    Vielleicht komme ich auch tatsächlich nochmal dazu selbst bisschen zu probieren. Ich komme aktuell nicht dazu viel zu machen. Meine VDR-Kiste wird kaum noch genutzt und ich muss meinen Bekannten, für den ich bisher noch ein bisschen versuche zumindest den Arch-Paketsatz nutzbar zu halten, mal fragen ob er überhaupt noch vorhat einen neuen VDR zu bauen. Seine alte Kiste (größer 10 Jahre alt) wird nämlich nur noch mit Gebraucht-Teilen "am Leben gehalten" und Updates fahren wir da schon lange keine mehr drauf weil die bei so alter Hardware nur Ärger machen. Wenn er da keine Motivation mehr hat würde ich mich tendenziell eher noch mehr aus dem VDR-Bereich zurückziehen.

    Ich hatte den NetCeiver bei einem guten Kumpel, der 30 km entfernt wohnt, in Betrieb gehabt. Ich hab den mit Hilfe hier aus dem Board irgendwie zum Laufen gebracht. Zunächst mit minisatip und dann mit gleichen Einstellungen mit dem mcli Plugin. Meine Möglichkeiten, noch etwas nachzuvollziehen, tendieren aber gegen Null. Wie schon erwähnt habe ich keinen funktionsfähigen NetCeiver mehr. Ich selber habe und hatte nie Interesse am NetCeiver. Das war eine Idee des Vaters meines Kumpels, welcher den NetCeiver entgegen meinen Rat dann "spontan" bestellt hatte. Bei den Preisen "guter" Sat>IP Server glaube ich am ehesten das da jetzt wieder PC-Hardware mit eingebauten Tunern hinkommt. Oder ein ARM mit PCI-Express um bestehende Tuner stecken zu können.


    Ich glaube "lftp" wurde ursprünglich eingebaut um einen "gängigeren" FTP Client zu nutzen. Allerdings gab es dann zumindest in einem Fall ein Problem das mit lftp nicht lösbar ist: https://github.com/vdr-projects/libnetceiver/issues/1


    Schon aus diesen Grund würde ich empfehlen nicht lftp sondern tnftp zu nutzen und wie der mit IPv6 konfiguriert wird steht hier: https://aur.archlinux.org/cgit…it/tree/PKGBUILD?h=tnftp6

    In Fällen wo "dauerlaufende" Scripts ein Problem sind ist es zumindest bei einem Shellscript extrem einfach das zu vermeiden.

    Der "Hack" mit "at" den man immer mal wieder sieht ist nämlich nie nötig gewesen.

    Einfach den gesamten Shell-Code klammern (normale runde Klammern) und hinter die schließende Klammer ein "&" setzen. Das gesamte Script läuft damit im Hintergrund und die VDR-Prozesse, die Scripte nutzen, werden nicht blockiert.