Neben der ISP-Schnittstelle bei auf 0 V gehaltenem Reset-Eingang können AVRs auch mit 12 V am Reset-Eingang programmiert werden. Im Gegensatz zu PICs ist dann das Programmier-Interface (leider) völlig anders:
Hochvolt-Programmierung ist erforderlich, um den Reset-Anschluss als Ein/Ausgang zu benutzen und Änderungen an der Firmware machen zu können. Auch kann es passieren, dass man sich aus Irrtum oder mit einem defekten(?) Programmiergerät die RSTDISBL-Fuse setzt und sich so vom weiteren ISP-Programmieren aussperrt. „Verfused“ genannt. Das betrifft alle AVR-Controller mit < 40 Beinchen.
PIC-Controller sind davon nicht betroffen, diese erlauben das Setzen einer vergleichbaren Fuse nur bei hoher Programmierspannung. Zudem ist die Umfunktionierung des Reset-Anschlusses weniger interessant, weil dieser nur als Eingang dienen kann. (Bei AVR ist ein Push-Pull-Ausgang möglich, allerdings mit verringerter Treiberstärke.)
Ausgehend von ElmChans Programmieradapter wurde auf www.mikrocontroller.net ein geeignetes Programmiergerät für alle Durchsteck-Chips veröffentlicht. Leider ist der Platinenentwurf nicht für die Produktion bei einer professionellen Platinenfertigung geeignet; die Löcher sind allesamt viel zu klein. Zudem gab es (bei mir) Schwierigkeiten mit dem 74HC299 in Verbindung mit einer langen Leitung zum Drucker. Obendrein benötigt man ein Kabel mit 2× Stecker.
Dafür habe ich das Windows+Linux-Programm avrpp geschrieben. Es hat eine auf Einfachheit optimierte Kommandozeile, lädt ELF-Dateien und kann Fuse-Bits dekodiert anzeigen. Der Zugang zum Parallelport kann sowohl direkt via giveio64 als auch indirekt via inpoutx64.dll erfolgen. Unter Linux immer direkt via ioperm(), der indirekte Zugriff über das Dateisystem /dev/port ist auskommentiert.
Steckbrief: Handliches AVR-Programmiergerät für alle 5-V-AVR-Controller mit allen Programmierschnittstellen ISP, HVPP, HVSP und TPI. Mit USB und integrierter Programmierspannungserzeugung. PIC-Unterstützung ist vorgesehen.
Motivation: Nicht das Aussterben von Parallelports bewegt mich zu einer USB-Lösung, sondern der nervige Griff zum Steckernetzteil für die Stromversorgung bewegte mich schließlich zum Neuentwurf mit echtem USB. Da ich die Software avrpp selbst in die Hand genommen hatte, sollte es keine allzu große Schwierigkeiten bereiten, die Programmier-Routinen in einen USB-Mikrocontroller zu stecken.
Hardware: Als Ausgangspunkt dienen tote Arduino Unos!
Diese enthalten neben dem ATmega328 auch einen
ATmega8U2 als USB-Seriell-Wandler.
(Nicht bei den chinesischen Nachbauten.)
Diesen wiederzuverwenden ist die Idee, ausgerechnet diesen
etwas seltener verwendeten Controller zu verwenden.
Auch „lebendigen“ Arduinos kann man den USB-Seriell-Wandler entreißen,
dann geht's halt mit ISP weiter.
Alles in allem ähnlich der Platine fürs Parallelport, mit folgenden Extras:
Im Muster wurde ein AT90USB162 bestückt. Für AT90USB82 oder ATmega8U2 ist derzeit die Firmware zu groß. Für ATmega16U4 bzw. ATmega32U4 ist weder Software noch Platinenentwurf ausgelegt. Der Atmel-Urlader wurde durch (mein) UBA ersetzt, der bei dieser Gelegenheit korrigiert und modernisiert wurde. Die Pins des Mikrocontrollers reichen dass es pufft und kracht! Dabei habe ich mir das Setzen der RSTDISBL-Fuse verkniffen.
Software-Entwicklung:
Ein völlig inkompatibles Interface nur zu avrpp.exe sollte vermieden werden.
Als sehr schwierig erwies sich die Auswahl und Emulation eines hinreichend bekannten und dokumentierten
vorhandenen Produkts.
Schließlich habe ich mich für drei USB-Interfaces
und eine Doppel-Emulation entscheiden müssen:
Sowohl STK500
— die serielle Schnittstelle via CDC-Interface läuft bis hinunter zu Windows98,
als auch STK600
— treiberlos ab Windows 8, benötigt avrdude 7, unterstützt TPI.
(Wichtig: Die beiden Emulationen können auf USB-Seite aus mehreren verschiedenen Gründen nicht
in einem Multifunktions-USB-Gerät koexistieren!
Sie müssen ggf. vom Anwender umgeschaltet werden.)
Ausgangspunkt war avr-doper,
aber im Gegensatz zu jenem unterstützt es
HVPP.
Und hat dank echtem USB-Full-Speed kein Problem mit CDC-via-Low-Speed.
Dabei stellte der nicht ausreichende RAM (512 Byte statt 1 KByte beim ATmega8)
für die avrdoper-Firmware die größte Portierungs-Hürde dar.
Wurde durch „Streaming-Interface“ für Lesedaten halbiert.
Die „Hochspannungs“-Erzeugung klappte auf Anhieb.
HVPP (bspw. AT90S4433) und externes ISP geht auch.
Die Firmware: Emuliert STK500 via USB-serielle Schnittstelle (erster Deskriptorsatz, für Windows < 8 ① oder avrdude < 7) oder STK600 via WinUSB ② bzw. WebUSB (zweiter Deskriptorsatz, Vorgabe). Das Schöne am STK600 ist, dass man bei avrdude kein COM-Port mehr angeben muss.
Es gibt eine — derzeit noch funktionsarme — Web-Äpp. Damit kann alternativ zwischen STK500- und STK600-Emulation gewechselt werden.
Das dritte USB-Interface ist ein MTP-Interface. Im Explorer oder Total Commander erscheinen dauerhaft 3 winzige ASCII-Dateien zur Konfiguration:
Bei angeschlossenem Mikrocontroller (kurz „Chip“ oder „Target“ genannt) erscheinen einige weitere Binärdateien:
Beim Verzeichnis-Refresh sucht die Firmware mit den Programmier-Algorithmen,
die in der Datei detect angegeben sind,
mit steigender Programmierspannung nach einer bekannten Signatur.
Über eine kompakte Lookup-Tabelle — updatefreundlich im EEPROM —
erfolgt die Zuordnung des Namens, der Sektionsgrößen und der Programmierparameter.
Daraus wird der weitere Verzeichnisinhalt generiert.
Ein Verkürzen der synthetisierten Dateiinhalte auf tatsächlich gefüllte Bereiche erfolgt nicht,
weil das ein doppeltes Auslesen des Chips erfordern würde.
Das gilt sinngemäß auch für jungfräuliche, leere Chips.
∙ Nicht jeder Chip enthält alle diese Sektionen. Entspreched „entstehen“ weniger Dateien.
Dazu „kennt“ die Firmware die Chips anhand ihrer Signatur.
∙ Das Auslesen von per Sperrbit auslesegeschützten Chips liefert Müll.
Deshalb entstehen die entsprechenden Dateien nicht bei detektiertem Ausleseschutz.
Das Schreiben einer Datei mit den oben angegebenen Endungen (außer signature) beschreibt den entsprechenden Speicher im Target. Zusätzlich löst das Anlegen einer Datei auf erase endend einen Bulk-Erase-Befehl aus, der ggf. das Sperrbyte rücksetzt. Auf diese Weise wird keine Programmiersoftware benötigt! Kein avrdude (mögliche Lesung: a-v-r-дюд), kein avr-objcopy: Aufkopieren der .elf-Datei genügt! Alternativ mit einer .hex-Datei, da diese bei PIC üblich ist. (Ich muss noch rausfinden wie das auf der Kommandozeile geht.) Alle anderen Datei-Endungen werden schlicht abgewiesen.
Stand: Datenbank aus 100 AVR-Controllern. Via HVPP erkennen und auslesen. Klartext-Name. Ohne ELF- und HEX-Synthese.
Das Durchschalten der drei USB-Interfaces erfolgt durch einen Jumper zwischen Pin 4 und Pin 6 am ISP oder ESP und Anstecken des USB-Kabels, also bei PowerOn. Bei Erreichen des Ziels Jumper entfernen! Er behindert den Programmiervorgang! Mit jedem Steckvorgang schaltet die Emulation eine Stufe herunter:
Stand: Es funktioniert ISP, HVPP, HVSP und TPI, via
avrdude -c stk600,
avrdude -c stk600pp,
avrdude -c stk600hvsp und
avrdude -c stk600.
Ein Taktsignal für ISP (4 MHz) kann im Innern abgegriffen werden.
Das braucht man wenn die Fuses auf Keramik- oder Quarzoszillator stehen
und kein Quarz oder Keramikschwinger beschaltet ist, oder wenn externe Taktspeisung eingestellt ist.
In Arbeit ist PIC-Programmierung und Integration in avrpp.exe.
In Arbeit
