Hallo, ich möchte gerne einen Atmel Studio-kompatiblen ISP-Programmer für Atmega8, -328,... bauen. Dabei möchte ich gerne den USB-seriell-Konverter, der die Signale des USB in Form von UART an den eigentlichen Programmer sendet, durch ein HC-05 Bluetooth-Board ersetzen, um den Programmer kabellos nutzen zu können. Dieses Board meldet sich im PC ja einfach als COM-Port an, wenn es gekoppelt ist, sodass ich hoffe, dass ich es dann einfach in Atmel-Studio als Programmer auswählen kann. 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. Ich habe hier auch schon einen Programmer und einige Atmega8 herumliegen, sodass ich auch diese dafür benutzen könnte. Hat einer von euch Tipps für eine möglichst simple Lösung?
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
Nimm doch einfach einen "USB-Isolator". Gibts vom Chinesen für unter 20€ und Markengeräte so um die 100€, sofern man sich mit 11Mbit/s begnügt. Für den AVR-Programmer sollte es jedenfalls locker reichen.
Stefan ⛄ F. schrieb: > Schau dich nach Programmieradaptern um, die das STK500v2 Protokoll > unterstützen. Ich glaube, die Baudrate ist normalerweise 115200. Das könnte zum Beispiel dieser hier sein: http://www.tuxgraphics.org/electronics/200705/article07052.shtml Hier ist es in einem ATMEGA8 umgesetzt, der Aufwand hält sich also in Grenzen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.