Forum: Mikrocontroller und Digitale Elektronik Bootlader über HC-05 Bluetoothadapter?


von Uhu U. (uhu)


Lesenswert?

Ich möchte einen Controller über einen HC-05 Bluetoothadapter flashbar 
machen. Auf dem Controller soll nach Möglichkeit ein um die 
HC-05-Initialisierung erweiterter Arduino-Bootlader laufen. Das Problem 
dabei:

Der Bootlader startet nur direkt nach einem Reset. Dieser Reset wird 
beim Arduino über die DTR-Leitung des FTD ausgelöst - siehe 
https://www.mikrocontroller.net/attachment/258727/CH340G_UNO_ArduinoBoard_3.pdf

Nun unterstützt der HC-05 leider kein DTR. In den Quellen des avrdude 
wird der Reset ausgelöst, indem DTR und RTS low und wieder high gesetzt 
werden.

Dass das mit DTR gut klappt, kann ich mir vorstellen, aber RTS dazu zu 
missbrauchen, könnte ein Schuss ins Knie werden, wenn der PC oder was 
immer sonst noch über Bluetooth kommuniziert, RTS auf low zieht.

Was tun?

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Uhu U. schrieb:
> Was tun?

Bootloader modifizieren oder eigenen scheiben. Soo schwierig ist das 
jetzt nicht.

von Uhu U. (uhu)


Lesenswert?

Knut B. schrieb:
> Bootloader modifizieren oder eigenen scheiben. Soo schwierig ist das
> jetzt nicht.

Für das Reset-Problem hast du keinen Vorschlag?

von Chr. M. (snowfly)


Lesenswert?

Uhu U. schrieb:
> könnte ein Schuss ins Knie werden,

Warum?
kannst du deinen Modulen und der Software nicht sagen sie sollen 
HW-Handshake ignorieren?

Wo siehst du das Problem? mit dem Pin wir nur vor der Datenübertragung 
gewackelt.(Der DRT-Pin am Arduino ist der Reset-Pin mit einem C in 
Reihe)

>Was tun?
Ausprobieren?

von Uhu U. (uhu)


Lesenswert?

Chr. M. schrieb:
> Warum?
> kannst du deinen Modulen und der Software nicht sagen sie sollen
> HW-Handshake ignorieren?

Sieh dir den Arduino-Schaltplan an, den ich im Eingangsposting verlinkt 
habe. Mit der Miemik kann man von der Controllerseite per Software 
nichts tun, um einen Reset zu verhindern, wenn das andere Ende der 
BT-Verbindung Eigenleben entwickelt.

Da das Gerät vor allem mit einem uralten Acer-PDA mit Windows Mobile 
kommunizieren soll, rechne ich aus Erfahrung mit allem möglichem Unrat 
auf der BT-Verbindung.

von Chr. M. (snowfly)


Lesenswert?

Ich habe gerade mal nach HC-05 gegoogelt.
Der HC-05 hat auf Pin4 einen RTS-Pin -> Problem gelöst.

von Uhu U. (uhu)


Lesenswert?

Chr. M. schrieb:
> Der HC-05 hat auf Pin4 einen RTS-Pin

Das ist mir bekannt... Ohne RTS auf dem HC-05 bräuchte ich mir 
diesbezüglich keine Gedanken machen.

> -> Problem gelöst.

Leider nicht. Wenn RTS aus welchen Gründen auch immer zappelt, dann 
macht der Controller Reset-Gymnastik.

: Bearbeitet durch User
von Chr. M. (snowfly)


Lesenswert?

Langsam verstehe ich, glaube ich, dein Problem.
Warum denkst du RTS ist wackeliger als DTR?

Der Reset sollte doch jederzeit in der Software deaktiviert werden 
können indem man einfach den Reset-Pin auf Low setzt.

von Uhu U. (uhu)


Lesenswert?

Chr. M. schrieb:
> Warum denkst du RTS ist wackeliger als DTR?

DTR sagt, dass das Gerät am anderen Ende in Betrieb ist, während RTS für 
Hardware-Handshake gedacht ist - es geht also u.U. einiges über diese 
Leitung, wenn Daten übertragen werden.

Nun weiß ich von den Acer n50 PDAs mit dem elenden Windows Mobile, dass 
der Bluetoothtreiber nicht sehr zuverlässig ist - der verklemmt auch 
ohne Hardware-Handshake schon mal und dann hilft nur noch ein 
Hard-Reset. Wer weiß, was das Lumpending sonst noch unbemerkt alles 
treibt und es nicht auf die Spitze zu treiben, scheint mir eine gute 
Idee zu sein.

Ich werde das Problem jetzt in etwa so lösen:
- beim Kaltstart wird vom Bootlader eine RAM-Variable gesetzt und der
  Watchdog auf eine kurze Zeit mit Reset initialisiert, dann wird auf
  die Adresse 0 gesprungen.
- Die Applikation muss als erstes den Watchdog entweder abschalten, oder
  auf einen Interrupt umbiegen und die RAM-Variable auf einen anderen
  Wert setzen.

Wenn der Controller keinen Code enthält, gibt es einen WD-Reset und der 
Bootlader erkennt das an der RAM-Variablen und wartet, auf den zu 
ladenden Code.

Die BT-Receive-Routine für die Applikation prüft ständig, ob eine 
bestimmte Byte-Sequenz gesendet wurde; wenn sie erkannt ist, wird die 
RAM-Variable des Bootladers so gesetzt, dass der einen Ladezyklus 
startet und ein WD-Reset ausgelöst; wenn nicht, wird das empfangene Byte 
zurückgegeben.

Die BT-Receive-Routine wird in den Bootlader gepackt.

Das Ganze wird ein modifizierter Arduino-Bootlader und avrdude bekommt 
einen Spezialmodul dafür. Das scheint mir die am wenigsten aufwendige 
Rangehensweise zu sein, denn den 103732. Bootlader muss ich wirklich 
nicht schreiben...

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.