Kabellosen AVR-Programmer bauen

DocProc schrieb:
> Was ich mich aber frage, ist, welchen Chip ich dann als eigentlichen
> Programmer wählen soll, und welche Baudrate ich in den HC-05
> programmieren soll.

Schau dich nach Programmieradaptern um, die das STK500v2 Protokoll 
unterstützen. Ich glaube, die Baudrate ist normalerweise 115200.

Bluetooth hat aber ein anderes Timing als die echte serielle Verbindung 
und auch anders als USB-UART. Mache dich da auf Probleme gefasst die du 
nicht lösen kannst, solange du am Atmel Studio fest hältst.

Mit dem Arduino ISP Sketch geht das jedenfalls, aber der ist nicht Atmel 
Studio kompatibel (so weit ich weiß). 
https://www.hackster.io/PSoC_Rocks/avr-blues-the-wireless-programmer-5a3d9e

Hallo Stefan, danke für die schnelle Antwort!

Stefan ⛄ F. schrieb:
> Bluetooth hat aber ein anderes Timing als die echte serielle Verbindung
> und auch anders als USB-UART.

Was meinst du damit konkret? Der HC-05 ist ja ein Adapter, der die 
Daten, die ich am virtuellen COM-Port einschleuse (z.B. über ein 
Terminalprogramm wie Hterm) auch mit der in das Modul per AT-Commands 
einprogrmmierten Datenrate ausgibt; das Empfangen funktioniert genauso. 
Es ist also im Grunde genommen ein seriell-Wandler bereits in dem Modul 
eingebaut...oder irre ich da? Die Kommunikation mit einem an den HC-05 
angeschlossenen AVR und dem PC funktioniert über UART zumindest 
tadellos, und unterscheidet sich in der Handhabung nicht von einem 
angeschlossenen USB-seriell-Wandler. Das hatte mir auch Hoffnung 
gemacht, dass ich den besagten kabelgebundenen Wandler einfach durch den 
HC-05 ersetzen könnte.

Weitere Frage: hängt die Kompatibilität mit Atmel Studio von dem 
USB-seriell-Wandler (Bei mir: Bluetooth-seriell) ab, oder von dem 
Programmer selbst?

DocProc schrieb:
> Was meinst du damit konkret?

Ich meine damit, dass die vom PC gesendeten Bytes verzögert am Ende der 
Bluetooth-Strecke ankommen und dass auch die Antworten verzögert werden. 
Bluetooth überträgt zudem nicht einzelne Bytes, sondern sammelt sie zu 
Blöcken. Dazu kommt, dass die Übertragung bei Funkstörungen ins Stocken 
geraten kann, womit die Software wahrscheinlich nicht rechnet. Wenn sie 
zu viele Bytes hintereinander sendet, gehen dann einige verloren.

Solche Störungen sind nicht selten, sondern quasi ständig vorhanden, 
weil Bluetooth sich die Funk-Frequenzen mit WLAN teilt.

> hängt die Kompatibilität mit Atmel Studio von dem
> USB-seriell-Wandler (Bei mir: Bluetooth-seriell) ab

Soweit ich weiß nicht. Hauptsache dein Windows stellt einen virtuellen 
COM-Port bereit.

Stefan ⛄ F. schrieb:
> DocProc schrieb:
>> Was meinst du damit konkret?
>
> Ich meine Damit, dass die vom PC gesendeten Bytes verzögert am Ende der
> Bluetooth-Strecke ankommen und dass auch die Antworten verzögert werden.
> Bluetooth überträgt zudem nicht einzelne Bytes, sondern sammelt sie zu
> Blöcken.

Okay, das verstehe ich. Das heißt dann ja, dass die Datenrate als solche 
kontant sein kann, aber die Daten an der seriellen Schnittstelle zwar 
mit der richtigen Baudrate, aber eben -wie du schriebst- zeitverzögert 
ausgegeben werden. Kann das denn zu anderen Problemen als einer 
Laufzeitverlängerung führen, wenn der PC auf eine Rückmeldung des 
Programmers wegen der "Hysterese" etwas länger warten muss? Schließlich 
ist der UART nach wie vor asynchron und deswegen nicht darauf 
angewiesen, dass Daten exakt zeitgleich ausgetauscht werden.

Es kann halt sein, dass die Software von Atmel nicht lange genug auf 
Antwort wartet. Es kann auch sein, dass sie den Puffer des sendenden 
Bluetooth Moduls während einer Funkstörung überflutet. Oder anders herum 
kann der ISP Programmer den Puffer in der umgekehrten Richtung 
überfluten.

Bei meinen Experimenten gingen nicht einmal 9600 Baud kontinuierlich 
über mehrere (10) Sekunden.

Okay, das ergibt natürlich Sinn. Tatsächlich ist meine Lust auf 
Troubleshooting in diesem Bereich auch eher überschaubar, sodass ich 
vorerst wohl weiter mit der physischen Verbindung vorliebnehmen oder 
höchstens mal einen kleinen Erstversuch unternehmen werde.
Schade, denn ich hätte wirklich gerne den PC, von dem aus ich 
programmiere, elektrisch völlig von meinen Experimenten getrennt, nicht 
zuletzt, um den PC bei der Programmierung von experimentellen 
Schaltkreisen zu schützen. Leider scheint es da keine fertige käufliche 
Lösung zu geben.
Oder ich steige doch auf die Arduino IDE um, und baue den ISP nach, zu 
dem du mir dankenswerterweise den Link gepostet hast.

DocProc schrieb:
> Leider scheint es da keine fertige käufliche Lösung zu geben.

Eben, das wird einen Grund haben. Du bist sicher nicht der einzige, der 
an so einem Produkt Interesse hat. Alleine für die ganzen 
Roboter-Bausätze wäre das super, aber die setzen alle entweder auf ISP 
über Kabel oder serielle Bootloader.

> Oder ich steige doch auf die Arduino IDE um

So weit musst du gar nicht gehen. Du kannst das ATmel Studio ja 
weiterhin benutzen, um die *.hex (oder *.elf) Datei zu erzeugen, und 
diese dann mit einem anderen Programm außerhalb der IDE flashen. 
Letztendlich ist das Programm von Atmet auch eigenständig - es ist 
lediglich ins Menü der IDE eingebunden.

Schau dir mal avrdude + AVR8-Burn-O-Map an. 
http://stefanfrings.de/avr_tools/index.html#avrdude