Universelle Fernsteuerung mit Bluetooth

[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

[Rabenauge]

Hm- hab das heute morgen mit nem Kumpel mal diskutiert, und es scheint sich ne noch cleverere Lösung aufzutun, zum abschalten:

Das Modul kommt an Rx1/Tx1, aber die Stromversorgung des HC 05 läuft über nen Transistor.
Der wiederum liegt an einem freien Pin- ich muss noch mal genauer in den Schaltplan gucken, aber da dürften noch einige frei sein.
Das wäre-wenns funktioniert-die eleganteste Lösung: man kann dann einfach per Software (z.B. beim Einschalten) zwischen USB-und BT-Betrieb wählen.

Ich werd aufm Steckbrett mal testen, was das HC 05 macht, wenn es "abgeschalten" ist aber auf den Logik-Leitungen Signale anliegen....mit etwas Glück funktioniert das.
Ein Transistor sollte reichen, so hoch ist ja die Stromaufnahme der BT-Module nicht..mit nem ESP würd ich das so nicht versuchen..

Aktueller Stand: das Display ist in die Fernsteuerung eingebaut und an den Nano angeschlossen, läuft.
Grad drucke ich mir ne kleine Halterung, mit der ich nen USB-Stecker (mit nem bisschen Kabel dran) in die Fernsteuerung schweissen kann, damit ich das Ding schonmal per Powerbank versorgen kann.

Nachtrag: Die Powerbank ist angeschlossen.
Den USB-Stecker zu verkleben, war gar nicht nötig, wenn man genau genug misst und druckt, passt der Stecker fest genug in den Halter.
Das Ding läuft nun auch standalone.
Ein-und ausgeschalten wird einfach, indem man die Powerbank rauszieht-oder reinschiebt.

Inzwischen gibt es auch ein Boot-Logo auf dem Display...frisst abartig Speicher, aber notfalls kann ich es noch ein paar Byte eindampfen. Wenn es ganz schlimm komt, kann ich _das_ auch noch aus Linien zusammencoden, das dürfte den Verbrauch auch senken, aber evtl ist das auch gar nicht nötig, mal sehn.

Etwas Ärger hat mir noch der Kontrast gemacht: erst klappte es gar nicht, den zu verstellen, bis ich drauf kam, dass Pin 12 bei den Nanos gar keine PWM kann.
Umgebaut auf Pin10 (12 ist nun CS, dem isses Wurst)...und ein schönes Flimmern *grummel
Hab dann Timer1 auf irgendwas mit 30KHz eingestellt, nun gehts- flimmern sieht man nur noch bei recht niedrigen Kontrasteinstellungen, aber da ist die Anzeige schon braun, statt weiss...

Die Betriebsdauer mit der kleinen Powerbank beträgt locker 1-2 Stunden (so lange lief die schon mit der einen, die hat inzwischen abgeschalten, aber ich weiss nicht, wie voll die vorher war) , und da ich von den Dingern zwei hab, halte ich das allemal für ausreichend.

 

[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