(→Quellcode) |
K (→Die Größe ermitteln) |
||
Zeile 156: | Zeile 156: | ||
0x42 0x0 0x2 68 44 blinky.o | 0x42 0x0 0x2 68 44 blinky.o | ||
0x70 0x0 0x2 114 72 timer1.o | 0x70 0x0 0x2 114 72 timer1.o | ||
− | Das | + | Das sind die Größen der einzelnen [[avr-gcc#Sections|Sections]]. |
Für das Flash relevant ist die Größe von | Für das Flash relevant ist die Größe von | ||
<tt>.text</tt> (Code) + <tt>.data</tt> (initialisierte Daten), | <tt>.text</tt> (Code) + <tt>.data</tt> (initialisierte Daten), |
Version vom 21. Februar 2006, 10:45 Uhr
Das erste C-Programm, das man zu sehen bekommt, ist für die meisten das "Hallo Welt". Bei "Hallo Welt" geht es weniger um die Funktionalität an sich, sondern darum zu lernen, wie man überhaupt ein Programm übersetzt und einen Compiler verwendet.
Was für den PC das "Hallo Welt", ist für einen kleinen Microcontroller der "Hallo Blinky", der einfach nur eine Leuchtdiode (LED) blinken lässt.
Im Vergleich zu "Hallo Welt" sieht der Blinky viel komplizierter aus, aber eigentlich ist er einfacher, dann es werden keine umfangreichen Funktionen oder Black-Boxen benutzt wie etwa printf(). Ausser dem eingegebenen Quellcode kommt also kein andere Code zur Ausführung!
Inhaltsverzeichnis
Beschreibung
Eine LED an Port B1 wird einmal pro Sekunde an bzw. ausgeschaltet. Die LED blinkt also mit einer Frequenz von 1/2 Hz.
Dazu wird Timer1 so initialisiert, daß er 1000 Interrupts pro Sekunde auslöst. In jedem 1000. Timer1-Interrupt wird dann die LED geschaltet.
Von der C-Quelle zum hex-File
Das Beispiel besteht ganz bewusst aus zwei getrennten Quelldateien (Modulen) um zu zeigen, wie man Code auf mehrere Dateien aufteilen kann um die Übersichtlichkeit bei grösseren Projekten zu wahren. Eine etwas einfachere Struktur hat die Datei im Abschnitt "Alles in einer Datei", das den Blinky in einer einzigen Datei implementiert.
Ausserdem wird das Übersetzen über Kommandozeilen-Eingaben erledigt und nicht über Werkzeuge wie make, das die Zusammenhänge eher verschleiert als erhellt, und dessen inkorrekte Anwendung eine häufige Fehlerquelle ist.
Nach Speichern der Quelldatein in ein eigenes Verzeichnis enthält dieses die Dateien
blinky.c timer1.c timer1.h
Compilieren
Zunächst werden die C-Dateien übersetzt. Der Übersetzungsvorgang wird gesteuert durch Kommandozeilen-Parameter (siehe avr-gcc). Die Option
- -c
- legt fest, daß nur compiliert wird (und nicht gelinkt),
- -o name
- gibt den Name der Ausgabedatei an. Ohne diese Option heisst die Ausgabedatei immer a.out
- -mmcu=atmega8
- legt den Controllertyp fest, in dem Beispiel den ATmega8
- -g
- erzeugt Debug-Infos und
- -Os
- optimiert auf Codegröße.
> avr-gcc blinky.c -c -o blinky.o -Os -g -mmcu=atmega8 > avr-gcc timer1.c -c -o timer1.o -Os -g -mmcu=atmega8
Danach sind zwei neue Dateien entstanden (*.o)
blinky.c blinky.o timer1.c timer1.h timer1.o
In der Quelle wird der Wert für das OCR1A-Register aus der Taktfrequenz des Controllers (F_CPU) und der Anzahl an Interrupts, die pro Sekunde ausgelöst werden sollen (INTERRUPTS_PER_SECOND), berechnet.
Standardmässig sind AVRs mit dem internen RC-Oszillator mit ca. 1 MHz getaktet. Daher wird F_CPU in timer1.c zu 1000000 definiert:
#ifndef F_CPU #define F_CPU 1000000 #endif /* F_CPU */
Dieser Wert hat rein informativen Charakter und bewirkt nicht, daß der Controller mit einer anderen Frequenz läuft! Das geht über einen anderen Quarz/Oszillator oder andere Fuse-Einstellungen.
Hat man den AVR mit einem anderen Takt laufen, dann gibt man diesen einfach in der Kommandozeile an, z.B. für 8 MHz:
> avr-gcc ... -DF_CPU=8000000
Analog kann man mit INTERRUPTS_PER_SECOND verfahren, das auf 1000 gesetzt ist, und auch mit der Option -D überschrieben werden kann.
Linken
Die beiden erzeugten Objekte werden nun zusammengebunden, um die Ausgabedatei (*.elf) zu erhalten:
> avr-gcc blinky.o timer1.o -o blinky.elf -mmcu=atmega8
erzeugt die ausführbare Datei (*.elf), die noch zusätzliche Informationen wie Debug-Infos etc. beinhaltet mit dem Namen blinky.elf:
blinky.c blinky.elf blinky.o timer1.c timer1.h timer1.o
Umwandeln nach hex
Code und Daten
Viele Progger wollen die zu ladende Datei im Intel-hex-Format (*.hex bzw. *.ihex). Dazu gibt man an
> avr-objcopy -j .text -j .data -O ihex blinky.elf blinky.hex
Damit enthält die hex-Datei die Sections .text (Programm) und .data (Daten). Das Verzeichnis beinhaltet jetzt
blinky.c blinky.elf blinky.hex blinky.o timer1.c timer1.h timer1.o
EEPROM
Ein hex-File, das den Inhalt des EEPROMs wiederspiegelt, erhält man mit
> avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex blinky.elf blinky_eeprom.hex
Für das Beispiel ist das EEPROM-File blinky_eeprom.hex leer, da wir keine Daten ins EEPROM gelegt haben.
Listfile erstellen
Falls man ein Listfile haben möchte, dann geht das mit
> avr-objdump -h -S -j .text -j .data blinky.elf > blinky.lst
Das Listfile ist eine Textdatei, die alle Assembler-Befehle auflistet, wie sie letztendlich auf den Controller geladen werden.
avr-objdump gibt seine Ausgabe auf das Terminal aus. Diese Ausgabe wird mit '>' in die Datei blinky.lst umgeleitet. Hier ein Ausschnitt aus dem Listfile:
0000005c <job_timer1>: uint16_t count; /* irq_count um 1 erhöhen und */ /* gegebenenfalls die LED blinken */ count = 1+irq_count; 5c: 20 91 60 00 lds r18, 0x0060 60: 30 91 61 00 lds r19, 0x0061 64: 2f 5f subi r18, 0xFF ; 255 66: 3f 4f sbci r19, 0xFF ; 255 if (count >= INTERRUPTS_PER_SECOND) 68: 83 e0 ldi r24, 0x03 ; 3 6a: 28 3e cpi r18, 0xE8 ; 232 6c: 38 07 cpc r19, r24 6e: 30 f0 brcs .+12 ; 0x7c { count = 0; 70: 20 e0 ldi r18, 0x00 ; 0 72: 30 e0 ldi r19, 0x00 ; 0 PORT_LED ^= (1 << PAD_LED); 74: 88 b3 in r24, 0x18 ; 24 76: 92 e0 ldi r25, 0x02 ; 2 78: 89 27 eor r24, r25 7a: 88 bb out 0x18, r24 ; 24 } irq_count = count; 7c: 30 93 61 00 sts 0x0061, r19 80: 20 93 60 00 sts 0x0060, r18 84: 08 95 ret
Links stehen die Adressen, dann die Maschinencodes der Befehle, danach die Maschinencodes in Assembler-Darstellung. Ganz rechts nach dem Kommentarzeichen ';' stehen die Dezimalcodes von Konstanten (z.B. 24 für die 0x18 an Adresse 74) oder die Zieladressen von Sprüngen, wie bei dem brcs-Befehl an Adresse 6e, der gegebenenfalls 12 Bytes überspringt und dann an Adresse 7c landet.
Mapfile erstellen
Ein Mapfile gibt Auskunft darüber, an welcher Adresse Code und Objekte landen. Erstellt wird das Mapfile während des Linkens, indem avr-gcc ein Option an den Linker weiterreicht, die diesem zum Erstellen eines solchen Files veranlasst:
> avr-gcc blinky.o timer1.o -o blinky.elf ... -Wl,-Map,blinky.map
Dadurch entsteht das Mapfile blinky.map.
Die Größe ermitteln
Die Größe der erhaltenen Objekte/Files können mit avr-size ausgegeben werden.
> avr-size -x blinky.o timer1.o
druckt aus:
text data bss dec hex filename 0x42 0x0 0x2 68 44 blinky.o 0x70 0x0 0x2 114 72 timer1.o
Das sind die Größen der einzelnen Sections. Für das Flash relevant ist die Größe von .text (Code) + .data (initialisierte Daten), für das SRAM relevent ist .data (initialisierte Daten) + .bss (null-initialisierte Daten).
Im Flash werden also 114+68+0+0=182 Bytes belegt, und im SRAM 0+0+2+2=4 Bytes.
Die Gesamtgrösse ergibt sich jedoch erst aus dem elf-File, denn auch die Vektortabelle und der Startup-Code belegen Platz:
> avr-size -x -A blinky.elf
druckt aus:
blinky.elf : section size addr .text 0x110 0x0 .data 0x0 0x800060 .bss 0x4 0x800060 .noinit 0x0 0x800064 .eeprom 0x0 0x810000 .stab 0x798 0x0 .stabstr 0x6b0 0x0 Total 0xf5c
Im Flash werden somit 0x110+0=272 Bytes belegt, also 90 Bytes mehr als die Objekte benötigen; davon entfallen z.B. schon 38 Bytes auf die Vektortabelle des ATmega8, die 2*19 Bytes groß ist.
Die Größen einzelner Funktionen lassen sich anzeigen mit
> avr-nm --size-sort -S blinky.elf
was nach Größe sortiert ausdruckt:
00800060 00000002 b irq_count 00800062 00000002 b timer1a_job 00000086 00000018 T main 0000009e 00000022 T timer1_init 0000005c 0000002a t job_timer1 000000c0 0000004e T SIG_OUTPUT_COMPARE_1A
Quellcode
Der Quellcode ist für die Version 3.x von avr-gcc. In der 4er-Version gab es tiefgreifende interne Änderungen im Compiler; er ist noch instabil und kann momentan noch nicht für den Produktiv-Einsatz empfohlen werden (Stand 02/2005).
blinky.c
#include <avr/io.h> #include <avr/interrupt.h> #include "timer1.h" /* PortB.1 blinkt jede Sekunde */ /* also mit einer Frequenz von 1/2 Hz */ #define DDR_LED DDRB #define PORT_LED PORTB #define PAD_LED 1 static void ioinit(); static void job_timer1(); /* Zählt in jedem aufgetretenem IRQ eins hoch */ static volatile uint16_t irq_count = 0; /* Diese Funktion ist ein 'Callback' */ /* Sie wird an timer1_init() übergeben */ /* und von dort aus aufgerufen, und zwar */ /* INTERRUPTS_PER_SECOND mal pro Sekunde. */ /* Sie wird also auf IRQ-Ebene ausgeführt */ void job_timer1() { uint16_t count; /* irq_count um 1 erhöhen und */ /* gegebenenfalls die LED blinken */ count = 1+irq_count; if (count >= INTERRUPTS_PER_SECOND) { count = 0; PORT_LED ^= (1 << PAD_LED); } irq_count = count; } void ioinit() { /* Port als Ausgang */ DDR_LED |= (1 << PAD_LED); /* Initialisiert Timer1, um jede Sekunde */ /* INTERRUPTS_PER_SECOND mal die Funktion job_timer1 */ /* aufzurufen */ timer1_init (job_timer1); } int main (void) { /* Peripherie initialisieren */ ioinit(); /* Interrupts aktivieren */ sei(); /* Nach main landen wir in exit(), */ /* das nur aus einer Endlosschleife besteht (avr-gcc) */ /* Der Interrupt lässt die LED weiterhin */ /* im Sekundentakt blinken */ return 0; }
timer1.h
#ifndef _TIMER1_H_ #define _TIMER1_H_ #include <inttypes.h> #ifndef INTERRUPTS_PER_SECOND #define INTERRUPTS_PER_SECOND 1000 #endif /* INTERRUPTS_PER_SECOND */ extern void timer1_init (void (*) (void)); #endif /* _TIMER1_H_ */
timer1.c
#include <avr/io.h> #include <avr/signal.h> #include "timer1.h" #ifndef F_CPU #define F_CPU 1000000 #endif /* F_CPU */ /* Test von F_CPU und INTERRUPTS_PER_SECOND */ /* auf Gültigkeitsbereich */ #if (F_CPU / INTERRUPTS_PER_SECOND -1 < 0) \ || (F_CPU / INTERRUPTS_PER_SECOND -1 >= 0x10000) #error Werte für F_CPU bzw. INTERRUPTS_PER_SECOND ungeeignet #error evtl. muss der Prescaler verwendet werden #endif /* Callback-Funktion */ static void (*timer1a_job) (void); void timer1_init (void (*job) (void)) { timer1a_job = job; #if defined (__AVR_AT90S2313__) /* AVR Classic: */ /* Timer1 läuft mit vollem Takt */ /* CTC: Clear Timer on CompareMatch */ /* Timer1 ist Zähler */ TCCR1A = 0; TCCR1B = (1 << CS10) | (1 << CTC1); #elif defined (__AVR_ARCH__) && ((__AVR_ARCH__==4) || (__AVR_ARCH__==5)) /* AVR Mega: */ /* Mode #4 für Timer1 (ATmega8 Manual S. 97) */ /* und voller MCU Takt (Prescale=1) */ TCCR1A = 0; TCCR1B = (1 << WGM12) | (1 << CS10); #else #error Dont know how to setup timer1 #endif /* OutputCompare1A Register setzen */ OCR1A = (uint16_t) ((uint32_t) F_CPU / INTERRUPTS_PER_SECOND -1); /* evtl. gesetztes OC1A-Flag zurücksetzen */ TIFR = (1 << OCF1A); /* OutputCompare1A Interrupt aktivieren */ TIMSK |= (1 << OCIE1A); } /* Die Interrupt Service Routine ruft lediglich */ /* timer1a_job auf (callback) */ SIGNAL(SIG_OUTPUT_COMPARE_1A) { timer1a_job(); }
Alles in einer Datei
In der folgenden Quelldatei sind alle Routinen in etwas vereinfachter Form zusammengefasst. Zum Übersetzen gibt man an (hier für ATmega32):
> avr-gcc blinky-all.c -o blinky-all.elf -mmcu=atmega32 -g -Os
oder, falls man die Ausgabe im Intel HEX-Format haben möchte:
> avr-gcc blinky-all.c -o blinky-all.hex -mmcu=atmega32 -g -Os -Wl,--oformat=ihex
Möchte man F_CPU oder INTERRUPTS_PER_SECOND ändern, dann muss das bei diesem Beispiel direkt in der Quelle angepasst werden. F_CPU hat wie immer nur rein informativen Charakter, um zu wissen, wie schnell der AVR läuft. Eingestellt wird die Taktfrequenz über die Fuse-Bits bzw. Wahl eines entsprechenden Quarzes/Oszillators/Resonators/RC-Glieds.
Quelle (blinky-all.c):
#include <avr/io.h> #include <avr/interrupt.h> #include <avr/signal.h> // PortB.1 blinkt jede Sekunde // also mit einer Frequenz von 1/2 Hz #define DDR_LED DDRB #define PORT_LED PORTB #define PAD_LED 1 // Werte zur Berechnung der Interrupt-Rate bei AVR-Fuses, // die auf 1MHz eingestellt sind (Werkseinstellung für internen RC-Oszillator) #define F_CPU 1000000 // 1000 Interrupts pro Sekunde #define INTERRUPTS_PER_SECOND 1000 // Prototypen der Funktionen void ioinit(); void timer1_init(); // Initialisierung der Hardware void ioinit() { // Port als Ausgang DDR_LED |= (1 << PAD_LED); // Initialisiert Timer1, um jede Sekunde 1000 IRQs auszulösen timer1_init(); } // Das Hauptprogramm (Einsprungpunkt) int main() { // Peripherie initialisieren ioinit(); // Interrupts aktivieren sei(); // Eine Endlosschleife. // Der Interrupt lässt die LED weiterhin blinken while (1) {} } // Wert für das OutputCompare-Register (OCR1A) #define OCR_VAL (F_CPU / INTERRUPTS_PER_SECOND -1) void timer1_init() { // ATmega: Mode #4 für Timer1 und voller MCU-Takt (Prescale=1) TCCR1A = 0; TCCR1B = (1 << WGM12) | (1 << CS10); // OutputCompare1A Register setzen OCR1A = (uint16_t) ((uint32_t) OCR_VAL); // OutputCompare1A Interrupt aktivieren TIMSK |= (1 << OCIE1A); } // Wird durch jeden IRQ eins hochgezählt static volatile uint16_t irq_count = 0; // Die Interrupt Service Routine (ISR) wird INTERRUPTS_PER_SECOND mal // pro Sekunde ausgeführt. irq_count zählt die Aufrufe und blinkt die LED // wenn 1 Sekunde vergangen ist. SIGNAL(SIG_OUTPUT_COMPARE_1A) { uint16_t count; // irq_count um 1 erhöhen und count = 1+irq_count; // alle 1000 IRQs die LED blinken if (count >= INTERRUPTS_PER_SECOND) { count = 0; PORT_LED ^= (1 << PAD_LED); } irq_count = count; }
Für klassische AVRs wie AT90S2313 muss die Initialisierung etwas abgeändert werden, weil sich Bit-Bezeichner unterscheiden:
// AVR Classic: // Timer1 läuft mit vollem Takt // CTC: Clear Timer on CompareMatch // Timer1 ist Zähler TCCR1A = 0; TCCR1B = (1 << CS10) | (1 << CTC1);
Spin-off
Eine LED blinken zu lassen könnte auch wesentlich einfacher implementert werden, also z.B. ohne Funktionsaufrufe oder Interrupt-Programmierung.
Neben der eigentlichen Aufgabe "LED blinken lassen" kann man an dem Code aber noch andere Dinge lernen:
- Programmierung eines Interrupts
- Initialisierung von Timer1 als Zähler mit "Clear Timer on Compare Match"
- Bedingte Codeübersetzung/Controllerunterscheidung mit #ifdef (in timer1_init)
- Abchecken der Güligkeit von Defines durch den Präprozessor
- Übergabe eines Funktionszeigers, um später eine Funktion indirekt aufzurufen
- Zusammenlinken mehrerer Module