RN-Wissen.de - Benutzerbeiträge [de]

Diskussion:Fallstricke bei der C-Programmierung

2007-06-12T15:08:25Z

Plaicy: C89 immer noch nicht überall unterstüzt?

==="TRUE ist nicht 1"===
In dem Abschnitt steht, dass man lieber folgendes schreiben soll.
#define FALSE (0!=0)
#define TRUE (0==0)

Was soll das bringen? Danach ist FALSE 0 und und TRUE als 1 definiert, da laut ANSI-C (ANSI99 6.5.9) ''Each of the operators ["==" und "!="] yields 1 if the specified relation is true and 0 if it is false.'''. Siehe auch
http://www.dclc-faq.de/kap8.htm#8.2 . Meine Meinung verwirrt die Aussage ''TRUE ist nicht 1'' nur.--[[Benutzer:Plaicy|Plaicy]] 22:43, 3. Jun 2007 (CEST)

: Es gibt mehr als einen C-Standard. Manchmal ist es günstiger, TRUE als -1 zu definieren. Die Makros oben sind jedoch unabhängig davon, welcher Wert ein Compiler implementiert --[[Benutzer:SprinterSB|SprinterSB]] 23:36, 5. Jun 2007 (CEST)
::Nur aus Interesse: Welcher Compiler unterstüzt nicht C89, wo dies auch schon galt? Außerdem schließe ich mich der Meinung von http://www.dclc-faq.de/kap8.htm#8.2 an, dass Vergleiche auf auf ''TRUE'' grundsätzlich ungünstig sind. Wenn man unbedingt auf eine Konstante abfragen will, was eigentlich auch mit dem "!"-Operator übersichtlicher ist, kann man noch ''!= FALSE'' verwenden.--[[Benutzer:Plaicy|Plaicy]] 17:08, 12. Jun 2007 (CEST)

Fallstricke bei der C-Programmierung

2007-06-12T15:01:45Z

Plaicy: /* Zuweisung statt Vergleich */ Beschreibung mehr am Beispiel orientiert

=Tippfehler=

Tippfehler können immer passieren. Besonders fies ist es, wenn der Tippfehler nicht zu einer Warnung oder zu einer Fehlermeldung führt, weil der entstandene Code korrekter C-Code ist.

==Ein <tt>;</tt> zu viel==
Ein reflexartig eingetippter oder nach Änderungen stehen gebliebener <tt>;</tt> hat schon so manches
Programm ausgeknockt:
if (a == 0);
{
/* mach was */
}
Wenn <tt>a == 0</tt> ist, dann wird <tt>;</tt> ausgeführt (also im Endeffekt garnichts). Danach kommt der Block, der im <tt>if</tt> stehen sollte. Der wird immer ausgeführt, denn er gehört nicht mehr zum <tt>if</tt>.

==Zuweisung statt Vergleich==
if (a = 0)
{
/* mach was */
}
Bei einer if-Bedingung wird ob der Ausdruck innerhalb der Klammern ungleich <tt>0</tt> (<tt>true</true>) ist, dann wird die darauf folgende Anweisung bzw. Block ausgeführt. In diesem Codebeispiel ist der Ausdruck eine Zuweisung. Eine Zuweisung hat den Wert der zugewiesen wird, also hier <tt>0</tt>. Damit wird bei diesem Code der Block zu der Bedingung nie ausgeführt.

Abhilfe schafft, indem man sich angewöhnt zu schreiben
if (0 == a)
Wenn man dann eine Zuweisung eintippt, gibt's einen Compiler-Fehler.

==Signal/Interrupt-Name vertippt (avr-gcc)==

SIGNAL (SIG_OVEFRLOW0)
{
/* mach was */
}
Nicht alle Compiler-Versionen meckern da. Der [[ISR]]-Code wird nicht in die Interrupt-Tabelle eingetragen. Kommt es zum [[Interrupt]], dann landet man in RESET.

=Mangelnde C-Kenntnis=

==Warnung ignoriert==

::"''Wieso soll das Probleme machen? Das ist doch nur eine Warnung!''"

Warnungen zur Compile-Zeit werden gerne zu Fehlern zur Laufzeit. Letztere sind deutlich schwerer zu finden, als angewarnten Code zu korrigieren.
<pre>
void foo (long*);

void bar (int *p)
{
foo (p+1);
// Was soll das sein?!
// ((long*) p) + 1 oder
// (long*) (p + 1)
}
</pre>

<pre>
> gcc -c -o prog.o prog.c

prog.c: In function `bar':
prog.c:5: warning: passing arg 1 of `foo' from incompatible pointer type
</pre>

==Array-Index==

Informatiker am Bahnhof:
:''"0, 1, 2, ... Wo ist mein dritter Koffer?!"''
Gleiches gilt für Arrays:
#define NUM 10;
int a[NUM]; // für die N Werte a[0] ... a[N-1]
Ein Zugriff auf <tt>a[N]</tt> greift irgendwo hin.
Wahlweise liest man Schrott oder überschreibt andere Daten, die in der Nähe liegen, und
plötzlich seltsame Werte enthalten.

==Bitweise vs. Logische Operatoren==

Die Operatoren AND, OR und NOT gibt es in C in zwei Ausprägungen
;bitweise: Die Operatoren <tt>^</tt>, <tt>|</tt>, <tt>&</tt>, <tt>~</tt>, <tt>|=</tt>, <tt>^=</tt>, <tt>&=</tt>, <tt>|=</tt> operieren bitweise. Der entsprechende Operator wird also auf alle Bits des Wertes parallel angewandt und das Ergebnis für ein Bit ist unabhängig vom Inhalt der anderen Bits.
;logisch: Die Operatoren <tt>||</tt>, <tt>&&</tt>, <tt>!</tt>, <tt>&&=</tt>, <tt>||=</tt> operieren auf dem ganzen (int) Wert und berücksichtigen nur, ob der Wert 0 (false) oder ungleich 0 (true) ist.
Dementsprechend liefert <tt>&&</tt> i.d.R. ein anderes Ergebnis als <tt>&</tt>:
if (a && b) // erfüllt, wenn a!=0 und b!=0
if (a & b) // erfüllt, wenn in a und b an der gleichen Stelle ein Bit gesetzt ist
Ein Verwechseln bzw. unkorrektes Einsetzen der Operatoren gibt also ein falsches Programm.

==TRUE ist nicht 1==

Da C die Begriffe TRUE und FALSE eigentlich nicht kennt, wurde schon öfter beobachtet, daß folgendes definiert wurde:
#define TRUE 1
#define FALSE 0
solange man damit nur Schalter setzt und abfragt, ist dagegen nichts zu sagen.
a = TRUE; b = FALSE;
if ( (a == TRUE) && (b == FALSE)) {.."this is true"..}
wenn man aber dann schreibt
if ( (a & b) == TRUE) {.."this is true"..}
kann man einen herbe Enttäuschung erleben. Man müßte für ein richtiges Ergebnis schreiben
if ( (a & b) != FALSE) {.."this is true"..}
Damit ist aber eine gute Lesbarkeit endgültig dahin.

Besser sind Definition wie
#define FALSE (0!=0)
#define TRUE (0==0)
denn damit gilt einerseits, daß für alle boolschen Werte einschliesslich dieser Konstanten der
Zusammenhang <tt>x = !!x</tt> besteht.
Mit der allerersten Definition hat man das unerwünschte Ergebnis <tt>TRUE != !FALSE</tt>.
Andererseits kann man direkt gegen diese Konstanten vergleichen:
a = (x < y);
...
if (a == TRUE) // oder die 'klassische' Variante: if (a)

Siehe auch: http://www.dclc-faq.de/kap8.htm#8.2

==Ein , anstatt . in Konstante==

In C sowie im angloamerikanischen Sprachraum werden Dezimalbrüche mit einem <tt>.</tt> (Punkt) geschrieben und nicht wie im Deutschen mit einem <tt>,</tt> (Komma):
float pi;
pi = 3,14; // *AUTSCH* soll wohl heissen 3.14
Die zweite Zeile besteht aus zwei durch ein Komma getrennten Anweisungen, so daß das ganze
etwa gleichbedeutend ist mit
float pi;
pi = 3;
14;
Jedenfalls ist es korrekter C-Code!
Die <tt>14;</tt> ist ein Ausdruck, der nicht weiter gebraucht wird und daher wegfällt, da
er im Gegensatz zu einer void-Funktion keine Wirkung hat.
Man rechnet also mit dem Wert 3 für <math>\pi</math>.

Das falsche Komma hat auch schon so manchen ebay-Freak aufs Kreuz gelegt...

==Führende 0 in Konstanten==

In C kennzeichnet eine führende 0 bei einer Zahlenkonstante,
daß die Zahl oktal dargestellt ist. Somit ist 010 nicht gleich 10.
if (a == 030) // ist a gleich 24?

=Nicht-atomarer Code=
Verwendet man in einem Programm [[IRQ|IRQs]] ([[Interrupt|Interrupts]]) und ändert in der [[ISR]] (Service Routine) ein Datum (Variable, SFR, ...), dann wird diese Änderung möglicherweise überschrieben, wenn die IRQ zu einem ungünstigen Zeitpunkt auftritt.

Ein ausführlicheres Beispiel, das zeigt, was passieren kann, findet sich im Artikel [[avr-gcc]] im Abschnitt "[[avr-gcc#Zugriff auf einzelne Bits|Zugriff auf einzelne Bits]]". Ein weiteres Beispiel ist das Lesen, Schreiben oder Testen einer mehrbytigen Variable:
<pre>
int volatile i;
...
if (0 == i)
</pre>
Weil <tt>i</tt> länger als 1 Byte ist, kann es je nach Architektur nicht in einem Befehl gelesen werden;
daher kann während des Lesens eine IRQ auftreten, in deren ISR der Wert von <tt>i</tt> möglicherweise
verändert wird. Der obige Code könnte etwa so assembliert werden (hier mit [[avr-gcc]]):
<pre>
; i wird vom SRAM in das Registerpaar r24:r25 geladen
; low-Teil laden
lds r24,i
; high-Teil laden
; wenn hier eine IRQ zuschlägt, in der i verändert wird, ist der Registerinhalt korrupt
lds r25,(i)+1
or r24,r25
brne ...
</pre>
Natürlich können auch komplexere Datenstrukturen von diesem Phänomen betroffen sein.
Besonders unangenehm an dieser Klasse von Fehlern ist, daß sie nur sporadisch auftauchen
und man sie daher selbst mit einem guten Debugger sehr schlecht orten kann, da die zugehörige
Codestelle fast immer korrekt abgearbeitet wird.

Eine Möglichkeit dem zu begegnen ist, den ganzen betroffenen Block ununterbrechbar (atomar) zu machen.
Wieder ein Beispiel für avr-gcc:
#include <avr/io.h>
#include <avr/interrupt.h>
...
{{ccomment|ein lokale(!) Variable, die das Status-Register und }}
{{ccomment|insbesondere das im folgenden geänderte I-Flag merkt }}
{{ccomment|Falls man an der Codestelle immer weiß, daß IRQs }}
{{ccomment|aktiviert sind, kann man die zu atomisierende Sequenz }}
{{ccomment|auch in cli()...sei() einschachteln }}
{{ccomment|Falls IRQs global deaktiviert sind brauch man natürlich }}
{{ccomment|keine besonderen Vorkehrungen zu treffen, da dann aller Code }}
{{ccomment|atomar ist. }}
unsigned char sreg = SREG;

{{ccomment|Interrupts global deaktivieren (I-Flag = 0) }}
cli();

if (0 == i)
{
i = 1;
{{ccomment|IRQs sobald als möglich wieder zulassen }}
{{ccomment|(I-Flag wieder herstellen) }}
SREG = sreg;
}
else
{
{{ccomment|IRQs so bald als möglich wieder zulassen }}
{{ccomment|(I-Flag wieder herstellen) }}
SREG = sreg;
return;
}
...
Oder je nach Programmstruktur sichert man den Wert, z.B. in eine lokale Variable oder deaktiviert nur selektiv die kritischen Interrupts, also solche, die Einfluss auf die kritischen Daten nehmen.

= Weitere Fallstricke =
* [[Warteschleife]]

= Siehe auch =
* [[C-Tutorial]]
* [[avr-gcc]]

[[Kategorie:Grundlagen]]
[[Kategorie:Quellcode C|!]]
[[Kategorie:Software]]

Kategorie Diskussion:Projekte

2007-06-04T13:05:17Z

Plaicy: typos

wie krieg ich meinen Artikel "Lötstation" hier rein?

----
Es gibt eine eigene Kategorie, die du ganz ans Ende deines Artikels schreibst:
<pre>
[[Kategorie:Projekte]]
</pre>

Hilfe findest du auch im für Autoren lesenswerten Artikel [[RN-Wissen:Editierhilfe]] im vorletzten Abschnitt.

--[[Benutzer:SprinterSB|SprinterSB]] 16:33, 2. Mär 2007 (CET)

:''SO macht die Veröfftlichung von Schaltungen mehr Nutzen, denn alles ist leicht kombinierbar erweiterbar.''
Da sind zwei typos drin: "SO" und "Veröfftlichung"--[[Benutzer:Plaicy|Plaicy]] 15:05, 4. Jun 2007 (CEST)

Bootloader

2007-06-04T12:25:23Z

Plaicy: typo

Ein Boot-Loader ist eine spezielle Software, die gewöhnlich im Rom bzw. Flash sitzt oder vom Betriebsystem geladen und anschließend ausgeführt wird. Der Boot-Loader lädt dann weitere Teile des Betriebssystems (gewöhnlich einen Kernel) oder ein Hauptprogramm.
{|
|valign="top"|Die [[Atmel]] Controller ([[Avr|AVR]] [[ATMega8|Mega8]], [[Atmel Controller Mega16 und Mega32|Mega32]] usw.) besitzen einen reservierten Speicherbereich in welchen ein eigener Bootloader geladen werden kann. Dieser Bootloader kann automatisch bei einem RESET des Controllers ausgeführt werden, dies kann über die [[Fusebits]] eingestellt werden.
Mit den zwei Fusebits ''BOOTSZ'' (für Bootsize) kann die Grösse des Bootsektors eingestellt werden, gemessen wird immer vom oberen Speicherende nach unten. Je nach Grösse ändert sich auch der Startpunkt nach einem RESET falls das Fusebit ''BOOTRST'' ausgewählt wurde.
Um den Bootsektor sowie auch den Programmspeicher vor ungewolltem überschreiben zu schützen, sind vier ''Boot Loader Lock Bits'' (BLB) vorgesehen, diese können die jeweiligen Bereiche mit einem Schreib-/Leseschutz versehen. Diese Lock Bits verhindern aber nicht das auslesen oder neu beschreiben über [[ISP]].

Die LockBits können entweder über ISP oder aber auch per Software direkt vom Programm aus gesetzt werden, zurücksetzen kann man sie aber nur durch einen sogenannten ''Chip Erase'', bei dem auch der ganze Speicher des AVR gelöscht wird.
||[[Bild:FlashBootsektor.png|thumb|Programmspeicher im AVR]]
|}

Oft wird dies genutzt, um einen Controller auch per [[RS232]], Infrarot oder Funk programmieren zu können.

Für das AVR Board [[RN-Control]] findet man im Roboternetz-Downloadbereich einen geeigneten Bootloader.

http://www.microsyl.com/megaload/megalo1.jpg

Leider funktionierte oben genannter Bootloader im Test nicht mit den üblichen Funkmodulen.
Es gibt nun aber einen neuen Bootloader der offenbar recht gut auch die Programmierung per Funk erlaubt, siehe [[#Weblinks|Weblinks]]

==Weblinks==
* [http://www.microsyl.com AVR Bootloader]
* [http://www.roboternetz.de/phpBB2/dload.php?action=file&file_id=269 Funktioniert auch über Funk]

[[Kategorie:Microcontroller]]
[[Kategorie:Software]]

Diskussion:Avr-gcc und avrdude installieren

2007-06-03T23:39:21Z

Plaicy: weitere Korrektur

super Tutorial!
ein paar kleinigkeiten im Makefile warn falsch, habs ausgebessert.
{{unsigned|Superdude|23:04, 3. Jun 2007 (CEST)}}
:Du meinst sicher bei der Abhängigkeit ''elf'' statt ''o'' bei dem ''hex''. Andernfalls würden keine Module unterstützt werden und das ''elf''-Target wäre überflüssig. Außerdem wüsste ich nicht, ob sichergestellt wird, dass der Linker aufgerufen wird, wenn man direkt aus einer ''o''-Datei eine ''hex''-Datei erstellt.---[[Benutzer:Plaicy|Plaicy]] 01:39, 4. Jun 2007 (CEST)

Vorlage:Unsigned

2007-06-03T23:34:36Z

Plaicy: erstellt

<includeonly><small>(''Der vorstehende, nicht [[Hilfe:Signatur|signierte]] Beitrag stammt von'' [[Benutzer:{{{1}}}|{{{1}}}]] ([[Benutzer Diskussion:{{{1}}}|Diskussion]] • [[Spezial:Beiträge/{{{1}}}|Beiträge]]) {{{2|}}}) {{{3|}}}</small></includeonly><noinclude>

Siehe http://de.wikipedia.org/wiki/Vorlage_Diskussion:Unsigned#Vorlagendokumentation

</noinclude>

Avr-gcc und avrdude installieren

2007-06-03T23:28:35Z

Plaicy: /* Beispiel-Projekt */ typo und $^ nach $< geändert: falls man mal mehr Abhängigkeiten einfach hinzufügt, klappt es sonst nicht mehr

Es gibt bereits eine sehr gute Anleitung für das Installieren vom [[avr-gcc]], aber sie ist etwas veraltet. Für den original Text siehe [http://www.tldp.org/linuxfocus/English/November2004/article352.shtml].
Ich werde im folgenden nur das nötigste von diesem Artikel kopieren.

Es gibt drei Teile. Im ersten Teil wird die Installation erklärt, im zweiten wird gezeigt, wie man damit denn nun seine Programme für den [[Microcontroller|MCU]] erstellt. Im dritten Teil stehen noch ein paar typische Fehlermeldungen und die Lösungen.

=Installation=

Also los. Wir brauchen folgende Software:

* [ftp://ftp.gnu.org/gnu/binutils/ binutils-2.17.tar.bz2]
* [ftp://ftp.gnu.org/gnu/gcc/gcc-4.1.2/ gcc-core-4.1.2.tar.bz2]
* [http://savannah.nongnu.org/download/avr-libc/ avr-libc-1.4.5.tar.bz2] Dort findet ihr auch das Manual der avr-libc
* [http://savannah.nongnu.org/download/avrdude/ avrdude-5.3.1.tar.gz]

Als erstes erstellen wir das Verzeichnis, in das der avr-gcc installiert wird:

* Als root:
mkdir /usr/local/avr

Und das Verzeichnis in dem die Programme liegen werden:

* Als root:
mkdir /usr/local/avr/bin

Dieses Verzeichnis wird auch gleich in die <tt>PATH</tt>-Variable geschrieben:
export PATH=$PATH:/usr/local/avr/bin

Achtung, dieser Befehl ist nur in dieser eine Konsole in der ihr seid gültig und auch nur solange wie diese offen ist. Um die Änderung systemweit wirksam zu machen, müsst ihr in die Datei <tt>/etc/profile</tt> den <tt>PATH</tt> nachtragen. Bei mir sieht das z.B. so aus:
<pre>
# Set the default system $PATH:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games[b]:/usr/local/avr/bin[/b]"
</pre>

==[[binutils]]==

Mit den binutils bekommt ihr Programme wie z.b. <tt>avr-as</tt> (Assembler), <tt>avr-ld</tt> (Linker), <tt>avr-objcopy</tt> (Um die Intel-Hex-Files zu erstellen).

Und so wird's gemacht (Das entpacken kann eine Weile dauern):
<pre>
tar jxf binutils-2.17.tar.bz2
cd binutils-2.17/
mkdir obj-avr
cd obj-avr
../configure --target=avr --prefix=/usr/local/avr --disable-nls
make
</pre>
* Als root:
make install

==[[avr-gcc]]==

avr-gcc ist unser eigentlicher Compiler. Er installiert sich wie folgt:
<pre>
tar jxf gcc-core-4.1.2.tar.bz2
cd gcc-4.1.2

mkdir obj-avr
cd obj-avr
../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-libssp

make
</pre>

Hinweis: Falls ihr jetzt beim Installieren Fehler bekommt die sich z.B so äussern:
make[2]: avr-ranlib: Command not found
Dann liegt <tt>/usr/local/avr/bin</tt> wider erwarten nicht in <tt>PATH</tt>. Führt diesen Befehl als root nochmal aus, dann sollte es gehen:
export PATH=$PATH:/usr/local/avr/bin

* Als root:
make install

==avr C-library ([[avr-libc]])==
<pre>
tar jxf avr-libc-1.4.5.tar.bz2
cd avr-libc-1.4.5

./configure --prefix=/usr/local/avr --build=`./config.guess` --host=avr

make
</pre>
* Als root:
make install

==[[avrdude]]==

<pre>
tar xzf avrdude-5.3.1.tar.gz
cd avrdude-5.3.1
./configure --prefix=/usr/local/avr
make
</pre>
* Als root:
make install

Wer den avr910 Programmer benutzt, muss avrdude erst fit für einige neuere Controller machen.
([[ATtiny2313]], [[ATmega162]], ...). Dazu müsst ihr die Configdatei von avrdude anpassen. Ihr findet sie unter <tt>/usr/local/avr/etc/avrdude.conf</tt>

Folgende Zeilen müssen ergänzt werden:
<pre>
#------------------------------------------------------------
# ATtiny2313
#------------------------------------------------------------

part
id = "t2313";
desc = "ATtiny2313";
stk500_devcode = 0x23;
## Try the STK500 devcode:
[b]avr910_devcode = 0x23;[/b]
.....

#------------------------------------------------------------
# ATmega8535
#------------------------------------------------------------

part
id = "m8535";
desc = "ATMEGA8535";
stk500_devcode = 0x64;
[b] avr910_devcode = 0x69;[/b]
</pre>
Analog verfahren für [[ATmega64]], [[ATmega162]] und [[ATmega169]]. Die devicecodes hiefür sind:
<pre>
m64: avr910_devcode = 0x45;
m162: avr910_devcode = 0x62;
m169: avr910_devcode = 0x78;
</pre>

Wer sich einen eigenen avr910 Programmer bauen will, dem sei diese Seite ans Herz gelegt:
[http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html].
Ich habe die Version genommen und um ein Buffer erweitert. Die Bauanleitung dafür gibt es bald auf [http://www.amee-bot.de unserer Roboterseite].

Somit hätten wir nun alles was wir brauchen installiert.

=Beispiel-Projekt=

Hier erstmal ein winziges Beispielprogramm für den [[ATtiny2313]].
<pre>
/*
* blink.c
* ATtiny2313 mit 1 MHz
* PORTB wird ueber ein Timer alle 0.263s ein- und ausgeschaltet. Das entspricht 3.81Hz
*/

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/signal.h>

SIGNAL (SIG_TIMER0_OVF)
{
PORTB =~ PORTB; // PORTB inventieren
}

int main()
{
DDRB = 0xFF; // PORTB als Ausgang schalten
PORTB = 0x00; // Alle Ausgaenge auf 0 schalten

TCCR0B |= (1 << CS02) | (1 << CS00); //Prescaler auf 1024 stellen
TIMSK |= (1 << TOIE0); // Timer 0 Overflow Interrupt enable

sei(); // Interrupts einschalten

for(;;); //ever
}
</pre>
Den Quelltext nehmt ihr und speichert ihn in die Datei <tt>blink.c</tt>.

Jetzt kommt das [[make|Makefile]]. Ich habe schonmal ein einfaches vorbereitet:
<pre>
TARGET = blink
MCU = attiny2313
CC = avr-gcc
OBJCOPY=avr-objcopy
CFLAGS =-g -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues -save-temps -fno-common

all: $(TARGET).hex

$(TARGET).hex : $(TARGET).elf
$(OBJCOPY) -j .data -j .text -O ihex $< $@

$(TARGET).elf: $(TARGET).o
$(CC) $(CFLAGS) -o $@ -Wl,-Map,$(TARGET).map $<

$(TARGET).o : $(TARGET).c
$(CC) $(CFLAGS) -c $<

load: $(TARGET).hex
avrdude -p t2313 -c avr910 -U flash:w:$(TARGET).hex -v

clean:
rm -f *.o *.map *.elf *.hex *.s *.i
</pre>
Das speichert ihr in der Datei <tt>Makefile</tt> im selben Ordner, in der auch die Datei <tt>blink.c liegt</tt>. '''Unbedingt darauf achten, daß die Einrückungen durch TABs erfolgen und nicht durch Leerzeichen!'''

Dann in der Konsole "<tt>[[make]]</tt>" tippen und es sollte compiliert werden. Mit "<tt>make load</tt>" wird das Hexfile dann in den MCU übertragen.

'''Erklärung:'''

;<tt>MCU=attiny2313</tt>: <tt>MCU</tt> ist eine Variable mit dem Inhalt <tt>attiny2313</tt>. Überall, wo jetzte <tt>$(MCU)</tt> steht, wird der Variabelninhalt benutzt. Genauso funktioniert das auch mit <tt>TARGET</tt>, <tt>CC</tt>, <tt>OBJCOPY</tt> und <tt>CFLAGS</tt>.

Nachdem ihr <tt>make</tt> erfolgreich ausgeführt habt, liegen in dem Ordner die Hexfile und eine Datei mit der Endung<tt> .s</tt>. Darin sind die Assemblerbefehle und -direktiven, die der Compiler aus dem C-Code gemacht hat. Wer so etwas nicht braucht, der kann den Parameter <tt>-save-temps</tt> in der Variable <tt>CFLAGS</tt> getrost entfernen.

Wenn ihr "<tt>make load</tt>" ausfürt, wird avrdude gestarte.
;<tt>-p</tt>: gibt an, um welchen MCU es sich handelt
;<tt>-c</tt>: gibt an, um welchen Programmer es sich handelt. Hier könnte z.B <tt>stk500</tt> stehen.
;<tt><nowiki>-U flash:w:$(TARGET).hex</nowiki></tt>: bedeutet einfach, dass das Programm in den Flash geschrieben werden soll. <tt>w</tt> steht für Schreiben, <tt>r</tt> für Lesen und <tt>v</tt> für verify. Dann kommt die Variable <tt>$(TARGET)</tt>, die besagt, welche Datei genau übertragen werden soll.
;<tt>-v</tt>: bedeutet ''"Verbose Output"'' und gibt euch mehr Informationen auf der Konsole aus.

Mit <tt>make clean</tt> werden alle Object-Dateien etc. gelöscht.

=Fehlermeldungen=

sollten eigentlich keine vorkommen. Wenn doch, vergewissert euch, dass ihr euch genau an die
Anleitung gehalten und nichts falsch abgeschrieben habt!

Hier ein paar typische Fehlermeldungen und ihr Lösungen:

;<tt>Permission denied</tt>: Ihr habt nicht die Rechte, um diesen Befehl auszuführen. Höchswahrscheinlich müsst ihr den Befehl als root ausführen.

;<tt><nowiki>make[2]: avr-ranlib: Command not found</nowiki></tt>:<tt>/usr/local/avr/bin</tt> liegt nicht in <tt>$PATH</tt>. Folgendes Command ausführen:
:<pre>export PATH=$PATH:/usr/local/avr/bin</pre>

;<tt>programmer is not responding</tt>: Es kann keine Verbindung zum Programmer aufgenommen werden: Defektes Kabel, Programmer an der falschen Schnittstelle angeschlossen (default: <tt>/dev/ttyS0</tt>), kein Strom am Programmer etc.

;<tt><nowiki>can't open device "/dev/ttyS0": Permission denied</nowiki></tt>: Als normaler User darf man auf die serielle Schnittstelle nicht lesen oder schreiben. Folgenden Befehl als root ausführen:
:<pre>chmod 666 /dev/ttyS0</pre>
:{|
Zweite und bessere Möglichkeit, die Rechte zu ändern ist es, den Benutzer in die tty-Gruppe auzunehmen.
Hier ein Beispiel für Gentoo.
Die Gruppe kann bei anderen Distributionen auch anders heißen!

Als root in die Konsole schreiben:
<pre>
> ls -all /dev/ttyS0
crw-rw---- 1 root tty 4, 64 25. Jun 02:12 /dev/ttyS0
>
</pre>
Hier kann man schön erkennen, daß die serielle Schnittstelle dem Benutzer root gehört und die Gruppe <tt>tty</tt> darauf zugreifen darf. Mit einem einfachen
> usermod -a -G tty sebastian
wird der User <tt>sebastian</tt> in die tty-Gruppe aufgenommen.

Noch ein Test, ob alles geklappt hat:
<pre>> groups sebastian
tty wheel audio cdrom dialout video games usb users portage scanner
</pre>
Danach muss sich Benutzer <tt>sebastian</tt> neu einlogen und wir sind fertig.

Der Vorteil hierbei ist, daß man Rechte für alle Geräte der Gruppe <tt>tty</tt> erlangt, also alle seriellen Schnittstellen sowie [[USB]] ↔ [[RS232]]-Adapter, und man braucht an den eigentlichen Rechten nichts zu verändern.
|}

=Web-Links=
*[http://www.nongnu.org/avr-libc/user-manual/install_tools.html ''"Installing the GNU Tool Chain"''] Hilfe zum Build und Installation von GCC, binutils, etc unter Linux
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml www.linuxfocus.org (Artikel)] - Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux
* [http://users.rcn.com/rneswold/avr/ Rich Neswold: ''A GNU Development Environment for the AVR Microcontroller'']
* [http://www.mikrocontroller.net/topic/24166 www.mikrocontroller.net (Foren-Beitrag)] - Installation von GCC und Toolchain unter Mac OS X

=Siehe auch=
* [[avr-gcc]]
* [[WinAVR]]

=Quelle=
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=125603#125603 www.roboternetz.de (Foren-Beitrag)] ''avrgcc + avrdude installieren''

=Autoren=
*[[Benutzer:Kater|Kater]] (Manuscript)
*[[Benutzer:SprinterSB|SprinterSB]] (Transcript und Typo)

[[Kategorie:Grundlagen]]
[[Kategorie:Microcontroller]]
[[Kategorie:Quellcode C]]

Benutzer:Plaicy

2007-06-03T21:28:17Z

Plaicy: erstellt

Siehe [http://de.wikipedia.org/wiki/Benutzer:Plaicy Meine Seite bei der Wikipedia]

Hallo Welt für AVR (LED blinken)

2007-06-03T21:23:03Z

Plaicy: /* Von der C-Quelle zum hex-File */ typo

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 [[Diode|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 <tt>printf()</tt>.
Ausser dem eingegebenen Quellcode kommt also kein anderer Code zur Ausführung!

{{FarbigerRahmen|
Bitte beachte auch die Hinweise zu [[avr-gcc#Inkompatibilität|Inkompatibilitäten von avr-gcc]]!
}}

=Beschreibung=

Eine [[LED]] an Port B1 wird einmal pro Sekunde an bzw. ausgeschaltet. Die LED blinkt also mit einer Frequenz von 1/2 Hz.

Im Programm wird der Wert für das OCR1A-Register aus der Taktfrequenz des
Controllers (<tt>F_CPU</tt>) und der Anzahl an Interrupts, die pro Sekunde
ausgelöst werden sollen (<tt>IRQS_PER_SECOND</tt>), berechnet.

Standardmässig sind [[AVR|AVRs]] mit dem internen RC-Oszillator mit ca. 1 MHz getaktet.
Daher wird <tt>F_CPU</tt> in <tt>blinky.c</tt> zu 1000000 definiert:
#define F_CPU 1000000
{{FarbigerRahmen|
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.
}}

Das Programm ist ausgelegt für eine Taktrate von 1 MHz. Wenn dein [[Controller]] mit einem anderen Takt läuft, dann hast du zwei Möglichkeiten:
* Du lässt das Programm so, wie es ist. Dann blinkt die LED entsprechend schneller bzw. langsamer. Hast du deinen AVR zB mit 16 MHz getaktet, dann blinkt die LED mit 8 Hz.
* Du passt die Taktfrequenz in der Quelle oder per Kommandozeile an. Für 8 MHz:
:<pre> > avr-gcc ... -DF_CPU=8000000</pre>

=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).
#include <avr/io.h>
#include <avr/interrupt.h>

{{ccomment|Für alte avr-gcc Versionen}}
#ifndef SIGNAL
#include <avr/signal.h>
#endif {{ccomment|SIGNAL}}

{{ccomment|Geblinkt wird PortB.1 (push-pull)}}
{{ccomment|Eine LED in Reihe mit einem Vorwiderstand zwischen}}
{{ccomment|PortB.1 und GND anschliessen.}}
#define PAD_LED 1
#define PORT_LED PORTB
#define DDR_LED DDRB

{{ccomment|Der MCU-Takt. Wird gebraucht, um Timer1 mit den richtigen}}
{{ccomment|Werten zu initialisieren. Voreinstellung ist 1MHz.}}
{{ccomment|(Werkseinstellung für AVRs mit internem Oszillator).}}
{{ccomment|Das Define wird nur gemacht, wenn F_CPU noch nicht definiert wurde.}}
{{ccomment|F_CPU kann man so auch per Kommandozeile definieren, z.B. für 8MHz:}}
{{ccomment|avr-gcc ... -DF_CPU=8000000}}
{{ccomment|  }}
{{ccomment|! Der Wert von F_CPU hat rein informativen Character für}}
{{ccomment|! die korrekte Codeerzeugung im Programm!}}
{{ccomment|! Um die Taktrate zu ändern müssen die Fuses des Controllers}}
{{ccomment|! und/oder Quarz/Resonator/RC-Glied/Oszillator}}
{{ccomment|! angepasst werden!}}
#ifndef F_CPU
#define F_CPU 1000000
#endif

{{ccomment|So viele IRQs werden jede Sekunde ausgelöst.}}
{{ccomment|Für optimale Genauigkeit muss}}
{{ccomment|IRQS_PER_SECOND ein Teiler von F_CPU sein}}
{{ccomment|und IRQS_PER_SECOND ein Vielfaches von 100.}}
{{ccomment|Ausserdem muss gelten F_CPU / IRQS_PER_SECOND <= 65536}}
#define IRQS_PER_SECOND 2000 {{comment|500 µs}}

{{ccomment|Anzahl IRQs pro 10 Millisekunden}}
#define IRQS_PER_10MS (IRQS_PER_SECOND / 100)

{{ccomment|Gültigkeitsprüfung.}}
{{ccomment|Bei ungeeigneten Werten gibt es einen Compilerfehler}}
#if (F_CPU/IRQS_PER_SECOND > 65536) || (IRQS_PER_10MS < 1) || (IRQS_PER_10MS > 255)
# error Diese Werte fuer F_CPU und IRQS_PER_SECOND
# error sind ausserhalb des gueltigen Bereichs!
#endif

{{ccomment|Compiler-Warnung falls die Genauigkeit nicht optimal ist.}}
{{ccomment|Wenn das nervt für deine Werte, einfach löschen :-)}}
#if (F_CPU % IRQS_PER_SECOND != 0) || (IRQS_PER_SECOND % 100 != 0)
# warning Das Programm arbeitet nicht mit optimaler Genauigkeit.
#endif

{{ccomment|Prototypen}}
void wait_10ms (const uint8_t);
void timer1_init();

{{ccomment|Zähler-Variable. Wird in der ISR erniedrigt und in wait_10ms benutzt.}}
static volatile uint8_t timer_10ms;

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Implementierungen der Funktionen}}
{{ccomment|//////////////////////////////////////////////////////////////////////}}

#if !defined (TCNT1H)
#error Dieser Controller hat keinen 16-Bit Timer1!
#endif {{ccomment|TCNT1H}}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Timer1 so initialisieren, daß er IRQS_PER_SECOND }}
{{ccomment|IRQs pro Sekunde erzeugt.}}
void timer1_init()
{
{{ccomment|Timer1: keine PWM}}
TCCR1A = 0;

{{ccomment|Timer1 ist Zähler: Clear Timer on Compare Match (CTC, Mode #4)}}
{{ccomment|Timer1 läuft mit vollem MCU-Takt: Prescale = 1}}
#if defined (CTC1) && !defined (WGM12)
TCCR1B = (1 << CTC1) | (1 << CS10);
#elif !defined (CTC1) && defined (WGM12)
TCCR1B = (1 << WGM12) | (1 << CS10);
#else
#error Keine Ahnung, wie Timer1 fuer diesen AVR zu initialisieren ist!
#endif

{{ccomment|OutputCompare für gewünschte Timer1 Frequenz}}
{{ccomment|TCNT1 zählt immer 0...OCR1A, 0...OCR1A, ... }}
{{ccomment|Beim überlauf OCR1A -> OCR1A+1 wird TCNT1=0 gesetzt und im nächsten}}
{{ccomment|MCU-Takt eine IRQ erzeugt.}}
OCR1A = (unsigned short) ((unsigned long) F_CPU / IRQS_PER_SECOND-1);

{{ccomment|OutputCompareA-Interrupt für Timer1 aktivieren}}
#if defined (TIMSK1)
TIMSK1 |= (1 << OCIE1A);
#elif defined (TIMSK)
TIMSK |= (1 << OCIE1A);
#else
#error Keine Ahnung, wie IRQs fuer diesen AVR zu initialisieren sind!
#endif
}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Wartet etwa t*10 ms. }}
{{ccomment|timer_10ms wird alle 10ms in der Timer1-ISR erniedrigt. }}
{{ccomment|Weil es bis zum nächsten IRQ nicht länger als 10ms dauert,}}
{{ccomment|wartet diese Funktion zwischen (t-1)*10 ms und t*10 ms.}}
void wait_10ms (const uint8_t t)
{
timer_10ms = t;
while (timer_10ms);
}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Die Interrupt Service Routine (ISR).}}
{{ccomment|In interrupt_num_10ms werden die IRQs gezählt.}}
{{ccomment|Sind IRQS_PER_10MS Interrups geschehen, }}
{{ccomment|dann sind 10 ms vergangen.}}
{{ccomment|timer_10ms wird alle 10 ms um 1 vermindert und bleibt bei 0 stehen.}}
SIGNAL (SIG_OUTPUT_COMPARE1A)
{
static uint8_t interrupt_num_10ms;

{{ccomment|interrupt_num_10ms erhöhen und mit Maximalwert vergleichen}}
if (++interrupt_num_10ms == IRQS_PER_10MS)
{
{{ccomment|10 Millisekunden sind vorbei}}
{{ccomment|interrupt_num_10ms zurücksetzen}}
interrupt_num_10ms = 0;

{{ccomment|Alle 10ms wird timer_10ms erniedrigt, falls es nicht schon 0 ist.}}
{{ccomment|Wird verwendet in wait_10ms}}
if (timer_10ms != 0)
timer_10ms--;
}
}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Das Hauptprogramm: Startpunkt }}
int main()
{
{{ccomment|LED-Port auf OUT}}
DDR_LED |= (1 << PAD_LED);

{{ccomment|Timer1 initialisieren}}
timer1_init();

{{ccomment|Interrupts aktivieren}}
sei();

{{ccomment|Endlosschleife}}
{{ccomment|Die LED ist jeweils 1 Sekunde an und 1 Sekunde aus,}}
{{ccomment|blinkt also mit einer Frequenz von 0.5 Hz}}
while (1)
{
{{ccomment|LED an}}
PORT_LED |= (1 << PAD_LED);

{{ccomment|1 Sekunde warten}}
wait_10ms (100);

{{ccomment|LED aus}}
PORT_LED &= ~(1 << PAD_LED);

{{ccomment|1 Sekunde warten}}
wait_10ms (100);
}

{{ccomment|main braucht keine return-Anweisung, weil wir nie hier hin kommen}}
}

=Von der C-Quelle zum hex-File=

Das Übersetzen über Kommandozeilen-Eingaben erledigen 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 Datei
blinky.c

==Compilieren==

Zunächst wird die C-Dateie übersetzt.
Der Übersetzungsvorgang wird gesteuert durch Kommandozeilen-Parameter (siehe [[avr-gcc]]).
Die Option
;<tt>-c</tt>: legt fest, daß nur compiliert wird (und nicht gelinkt),
;<tt>-o name</tt>: gibt den Name der Ausgabedatei an. Ohne diese Option heisst die Ausgabedatei immer <tt>a.out</tt>
;<tt>-mmcu=atmega8</tt>: legt den Controllertyp fest, in dem Beispiel den [[ATmega8]]
;<tt>-g</tt>: erzeugt Debug-Infos und
;<tt>-Os</tt>: optimiert auf Codegröße.
;<tt>-DF_CPU=xxx</tt>: optional, falls der Controller nicht mit 1 MHz läuft. <tt>xxx</tt> ist die Taktfrequenz in Hertz.
> avr-gcc blinky.c -c -o blinky.o -Os -g -mmcu=atmega8
Danach ist eine neue Datei entstanden (*.o)
blinky.c blinky.o

==Linken==
Die erzeugte Objek-Datei wird nun zur Ausgabedatei (*.elf) gelinkt:
> avr-gcc blinky.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 <tt>blinky.elf</tt>:
blinky.c blinky.elf blinky.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 <tt>.text</tt> (Programm) und <tt>.data</tt> (Daten).
Das Verzeichnis beinhaltet jetzt
blinky.c blinky.elf blinky.hex blinky.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 <tt>blinky_eeprom.hex</tt> 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.

<tt>avr-objdump</tt> gibt seine Ausgabe auf das Terminal aus.
Diese Ausgabe wird mit '<tt>></tt>' in die Datei <tt>blinky.lst</tt> umgeleitet.
Hier ein Ausschnitt aus dem Listfile:
<pre>
00000072 <wait_10ms>:

// //////////////////////////////////////////////////////////////////////
// Wartet etwa t*10 ms.
// timer_10ms wird alle 10ms in der Timer1-ISR erniedrigt.
// Weil es bis zum nächsten IRQ nicht länger als 10ms dauert,
// wartet diese Funktion zwischen (t-1)*10 ms und t*10 ms.
void wait_10ms (const uint8_t t)
{
timer_10ms = t;
72: 80 93 61 00 sts 0x0061, r24
while (timer_10ms);
76: 80 91 61 00 lds r24, 0x0061
7a: 88 23 and r24, r24
7c: e1 f7 brne .-8 ; 0x76 <wait_10ms+0x4>
7e: 08 95 ret
</pre>
Links stehen die Adressen, dann die Maschinencodes der Befehle,
danach die Maschinencodes in Assembler-Darstellung.
Ganz rechts nach dem Kommentarzeichen '<tt>;</tt>' stehen die Dezimalcodes von
Konstanten oder die Zieladressen von Sprüngen, wie bei dem <tt>brne</tt>-Befehl an Adresse 7c, der gegebenenfalls
8 Bytes zurückspringt und dann an Adresse 76 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 <tt>avr-gcc</tt>
ein Option an den Linker weiterreicht, die diesem zum Erstellen eines solchen Files veranlasst:
> avr-gcc blinky.o -o blinky.elf ... -Wl,-Map,blinky.map
Dadurch entsteht das Mapfile <tt>blinky.map</tt>.

==Die Größe ermitteln==

Die Größe der erhaltenen Objekte/Files können mit <tt>avr-size</tt> ausgegeben werden.
> avr-size -x blinky.o
druckt aus:
text data bss dec hex filename
0x7c 0x0 0x2 126 7e blinky.o
Das sind die Größen der einzelnen [[avr-gcc/Interna#Sections|Sections]].
Für das Flash relevant ist die Größe von
<tt>.text</tt> (Code) + <tt>.data</tt> (initialisierte Daten),
für das SRAM relevent ist <tt>.data</tt> (initialisierte Daten)
+ <tt>.bss</tt> (null-initialisierte Daten).

Im Flash werden also 126+0=126 Bytes belegt, und im SRAM 0+2=2 Bytes.

Ab binutils 2.16 gibt es für <tt>avr-size</tt> die Option <tt>-C</tt>, mit der man eine Zusammenfassung des ganzen Programms ausgeben kann:
> avr-size -C --mcu=atmega8 blinky.elf
druckt aus:
<pre>
AVR Memory Usage
----------------
Device: atmega8

Program: 216 bytes (2.6% Full)
(.text + .data + .bootloader)

Data: 2 bytes (0.2% Full)
(.data + .bss + .noinit)
</pre>

Die Gesamtgrösse ergibt sich erst aus dem elf-File,
denn auch die Vektortabelle und der Startup-Code belegen Platz. Hier eine Auflistung der beteiligten Sections:
> avr-size -x -A blinky.elf
druckt aus:
<pre>
blinky.elf :
section size addr
.text 0xd8 0x0
.data 0x0 0x800060
.bss 0x2 0x800060
.noinit 0x0 0x800062
.eeprom 0x0 0x810000
.stab 0x36c 0x0
.stabstr 0x84 0x0
.debug_aranges 0x14 0x0
.debug_pubnames 0x48 0x0
.debug_info 0xfc 0x0
.debug_abbrev 0xa2 0x0
.debug_line 0x101 0x0
.debug_str 0xa6 0x0
Total 0x86b</pre>
Im Flash werden somit 0xd8+0=216 Bytes belegt, also 90 Bytes mehr als das Object benötigt; davon entfallen z.B. schon 38 Bytes auf die Vektortabelle des [[ATmega8]],
die 2*19 Bytes groß ist.

Die Größen einzelner Funktionen/Variablen lassen sich anzeigen mit
> avr-nm --size-sort -S blinky.elf
was nach Größe sortiert ausdruckt:
<pre>
00800060 00000001 b interrupt_num_10ms.0
00800061 00000001 b timer_10ms
00000072 0000000e T wait_10ms
0000005c 00000016 T timer1_init
000000bc 0000001c T main
00000080 0000003c T __vector_6
</pre>

= HEX-Dateien zu diesem C-Code =
Zu dieser C-Datei gibt es HEX-Dateien für einige AVRs. Siehe dazu [[HEX Beispiel-Dateien für AVR]].
=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 <tt>#ifdef</tt> (in <tt>timer1_init</tt>)
* Abchecken der Gültigkeit von Defines durch den Präprozessor

=Siehe auch=
* [[HEX Beispiel-Dateien für AVR]] - Aus diesem Quellcode erzeugte Binärdateien zum Download und Proggen.
* [[AVR]]
* [[avr-gcc]]
* [[Interrupt]]
* [[:Kategorie:Quellcode C|weitere C-Code Beispiele]]

[[Kategorie:Grundlagen]]
[[Kategorie:Microcontroller]]
[[Kategorie:Quellcode C]]
[[Kategorie:Software]]
[[Kategorie:Praxis]]

Fallstricke bei der C-Programmierung

2007-06-03T20:44:42Z

Plaicy: /* TRUE ist nicht 1 */ siehe auch

=Tippfehler=

Tippfehler können immer passieren. Besonders fies ist es, wenn der Tippfehler nicht zu einer Warnung oder zu einer Fehlermeldung führt, weil der entstandene Code korrekter C-Code ist.

==Ein <tt>;</tt> zu viel==
Ein reflexartig eingetippter oder nach Änderungen stehen gebliebener <tt>;</tt> hat schon so manches
Programm ausgeknockt:
if (a == 0);
{
/* mach was */
}
Wenn <tt>a == 0</tt> ist, dann wird <tt>;</tt> ausgeführt (also im Endeffekt garnichts). Danach kommt der Block, der im <tt>if</tt> stehen sollte. Der wird immer ausgeführt, denn er gehört nicht mehr zum <tt>if</tt>.

==Zuweisung statt Vergleich==
if (a = 0)
{
/* mach was */
}
Zuerst wird <tt>a = 0</tt> gesetzt und dann überprüft, ob die <tt>if</tt>-Bedingung erfullt ist. Der Wert ist aber immer <tt>0</tt>, was ''nicht erfüllt'' bedeutet. Der nachfolgende Block wird nie betreten.

Abhilfe schafft, indem man sich angewöhnt zu schreiben
if (0 == a)
Wenn man dann eine Zuweisung eintippt, gibt's einen Compiler-Fehler.

==Signal/Interrupt-Name vertippt (avr-gcc)==

SIGNAL (SIG_OVEFRLOW0)
{
/* mach was */
}
Nicht alle Compiler-Versionen meckern da. Der [[ISR]]-Code wird nicht in die Interrupt-Tabelle eingetragen. Kommt es zum [[Interrupt]], dann landet man in RESET.

=Mangelnde C-Kenntnis=

==Warnung ignoriert==

::"''Wieso soll das Probleme machen? Das ist doch nur eine Warnung!''"

Warnungen zur Compile-Zeit werden gerne zu Fehlern zur Laufzeit. Letztere sind deutlich schwerer zu finden, als angewarnten Code zu korrigieren.
<pre>
void foo (long*);

void bar (int *p)
{
foo (p+1);
// Was soll das sein?!
// ((long*) p) + 1 oder
// (long*) (p + 1)
}
</pre>

<pre>
> gcc -c -o prog.o prog.c

prog.c: In function `bar':
prog.c:5: warning: passing arg 1 of `foo' from incompatible pointer type
</pre>

==Array-Index==

Informatiker am Bahnhof:
:''"0, 1, 2, ... Wo ist mein dritter Koffer?!"''
Gleiches gilt für Arrays:
#define NUM 10;
int a[NUM]; // für die N Werte a[0] ... a[N-1]
Ein Zugriff auf <tt>a[N]</tt> greift irgendwo hin.
Wahlweise liest man Schrott oder überschreibt andere Daten, die in der Nähe liegen, und
plötzlich seltsame Werte enthalten.

==Bitweise vs. Logische Operatoren==

Die Operatoren AND, OR und NOT gibt es in C in zwei Ausprägungen
;bitweise: Die Operatoren <tt>^</tt>, <tt>|</tt>, <tt>&</tt>, <tt>~</tt>, <tt>|=</tt>, <tt>^=</tt>, <tt>&=</tt>, <tt>|=</tt> operieren bitweise. Der entsprechende Operator wird also auf alle Bits des Wertes parallel angewandt und das Ergebnis für ein Bit ist unabhängig vom Inhalt der anderen Bits.
;logisch: Die Operatoren <tt>||</tt>, <tt>&&</tt>, <tt>!</tt>, <tt>&&=</tt>, <tt>||=</tt> operieren auf dem ganzen (int) Wert und berücksichtigen nur, ob der Wert 0 (false) oder ungleich 0 (true) ist.
Dementsprechend liefert <tt>&&</tt> i.d.R. ein anderes Ergebnis als <tt>&</tt>:
if (a && b) // erfüllt, wenn a!=0 und b!=0
if (a & b) // erfüllt, wenn in a und b an der gleichen Stelle ein Bit gesetzt ist
Ein Verwechseln bzw. unkorrektes Einsetzen der Operatoren gibt also ein falsches Programm.

==TRUE ist nicht 1==

Da C die Begriffe TRUE und FALSE eigentlich nicht kennt, wurde schon öfter beobachtet, daß folgendes definiert wurde:
#define TRUE 1
#define FALSE 0
solange man damit nur Schalter setzt und abfragt, ist dagegen nichts zu sagen.
a = TRUE; b = FALSE;
if ( (a == TRUE) && (b == FALSE)) {.."this is true"..}
wenn man aber dann schreibt
if ( (a & b) == TRUE) {.."this is true"..}
kann man einen herbe Enttäuschung erleben. Man müßte für ein richtiges Ergebnis schreiben
if ( (a & b) != FALSE) {.."this is true"..}
Damit ist aber eine gute Lesbarkeit endgültig dahin.

Besser sind Definition wie
#define FALSE (0!=0)
#define TRUE (0==0)
denn damit gilt einerseits, daß für alle boolschen Werte einschliesslich dieser Konstanten der
Zusammenhang <tt>x = !!x</tt> besteht.
Mit der allerersten Definition hat man das unerwünschte Ergebnis <tt>TRUE != !FALSE</tt>.
Andererseits kann man direkt gegen diese Konstanten vergleichen:
a = (x < y);
...
if (a == TRUE) // oder die 'klassische' Variante: if (a)

Siehe auch: http://www.dclc-faq.de/kap8.htm#8.2

==Ein , anstatt . in Konstante==

In C sowie im angloamerikanischen Sprachraum werden Dezimalbrüche mit einem <tt>.</tt> (Punkt) geschrieben und nicht wie im Deutschen mit einem <tt>,</tt> (Komma):
float pi;
pi = 3,14; // *AUTSCH* soll wohl heissen 3.14
Die zweite Zeile besteht aus zwei durch ein Komma getrennten Anweisungen, so daß das ganze
etwa gleichbedeutend ist mit
float pi;
pi = 3;
14;
Jedenfalls ist es korrekter C-Code!
Die <tt>14;</tt> ist ein Ausdruck, der nicht weiter gebraucht wird und daher wegfällt, da
er im Gegensatz zu einer void-Funktion keine Wirkung hat.
Man rechnet also mit dem Wert 3 für <math>\pi</math>.

Das falsche Komma hat auch schon so manchen ebay-Freak aufs Kreuz gelegt...

==Führende 0 in Konstanten==

In C kennzeichnet eine führende 0 bei einer Zahlenkonstante,
daß die Zahl oktal dargestellt ist. Somit ist 010 nicht gleich 10.
if (a == 030) // ist a gleich 24?

=Nicht-atomarer Code=
Verwendet man in einem Programm [[IRQ|IRQs]] ([[Interrupt|Interrupts]]) und ändert in der [[ISR]] (Service Routine) ein Datum (Variable, SFR, ...), dann wird diese Änderung möglicherweise überschrieben, wenn die IRQ zu einem ungünstigen Zeitpunkt auftritt.

Ein ausführlicheres Beispiel, das zeigt, was passieren kann, findet sich im Artikel [[avr-gcc]] im Abschnitt "[[avr-gcc#Zugriff auf einzelne Bits|Zugriff auf einzelne Bits]]". Ein weiteres Beispiel ist das Lesen, Schreiben oder Testen einer mehrbytigen Variable:
<pre>
int volatile i;
...
if (0 == i)
</pre>
Weil <tt>i</tt> länger als 1 Byte ist, kann es je nach Architektur nicht in einem Befehl gelesen werden;
daher kann während des Lesens eine IRQ auftreten, in deren ISR der Wert von <tt>i</tt> möglicherweise
verändert wird. Der obige Code könnte etwa so assembliert werden (hier mit [[avr-gcc]]):
<pre>
; i wird vom SRAM in das Registerpaar r24:r25 geladen
; low-Teil laden
lds r24,i
; high-Teil laden
; wenn hier eine IRQ zuschlägt, in der i verändert wird, ist der Registerinhalt korrupt
lds r25,(i)+1
or r24,r25
brne ...
</pre>
Natürlich können auch komplexere Datenstrukturen von diesem Phänomen betroffen sein.
Besonders unangenehm an dieser Klasse von Fehlern ist, daß sie nur sporadisch auftauchen
und man sie daher selbst mit einem guten Debugger sehr schlecht orten kann, da die zugehörige
Codestelle fast immer korrekt abgearbeitet wird.

Eine Möglichkeit dem zu begegnen ist, den ganzen betroffenen Block ununterbrechbar (atomar) zu machen.
Wieder ein Beispiel für avr-gcc:
#include <avr/io.h>
#include <avr/interrupt.h>
...
{{ccomment|ein lokale(!) Variable, die das Status-Register und }}
{{ccomment|insbesondere das im folgenden geänderte I-Flag merkt }}
{{ccomment|Falls man an der Codestelle immer weiß, daß IRQs }}
{{ccomment|aktiviert sind, kann man die zu atomisierende Sequenz }}
{{ccomment|auch in cli()...sei() einschachteln }}
{{ccomment|Falls IRQs global deaktiviert sind brauch man natürlich }}
{{ccomment|keine besonderen Vorkehrungen zu treffen, da dann aller Code }}
{{ccomment|atomar ist. }}
unsigned char sreg = SREG;

{{ccomment|Interrupts global deaktivieren (I-Flag = 0) }}
cli();

if (0 == i)
{
i = 1;
{{ccomment|IRQs sobald als möglich wieder zulassen }}
{{ccomment|(I-Flag wieder herstellen) }}
SREG = sreg;
}
else
{
{{ccomment|IRQs so bald als möglich wieder zulassen }}
{{ccomment|(I-Flag wieder herstellen) }}
SREG = sreg;
return;
}
...
Oder je nach Programmstruktur sichert man den Wert, z.B. in eine lokale Variable oder deaktiviert nur selektiv die kritischen Interrupts, also solche, die Einfluss auf die kritischen Daten nehmen.

= Weitere Fallstricke =
* [[Warteschleife]]

= Siehe auch =
* [[C-Tutorial]]
* [[avr-gcc]]

[[Kategorie:Grundlagen]]
[[Kategorie:Quellcode C|!]]
[[Kategorie:Software]]

Diskussion:Fallstricke bei der C-Programmierung

2007-06-03T20:43:46Z

Plaicy: "TRUE ist nicht 1"