Hallo,
ich versuche, den Bootloader von Peter Dannegger auf einem 644P über
Bluetooth zum Laufen zu bringen.
Auf dem PC verwende ich den Loader von FBoot von Bernhard Michler /
Andreas Butti.
Über USB via FTDI funktioniert er, dort kann ich meine Hex-Files
übertragen.
Wenn ich jetzt den FTDI durch einen UART-Bluetooth-Adapter ersetze, dann
bricht der Vorgang bei 22% (und zwar immer bei 22%) ab.
Die Verbindung über Bluetooth klappt, ich kann mich mit einem
Terminal-Programm mit meinem Atmega unterhalten.
Ich habe auch shcon mit den Optionen herumgespielt (Baudrate, Blocksize,
TCDrain), und ich habe das Timeout im Sourcecode hochgedreht. Aber auch
wenn ich lange warte, bricht er immer bei 22% ab.
Ich habe beobachtet, dass er auch beim Flashen via FTDI bei 22% jurz
stehenbleibt, aber dann gleich weiterläuft.
Hat jemand einen Tipp? Irgendwelche Sendepuffer, Flush(), ...?
Warum kann ich über USB flashen aber über Bluetooth nicht?
Zwischen Atmega und meinem PC-Bluetooth-Dongle ist 1m Distanz, daran
sollte es nicht scheitern.
Gruß
Chris
Chris R. schrieb:> Ich habe beobachtet, dass er auch beim Flashen via FTDI bei 22% jurz> stehenbleibt, aber dann gleich weiterläuft.
Hi,
dann sind die 22% wahrscheinlich die Buffergröße (also das, was unter
"Buffer :" angegeben ist), danach erwartet der Bootloader eine Antwort
des Controllers.
Hast Du schon mal (mit source Änderung) die Daten, die vom Controller
kommen, ausgeben lassen? Kommt da die Antwort nach den 22% (also hex
0xA9)?
Gruß,
Bernhard
P.S.: welche version des bootloaders verwendest Du? Die aktuelle aus
github: https://github.com/Boregard/FBoot-Linux
Wenn ich deinen Loader ohne mein Debug-printf() betreibe, dann hängt er
wie gesagt bei den 22%.
Wenn ich aber das printf() einbaue, dann stirbt er lange vorher:
Bluetooth und Debug-printf():
Gibt es da evtl. ein Timing-Problem? Ich verstehe aber grade nicht,
wieso.
Das printf() habe ich in die com_getc eingebaut (Z.313). Das sollte aber
keinen großen Einfluss auf den weiteren Programmablauf haben.
Interessanterweise ist der Puffer in beiden Fällen gleich groß, bei der
Verbindung per USB bekommt dein Loader aber ein Antwort vom Chip.
Wenn ich mich mit einem Terminalprogramm mit meinem Baustein verbinde,
erhalte ich aber auch Antworten über Bluetooth.
Der Bootlader von Peter Dannegger merkt doch aber überhaupt nicht,
welches Übertragungsmedium ihn mit Daten versorgt...?
Gruß
Mr.Green
Chris R. schrieb:> Interessanterweise ist der Puffer in beiden Fällen gleich groß
die Buffer größe kommt ja von Peters Code vom ATMega, das ist der
verfügbare Pufferspeicher.
Mein Verdacht ist auch ein Timingproblem, und daß sich der Bluetooth
Adapter anders verhält bzgl. der IOCTLs.
Probiere das mal mit den Extremwerten: -t 1 -w 64 -r
Gruß,
Bernhard
Hallo,
sorry, ich habe die letzten Postings hier übersehen...
Das Problem scheint immer das gleiche zu sein. Es geht, wenn die Bytes
einzeln über Bluetooth geschickt werden, also kein Puffer benutzt wird.
Damitwird die maximale Übertragungsgeschwindikeit natürlich sehr
langsam.
Man könnte die Wartezeit noch hochsetzen, z.B. -w 128...
Ich muß mir jetzt mal bluetooth adapter besorgen, um es zu testen, was
verwendet ihrdenn so?
Gruß,
Bernhard
