AVR ATMega8 Systementwicklung in C

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

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.

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?

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

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.

Ja, da haben sich einige Namen geändert:

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


Peter

Peter Dannegger wrote:

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

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 :-)

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

@ 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

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

Falk Brunner wrote:

> Wann und wo gibst Freibier?

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

@ 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?

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
        ^^^^^^^^^

@ 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.

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

@ 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.

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.

@ 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).

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! ;)

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