USBserLCD: T6963C basierte LCDs an USB betreiben

  • Nochmal als "Referenz" was ich da treibe mit den "Variablen" (die eigentlich keine sind).


    Mein "Angelpunkt" sind diese Zeilen:

    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L768


    Der "Status" eines USB-Geräts kann am Auftreten von gewissen "Ereignissen" (am Atmel Interrupts) festgemacht werden. In unserem Fall sind das die Interrupts "WAKEUPI" und "SUSPI". Diese selbst können wir aber nicht abfangen oder "empfangen" weil die Arduino-Lib selber dafür eine Interrupt-Service-Routine definiert. Wovon man aber profitieren kann, ist, dass (wie am Kommentar darüber schon ersichtlich) zur "Stabilisierung" des ganzen Interrupts "getogglet" werden:


    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L773

    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L783


    Das Register "UDIEN" ist aber global. Was die Arduino-Lib hier macht kann also von jeder Stelle im Code (auch im "Arduino-Sketch") gelesen werden. Auf dem Weg kann man ohne Änderungen den Status des Controllers lesen indem man diesen Code-Teil der Arduino-Library für eigene Zwecke "missbraucht".


    Was ich oben beschrieben habe (RX-LED) wäre zwar in der Theorie möglich, aber man müsste dann, dass die LED bei "laufendem PC" auch aus geht, das Timeout abwarten:


    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L768


    Und ich bin mir nicht sicher ob ich wirklich irgendwo > 100 Millisekunden verschenken will. Die Lösung mit den Interrupts ist "schöner" und bei den meisten Mainboards sollte sie funktionieren. Auf dem "problematischen" geht ja nichtmal die FT232RL-Lösung und das ist ein ASIC. Wenn der schon nicht geht, warum sollte dann etwas anderes auf Biegen und Brechen funktionieren?


    Die "SOF-Lösung" ist schöner und auch zuverlässiger. Allerdings kümmern die bei Arduino sich eh nicht um den entsprechenden Bug oder Pull-Request. Man wird also erstmal mit einem Würaround nach Wahl leben müssen.


    https://github.com/arduino/Arduino/issues/7363

    https://github.com/arduino/Arduino/pull/6964


    Ich weiß nicht wie und nach welchem Prinzip bei denen entwickelt wird, aber eine handelsübliche Rennschnecke ist schneller :evil:

  • Zunächst: USBserLCD auf dem 32u4 läuft bestens. Mit dem Interrupt Hack bekomme ich auch mit wenn der PC aus ist.

    Bin da aber noch an einer anderen Lösung dran, die ohne Hack auskommt und nur Arduino Features und Atmel Register braucht. Ist letztlich genau was SHF macht. Kann aber ohne Konflikte mit den bestehenden Arduino Libs zusammenarbeiten. Ich habe vor das als kleine Arduino Library umzusetzen und in den Library Manager zu bekommen.

  • Noch nicht im Zusammenhang getestet (habe die Hardware im Moment nicht hier) aber der Code kompiliert und die Library funktioniert:


    https://github.com/M-Reimer/us…58e2007dfbc83fb321d5778c5


    https://github.com/M-Reimer/USBStatus


    Die Library ist kein Hack sondern die Lösung, die ich für IRMP_STM32 umgesetzt habe und die SHF hier auch schon vorgeschlagen hat. Nur das ich das ganze etwas anders angehe um keine Konflikte mit den Arduino-Libs zu bekommen. Im Prinzip sollte das auch auf meinem "problematischen" Mainboard gehen.


    Die Library habe ich für den Library-Manager vorgeschlagen https://github.com/arduino/Arduino/issues/7529. Falls das also jemand für seine Projekte braucht, dann einfach etwas warten oder von meinem GIT als ZIP installieren. Ich habe die Library unter LGPL3 gestellt. Sollte also für die meisten Projekte einsetzbar sein.