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
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.
Als Incircuit emulator kann der Dragon (50Euro) gelten. Leider ist der auf 32k begrenzt. Schade. Mehr gibt's von Atmel nicht. Von Drittanbietern schon.
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?
Hi @Peter : der ATMega168 hat TIMSK0, TIMSK1, TIMSK2 , nämlich für jeden Timer. MfG Spess
@ 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
Ü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
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.
> 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
@ 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! ;)
>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.
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
>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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.