Universelle Fernsteuerung mit Bluetooth

[HaWe]

Ich halte tatsächlich auch Seriell/BT ohne Transport-Control-Protokoll für zu fehleranfällig und nicht ausreichend übertragungssicher, v.a. wenn auf der Zielplattform noch weitere zeitintensive Threads mit hoher Prio laufen.

Mit ESP WiFi und Webserver Libs habe ich andererseits zwar eine sichere, aber noch nie eine Kommunikation mit Echtzeitfähigkeit hinbekommen.

Gelänge es, die PS2X_lib für das 2,4GHz Empfangsmodul so umzuschreiben, dass man es direkt an einem ESP32 anschließen kann (ESP32: Dualcore mit std::thread Implementierung), dann hätte man 3 Fliegen mit 1 Klappe erwischt:
- eine etablierte, gut funktionierende Lib, bei der man sich keine Gedanken machen muss, wie der Empfänger der PS2-Signale der Buttons und Joysticks empfängt + auswertet,
- eine MT-fähige Plattform, die neben der Echtzeitabfrage und -verarbeitung auch weitere Threads in Echtzeit parallel abarbeiten kann, sogar mit verschiedenen prios, und
- eine ESP-MCU. die Telemetriedaten per WiFi synchron zurückschicken kann (an einen an den PS2 Controller angeklebten ESP8266 mit Display), zur Visualisierung, und da das synchron zur 2.4GHz Richtung geht, auch ohne gegenseitige Behinderung der Datenübertragung.
Leider ist die PS2X_lib aber nur für AVRs, nicht für ARMs und nicht für ESPs (wegen vieler AVR-spezifischer low level Befehle oder Registernamen etc., und auch die verwendeten Pins müssten ggf. umbelegt werden).

Eventuell könnte man statt dem ESP32 auch einen der neuen WiFi-fähigen Arduino MKR-Boards verwenden.

Eine Alternative wäre auch, deine Fernbedienung Marke Eigenbau mit einer ähnlichen Lib auszustatten wie die PS2X_lib für den PS2 Controller, womit man dann bei identischer Syntax genau so einfach und genau so universell den Zustand aller Buttons+Sticks abfragen kann, wie es die PS2X_lib tut.

[Klebwax]

Mit ESP WiFi und Webserver Libs habe ich andererseits zwar eine sichere, aber noch nie eine Kommunikation mit Echtzeitfähigkeit hinbekommen.

Das ist pflichtgemäß so. Ethernet ist nicht echtzeitfähig, WiFi erst recht nicht. Da braucht nur ein Sender, der noch nicht mal zum eigenen Netz gehören muß, einen Kanal zu blockieren und schon hat man ein Delay. Webserver heißt http und das ist Schicht 7 im OSI Modell. Da kommen also zu Ethernet/WiFi noch die Latenzen von den 7 Schichten dazu. Wenn man den http-Overhead, der einem am Ende nichts bringt, wenn man kein Webserver oder Browser ist, weglässt, wirds schon mal besser.

Eine klassischen Fernsteuerungen hat eine Framerate von ca. 20ms. Wenn man direkt auf Sockets programmiert, kann man mit WiFi ähnliches erreichen. Mit gelegentlichen Überschreitungen der 20ms muß man aber schon rechnen. Der Verlust eines Frames kommt aber auch bei einer Funkfernsteuerung vor und bleibt dort typisch unbemerkt. Für den Menschen mag das Echtzeit sein, das reicht auch für Kunstflug. Von dem, was man technisch bei Echtzeit erwartet, ist das meilenweit entfernt.

MfG Klebwax

[Rabenauge]

Sodele.
Das Display läuft.
Momentan nur ein Test-Beispiel (ne abgewandelte Version vom Graphics-Test der U8g2lib), aber der tut es.
Und: der Kontrast _lässt_ sich per PWM einstellen- mit Einschränkungen.
Der Kontrast-Pin hängt erstmal auf Pin D9, und ab etwa PWM 170 werden die Zeichen "sichtbar".
Allerdings noch sehr schwach, und eher rötlich, als weiss.
Bei PWM 200 kann man sie schon sehr gut erkennen, aber immernoch rötlich und...flackernd wie ein alter Bildschirm.
Kurz gesagt: es ist eher unnötig bei meinem, da jemals _irgendwas_ dran rum zu stellen: PWM 255 und gut.
Das ergibt blitzsaubere, weisse Pixel (eigentlich könnt man sich den Pin auch sparen, und einfach 5V ran legen).
Ich schaue mir das heute abend im Dunklen noch mal an, aber wenn es dann auch so schön aussieht, kommt der Kontrast-Pin einfach an die 5V-Schiene und fertig.
Umso mehr bleibt für Erweiterungen übrig, hehe.

Angeschlossen hab ich das Teil mometan an nem Uno (der ist halt mein Knecht fürs Steckbrett), nach dem Schema der Anleitung von AZ-Delivery.
Das E-Book gibts gratis bei denen, wer Interesse hat...hier rein werfen möcht ich es nicht.

Als nächstes teste ich mal, ob es auch mit anderen Pins so gut geht, ich denke aber, schon, da die Pins im Programm definiert werden.
Dazu gäbs keinen Grund, wenn man sie nicht ändern könnte.

[Rabenauge]

Sodele.
Inzwischen habe ich noch ein bisschen mit dem Display gespielt- und es gibt einige Erkenntnisse:

1.: wenn mans _richtig_ anschliesst, funktioniert die Sache mit dem Kontrast per PWM _besser_.
Ich hatte doch tatsächlich den 5V der LED-Beleuchtung an den Kontrastpin angeschlossen-daher das Geflackere.

2.: der Plan geht auf: ich kann im Bedarfsfall die AltSoftSerial-Bibliothek benutzen (die normale SoftSerial ist recht...unzuverlässig), da es kein Problem ist, die Pins 8 und 9 dafür freizuhalten.

3. man _könnte_ den CS-Pin auch noch frei bekommen, indem man den entsprechenden Pin vom Display einfach auf 5V legt- funktioniert!
Ob es ne gute Idee ist, weiss ich nicht....
Das hätte z.B. die Einschränkung, dass man dann den SPI-Bus nicht noch für andere SPI-Geräte benutzen kann. Da es ausreichend freie Pins geben wird, lass ich den CS auf Pin 10, und gut.
Das Display braucht trotzdem insgesamt nur vier Pins: Kontrast (12), CLk(13), MOSI(11) und CS(10).
Ist doch ganz erträglich.

Ich häng mal das Anschlusschema an. Der Übersicht wegen hab ich mal die ganzen Leitungen für die Eingabegeräte und das BT-Modul rausgenommen.

[Moppi]

Hallo Sly,

vergiss Software Serial beim Nano am besten. Was damit funktioniert ist das Senden in eine Richtung, Halbduplex. Bei Vollduplex kannst Du Probleme bekommen. Das AltSoftSerial ist da nicht viel besser, habe ich auch ausprobiert. Aber dazu hat man ja den UART, um Daten zuverlässig zu übertragen. Grundsätzlich musst Du aber immer damit rechnen, dass bei einer Seriellen Übertragung der Datenstrom gestört werden kann. Ob der UART da mit Prüfsummen/-bits Abhilfe schafft, weiß ich allerdings nicht. Von UART zu UART seriell zu übertragen, ist auch kein Problem, wenn Du einen DIP-Schalter (oder einen anderen) einsetzt, mit dem Du die serielle Verbindung unterbrechen kannst, um Software auf die Geräte, per USB-Kabel, aufzuspielen.

MfG

[Rabenauge]

Ich habs befürchtet- du hast damit (schlechte) Erfahrungen?
Getestet hatte ich die Kommunikation neulich zwischen dem XPlorer (der hat ja inzwischen auch ein HC 05 drin) und nem Uno, auf beiden SoftSerial....auf dem UNO lief es tadellos, aber der NANO zickte etwas.
Allerdings hatte der UNO auch nix weiter zu tun, während auf dem Nano ja "nebenbei" die XP2-Software läuft.

Schalter einbauen (um USB weiter nutzen zu können) wäre eigentlich Plan B gewesen- aber vielleicht sollte ich _den_ tatsächlich zu Plan A erklären?

[Moppi]

auf dem UNO lief es tadellos, aber der NANO zickte etwas

Da haben wir dieselben Erfahrungen gesammelt. Mit dem 328P vom UNO hatte ich nie Probleme, aber mit dem vom NANO. Deswegen habe ich das dann bleiben lassen, mit SoftwareSerial. Allerdings, Halbduplex scheint damit auch auf dem NANO gut zu funktionieren. Also erst in eine Richtung senden und danach in die Gegenrichtung. Per UART und Schalter dazwischen ist die beste Lösung - jedenfalls für meine Bedürfnisse. ZUmal Du dadurch Pins freihältst, für was anderes.

MfG

[inka]

Hi Sly,

gratulation! Und wie schon erwähnt, denke ich ersnthaft darüber nach das teil nachzubauen, wenn ich denn Deine ideen nutzen darf