include <avr/eeprom.h> hängt sich AVRStudio auf [gelös

Hallo,

ich würde gerne das EEPROM des ATMega32 nutzen. Sobald ich aber die <avr/eeprom.h> include, hängt sich das AVRStudio beim kompilieren auf. Danach kann ich noch nicht einmal das Projekt wieder öffnen (hängt sich sofort wieder auf), bevor ich nicht das "default"-Verzeichnis geleert habe. Ich hab's auf verschiedenen Rechnern ausprobiert, und auch statt der mitgelieferten von WinAVR die Versionen von libc verwendet. Hat wer 'nen Tip?

Außerdem hab ich das CodeSample aus dem ATMega32-Datasheet zum EEPROM lesen/schreiben abgetippt - funktioniert nicht (kein Fehler, kein Hänger, schreibt aber nicht). In Assembler dagegen geht's... ?!?

Gerry

Hast du das COmpilieren mal ohne AVR-Studio gemacht? Hängt es dann auch?
Weisst du genau, was sich aufhängt?
Windows?
AVR-Studio?
maks?
avr-gcc?
Assembler?
Linker?
Hast du vernünftige Pfadnamen?

Hallo Georg-Johann,

also komplett zu Fuß hab ich's mit der Compiliererei jetzt nicht hinbekommen (dafür hat man ja eigentlich auch eine IDE, oder?), ABER: Es wird sogar eine .hex-File erzeugt und wenn ich die in den Controller lade, funktioniert das Schreiben sogar. Nur das AVR-Studio stürzt ab... ich suche noch nach dem Fehler...

Die Pfadnamen sollten kein problem sein: C:\eeprom5\eeprom5.c und die Softwarepakete sind alle in die Standardverzeichnisse installiert.

So,

ich bin ein Stück weiter: Beim Build wird im "default"-Verzeichnis ein "dep"-Verzeichnis angelegt, dieses enthält eine Datei "eeprom5.o" und darin werden an zwei Stellen im Pfadnamen BackSlashes statt normaler Slashes verwendet:

Code:

---

eeprom5.o: ../eeprom5.c C:/WinAVR/avr/include/avr/io.h \
  C:/WinAVR/avr/include/avr/sfr_defs.h C:/WinAVR/avr/include/inttypes.h \
  C:/WinAVR/avr/include/stdint.h C:/WinAVR/avr/include/avr/iom32.h \
  C:/WinAVR/avr/include/avr/portpins.h \
  C:/WinAVR/avr/include/avr/version.h C:/WinAVR/avr/include/avr/eeprom.h \
  C:\WinAVR\bin/../lib/gcc/avr/3.4.5/include/stddef.h

C:/WinAVR/avr/include/avr/io.h:

C:/WinAVR/avr/include/avr/sfr_defs.h:

C:/WinAVR/avr/include/inttypes.h:

C:/WinAVR/avr/include/stdint.h:

C:/WinAVR/avr/include/avr/iom32.h:

C:/WinAVR/avr/include/avr/portpins.h:

C:/WinAVR/avr/include/avr/version.h:

C:/WinAVR/avr/include/avr/eeprom.h:

C:\WinAVR\bin/../lib/gcc/avr/3.4.5/include/stddef.h:

---

Wenn ich die durch normale Slashes ersetze, kann ich das Projekt wieder öffnen. Jetzt wüsst ich bloß gerne noch, woher die kommen...

Vielleicht klingt das etwas konservativ und uncool, aber wozu braucht man eine IDE zum programmieren ?
Ein guter Editor und ein standard Makefile in Verbindung mit make und Du bist Deine Sorgen los.

Gruß Sebastian

Hach,

der alte immerwährende Streit...

Ich hab mal die folgende Antwort gelesen: "Wenn ich einen Nagel in die Wand haben will, nehm ich ja auch einen Hammer und drück ihn nicht mit dem Daumen rein." Ich find das passend ;)

Zitat:

---

der alte immerwährende Streit...

---

[-X , hier streitet ja keiner [-(

Es war eine ernste Frage, sheinbar kannst Du sie selber nicht beantworten, aber bevor ich mit einem Hammer arbeite, der immer wieder abbricht,
nehme ich doch lieber die Finger O:)

Gruß Sebastian

Also, das Thema hat sich soweit erledigt. Fehlerursache ist offenbar, dass in "eeprom.h" die Datei "stddef.h" inkludiert wird. Diese liegt unter C:\WinAVR\lib\gcc\avr\3.4.5\include, und das ist wohl aus irgend einer Pfadangabe bekannt, was dann zu den Backslashes führt. Wenn man diesen Pfad aber unter Project->Configuration Options manuell hinzufügt, dann geht's.

Zum Glück bin ich auf dieses Thema gestoßen.
Bei mit hat sich auch das AVR Studio aufgehängt, nachdem ich string.h eingebunden hatte.
Aber mit den Veränderungen die Gerry herausgefunden hat funktioniert es.
Super, wäre da nie von alleine drauf gekommen!!!!!

Zitat:

---

Zitat von Gerry77

Also, das Thema hat sich soweit erledigt. Fehlerursache ist offenbar, dass in "eeprom.h" die Datei "stddef.h" inkludiert wird. Diese liegt unter C:\WinAVR\lib\gcc\avr\3.4.5\include, und das ist wohl aus irgend einer Pfadangabe bekannt, was dann zu den Backslashes führt. Wenn man diesen Pfad aber unter Project->Configuration Options manuell hinzufügt, dann geht's.

---

Vielen Dank! Ich war schon kurz vor dem verzweifeln...

...Vielleicht klingt das etwas konservativ und uncool, aber wozu braucht man eine IDE zum programmieren ?
Ein guter Editor und ein standard Makefile in Verbindung mit make und Du bist Deine Sorgen los...

Das muss man als Linux-progger machen, weil es keine vernünftige IDE gibt.
Habe 6 Jahre lang mit Linux gearbeitet, immer wieder die Textconsole wenn man was Spezielles machen wollte, es gab keine IDE, war immer wieder ein Rückschritt in die Siebziger von UNIX, furchtbar.

Hi

Ich hatte das Problem auch allerdings mit stdio.h und stdlib.h.
Wenn man die Files auch einfach links unter "Header Files" einträgt gehts auch.

Aber ich denke das ist ein echter Bug. DENN nach C-Standard sollte man, egal welche header-Datei per #include einbinden.

Und was sich da aufhängt oder nicht, ist zunächst vollig nebensächlich.
Ob IDE oder nicht, man sollte immer includieren können wie man Lust und Laune hat.

PC-C Programme, wenn man auf den ganzen Fensterles-Schnickschnack verzichtet, und das solide per API programmiert, dann braucht man da auch keine IDE.
Aber bei einem ich sage jetzt bewusst komplizierzen AVR-Komplettsystem, das mehrere Prozessortypen unterstützen muss, ist es relativ kompliziert den Überblick zu behalten. Es ist doch prima, wenn eine IDE das für einen macht.
Aber das ist eine andere Baustelle.

VLG Tobi

Hi!

Hm. Also Gerry scheint recht zu haben, es liegt an dieser stddef.h.
Die ist auch bei mir das Problem.

Jetzt ist die Frage, wer erstellt die Datei in default\dep\ ?
AVRStudio oder WinAVR.

Ich tippe ja auf AVRStudio.

Hat das eine Datei mit Pfadangaben zu den einzelnen libs? (für den schönen Projektbaum links...??!) Da müsste der Fehler zu finden sein.

Die Lösung mit dem Pfad in den Einstellungen scheint zwar zu funzen, aber ist auch keine endgültige lösung... :(

VLG Tobi

EDIT: Also meine Eingeweide-Forschungen waren ziemlich erfolglos...

Ich habe jetzt die neueste Version von Win-avr-c (April2006) installiert.
und das neueste Update-AVRstudio. Kann über Avrstudio den ganzen Winavr-c-kram bewerkstelligen. Auch die Make wird vom Avr-studio erstellt.
Kann das EEprom vom AVR16 beschreiben und lesen.

HI

+++WICHTIG+++WICHTIG+++WICHTIG+++

Es gibt ein Service Pack zum AVR Studio 4.
Es installiert u.A. neue Devices (u.A. den Mega 164P) und behebt den Bug mit der stddef.h.
Zumindest hängt es sich bei mir nimmer auf.

Link:
http://www.atmel.com/dyn/resources/p...412SP3b490.exe

Die zugehörige History (txt)
http://www.atmel.com/dyn/resources/p...tesStudio4.txt

</WICHTIG>

VLG Tobi

Man sollte ruhig mal bei Atmel reinschauen.......


Man liest jeden Tag Zeitung.....warum nicht mal öfters bei Atmel reinschauen, gerade da tut sich in letzter Zeit was.

danke..

war schon am verzweifeln