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

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) 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

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. 

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

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.

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.

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. 

• 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.

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 ).

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.

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.
 

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.

"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. 

---

---