Hallo zusammen,
es geht hier um etwas seltsames in Verbindung mit dem JDY16 BT Modul und einen Tiny1634 im Powerdown.
Ich bin mir nicht sicher ob es eine Eigenart der JDY16 ist oder ich einfach zu doof bin..
Es geht darum daß, das Modul dauernd >0 und CR< schickt wenn die RX Leitung auf LO liegt,
was bedeutet das es nicht in SLEEP geht weil es ja dauernd beschäftigt ist.
Auch wenn die Verbindung zum Serial Bluetooth Terminal unterbrochen wird sendet es fröhlich weiter.
Was ich nun heraus gefunden habe ist, das der 1634 im Powerdown gerade das macht, den RX auf LO zu ziehen.
Schick man den 1634 in den IDLE Modus funktioniert zwar der SLEEP Modus beim JDY16, aber halt der Stromverbrauch beim Tiny ist dem entsprechen höher.
Jetzt versuche ich schon seit tagen mit den Alternativen Möglichkeiten der PIN manipulations den RX im Powerdown auf HI zu bekommen, klappt aber irgendwie
net wirklich..
Hatte rein zufällig schon jemand ein solches Problemchen, oder vielleicht noch besser einen Tipp?
Dank euch
Ronnie
Hmm,
was macht der RxD-Pin, wenn
- Du die in Kap. 16.9.4 beschriebene Start Frame Detection als WakeUp-Source konfigurierst?
- Du ggf. noch den internen PullUp des RxD-PortPins aktivierst?
Müsste doch eigentlich gehen, wenn das DB zumindest zusichert, dass die UART als WakeUp aus dem PowerDown funzt.
Is ja Geil.. So hab ich das auch noch nicht gemacht. Habe immer mit dem Modul Status Ausgang gearbeitet.
Auf diesen Weg wacht der Tiny auch beim Verbinden schon auf. Behalte ich mir mal im Hinterkopf.
Wie es aber immer so ist, verzapf ich halt auch immer wieder Mist..
Bin jetzt erst bei der Versuchsreihe draufgekommen, das es nicht der RX Pin ist was ärger macht sondern der TX Pin beim Tiny.
Also das Modul spinnt rum wenn dessen RX Pin LO ist..
Gibt es da auch so ein schönes Beispiel.
Hab schon versucht den TX beim Tiny abzuschalten.
Bit 3 – TXENn: Transmitter Enable
Writing this bit to one enables the USART Transmitter. When enabled, the transmitter will override normal port
operation for the TxDn pin.
Und den Pin via PueB auf HI zu legen funktioniert leider nicht..
Der TX Pin beim Tiny bleibt fröhlich auf LO
Doppel-Hmm:
Nach Table 10.1 wäre wohl die wahrscheinlichste Pin-Konfiguration
DDxn=0; PORTxn=PUExn=1
Wenn Dir dann immer noch die alternate Function (TxD) am Pin in die Suppe spuckt, kannst Du vor dem Sleep das Senden einzeln unterbinden (In UCSRnB das TXENx-Bit löschen).
Bringt das immer noch nichts, MUSS aber eigentlich ein externer PullUp helfen.
Also Sachen gibt's... Musste ich so auch noch nicht machen...
Aber es geht....
Eigentlich hab ich mich nie weiter um die RX/TX Pins in den Config Einstellungen gekümmert, hat immer funktioniert in der Mega Abteilung jedenfalls.
Hier beim Tiny hab ich in meiner Not mal den RX als Ausgang Konfiguriert und vorm Schlafen auf HI
und zack.. keine herum Spinnerei mehr.. Datenübertragung funktioniert visa versa einwandfrei
Zwar liegt der verbrauch in Sleep noch bei 2ma aber damit kann ich erstmal leben..
Da beiß ich mich aber auch noch fest dran.
Sind schon manchmal kleine Divas die Käfer
Ich dank Dir jetzt erstmal für deine Tolle Hilfe!!
Ronnie
Auch erledigt.
Die 2mA waren der Spannungsregler auf dem BT Shield...
Jetzt sind es grad mal 150µA.. Passt
Bitte schön, hatte der Tag ja doch noch 'ne Daseinsberechtigung.Zitat von Head Free
Mein Classic BT-Master SPP auf dem ESP32 zu einem HC-06 funzt währenddessen nicht die Bohne. An manchen Tagen reicht das Verständnis halt nur zu Workarounds.
Also da bin ich auch schon durch...
Manchmal verstehen die sich auch untereinander nicht..
Genauso wie die HC-12 Module (auf RF Basis), die funktionieren nur wenn sie aus der gleichen charge sind..
Aber dann wenn es klappt - mit einen selbergebauten Dipol und!! die erlaubte FRQ und Power eingehalten..
Satte 8km auf Sicht!
Auf Master Slave haste ja aufgepasst (doofe frage)
Versuch mal eins aus der 5er Serie.. Die haben eine andere Firmware drauf..
Ist nicht kriegsentscheidend: Ich habe hier einen Roboter, der mit einem HC-06 bislang wahlweise mit dem PC oder einem OnBoard BananaPi per UART (über Bluetooth) spricht.
Mittlerweile habe ich allerdings den PC-Teil (der hier: https://www.roboternetz.de/community...-auf-dem-ESP32) auch auf dem ESP32.
Damit ich für erste Tests mit der Hardware nicht gleich eine physikalische Schnittstelle einbauen muss, kann ich mich auch übergangsweise mit der Kröte abfinden, ESP32 und Roboter als BT-Slave (der funzt auch auf dem ESP) mit dem PC zu verbinden und einfach dort die Daten über die beiden COMs wechselseitig auszutauschen (das ist ein Fünfzeiler).
Berechtigungen
Zitieren
Lesezeichen