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. Mit PIC-UnterstĂŒtzung: ICSP-HV und ICSP-LV.
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 ATmega16U2 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 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 vier USB-Interfaces
und eine Doppel-Emulation fĂŒr AVR 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 drei Emulationen können auf USB-Seite aus mehreren verschiedenen GrĂŒnden nicht
in einem Multifunktions-USB-GerÀt koexistieren!
Sie mĂŒssen 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:
Es gibt eine â derzeit noch funktionsarme â Web-Ăpp. Damit kann alternativ zwischen STK500- und STK600-Emulation gewechselt werden.
Das vierte 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 vier 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 hoch:
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 PICkit2-Emulation avrdude -c pickit2
und Integration in avrpp.exe.
In Arbeit