Compilieren, FuseBits und Flashen

[Torsten]

Hallo Leute,

 

bevor ich gleich noch das erste Testprogramm für das Evaluations Board einstelle, möchte ich euch kurz mit der Routine des Compilierens und Flashens vertraut machen.

Auch die FuseBits werden wir schon einmal kurz streifen; wenn da bestimmte Einstellungen erforderlich sind, werde ich an entsprechender Stelle im Kurs darauf hinweisen.

 

Wichtig bei allem, was wir mit den Chips anstellen möchten, ist das jeweilige Datenblatt. Die gibt´s zum Download bei atmel.com - leider nur auf Englisch...

 

Aber fangen wir mal an, wir starten also Bascom und werden mit einer relativ leeren Seite begrüßt.

Nun kann man entweder ein Programm schreiben, öffnen oder - was auch sehr gut geht - mittels Copy&Paste einfügen, denn Bascom ist textbasiert.

Da ich die Code-Beispiele hier in Textform einstellen werde, entscheiden wir uns mal für diesen Weg.

 

Also, den jeweiligen Quellcode markieren, kopieren (oder STRG+C) und dann in den Texteditor einfügen.

 

Anschließend sollte man erst einmal speichern:

 

 

 

Wenn man jetzt in das Verzeichnis schaut, findet man ein oder zwei Dateien, je nachdem, ob man das Projekt von anderswo geöffnet (die Frage nach dem CFG-File ggf. mit Ja beantworten) oder frisch erzeugt hat.

 

Die .BAS ist das eigentliche Programm, die andere Datei die .CFG (die Windows natürlich gleich als Outlook-Datei vereinnahmen möchte...)

 

Die .BAS-Datei kann nicht direkt in den Prozessor geschoben werden sondern muß zunächst in einen Code übersetzt werden, die der Chip (und leider auch nur der Chip...) verstehen kann. Das gilt im Übrigen für alle Hochsprachen - auch "C"-Programme und Assembler.

Aber gut - Compilieren wir mal und sehen, was passiert...

 

 

Es rattert ein wenig, und dann erscheint hoffentlich diese kleine, etwas wortkarge Erfolgsmeldung:

 

"Flash used:" zeigt uns an, wie viel des Prozessor-Speichers wir mit unserem Programm "verbraten" werden.

 

Wenn der Compiler Fehler feststellt, zeigt er diese unten im Meldungsfenster an. Klickt man auf die Meldungszeile, wird der Cursor auf die fehlerhafte Stelle im Programm gesetzt. Da muß aber nicht zwingend auch der eigentliche Fehler liegen.

 

Aber das wird erst richtig wichtig, wenn ihr eigene Programme schreibt. Nicht erschrecken oder verzweifeln, wenn mal etwas nicht gleich so tut - das lernt sich schon alles.

 

Verlief das Compilieren fehlerfrei, dann ist jetzt im Hintergrund so Einiges passiert - wir schauen noch einmal in das Programm-Verzeichnis:

 

Es sind einige Files dazu gekommen, für uns entscheidend ist das HEX-File, denn das enthält den Code, den wir zum Prozessor übertragen müssen.

Bascom kann das leider nicht über die uns zur Verfügung stehenden Schittstellen, deshalb ist jetzt der Burn-O-Mat an der Reihe. Wir verbinden also den Prozessor über die ISP-Schnittstelle des Atmel-Boards mit unserem Adapter bzw. stöpseln das RS232-Kabel an der ISP-Schnittstelle ein und starten das Programm.

Falls noch nicht geschehen, macht bitte noch die richtigen Einstellungen für Burn-O-Mat, wie bei der "Verwendeten Software" angegeben.

 

 

Wenn wir das Programm gestartet haben, stellen wir den verwendeten Prozessor ein und klicken zunächst einmal auf "Fuses", worauf hin sich ein weiteres Fenster öffnet. In diesem klicken wir oben rechts auf "read fuses".

 

Wenn alles richtig verbunden und eingestellt ist (und der Prozessor in der Fassung steckt... ), bekommen wir ein solches Ergebnis angezeigt:

 

 

Zunächst relativ nichtssagend, aber wir blicken hier direkt ins "BIOS" des Microprozessors. Hier kann (und muss) man wichtige Einstellungen vornehmen, und leider gibt es auch ein paar Häkchen, die den Prozessor dauerhaft zum Schweigen bringen, wenn man etwas falsch macht.

Die Einstellungen sind im Datenblatt beschrieben.

Zu allem Überfluss sind die Häkchen auch noch umgekehrt - nein, ich verstehe diese Logik auch nicht - man muß also schon sehr aufpassen, wenn man hier etwas einstellt.

 

Zunächst wechseln wir mal oben rechts in den Experten-Modus (sind wir vielleicht noch nicht, aber das wollen wir ja werden...), damit wir Zugriff auf die rot markierten Zeilen erhalten und setzen die Häkchen entsprechend dem Bild:

 

 

Was richten wir damit an? Nun, wir schalten SPI, JTAG und OCD ab, denn JTAG belegt bestimmte Ports, die wir dann nicht zum Programmieren nutzen können.

Im Unteren Teil findet man die vier CKSEL-Bits, mit denen der Prozessortakt bzw. die Taktquelle ausgewählt wird. Im Auslieferungszustand hat der Prozessor 1Mhz interne Taktfrequenz eingestellt.

Wenn man das Ergebnis einmal mit der Tabelle im Datenblatt vergleicht, werden auch die "verdrehten" Häkchen deutlich:

 

 

Sind die Häkchen richtig gesetzt, werden die neuen Einstellungen mit "write fuses" zum Prozessor geschrieben, was dann hoffentlich auch positiv bestätigt wird:

 

 

 

So... und nun kann endlich auch das Programm in den Chip geladen werden. Das Fuses-Fenster wird geschlossen, und dann mit dem Button "File" das HEX-File aus dem Programmverzeichnis auswählen:

 

 

Und wenn das HEX-File ausgewählt ist, können wir es in den Prozessor übertragen, was dann hoffentlich auch mit einer Erfolgsmeldung endet. Einfach mal unten das Meldungsfenster verfolgen:

 

 

 

Damit ist eigentlich alles passiert - der Prozessor nimmt seine Arbeit auf, und das Programm kann getestet werden.

 

Was noch wichtig ist: wer über die RS232 auf das Evaluations Board zugreift, wird feststellen, dass der Prozessor eben nicht startet. Aus irgendeinem Grunde hält dieser Programmer den Reset-Pin gedrückt.

Einfach das Kabel abziehen, dann klappts.

Der USB-Adapter hat diesen Effekt nicht und kann an der ISP-Schnittstelle verbunden bleiben.

 

Viele Grüße

 

Torsten