www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR ATMega8 Systementwicklung in C


Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als langjähriger PIC-Anwender muss (darf? ;-) ich jetzt ein Projekt 
pflegen und weiterentwickeln, das auf einem AVR ATMega8L basiert.

Ich habe Schema und Sourcecode mit Makefile, jedoch keine fertigen 
Projektdateien. Im Makefile tauchen Begriffe auf wie "avr-gcc", 
"avrdude" und  "STK200" (ja, 200 und nicht etwa 500), die mir zumindest 
schon mal begegnet sind.

Jetzt die Frage an die AVR-Profis:
Wie lege ich jetzt los: Ich denke, ich lade AVR Studio 4 herunter.
Dort ist aber der C-Compiler noch nicht dabei, oder? Wo bekomme ich den?
Weiter brauche ich einen Programmer. Am liebsten wäre mir so etwas wie 
der ICD2 von Microchip, aber für AVR, also ein In-Circuit Programmer und 
Debugger.
Für's erste möchte ich auf einen (teuren?) richtigen In-Circuit-Emulator 
verzichten.
Wo immer möglich möchte ich Original-Tools von ATMEL verwenden.

Nach Möglichkeit wünsche ich konkrete kurze Tipps/Antworten.
Natürlich werde ich das Tutorial und die Datasheets studieren, aber ich 
muss vorerst halt den Aufwand für den Einstieg abschätzen.

Vielen Dank

Severino

Autor: Hans Josef (hjm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Severino,

sieh einmal hier: 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

dort steht alles was Du bruachst und wissen muß um los legen zu können.

Grüße
Hans-Josef

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles was du an Software brauchst, um einen AVR Controller in C zu 
programmieren und flash'en  zu können, ist ein einem Softwarepaket 
namens "winavr" enthalten (google ist dein Freund).

Alles weitere findest du, wie eben schon geschrieben, im hiesigen 
Tutorial.

Autor: 2961 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Incircuit emulator kann der Dragon (50Euro) gelten. Leider ist der 
auf 32k begrenzt. Schade. Mehr gibt's von Atmel nicht. Von 
Drittanbietern schon.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank.

Lässt sich der Dragon von AVR Studio aus einigermassen bequem bedienen?
Und wie sieht es aus mit C Source Level Debugging?

Wie heissen Drittanbieter, die weitere Emulatoren für AVR anbieten?

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, vielen Dank. Ich bin jetzt schon einen gewaltigen Schritt weiter.
Ich habe WinAVR installiert und konnte die Sourcen auf Anhieb 
compilieren.

Nun ist es aber so, dass im MAKEFILE verschiedene Controller eingetragen 
sind und alle bis auf einen auskommentiert:
#MCU_TARGET     = atmega8
#MCU_TARGET     = atmega16
MCU_TARGET     = atmega32

So liess sich die Sache compilieren und linken.
In der Schaltung ist aber der ATMega8 vorgesehen. Wenn ich also den 
"aktiviere":
MCU_TARGET     = atmega8
#MCU_TARGET     = atmega16
#MCU_TARGET     = atmega32
und erneut make aufrufe, bekomme ich die Meldung:

c:\winavr-20070525\bin\..\lib\gcc\avr\4.1.2\..\..\..\..\avr\bin\ld.exe: 
address
0x25ee of ABCD001_Module.elf section .text is not within region text
make: *** [ABCD001_Module.elf] Error 1


Verstehe ich das richtig, dass der Speicherplatz nicht ausreicht?

Nun habe ich bei atmel.com gesucht in der Hoffnung, einen Controller mit 
gleichem Gehäuse wie der Mega8 aber mit mehr Flash zu finden, und bin 
auf den Mega168 gestossen. Verstehe ich es richtig, dass sich der vom 
Mega8 hauptsächlich im Flash-Speicher unterscheidet?

Wenn ich jedenfalls im MAKEFILE den ATMega168 statt dem ATMega8 
eintrage, bekomme ich etliche Fehlermeldungen:

C:\AVR\SCA1X5\CVERSI~1.6>make all
avr-gcc -g -Wall -Wstrict-prototypes -Os -mcall-prologues 
-mmcu=atmega168    -c
-o ABCD001_Module.o ABCD001_Module.c
In file included from ABCD001_Module.h:218,
                 from ABCD001_Module.c:27:
ABCD001_setup.c: In function 'setup':
ABCD001_setup.c:19: error: 'TCCR0' undeclared (first use in this 
function)
ABCD001_setup.c:19: error: (Each undeclared identifier is reported only 
once
ABCD001_setup.c:19: error: for each function it appears in.)
ABCD001_setup.c:26: error: 'TCCR2' undeclared (first use in this 
function)
ABCD001_setup.c:28: error: 'OCR2' undeclared (first use in this 
function)
ABCD001_setup.c:36: error: 'TIMSK' undeclared (first use in this 
function)
ABCD001_setup.c:36: error: 'OCIE2' undeclared (first use in this 
function)
In file included from ABCD001_Module.h:220,
                 from ABCD001_Module.c:27:
RS485.c: In function 'get_chr':
RS485.c:23: error: 'UCSRA' undeclared (first use in this function)
RS485.c:23: error: 'RXC' undeclared (first use in this function)
RS485.c:26: error: 'UDR' undeclared (first use in this function)
[...]

Muss ich irgendwelche anderen Files includen?
Ich meinte, abhängig vom Parameter -mmcu=... werden die richtigen Files 
included.

Hat mir jemand von Euch Gurus einen Tipp?

Danke

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Severino R. wrote:

> Wenn ich jedenfalls im MAKEFILE den ATMega168 statt dem ATMega8
> eintrage, bekomme ich etliche Fehlermeldungen:

Wie hasst du den MCU_Type angegeben.... bitte so genau wie möglich.
Der richtige Eintrag muss "MCU_TARGET=atmega168" 
(gross-/kleinschreibung wichtig!) heissen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, da haben sich einige Namen geändert:

http://www.atmel.com/dyn/resources/prod_documents/...


Peter

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> http://www.atmel.com/dyn/resources/prod_documents/...

Mag ja sein, das sich Namen geändert haben, aber das es sowas wie 
'TIMSK' in winavrs libc nicht mehr geben soll, halte ich für nahezu 
ausgeschlossen ;)

da halte ich jede Wette ohne entsprechendes pdf-dokument zu lesen :-)

Autor: Jochen S. (schiffner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann es sein das dein Programm zu groß für einen mega8 ist und es daher 
nur für die größeren erstellt wird?

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@Peter : der ATMega168 hat TIMSK0, TIMSK1, TIMSK2 , nämlich für jeden 
Timer.

MfG Spess

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Niels Hüsken (monarch35)

>Mag ja sein, das sich Namen geändert haben, aber das es sowas wie
>'TIMSK' in winavrs libc nicht mehr geben soll, halte ich für nahezu
>ausgeschlossen ;)

>da halte ich jede Wette ohne entsprechendes pdf-dokument zu lesen :-)

>@Peter : der ATMega168 hat TIMSK0, TIMSK1, TIMSK2 , nämlich für jeden
>Timer.

Wann und wo gibst Freibier?

MFG
Falk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niels Hüsken wrote:

> Mag ja sein, das sich Namen geändert haben, aber das es sowas wie
> 'TIMSK' in winavrs libc nicht mehr geben soll, halte ich für nahezu
> ausgeschlossen ;)
>
> da halte ich jede Wette ohne entsprechendes pdf-dokument zu lesen :-)

Daß Du es nicht gelesen hast, ist mir klar:

Du hast die Wette verloren.


Peter

Autor: strange99 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens kannst du - nachdem du WinAVR installiert hast - auch das AVR 
Studio (ich habe 4.13) installieren. Dann hast du nämlich beides 
(Assembler und C) in einer IDE, kannst komfortabel debuggen und sparst 
dir das "hantieren" mit makefiles usw., darum kümmert sich nämlich das 
Studio.
Und Programmieren / Fuses setzen kannst du von dort aus auch ganz 
komfortabel. Versuchs mal ...

Strange

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

> Wann und wo gibst Freibier?

Mist! :-)
Da hab ich mich wohl ziemlich grob verschätzt, sorry :)

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen:

Jochen Schiffner wrote:
> kann es sein das dein Programm zu groß für einen mega8 ist und es daher
> nur für die größeren erstellt wird?

Das nehme ich ja an, deshalb habe ich geschrieben:
> Verstehe ich das richtig, dass der Speicherplatz nicht ausreicht?

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niels Hüsken wrote:
> Severino R. wrote:
>
>> Wenn ich jedenfalls im MAKEFILE den ATMega168 statt dem ATMega8
>> eintrage, bekomme ich etliche Fehlermeldungen:
>
> Wie hasst du den MCU_Type angegeben.... bitte so genau wie möglich.
> Der richtige Eintrag muss "MCU_TARGET=atmega168"
> (gross-/kleinschreibung wichtig!) heissen.

Habe ich, siehe:
> C:\AVR\SCA1X5\CVERSI~1.6>make all
> avr-gcc -g -Wall -Wstrict-prototypes -Os -mcall-prologues
> -mmcu=atmega168    -c
        ^^^^^^^^^

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger

Alles klar, danke.

Gibt es denn einen Controller, der so kompatibel wie möglich ist, aber 
mehr Flash-Speicher hat als der ATMega8 ?
Am liebsten ohne grosse Änderungen.

Autor: Jochen S. (schiffner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh,ja :-) (wer lesen kann ist klar im Vorteil)
wenn die .hex-Datei größer als 8kB ist passts nicht innen mega8.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ strange99:

Vielen Dank. Ich werde das noch nachholen.
Es geht mir im Moment darum:
Ich habe ein Design übernommen, so im Stil: "Da ist das Zeug. Schau 
selber mal, ob Du damit etwas anfangen kannst.".

Also wollte ich zuerst mit vertretbarem Aufwand sehen, ob:
1. sich die Software überhaupt kompilieren lässt
2. ob sie in einen ATMega8 (Print Layout ist für diesen Controller) 
programmiert werden kann.
3. ob das Ganze überhaupt in etwa so funktioniert, wie es soll.

Wenn das bis dahin gelingt, werde ich mich tiefer in die Materie AVR 
einarbeiten.
Wenn hingegen so ziemlich nichts funzt, dann werde ich eine 
Implementierung in PIC in Erwägung ziehen, da ich hier Erfahrung und 
Tools habe.
Wenn ich ohne Erfahrung Bugs in AVR suchen muss, werde ich noch 
Stammgast hier im Forum.


@ alle:
Vielen Dank für die schnelle Hilfe.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jochen Schiffner wrote:
> oh,ja :-) (wer lesen kann ist klar im Vorteil)
> wenn die .hex-Datei größer als 8kB ist passts nicht innen mega8.

Leider ist es nun so, dass im beschriebenen Fall (für den ATMega8) gar 
keine .hex-Datei erstellt wurde :-(

Ausserdem könnte es ja sein (dachte ich mir jedenfalls), dass irgend 
etwas an eine absolute Adresse reloziert wird, die es beim ATMega8 gar 
nicht gibt (weil zu hoch), und nicht einfach der Code als solcher zu 
gross ist.

Autor: Jörg X. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wenn die .hex-Datei größer als 8kB ist passts nicht innen mega8.
DAS stimmt ja so nicht, weil eine .hex-Datei min. 100% Overhead hat 
(jedes Byte wird durch min. 2 Zeichen dargestellt).

Aber avr-size kann anzeigen, wieviel Speicher belegt ist, wenn der 
Controller korrekt angegeben ist - funktioniert bei AVR-Studio, WinAVR 
bzw. der mFile-Makefile-Vorlage tadellos.

scnr, Jörg

ps.: @OP den Code wirst du wohl überarbeiten müssen, wenn du vom Atmega8 
auf den 168 umsteigen willst (s. Post von P. Dannegger) - ob nun mit 
find & replace oder (mehr oder weniger cleveren) macros

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jörg X.

Danke für die klare Antwort.
Also kann ich entweder den Sourcecode überarbeiten (und dann wohl noch 
ein bisschen debuggen) oder sehen, ob ich das Layout für den ATMega16 
oder 32 anpassen kann.

Übrigens: Natürlich zeigt die simple Dateigrösse einer Hex-Datei nicht 
die Grösse des Codes an.
Da ist mehr als 100% "Overhead" drin.
Aber wenn man die Datei anschaut, sieht man die verwendeten Adressen, 
was noch viel wichtiger ist.
Denn was nützt eine noch so kleine Hex-Datei, wenn sehr hohe Adressen 
belegt sind.
Ausserdem dürften in der Hex-Datei auch die Werte für Fuses drinsein 
(jedenfalls bei PIC).

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jochen Schiffner wrote:
> wenn die .hex-Datei größer als 8kB ist passts nicht innen mega8.

Die einen versuchen genau diese Falschaussage aus der Welt zu schaffen 
und du setzt sie wieder rein. Tz! ;)

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ausserdem dürften in der Hex-Datei auch die Werte für Fuses drinsein
>(jedenfalls bei PIC).

Sind sie bei AVR nicht :( Auch die EEprom Daten landen in einer
eigenen HEX-Datei. Lass dir doch mal statt HEX ne BIN
Datei erzeugen. Dann ist alles klar.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Severino R. wrote:
> Als langjähriger PIC-Anwender muss (darf? ;-) ich jetzt ein Projekt
> pflegen und weiterentwickeln, das auf einem AVR ATMega8L basiert.

Dann sollte es ja in einen ATmega8 passen.

Hast Du vielleicht ohne Optimierung (-O0) compiliert ?

Versuch mal -Os, das sollte den kleinsten Code erzeugen.

Nicht pinkompatibel, aber Registerkompatibel zum ATmega8 sind ATmega16 
und ATmega32.


Peter

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>MCU_TARGET     = atmega32

Diese CPU zu nehmen hatte sicherlich einen Grund.
Vieleicht irgendwas mit Bootloader ?
Keine Ahnung ! Ohne deinen Quellcode kann man hier
nur weiter spekulieren. Also mein Tip:
Trag mal wieder den ATMega32 ins makefile ein
und lass dir eine BIN Datei erzeugen. Nur so
kannst du schnell sehen wie groß das Programm
wirklich wird.

@ Peter
>avr-gcc -g -Wall -Wstrict-prototypes -Os -mcall-prologues

Siehe oben. Kleiner gehts kaum noch.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.