AVR-Programmieren mit BASCOM und AVR Studio
Erstellt: DL6GL, 23.12.2012, letzte Änderung 25.01.2022
Zum Programmieren ("Brennen", "Flashen") von AVR-Controllern über die ISP-Schnittstelle braucht man - egal wie - eine geeignete Verbindung zum PC, auf dem die Software erstellt wird. Früher ging das über eine serielle RS232- oder eine parallele Druckerschnittstelle am PC. Heutige PC kennen nur noch USB-Schnittstellen. Entsprechende Programmer USB zu ISP schaffen den Anschluss an moderne Zeiten und das mit mit einem Affentempo.
Da ich es vor einigen Jahren nicht geschafft habe, den zuerst beschafften ISP-PROG [1] an einer älteren Version von BASCOM zum Laufen zu bringen, gibt es nun einem zweiten Programmer, den USBasp [2]. Beide haben in der vorhandenen Entwicklungsumgebung eigene Vorteile.
Eine Beschreibung zur Installation des DIAMEX PROG-S, die auch sinngemäß für andere USB-Programmiergeräte gilt, ist unten im Download verfügbar. Ebenfalls im Download findet sich die Beschreibung zu der hiervon abweichenden Installation des USBasp-Treibers.
Ergänzung 25.01.2022: Die angegebenen Beschreibungen zur Verwendung der Programmer (Diamex bzw. USBasp) wurden noch zu Zeiten von Windows XP erstellt. Sie gelten ebenso für Windows 7.
Mit Windows 10 hat sich einiges geändert.
- Win10 erkennt den Diamex PROG-S (ISP-PROG) von 2010 und installiert automatisch den Treiber.
So weit so gut. - Diamex verkauft inzwischen einen neuen "USB ISP-Programmer", auch wieder mit einer bunten Acryl-Abdeckung. Der sieht etwas anders aus und verwendet wohl auch einen anderen Controller. Ob mein ISP-PROG von 2010 funktional identisch mit dem neuen USB ISP-Programmer ist, kann ich nicht sagen.
Zumindest ist es gelungen, unter Win10 Pro Version 21H2 meinen ISP-PROG mit dem handlichen AVR Studio 4.19 und BASCOM 2.0.8.3 in Betrieb zu nehmen, obwohl Diamex ausdrücklich das Ungetüm Atmel Studio 7 unter Win10 empfiehlt. - Der USBasp-Programmer hat ausgedient. Der Originaltreiber ist nicht signiert, so dass Win10 die Installation verweigert. Der ersatzweise mit dem Zadig-Tool installierte Treiber hat nicht funktioniert.
- Ein Bericht zu meinen Versuchen mit Win10 ist im Download zu finden. Ob das mit dem neuen Diamex USB ISP-Programmer auch so funktioniert, wäre schön, bleibt aber zunächst offen.
Zweck der Veranstaltung war herauszufinden, wie Anwender mit minimalem Aufwand in einer übersichtlichen Darstellung die Fuses einstellen und ein kompiliertes hex-File in einen AVR-Controller laden können.
Mal so vorab: Ist BASCOM (k)eine Programmiersprache?
"C ist eine Programmiersprache, BASCOM ist Müll" hat sich ein C-Nerd bemüßigt gesehen, in einem Forum abzusondern. Was treibt solche Wichtigtuer, ihre unmaßgebliche Meinung immer wieder missionarisch fiebernd hinaus zu posaunen? Erbarmen mit uns Ungläubigen! Den BASIC-Interpretern konnte ich vor Zeiten als Physiker, der die Welt mit FORTRAN zu erklären versuchte, auch wenig abgewinnen. Später dann, an der Wende zum 21-ten Jahrhundert, offenbarte Microsoft Visual Basic for Applications (VBA), hier und da aufgepeppt mit Windows API's, was man alles mit MS Office, insbesondere Access und Excel, anstellen kann. Auch mit BASIC ist einiges möglich. Diese Sprache ist relativ schnell zu lernen. Der Weg zum Erfolg gerät daher kurz und fast geradlinig. Auch als nur noch Gelegenheitsprogrammierer bin ich selbst nach längerer Abstinenz schnell wieder drin. Der Schritt hin zu BASCOM für Mikrocontroller war dann nicht mehr weit. Die C-Syntax mag zwar überaus ökonomisch sein, was den Schreibaufwand betrifft, ist mir aber dann doch zu kryptisch, auch wenn C-Programmierer das als "elegant" bezeichnen werden. Deshalb programmiere ich AVR lieber weniger elegant mit BASCOM. Spiele halt inzwischen in der Amateurliga und fühle mich sauwohl dabei.
Um einiges schöner als BASCOM, irgendwie seelenverwandt mit Visual Basic und sogar kostenlos ist LunaAVR [6]. Wegen der größeren BASCOM-Gemeinde habe ich Überlegungen zum Umstieg dann doch fallen gelassen. Überaus rege im Web ist die Gemeinde auch noch, etwa mit dem BASCOM WIKI [7]. Und - ein dickes Lob muss auch mal sein - der Support (support@mcselec.com) ist rührig. Zwei Anfragen in 2018 zum neuen BASCOM-AVR-Compiler 2.0.8.1 wurden nach 20 Minuten (die erste) und 2 Stunden (die zweite) ausführlich und verständlich beantwortet. Die Serien-Nr. des eigenen Compilers sollte man gleich mit angeben. Konferenzsprache war englisch. Übrigens, bei Ladehemmungen im Englischen kann deepl.com assistieren. Das ist der beste Online-Übersetzer, den ich kenne.
Kurz und gut: Für die eher übersichtlichen Aufgabenstellungen eines Funkamateurs bietet BASCOM trotz mancher Einschränkungen ausreichende Möglichkeiten. Es ist schon lästig, dass in einer Zeile nur eine Rechenoperation möglich ist. Vorteile insbesondere für Anfänger sind ganz klar mächtige Hochsprachenbefehle wie z.B. "GETADC", mit denen mit einer einzigen Zeile Code ein ganzer Schwall von Funktionen im AVR losgetreten wird. Mit der Vorauswahl des zu programmierenden Controllers sind das auch gleich die jeweils Controller-spezifischen. Die Häme von C-Freaks ist damit gesichert. Ohne sich um die Controller-Hardware und deren Register zu scheren, geht ja gar nicht. Mit Verzicht auf solche vorgefertigte Funktionen können jedoch Potenziale einer direkten Programmierung von AVR-Registern, somit näher an der Hardware, auch mit BASCOM erschlossen werden. Kann man, muss man aber nicht. Basisdemokratisch eben nach eigenem Gusto.
Vorbereitung, Fuse Bits setzen mit AVR Studio (Atmel Studio)
Das Brennen eines fabrikfrischen Controllers erfordert zunächst das Setzen/Ändern der Fuse Bits, u.a. um den angeschlossenen Schwingquarz zu aktivieren. PonyProg 2000 ist (war mal) ein nettes Programm zum Setzen der Fuse Bits, sofern der PC noch eine parallele oder serielle Schnittstelle hat und solange man mit älteren AVR-Baureihen arbeitet. RS232 - USB-Wandler funktionieren hier nicht. Den neulich eingesetzten ATmega1284P kennt PonyProg nicht mehr. AVR Studio [3] (bei mir noch in der Version 4.18) ist da besser geeignet. AVR Studio wurde inzwischen umbenannt in Atmel Studio. Der ISP-PROG funktioniert hier bestens, der USBasp mit der Version 4.18 von AVR Studio nicht.
Es geht aber auch einfacher, und das mit dem USBASP ohne einen zweiten Brenner wie den ISP-Prog: mit dem kostenlosen Khazama AVR Programmer [10]. Eine Kurzbeschreibung zum Setzen der Fuse & Lock Bits ist im Download zu finden.
Ein recht universelles Brennprogramm, das auch kostenlos zu haben ist und ohne Installation auskommt, ist das myAVR Prog Tool V1.41 [11]. Beide o.g. Programmer funktionieren damit, der ISP-Prog mit der Einstellung "AVR ISP mk-II" direkt auf der Hardware-Übersicht, der USBasp ist in einer schier endlosen Liste weiterer Programmer unter "Sonstige" wählbar.
Wie das Fuse Bits setzen mit BASCOM geht, etwas gewöhnungsbedürftig, aber immerhin, ist im Download beschrieben.
Abb. 1: Auswahl des Programmers und der COM-Schnittstelle in AVR Studio.
In AVR Studio muss zunächst der verwendete Programmer, hier der ISP-PROG, festgelegt werden. Als Protokoll ist STK500 zu wählen. Die USB-Schnittstelle zum ISP-PROG liegt bei mir auf COM4. Die COM-Schnittstelle ist im Gerätemanager von Windows festzustellen, siehe Beschreibung unten im Download. Wenn dort z.B. COM6 zugewiesen ist, AVR Studio aber nur bis COM4 zählt, wählt man dort "Auto".
Mit Klick auf Connect wird die Verbindung über USB an COM4 zum Programmer ISP-PROG hergestellt, weiter dann über ISP zum AVR Controller. Wenn der Connect geklappt hat, erscheint nachfolgendes Fenster. Wenn nicht, bleibt das obige Fenster stehen mit dem Hinweis "...failed".
Was tun bei "...failed"? Das kann an den Verbindungen (USB- und ISP-Kabel) liegen, am falschen COM-Port, am falschen Protokoll im Feld "Platform" oder an einem defekten oder zerschossenen AVR oder auch nur am ausgeschalteten Controller-Board. Solch ein Fall war einmal an einem zerschossenen AVR zu klären. Dabei reichte es nicht, nach Behebung eines möglichen Fehlers ein erneutes Connect zu versuchen. Was schließlich half, war den PC herunterzufahren und wieder neu zu starten. Möglicherweise wurden damit die COM-Schnittstellen neu initialisiert. Die Computerei ist manchmal eine unergründliche Welt der Wunder...
Wenn sich also AVR Studio auf dem PC und der über USB am Progger hängende AVR gefunden haben, erscheint dieses Fenster:
Abb. 2: Auslesen der Microcontroller-Signatur.
Der AT mega1284P wurde über die ISP-Schnittstelle auf dem Controller-Board richtig erkannt (nach Klick auf Read Signature).
Halt! Dieser Screenshot wurde von einem ATmega1284P gemacht, bei dem die Fuses bereits gesetzt waren. Fabrikfrische AVR sind auf den internen RC-Taktoszillator eingestellt, je nach Typ 1 oder 8 MHz (im Datenblatt unter "System Clock and Clock Options" zu finden).
Bei älteren AVR wie den ATmega8/16/32 ist die Werkseinstellung für den RC-Takt 1 MHz. Mit der in AVR Studio gesetzten ISP-Frequenz 460,8 kHz kommt ein solcher AVR nicht zurecht. Der Leseversuch in Abb. 2 würde scheitern, da der Controller nicht erkannt wird.
Die ISP-Frequenz darf maximal 1/4 der Taktfrequenz betragen.
Vorerst muss daher die ISP-Frequenz auf ein erträgliches Maß unterhalb 250 kHz bei AVR-Typen mit 1MHz RC-Takt eingestellt werden:
Abb. 3: Setzen der ISP-Taktfrequenz vor dem erstmaligen Brennen des Microcontrollers mit 1 MHz RC-Takt.
- Klick auf "Settings"
- Im Fenster Target Settings 115,2 kHz (< 250 kHz) auswählen
- Mit Klick auf "Write" wird diese Einstellung übernommen.
Damit sollte nun "Read Signature" im Main-Register funktionieren. Nachdem wie nachfolgend beschrieben der externe Crystal Oscillator (Quarz an XTAL1 und XTAL2) aktiviert ist, kann die ISP-Frequenz wieder höher bis auf 1/4 der Quarzfrequenz gesetzt werden.
Nachdem das geklärt ist, geht es endlich an die Fuse Bits.
Abb. 4: Setzen der Fuse-Bits, hier ATmega1284P.
So wurden die Fuse Bits des ATmega1284P eingestellt. Die Fuse Bits unterscheiden sich je nach Controller. Andere Brennprogramme sind eventuell nicht so vornehm ausgestattet und erwarten die hex-Werte für die Fuses. Diese sind im mittleren Teil von Abb. 4 zu sehen, hier also hex FF für das Extended Fuse-Byte und hex DF und hex EF für das high und low Fuse-Byte.
- Der Brown-out detection level (BODLEVEL) kann auf eine minimale Versorgungsspannung eingestellt werden, unterhalb der der AVR seinen Dienst verweigert und einen Reset durchführt statt Unsinn zu machen. Ist in Abb. 4 ausgeknipst (disabled). Wenn in das EEPROM geschrieben wird, sollte das Brown-out auf alle Fälle eingeschaltet werden.
- SPIEN (Serial program interface enabled) aktiviert die ISP-Programmierschnittstelle. Finger weg! Ist in AVR Studio zum Glück nicht aktiviert. Wurde die ISP-Schnittstelle einmal ausgeknipst, kann der Controller nicht mehr über ISP programmiert werden.
- Mit BOOTSZ (Boot loader size) wird die Größe des Bereiches festgelegt, der für den Bootloader am oberen Ende des Flash-Speichers reserviert wird, falls ein solcher eingesetzt wird. Wenn nicht, kann man BOOTSZ wie hier auf den minimalen Wert setzen.
- Mit SUT CKSEL werden die Controller-Taktquelle (CKSEL, je nach Controller mehrere Bits, z.B. 4 Bits CKSEL0...3), hier externer Quarz > 8 MHz, und die Wartezeit (Start up time) nach einem Reset (SUT = 2 Bits SUT0, 1), hier 16k Takte + 4,1 msec, eingestellt. Dazu bietet AVR Studio eine Menge Einstellungen zur Auswahl an. "External Crystal" ist z.B. ein an XTAL1 und XTAL2 angeschlossener Quarz, "External Clock" ist ein an XTAL1 angeschlossener freischwingender Taktgenerator (XTAL2 bleibt dann unbeschaltet).
- Wenn das EEPROM benutzt wird, sollte noch EESAVE aktiviert werden. Damit wird verhindert, dass das EEPROM beim erneuten Flashen eines .hex-Files gelöscht wird.
Mit Klick auf Program werden die vorgenommenen Einstellungen über ISP an den Controller geschickt. Das Übertragungsprotokoll ist unten im Fenster (...OK!) zu sehen. Zu Fuse Bits siehe z.B. [4]. Damit ist der Controller vorbereitet. Die Fuse Bits können natürlich auch nachträglich nach dem Brennen eines Programms geändert werden, z.B. wenn wegen eines stehen gebliebenen JTAGEN (JTAG enabled, ist standardmäßig bei den entspr. Controllern gesetzt) einige Ports, z.B. PortC im ATmega16/32, nicht wie erwartet funktionieren.
Die Fuse Bit-Einstellungen aller Programme auf dieser Website sind im Quellcode angegeben. Sie unterscheiden sich bei den vorgestellten Controllern und Anwendungen nicht oder nur kaum von den in Abb. 4 gezeigten. Unter [8] gibt es einen richtig netten Fuse Calculator. Erklärung der Fusebits in [12].
Vorsicht! Man sollte wissen, was man mit dem Aktivieren und Deaktivieren der Fuses anstellt, siehe z.B. [4]. Also noch einmal alles überprüfen, bevor man auf Program klickt.
Nebenbei bemerkt, sollte jemand die Fuse Bits direkt, z.B. mit AVRDUDE (s.u.) programmieren wollen: Ein Fuse Bit ist mit dem Wert = 0 programmiert (Haken in AVR Studio oder z.B. in PonyProg).
Wert = 1 heißt nicht programmiert - verkehrte Welt.
Nur der Vollständigkeit halber sei noch erwähnt, das der BASCOM-Compiler mit der $Prog-Direktive eine Konfiguration der Fuse-Bits im Quellcode möglich macht, aber das ist Geschmackssache. Vorteil wäre immerhin, dass sogleich das .hex-File ohne händisches Setzen der Fuses wie in Abb. 4 gebrannt werden kann. Auch da sollte man wissen, was man tut. Einzelheiten dazu im Download ("fuses mit bascom...").
Und noch einmal Vorsicht in Bezug auf die ISP-Schnittstelle zur seriellen Programmierung:
- Der RESET-Pin ist tabu. Er ist i.d.R. über einen 10k-Pullup mit +Vcc verbunden. Die ISP-Schnittstelle braucht diese Konfiguration. Bei vielen AVR, etwa dem auch in den Arduino NANO verbauten ATmega328P, könnte dem Datenblatt nach eine Doppelnutzung des Pins PC6/RESET auch als I/O-Pin vermutet werden. Könnte man durchaus, aber dann hat sich das mit der ISP-Schnittstelle erledigt. Also lieber nicht, wenn ISP zur Programmierung verwendet werden soll. Die einzig sinnvolle Beschaltung wäre ein Taster vom Reset-Pin nach Masse für einen manuellen Reset auf einem Test-Board. Wenn allerdings z.B. bei einem Arduino mit Hilfe eines Bootloaders über USB programmiert wird, kann der Reset-Pin anderweitig für I/O-Aufgaben verwendet werden.
Einen Vorteil könnte das o.a. $Prog ohne einen Bootloader ausspielen, wenn etwa bei einem ATtiny die wenigen Beinchen vergeben sind und der Reset-Pin unbedingt als I/O-Port benötigt wird. Mit dem Kompilieren bereitet $Prog die Konfiguration der Fuses vor. Die Fuses werden vor dem Brennen des Programms nicht (!) wie in Abb. 4 gesetzt und in den AVR geschrieben. Mit dem ersten Brennen ist ISP einschl. Reset noch voll funktionsfähig. Es gibt allerdings nur diesen ersten und einzigen Schuss. Danach ist der Reset-Pin umprogrammiert, ISP war dann mal. Soll der Reset-Pin als Input arbeiten, ist der Pullup nach +Vcc schon da, extern mit dem 10k-Widerstand. Soll der Reset-Pin als Output herhalten, muss der Pullup-Widerstand anschließend entfernt werden. - Die anderen ISP-Pins (MISO, MOSI, SCK) können doppelt genutzt werden, wenn es eng wird mit Anschlüssen oder für einen SPI-Bus. In der Application note AVR042 empfiehlt Microchip Entkopplungswiderstände zur Strombegrenzung. Im Antennentuner auf dieser Website wurden MISO, MOSI und SCK, entkoppelt jeweils mit 2,2k, auch zur LCD-Ansteuerung genutzt.
- Das Fuse-Bit SPIEN (SPI enabled) ist über einen seriellen Programmer nicht erreichbar, in Abb. 4 deaktiviert, über AVRDUDE mit Übertragen eines falschen Fuse-Bytes aber schon. Wurde damit etwa SPI disabled, ist es vorbei mit einer seriellen Programmierung. Dann hilft nur noch eine HV- (High Voltage)-Programmierung, um die Fuses wieder zurückzusetzen. Lösungen dazu sind im Netz zu finden. Oder aber den Controller entsorgen...
Programmieren/Brennen mit AVR Studio
Das Programmieren ("Brennen") des Controllers mit einem .hex-File ist nur noch einen Klick weit entfernt. Oben im Reiter von AVR Studio "Program".
Abb. 5: Programmieren (Brennen) des Microcontrollers mit AVR Studio.
- Das Input .hex-File im Computer suchen
- Mit Klick auf Program wird der Controller mit dem .hex-File programmiert ("gebrannt"). Mit dem Haken oben an "Verify device after programming" wird das gebrannte Controllerprogramm mit dem Input .hex-File verglichen - sicher ist sicher. Das Brennprotokoll ist unten im Fenster zu sehen (...OK!).
Im Reiter "Auto" geht es noch etwas vornehmer. Da kann man alle denkbaren Optionen einzeln anhaken, nachdem im Fenster Abb. 5 das Input .hex-File gewählt wurde.
Mit AVR Studio lassen sich also mit einer ansprechenden Benutzeroberfläche die Fuse Bits setzen und ein vorhandenes .hex-File brennen.
Programmieren/Brennen mit BASCOM
Für diejenigen, die mit BASCOM-AVR programmieren, ist der Umweg über AVR Studio zum Brennen überflüssig. Das kann BASCOM auch.
Nicht besonders schön, aber mit dem USBasp-Programmer auch für weniger gebräuchliche AVR-Controller, die z.B. der o.a. Khazama AVR Programmer nicht beherrscht, kann BASCOM auch Fuses setzen. Da mehrere OMs danach gefragt haben, ist eine Beschreibung im Download abgelegt.
Das Übertragen der kompilierten .hex-Files in den AVR kann auch mit dem o.g. ISP-PROG über USB vorgenommen werden. Dazu müssen in Bascom unter "Options-Programmer" wieder das STK500-Protokoll im Feld "Programmer" und die Daten der USB-Schnittstelle (COM-Port und Baudrate entsprechend den Einstellungen im Windows-Gerätemanager) angegeben werden. Wenn oben als "Programmer" STK500 ausgewählt wird, erscheint unten automatisch die vollständige Pfadangabe von STK500.exe (C:\Programme\Atmel\...). Voraussetzung ist ein installiertes AVR Studio, das das Programm STK500.exe mitbringt. Wenn nicht, kann es mit dem Windows-Dateisuchen-Dialog lokalisiert werden, gelbes Icon rechts im Feld).
Abb. 6: Programmieren (Brennen) des Microcontrollers in BASCOM mit STK500.exe .
Die Programmierung eines AVR-Chips geht richtig flott vor sich, angezeigt in einer kleinen DOS-Box. Die verschwindet allerdings sofort nach Beendigung. Das ist mir dann doch etwas zu flott.
Mit dem zweiten USB-Programmer – USBasp [2] kann man mit Hilfe von AVRDUDE [5] die Steuerung selbst in die Hand nehmen.
Abb. 7: Programmieren (Brennen) des Microcontrollers in BASCOM mit AVRDUDE .
Einbindung des USBasp als Programmer in Bascom.
Als "Program" wählt man ein mit dem Windows-Editor selbst erstelltes Batchfile (.bat) aus. Das kann so aussehen:
cls
echo off
@SET Filename="ATU_CONTROLLER_200g.hex"
@SET Device=m1284p
@SET Programmer=usbasp
@SET DudePath="C:\PROGRAMME\AVRDUDE511\avrdude.exe"
%Dudepath% -p %Device% -c %Programmer% -u -U flash:w:%Filename%
pause
exit
Erinnert das jemand an alte MS DOS-Zeiten? Anzupassende Eintragungen:
- SET Filename: Name der zu ladenden .hex-Datei
- SET Device: Microcontroller, hier ATmega1284P
- SET Programmer: Verwendeter Programmer, hier USBasp
- SET DudePath: Speicherort von avrdude.exe
darunter AVRDUDE-Kommandozeile
"DudePath" ist hier das Standard-Installationsverzeichnis unter Windows XP. Windows 7 etwa installiert ARVDUDE in einem anderen Verzeichnis.
Mit dem im obigen BASCOM-Fenster als "Program" mit vollständigem Pfad angegebenen Batchfile wird das zu ladende .hex-File im gleichen Verzeichnis erwartet.
Das Batchfile zeigt auch wieder in einer DOS-Box den Fortschritt an, bleibt aber wegen des vorletzten Statements "pause" stehen. So kann man das Ergebnis erst einmal beäugen, bevor man es mit einem Tastendruck wegklickt. Es könnte ja auch mal was schief gegangen sein.
Zum Ändern das Batch-File auf keinen Fall im Explorer doppelt klicken!
Im Windows-Explorer: Rechtsklick, dann im Kontextmenü: Bearbeiten. Der Editor öffnet das File.
Nach der Anpassung den Editor oben rechts am "X" schließen, Speichern "Ja".
Viele Betriebssysteme, Mail-Server und MS Outlook reagieren allergisch auf .bat-Files. Mit Umbenennen in ".txt" vor der Versenden lässt sich das umgehen.
AVRDUDE kann wesentlich mehr als das hier gezeigte Rüberschieben des .hex in den Controller. Auch Fuse Bits können damit direkt gesetzt werden. Da sollte man aber wissen, was man tut.
Erklärung der Parameter in [5], "... avrdude-doc-5.11.pdf".
Eine Beschreibung zu Installation und Nutzung des USBasp unter BASCOM ist im Donwload zu finden. Treiber für den Diamex ISP-Prog können von [1], drittes Zitat, für den USBASP von [2] heruntergeladen werden, auch für Windows 7 und 10 (64bit) tauglich. Eine ausführliche Diskussion zum Einsatz verschiedener Programmer unter Windows 10 ist in [9] zu finden.
Referenzen
[1] http://stores.ebay.de/stange-distribution-Shop
http://www.diamex.de/dxshop/DIAMEX-USB-ISP-Programmer-Stick-fuer-AVR
http://forum.diamex.de/content.php?26-programmierger%E4te
[2] http://www.fischl.de/usbasp/
http://www.protostack.com/blog/2011/05/usbasp-driver-for-windows-7-and-…
[3] Übersicht in http://www.mikrocontroller.net/articles/Atmel_Studio
[4] http://www.wiki.elektronik-projekt.de/mikrocontroller/avr/fusebit_tutorial
http://mcpg.augusta.de/kmodule/k-cpu-modul/kcpuF.html
[5] http://www.mikrocontroller.net/articles/AVRDUDE
unten mit Link auf das 2011 aktuelle AVRDUDE 5.11
direkter Link: http://www.mikrocontroller.net/attachment/123564/AVRDUDE_5.11.1.zip
Beschreibung: http://mirrors.fe.up.pt/pub/nongnu/avrdude/avrdude-doc-5.11.pdf
AVRDUDE-Site: http://savannah.nongnu.org/projects/avrdude/
[6] http://avr.myluna.de/doku.php
[7] http://bascom-forum.de/mediawiki/index.php/Hauptseite
[8] http://www.engbedded.com/fusecalc/
[9] http://www.mikrocontroller-elektronik.de/isp-programmer-fuer-arduino-ba…
[10] http://khazama.com/project/programmer/
[11] http://shop.myavr.de/index.php?sp=download.sp.php&akt_kategorie=4
[12] http://www.gtkdb.de/index_18_1044.html
Download
DIAMEX PROG_S Installationsbeschreibung
usbasp_installieren_und_einsatz_mit_bascom.pdf