gcc Kompiler

Wenn du in C programmieren willst, dann brauchst du avr-gcc:

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Ingo schrieb:

> Dazu brauche ich ja den GCC-Compiler. Diesen habe ich schon
> auf meinem Rechner. Oder zumindestens habe ihc einen gcc-compiler um auf
> windows Programme zu schreiben. Ist der für Mikrocontroller der gleiche
> compiler? Oder heisst der nur gleich?

Das Frontend ist das gleiche, aber nicht das Backend. Du brauchst einen 
Compiler, der AVR8-Code erzeugen kann, wenn du Controller mit 
AVR8-Architektur programmieren möchtest.

Trotzdem der avr-gcc über weite Strecken der gleiche Compiler ist, ist 
dort aber eben doch vieles ganz anders. Insbesondere solltest du dich 
unerverzüglich von der Vorstellung trennen, dass du bestehende Programe 
für Windows einfach mal so für den AVR8 übersetzen könntest...

Das nennt man die "Portabilitäts-Lüge". Jeder C-Freak wird natürlich 
abstreiten, dass es sie gibt. Aber die normative Kraft des Faktischen 
wird dich überzeugen: es gibt sie...

c-hater schrieb:
> Das nennt man die "Portabilitäts-Lüge". Jeder C-Freak wird natürlich
> abstreiten, dass es sie gibt. Aber die normative Kraft des Faktischen
> wird dich überzeugen: es gibt sie...
Und mit Assembler ist das besser? Oder was moechtest du uns damit sagen?

c-hater schrieb:
> Insbesondere solltest du dich
> unerverzüglich von der Vorstellung trennen, dass du bestehende Programe
> für Windows einfach mal so für den AVR8 übersetzen könntest...

Wenn man das zeug richtig schreibt, ist das durchaus machbar. Schau zum 
Beispiel mein altes Webserver Projekt an, das ich nie wirklich 
fertiggestellt habe: 
https://github.com/Daniel-Abrecht/DPA-UCS/tree/162fbd5ab9425fa0f2d45f9309c0d8639a4948ca

Das einzige Hardwarespezifische sind die Treiber & die (optionalen) 
Board configs:
https://github.com/Daniel-Abrecht/DPA-UCS/tree/162fbd5ab9425fa0f2d45f9309c0d8639a4948ca/src/server/driver
https://github.com/Daniel-Abrecht/DPA-UCS/tree/162fbd5ab9425fa0f2d45f9309c0d8639a4948ca/src/config/board

Diese implementieren generische Interfaces:
https://github.com/Daniel-Abrecht/DPA-UCS/tree/master/src/headers/DPA/UCS/driver

Um es verwenden zu können, muss man nur das adelay interface noch 
mindestens ein Ethernettreiberinterface implementieren.

Gemäss

1

wc -l $(find . -iname .git -prune -o -iname '*.c' -or -iname '*.h')

Sind das insgesamt 9962 Zeilen an code. Davon machen die Treiber 
gerademal soviel aus:

1

> wc -l $(find src/server/driver/ -type f)

2

  618 src/server/driver/generic/enc28j60.c

3

   34 src/server/driver/generic/dummy.c

4

   51 src/server/driver/atmega1284/io_pin.c

5

   36 src/server/driver/atmega1284/adelay.c

6

   48 src/server/driver/atmega1284/spi.c

7

   28 src/server/driver/atmega1284/stdio_to_uart.c

8

   11 src/server/driver/linux/adelay.c

9

  205 src/server/driver/linux/ethernet.c

10

   23 src/config/board/avr-net-io.c

11

 1054 total

Wobei der 618 Zeilige enc28j60 Treiber sowie der dummy ethernet Treiber 
eigentlich auch Hardwareunabhängig sind, und der Rest ja Treiber für 
mehrere Plattformen umfasst. 228 für Linux, 163 Zeilen für den 
atmega1284, + 23 Zeilen für die avr-net-io board config.

Mit anderen Worten, von 9560 Zeilen Platformunabhängigem C Code muss 
man, um eine neuen uC hinzuzufügen, nur ~200 Zeilen Code schreiben. 
Naja, zumindest sofern es auf den Chip passt, die Buffer für Ethernet 
frames usw. verbraten zwangsläufig recht viel platz, und der Stack 
verbrauch ist auch etwas hoch.

Und dass ist noch ohne die Verwendung bestehender Fameworks und 
Libraries, die einem teils selbst dass abnehmen können.