Holgi's AVR/ATMega Prommer und Testboards

Einfacher AVR / ATMega Parallelport  Prommer. NEU AVR/ATMega USB Prommer mit FTDI FT245BM Chip
Quellcode zum AVR/ATMega Prommer (LPT+USB VC 5.00)
AVR-GCC/WinAVR ein genialer kostenloser C-Compiler für AVR/ATMega
Ein paar Tips zu den Fuse Bits und anderes

Testprojekte:
LCD-Display für GPS-Mäuse
ATMega128 Grafik- und Textroutinen für Displays mit KS108 Controller
ATMega323 Grafik- und Textroutinen für Displays mit T6963 Controller
ATMega32 liest und schreibt CompactFlash/MMC/SD mit FAT 12/16/32
FAT Single-File-System für ATMega ab 1kB RAM
FAT Multi-File-System für ATMega ab 4kB RAM
FAT Mini File-System ab 100 Byte RAM (FAT12/16 und READONLY)
T6963 Display: Bilder speichern und lesen von MMC/SD mit FAT Dateisystem


Holgi's AVR / ATMega Testboards
AVR/ATMega Testboard 2


Es muß nicht immer gleich ein AVR-Starterkit für 128 Euro sein um mal ein bißchen mit Atmels AVR / ATMega rumzuspielen. Ein einfaches Selbstbau-Board ist besser dazu geeignet die ersten Gehversuche zu machen. Meine kostengünstigen Testboards sind Vorschläge wie ein einfaches Versuchsboard für z.B. Schulen oder FH/UNI's aussehen könnte. Damit kann man nicht alles machen was ein AVR-Starterkit bietet, aber sie reichen aus um nur mal ein paar Zeichen die per serieller Schnittstelle empfangen wurden auf einem LCD-Display auszugeben. AVR-Studio mit Software-Simulator und Debugger verwende ich nicht. Dauert alles viel zu lange und schnelle externe Interrupts in Echtzeit kann man damit sowieso nicht simulieren. Der beste Simulator/Debugger ist immer noch eine einzelne LED um zu sehen wie weit das Programm kommt und ein LCD-Display um Werte an bestimmten Stellen auszugeben. Mehr braucht der erfahrene Entwickler nicht. 

Die Testboards sind alle ähnlich aufgebaut.

  • 3,5mm Klinken-Buchse für ein 12V Steckernetzteil
  • 5V Spannungsregler Onboard
  • ISP Schnittstelle zum programmieren
  • 9 polige serielle Schnittstelle mit MAX232
  • Anschluß für Standard LCD-TextDisplays (14polig)
  • Alle Portpins auf mehrere kleine Wannenstecker verteilt um Erweiterungen auf einseitigen Platinen zu erleichtern
  • Zwei LED's um ein bißchen Licht in die Sache zu bringen
AVR/ATMega Testboard (Eagle 3.5) AT90S8515, ATMega161 u.a.

AVR/ATMega Testboard (Eagle 3.5) AT90S8535, ATMega323 u.a.
AVR/ATMega Testboard (Eagle 3.5) AT90S8535, ATMega323, ATMega32, ATmega644 u.a. verbesserte Version. Der LCD-Anschluss mit 8Bit Ansteuerung war keine gute Idee. PORTC liegt jetzt wie alle anderen Ports auf einer 10 poligen Stiftleiste. Das ist flexibler.

AVR/ATMega Testboard (Eagle 3.5) AT90S4433, ATMega8 u.a.
AVR/ATMega Testboard (Eagle 3.5) AT90S4433, ATMega8,88,168 u.a. verbesserte Version für meine MMC/SD und MP3 Module

ATMega128  Testboard (Eagle 3.5) Nichts für zittrige Finger ;) Übrigends: Das TQFP64 Package das in der at90smcus.lbr von der CADSoft Seite für ATMega enthalten war, war einfach falsch. Pinabstand 0.76mm statt 0.8mm. Das passt nicht. Die Library gibts zum Glück nicht mehr. In der neueren avr.lbr ist der Pinabstand für TQFP64 aber immer noch etwas zu klein.

128kB SRAM-Modul für das ATMega128 Testboard Davon sind 120kB in zwei 60kB Bänken nutzbar. Im Archiv ein einfaches SRAM-Testprogramm. Kann man auch mit AT90S8515, ATMega162 u.a. nutzen wenn man es entsprechend anschließt.

MMC/SD Karten Modul



Dieses Projekt wurde mit ATMega323 und mehreren anderen AVR/ATMega's mit den Testboards, dem AVR/ATMega Prommer und AVR-GCC entwickelt. Eine Anzeige für GPS-Mäuse.
Quellcodes dazu für alle von mir verwendeten Prozessoren AVR-GCC 3.2
Quellcodes dazu für alle von mir verwendeten Prozessoren WINAVR 3.4.3
Dank an Arne der die Codes an WINAVR 3.4.3 angepasst hat. Es sind auch Projektdateien für Programmers Notepad dabei.

GPS-Display


ATMega128 Grafik- und Textroutinen für Displays mit KS108 Controller  WinAVR 3.3 (bleibt nicht mehr lange hier liegen)
ATMega128 Grafik- und Textroutinen für Displays mit KS108 Controller  WinAVR 3.4.5 Version mit Updates für 128x64 Displays

ATMega323 Grafik- und Textroutinen für Displays mit T6963 Controller
Der Bauplan für den notwendigen Adapter ist im Archiv. Das Programm oben belegt fast 100% des FlashSpeichers vom ATMega323 und funktioniert trotzdem ohne Probleme. Da der FlashSpeicher für weitere Funktionen nicht mehr reicht hier noch ein zweites Demoprogramm:
Arbeiten mit DUAL Screens

Und noch ein wirklich schickes Demoprogramm mit ATMega323: Rotierende Vektorgrafik
Wie zu besten Elite Zeiten fliegt ein Raumschiff über den Schirm und dreht sich um seine Längsachse oder kreist um eine Kugel. Bei 4MHz Takt ruckelt das ganze noch. Bei 8MHz sieht es schön flüssig aus. Bei einem ATMega32 getaktet mit 16MHz sieht man Warpspuren hinter der Viper. 

Das Programm ist nicht von mir sondern von Holger Buss und läuft im Original auf einem M16C62 Prozessor http://www.mikrocontroller.com
Er hat mir freundlicherweise erlaubt die ATMega Version hier zu veröffentlichen. 

T6963 Demo 1


Ich habe das T6963 Demoprogramm mit meinem FAT Dateisystem verheiratet. Achtung: Ohne Änderung nur für ATMega mit mehr als 32kB Flash. Ich habe einen ATMega644 benutzt. Man kann komplette Screens vom Display auf MMC/SD speichern und auch wieder in das Display einlesen. Die Screens werden als Bitmap Datei (*.bmp) gespeichert. Die sollte jedes Grafikprogramm anzeigen können. Ich kann aber nicht sagen ob das Programm ALLE Bitmaps lesen kann die mit einem Grafikprogramm erzeugt wurden ! 

Wozu ist das gut ? Mein altes T6963 Demoprogramm lädt Bitmaps nur aus dem Flash des Microcontrollers. Bei einem 240x64 Display sind das immerhin 2kB pro Screen. Auch Fonts müssen im Flash stehen. Bei aufwendigen Menü's mit mehreren Ebenen und vielen Grafikelementen ist der Speicher des Microcontrollers schnell am Ende. Wenn man vorher berechnete Screens von einer MMC/SD liest sind die Möglichkeiten fast unbegrenzt. Bleibt da nur die Frage: Was ist das kleinere Übel ? Bitmaps im Flash oder der Speicherbedarf der Routinen mit MMC/SD und FAT System. Für mich keine Frage: Auf der MMC/SD ist ja auch noch Platz für einige MP3's ! 

Getestet wurde bisher nur mit 240x64 Display. Im 8 Bit Modus sollte es auch keine Probleme mit 128x64 Displays geben. Im 6 Bit Modus erwarte ich aber noch Fehler.

T6963 und SingleFAT lesen und speichern von Bitmaps
Kleines Programm das eine Animation berechnet, auf MMC/SD speichert und dann abspielt


ATMega32 liest und schreibt CompactFlash und sendet die Daten über die serielle Schnittstelle zum PC. Man kann einzelne Sektoren auslesen und beschreiben oder auch schon einfache Befehle für FAT12/FAT16/FAT32 Dateisysteme ausführen. Näheres siehe readme.txt im ZIP-Archiv. Der ATMega32 braucht dazu KEIN externes RAM. Ist natürlich alles in C (AVR-GCC 3.2) geschrieben. In Assembler würde ich mir das nie antun.

Beispiel ls-Befehl:

>ls
F IO      .SYS RSH-  31.05.94  06:22     41055  Clu:         3
F MSDOS   .SYS RSH-  31.05.94  06:22     38186  Clu:        24
F COMMAND .COM R---  31.05.94  06:22    57377  Clu:        41
D DCIM    .    ----  14.04.03  13:00 <DIR>      Clu:      7892
V HITACHI .    ---A <VOL>
F GPSREA~1.EXE ---A  19.11.02  13:19    125440  Clu:       446
F KERNEL  .    ---A  16.01.02  22:52    458824  Clu:        68
F LINUX   .BAT ---A  06.09.01  11:10        78  Clu:       348
F LOADLIN .EXE ---A  24.01.97  00:32     32177  Clu:       349
F OPT     .TGZ ---A  28.01.02  01:41    278041  Clu:       293
F ROOTFS  .GZ  ---A  07.06.01  13:52    331581  Clu:       593
F AUTOEXEC.BAT ---A  10.01.02  00:35         7  Clu:         2
F CDROM   .SYS ---A  22.03.00  13:35     24710  Clu:       508
D TRACKS  .    ----  06.01.03  16:24 <DIR>      Clu:       521

Dateien können gelesen werden. Man kann neue Dateien erzeugen oder Daten an vorhandene Dateien dranhängen. Lesen und schreiben geht auch in Unterverzeichnissen. Die FAT darf im Gegensatz zu andern FAT Implementationen die mir hier und da begegnet sind auch fragmentiert sein. Verzeichnisse anlegen, löschen und lange Dateinamen geht nicht. Diese FAT Version sollte man aber nicht mehr benutzen. Sie ist schon zu alt.
Nimm besser FATSingle oder FATMulti.



FullFAT Single-File-System für ATMega ab 1kB RAM:
FullFAT ist eine verbesserte Version meiner ersten FAT-Routinen. Man kann neben CompactFlash auch MMC/SD Cards mit FAT12/16/32 lesen und schreiben. Zusätzlich kann man Verzeichnisse selbst anlegen und auch Dateien löschen. Man kann immer nur eine offene Datei zur Zeit bearbeiten. Mehrere Dateien können nur NACHEINANDER bearbeitet werden.

FATSingle WinAVR 3.4.3 alte Version ohne SDHC Support. Dafür kleinerer Code. Wird nicht mehr gepflegt.

FATSingleOpt WinAVR 4.1.1  Version mit SDHC Support.

FATSingleOpt41 Beta WinAVR4.1.1   Neue Version mit komplettem Fseek().
Fseek() jetzt auch beim schreiben möglich. Daten in Dateien überschreiben ist jetzt erlaubt.
Fopen(filename,'w') spult nicht mehr automatisch ans Dateiende. Das macht jetzt Fopen(filename,'a'). 

FatSingleOpt41LFN Alpha WinAVR4.1.2  Für den experimentierfreudigen. Erste Versuche für LFN (Long File Name) Support.
Dateien oder Verzeichnisse mit LFN erzeugen geht nicht. Man kann in Dateien mit LFN schreiben wenn sie bereits existieren.

Hier gibt es eine Version für ARM7 LPC2136 WinARM

Ein reines Lesesytem für FAT12/16/32 kommt mit ca. 5kB Code aus. Ein KLEINES Schreib/Lesesystem mit ca. 10kB. Wenn man ALLE Funktionen benutzen möchte, kann es in einem ATMega16 schon zu eng werden. RAM Bedarf ohne FAT-Buffer ca. 0.7kB. Mit FAT-Buffer 1.2kB

24.03.2010  Bug in Fseek() beseitigt. 

09.09.2009  Fehler in fat.c gefunden. Bei einem reinen FAT16 System wurde die Clusterzahl falsch berechnet. 

11.08.2007  Rename() benennt jetzt auch Verzeichnisse um. Remove() löscht jetzt Verzeichnisse. Es macht sie vorher aber NICHT leer !

10.07.2007  2GB SD Karten funktionieren jetzt. 4GB non-SDHC Karten noch nicht getestet.

30.04.2007  Verbesserte Version mit SDHC Support. FAT Zugriffe konnten auch ohne FAT Buffer halbiert werden.


Multi-FAT Multi-File-System für ATMega ab 4kB RAM

Dieses FAT-File-System kann mehrere Dateien gleichzeitig zum lesen oder schreiben öffnen. Es basiert auf einem Vorschlag von Qpel (seinen richtigen Namen wollte er mir  nicht nennen :(  Thanks to Qpel !

Der Funktionsumfang ist wie bei FATSingle: CF/MMC/SD Cards mit FAT12/16/32. Dateien lesen, schreiben und löschen. Verzeichnisse erzeugen und in Unterverzeichnisse wechseln.

Die Anzahl gleichzeitig geöffneter Dateien hängt nur vom verfügbaren freien RAM Speicher ab.

FATMulti WinAVR 3.4.3

FATMulti Beta WinAVR4.1.1   Neue Version mit komplettem Fseek().
Fseek() jetzt auch beim schreiben möglich. Daten in Dateien überschreiben ist jetzt erlaubt.
Fopen(filename,'w') spult nicht mehr automatisch ans Dateiende. Das macht jetzt Fopen(filename,'a'). 

FATMulti Beta LFN WinAVR4.1.1  Für den experimentierfreudigen. Erste Versuche für LFN (Long File Name) Support.
Dateien oder Verzeichnisse mit LFN erzeugen geht nicht. Man kann in Dateien mit LFN schreiben wenn sie bereits existieren.

Hier gibt es eine Version für ARM7 LPC2136 WinARM

24.03.2010  Bug in Fseek() beseitigt. 

09.09.2009  Fehler in fat.c gefunden. Bei einem reinen FAT16 System wurde die Clusterzahl falsch berechnet. 

11.08.2007  Rename() und Fseek() neu dazu gekommen. Remove() löscht jetzt Verzeichnisse. Es macht sie vorher aber NICHT leer !

03.08.2007  Code aufgeräumt. FAST_FREAD,FAST_FWRITE beschleunigt und Code verkleinert. FASTER_RW wieder entsorgt.

10.07.2007  2GB SD Karten funktionieren jetzt. 4GB non-SDHC Karten noch nicht getestet. Kleine Anpassungen für AVR-GCC 4.1.1.

30.04.2007  Verbesserte Version mit SDHC Support. 



MiniFAT:
Es geht aber auch mit weniger als 100 Byte RAM und ca. 3kB Code wenn man mit einigen Einschränkungen leben kann:
  • Die FAT darf nicht fragmentiert sein
  • Nur FAT12 und FAT16
  • Keine Unterverzeichnisse
  • NUR lesen möglich
  • maximal 512 Dateien (im RootVerzeichnis)


MiniFAT WinAVR 3.4.3

29.10.2006  Fehler in fat.c gefunden.



 
 




Holgi's AVR / ATMega Prommer

AVR / ATMega Prommer Software (LPT+USB) und LPT-Hardware (Eagle 3.5) USB Hardware siehe unten

Getestet mit W95 / W98 / NT4 und XP (mit giveio.sys Treiber ).


AVR/ATMegaprom OberflächeAVR/ATMega Prommer. Das ist alles !


Bisher habe ich mit dem LPT-Prommer ATiny26, ATMega8, 168, 128, 161, 163, 323, 32, 644 und AT90S2333, 4433, 8515, 8535 ohne Probleme auf den Testboards programmiert. Takte von 1MHz bis 16MHz. 

Wer den LPT-Prommer lieber mit AVRDUDE zum prommen benutzen möchte, hier eine Beschreibung von Arne wie das geht: AVRDUDE

14.03.2003 Neu: AVR / ATMega USB Prommer (ziemlich langsam)

11.10.07 Versuche haben gezeigt das AVR/ATMega ab 1MHz Takt ohne Probleme per LPT programmiert werden können. Für den Fall das der Prozessor mit Taktfrequenzen unter 1MHz getaktet wird gibt es jetzt unter "Prefs" eine Möglichkeit die SPI-Programmierung anzupassen. Die LPT-Bremse. Der Wert 0 ist Maximum-Speed für die Programmierung. Werte größer 0 bremsen die Programmierung dann entsprechend immer mehr. Es gibt einen neuen Knopf "Sende Reset". Damit wird der Prozessor angehalten und das Programm neu gestartet. Ist manchmal ganz nützlich.

Nachbau und Benutzung auf eigene Gefahr. Ich habe den LPT-Prommer an mehreren Rechnern getestet. Es könnte durchaus noch Probleme geben. Bei einem Teilepreis <5 Euro ist er aber wohl einen Versuch Wert. Diese Schaltung ist für die experimentierfreudigen unter euch. Es gibt keine Funktionsgarantie von mir ! 

Probleme: Alle Kabel sollten möglichst kurz sein. Das Parallelportkabel sollte nicht länger als 1,5m sein und nicht zur billigsten Sorte gehören. Das Kabel vom Prommer zur Schaltung nicht länger als 20cm. Das sollte dann auch ein Flachbandkabel sein und nicht irgendwelche Kabelreste. Wer längere Kabel benutzt tut dies auf eigene Gefahr. Da ist ausprobieren angesagt.

Es können mehrere HEX-Formate und das Atmel ROM-Format gelesen und gespeichert werden. Beim ersten Start muß man zunächst auf den PREFS Knopf drücken. Dort kann die Portadresse ausgewählt oder eingegeben werden wenn sie dort fehlt. Wenn die eingestellte Adresse nicht stimmt bekommt man meist ein SPISync() fehlgeschlagen als Meldung wenn man z.B. programmieren wollte.

Die Bedienung ist sehr einfach. Die Knöpfe sprechen für sich. Etwas gewöhnungsbedürftig sind die FuseBits. Man muß dort die Fuses anklicken die programmiert werden sollen. Programmiert heißt 0 nicht 1. Also nur die Fuses anklicken die 0 werden sollen. Zur Bedeutung der Fuse-Bits bitte das Datenblatt zum Chip lesen. Wenn ein neuer Chip ausgewählt wird werden alle Einstellung des alten Chips gespeichert. Man muß also die Fusebits und die Brenndatei nicht jedesmal neu einstellen wenn man wieder auf den alten Chip wechselt.

ID-prüfen sollte besser nur in Ausnahmefällen deaktiviert werden. Leerzellen speichern und Checksumme prüfen am besten so lassen wie sie sind.

Die Brenndatei wird für jeden Programmiervorgang neu gelesen. Man kann also das Brennprogramm in den Hintergrund klicken, das Programm für den Prozessor ändern und neu übersetzen, das Brennprogramm wieder in den Vordergrund holen und losprogrammieren. Das Brennprogramm kann nicht per Kommandozeile in eine IDE eingebunden werden (naja, starten kann man es natürlich). Das wurde von mir nicht vorgesehen. Man kann auch das Daten-EEPROM programmieren. Dazu muß eine zweite Datei mit der Endung *.EEP vorhanden sein. Ganz wie bei AVR-Studio. Die wird dann automatisch mitprogrammiert. Beispiel: Programm in GPS.HEX und Daten in GPS.EEP, oder LCD.ROM und LCD.EEP .

Der Prommer hat keine eigene Stromversorgung. Er wird aus der Zielschaltung versorgt. Daraus ergibt sich das die Schaltung laufen muß wenn sie programmiert werden soll. (Bitte nicht lachen, danach wurde tatsächlich schon gefragt :) Vor dem programmieren wird der Prozessor angehalten, dann programmiert und zum Schluß sollte die Schaltung mit dem neuen Programm loslaufen. Alles mit einem Knopfdruck. Problem: Wenn der PC runtergefahren wird bleibt die Schaltung stehen. Dann entweder den ISP-Stecker ziehen, oder wenn der PC gerade hochgefahren wurde das Brennprogramm einmal kurz starten.

Zum Nachbau: Wer andere Teile als die in meiner Schaltung angegebenen benutzen möchte braucht mich gar nicht erst danach zu fragen. Probier es selbst aus. Bei meinem Platinenlayout muß ein Sub-D Stecker eingesetzt werden, keine Buchse.

Mein Tip: Wer wenig Zeit hat sollte keine alten AT90Sxxxx mehr programmieren. ATMega's und ATiny's werden pageweise beschrieben. Das geht wesentlich schneller. AT90Sxxxx werden einer nach dem anderen abgekündigt. Es gibt inzwischen ATMega8515, 8535. ATiny2313 usw. Für neue Designs sollte man besser gleich einen ATMega oder einen ATiny vorsehen.


AVR / ATMega USB-Prommer

Voraussetzungen: Mein FT245BM Testboard mit Zusatzplatine und D2XX Treiber.  Die angegebene Seite auf jeden Fall äußerst aufmerksam durchlesen ! Funktioniert mit W98 bis XP. W95 ist leider nicht möglich. Der D2XX Treiber unterstützt W95 nicht mehr.

Vorsicht: Der AVR / ATMega USB Prommer ist nur eine Designstudie zum BitBang Mode vom FTDI Chip. Ich wollte mal sehen was einen bei einer realen Anwendung so erwartet. Als Ergebnis zeigt sich das dies ein schönes Beispiel ist wie man es nicht machen sollte. Der USB Prommer ist wesentlich langsamer als der LPT Prommer. Das liegt daran wie die Daten auf dem USB Bus übertragen werden. Ein gleichzeitig arbeitendes USB-DSL Modem beim Download beschleunigt die Programmierung nicht gerade. AVR's werden nur extrem langsam programmiert. Bei ATMega's ist die Programmierzeit noch akzeptabel. Wie man sieht ist bei USB gerade das zurücklesen von Daten im BitBang Mode besonders langsam.
 

ATMega32
32kB Daten
AT90S2333
2kB Daten
Mit Prüfen Kein Prüfen
LPT 9s 8s
USB 61s 37s
Mit Prüfen Kein Prüfen
LPT 11s 10s
USB 124s 30s

Um die  Knöpfe Leertest, Prüfen und Auslesen sollte man einen großen Bogen machen. Einen Versuch den ATMega auszulesen habe ich bei 50% abgebrochen. Verschwendete Zeit 849s. Das sind ca. 6-7ms pro Bit.

Fazit: Eigentlich wollte ich den USB Prommer hier schon nicht mehr veröffentlichen. Aber so ganz unbrauchbar ist er ja nicht solange man Prüfen abschaltet. Vieleicht findet sich ja irgendwer der einen Trick kennt wie man das auslesen beschleunigt.

Einen richtig schnellen USB Prommer kann man wohl nur bauen wenn man das SPI Protokoll nicht direkt mit dem FTDI Chip erzeugt. Man nimmt den FIFO Mode des Chips und schließt z.B. einen AVR an. Der managt dann die Daten und erledigt das SPI Protokoll.



Grundeinstellung für den AVR / ATMega Prommer ist der LPT Mode. Den USB-Mode stellt man ein indem man auf den "PREFS" Knopf drückt. Dann erscheint dieser Dialog:

"USB Prommer" aktivieren.

USB SerialNr:  Dort trägt man die Seriennummer ein die von FTD2XXST in das EEPROM einprogrammiert wurde. Also nicht die die oben zu sehen ist. Ohne Seriennummer findet das Programm den USB Prommer nicht. Groß/Kleinschreibung beachten. Die Zahl 0 nicht mit dem Buchstaben O verwechseln.

USB Baudrate: 38400 Baud sind bei 16, 8, 4, 2 MHz Taktfrequenz vom AVR / ATMega optimal. Mit 57600 Baud oder größer ging es einfach nicht mehr. Wenn die Schaltung mit weniger als 2MHz Taktrate läuft kann es erforderlich sein die USB Baudrate kleiner als 38400 Baud zu machen.


Ich entwerfe keine Schaltungen oder Programme für andere. Dazu fehlt mir einfach die Zeit. Bei mir sind keine Bausätze, Platinen oder programmierte Chips zu den Schaltungen erhältlich. 

E-Mail

Zur Startseite