Error: predefs.h / Umzug AVR-Studio-CodeBlocks + Win-Ubuntu

[walter (Gast)]

Hallo,

bin neu von AVR-Studio unter Windows jetzt auf Code::Blocks in Ubuntu 
umgestiegen.
Mein C-Code für AVR lässt sich nicht mehr Compilieren.

Error:
/usr/include/features.h|324|fatal error: bits/predefs.h: No such file or 
directory|

es geht hier wohl um #define

allerdings habe ich selbst features.h und predefs.h nie eingebunden 
(höre ich zum ertsen mal)

Suche in Google ergibt dass es an der libc6-dev liege. Ist bei mir 
allerdings installiert. Und läuft alles auf meinem 32-Bit Linux.

Kann mir jemand von euch helfen?
Walter

[Albert .. (albert-k)]

Hast du das AVR entwicklungspacket maus dem Packet-Manager von Ubuntu 
installiert? Darin sollten eigentlich alle nötigen Packete enthalten 
sein.

Folgende Packete fallen mir da spontan ein:
 -binutils-avr
 -avr-libc
 -gcc-avr

[walter (Gast)]

danke für die Antwort!

habe mich an diese Anleitung gehalten und alles mit dem Synaptic 
Paketmanager installiert.
http://www.ladyada.net/learn/avr/setup-unix.html

deine Pakete sind da auch dabei.
seltsam ... jemand eine Idee was ich ausprobieren könnte?

[Stefan E. (sternst)]

walter schrieb:
> Error:
> /usr/include/features.h|324|fatal error: bits/predefs.h: No such file or
> directory|

walter schrieb:
> jemand eine Idee was ich ausprobieren könnte?

Wenn da was aus /usr/include inkludiert wurde, dann wurde von 
Code::Blocks sicher nicht der avr-gcc aufgerufen, sondern der gcc des 
Host-Systems. Du musst Code::Blocks schon mitteilen, welchen Compiler es 
benutzen soll.

[walter (Gast)]

> von
> Code::Blocks sicher nicht der avr-gcc aufgerufen, sondern der gcc des
> Host-Systems

Habe aber AVR-GCC eingestellt.  Und sogar versucht ein neues AVR-Projekt 
zu erstellen, meinen C-Code rein kopiert und es kommt die gleiche 
Fehlermeldung.

Ist es sicher, dass es am AVR-GCC liegt?  XUbuntu 12.04 32bit, 
Codeblocks 10.05

dies sind die Includes des Codes:

#include <avr/io.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <avr/eeprom.h>
#include <util/delay.h>
#include <avr/pgmspace.h>

(also kein features.h und keinpredefs.h)



und das ist der Build-Log von Codeblocks:
-------------- Build: Release in test ---------------

Compiling: main.c
main.c:39:0: warning: "F_CPU" redefined
<command-line>:0:0: note: this is the location of the previous 
definition
In file included from /usr/include/inttypes.h:26:0,
                 from 
/usr/lib/gcc/avr/4.5.3/../../../avr/include/avr/sfr_defs.h:126,
                 from 
/usr/lib/gcc/avr/4.5.3/../../../avr/include/avr/io.h:99,
                 from main.c:63:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such 
file or directory
compilation terminated.
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 1 warnings

[Stefan E. (sternst)]

walter schrieb:
> Habe aber AVR-GCC eingestellt.

Dann poste doch mal die von Code::Blocks generierte Command-Line des 
Compiler-Aufrufs. Denn dann steckt da wahrscheinlich ein -I/usr/include 
oder so drin, was da nichts zu suchen hat.

[walter (Gast)]

habe das hier gemacht:
http://lovingthepenguin.blogspot.fr/2012/01/fixing-codeblocks-avr-build-problems-on.html
und die Fehlermeldung ist weg.

allerdings gibts jetzt mehr errors and warnings:
-------------- Build: Release in test ---------------

Compiling: main.c
main.c:39:0: warning: "F_CPU" redefined
<command-line>:0:0: note: this is the location of the previous 
definition
main.c: In function ‘clockinit’:
main.c:904:5: warning: pointer targets in passing argument 1 of 
‘__eerd_word_m168’ differ in signedness
/usr/lib/gcc/avr/4.5.3/../../../avr/include/avr/eeprom.h:520:1: note: 
expected ‘const uint16_t *’ but argument is of type ‘int16_t *’
Linking console executable: bin/Release/test.elf
Output size is 8.59 KB
Running project post-build steps
avr-objcopy -O ihex -R .eeprom -R .eesafe bin/Release/test.elf 
bin/Release/test.elf.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma 
.eeprom=0 -O ihex bin/Release/test.elf bin/Release/test.elf.eep.hex
avr-objdump -h -S bin/Release/test.elf > bin/Release/test.elf.lss
Process terminated with status 0 (0 minutes, 0 seconds)
1 errors, 2 warnings
-----------------------------------------

Fehler:
/usr/lib/gcc/avr/4.5.3/../../../avr/include/avr/eeprom.h|520|note: 
expected ‘const uint16_t *’ but argument is of type ‘int16_t *’|

Zeile 520:
uint16_t eeprom_read_word (const uint16_t *__p) _ATTR_PURE_;


warning:
main.c|905|warning: pointer targets in passing argument 1 of 
‘__eerd_word_m168’ differ in signedness|

Zeile 905:
rtc_cal= eeprom_read_word(&ee_rtc_cal); // EEPROM Werte auslesen


In Win AVR-Studio 4 hat alles problemlos funktioniert. Soll ich einen 
neuen Thread aufmachen??

[walter (Gast)]

was ist Grundsätzlich bei meinem Umzug vin Win AVR-Studio 4 nach Ubuntu 
12.04 Code::Blocks zu beachten?  Müsste doch eigendlich problemlos 
funktionieren????
Danke
Walter

[Norbert (Gast)]

walter schrieb:
> was ist Grundsätzlich bei meinem Umzug vin Win AVR-Studio 4 nach Ubuntu
> 12.04 Code::Blocks zu beachten?  Müsste doch eigendlich problemlos
> funktionieren????

Zuerst einmal feststellen ob es nur ein Konfigurationsproblem ist, oder 
ob Canonical mal wieder die Debian Pakete soweit verbessert hat bis es 
nicht mehr läuft ;-)

Mit anderen Worten, ab in's source Verzeichnis und von Hand make 
aufrufen.
Vorher vielleicht noch überprüfen ob von Windows irgendwelche '\' in den 
Pfaden geblieben sind.

Wenn make problemlos läuft kann man in C::B suchen.

[walter (Gast)]

danke für den Tip!

habe make im Terminal ausgeführt und erhalte die gleichen warnigs und 
errors. (alle meldungen genau gleich  s.o.)
Es werden sowohl in C::B als auch beim Von-Hand-Make .hex .elf und alles 
drum und dran erstellt. Die .hex allerdings etwas größer als es bem 
AVR-Stduio war.

Aber mit der warning und dem error, die es vorher nicht gab.

> Vorher vielleicht noch überprüfen ob von Windows irgendwelche '\' in den
> Pfaden geblieben sind.
was meinst du damit genau? Wo soll ich nach Backslashes suchen??

> oder
> ob Canonical mal wieder die Debian Pakete soweit verbessert hat bis es
> nicht mehr läuft ;-)
ist das jetzt der Fall??  Bin ich der erste dem das auffällt????
Das ist ja schon seltsam!"§$/$/§$&//)()=(&%$§
was ist jetzt angesagt? Debian Pakete installieren?

[Norbert (Gast)]

walter schrieb:
> was ist jetzt angesagt? Debian Pakete installieren?
Ne,ne, auf gar keinen Fall Pakete von versch. Distributionen mischen.
Das ist ein Rezept für Desaster.

> was meinst du damit genau? Wo soll ich nach Backslashes suchen??
Falls sich in den Sourcen oder Headerdateien DEINES Projektes so etwas 
wie:
#include <arv\interrupt.h>
befände, würde sich ein Linux System damit unwohl fühlen.

#define F_CPU 16000000
#include <avr/io.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <avr/eeprom.h>
#include <util/delay.h>
#include <avr/pgmspace.h>

int main()
{
  uint16_t ee_rtc_cal, rtc_cal;
  const uint16_t *p = &ee_rtc_cal;

  rtc_cal = eeprom_read_word(p); // EEPROM Werte auslesen
  rtc_cal++;
}

avr-gcc -Wall -O2 -mmcu=atmega16 -o simple.elf simple.c

kompiliert hier auf Debian Wheezy sauber und ohne warnings/errors

Ich vermute das irgendetwas in deinen sources nicht ganz sauber ist 
und die Win-gcc Version das vielleicht nicht gesehen hat.

[walter (Gast)]

Ja, kompiliert bei mir auch sauber und ohne Probleme:
> #define F_CPU 16000000
> #include <avr/io.h>
> #include <avr/sleep.h>
> #include <avr/interrupt.h>
> #include <avr/eeprom.h>
> #include <util/delay.h>
> #include <avr/pgmspace.h>
>
> int main()
> {
>   uint16_t ee_rtc_cal, rtc_cal;
>   const uint16_t *p = &ee_rtc_cal;
>
>   rtc_cal = eeprom_read_word(p); // EEPROM Werte auslesen
>   rtc_cal++;
> }

Norbert schrieb:
> Ich vermute das irgendetwas in deinen sources nicht ganz sauber ist
> und die Win-gcc Version das vielleicht nicht gesehen hat.
Diese Vermutung hatte ich auch schon, allerdings ist der betroffene 
Code nicht von mir sondern von Peter Dannenberger's "Die genaue 
Sekunde": 
http://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC#Beispielprogramm

Wenn ich diesen unmodifiziert kompiliere, erhalte ich genau die gleichen 
Error/Warnings.

Woran liegt es nun? Am Code oder AVR-GCC Ubuntu? Was bedeuten die 
Meldungen überhaupt? Und warum läuft Norberts Code rund aber Peters 
nicht?

Danke  Walter

[Stefan E. (sternst)]

walter schrieb:
> main.c:39:0: warning: "F_CPU" redefined

Entweder du hast ein "#define F_CPU" doppelt in deinem Code, oder bei 
Code::Blocks kann man den Takt irgendwo einstellen und es "injiziert" 
dann ein F_CPU bereits über die Kommando-Zeile.


walter schrieb:
> main.c|905|warning: pointer targets in passing argument 1 of
> ‘__eerd_word_m168’ differ in signedness

rtc_cal= eeprom_read_word(&ee_rtc_cal);

->

rtc_cal= eeprom_read_word((uint16_t*)&ee_rtc_cal);

walter schrieb:
> 1 errors, 2 warnings

Was ist denn der "1 errors"? Ich sehe nur die "2 warnings".

[Norbert (Gast)]

Hmm, hab's gerade noch einmal mit EEMEM versucht, geht aber auch ohne 
Probleme

#include <avr/eeprom.h>

// avr-gcc -Wall -O2 -mmcu=atmega16 -o tst tst.c

uint16_t EEMEM ee_rtc_cal;

int main(void)
{
  uint16_t rtc_cal;

  rtc_cal = eeprom_read_word(&ee_rtc_cal);

  rtc_cal++;
  return 0;
}

Und der von dir erwähnte code kompiliert mit nur einer *Warnung*:
tst.c: In function ‘main’:
tst.c:81: warning: pointer targets in passing argument 1 of 
‘__eerd_word_m88’ differ in signedness

das liegt daran,

int16_t ee_rtc_cal EEMEM = (F_CAL-12800000)*256/100;
rtc_cal= eeprom_read_word(&ee_rtc_cal);

ee_rtc_cal ist signed und die Funktion erwartet unsigned.
Ansonsten keine Probleme.

[walter (Gast)]

Stefan Ernst schrieb:
> bei
> Code::Blocks kann man den Takt irgendwo einstellen
genau so ist es, diese Warnung ist mir klar

> rtc_cal= eeprom_read_word(&ee_rtc_cal);
>->
> rtc_cal= eeprom_read_word((uint16_t*)&ee_rtc_cal);
Durch diese Änderung gibts hier keine Warnungen/Errors. Weder in meinem 
Code, noch in eeprom.h
Ist das so also korrekt und Peter Dannenberg's Programm fehlerhaft?

> Was ist denn der "1 errors"? Ich sehe nur die "2 warnings".
Wundert mich auch schon die ganze Zeit. Da stehen immer nur die 2 
Warnings und das "Note:" in rot. Kompiliert jedoch alles. Bei einem 
Error würde ja alles stoppen!?
Scheinbar ist das AVR-GCC oder make irgendwo doch Fehlerhaft.

Norbert schrieb:
> Hmm, hab's gerade noch einmal mit EEMEM versucht, geht aber auch ohne
> Probleme
hier auch ohne Probleme

......
> das liegt daran,int16_t ee_rtc_cal EEMEM = (F_CAL-12800000)*256/100;
> rtc_cal= eeprom_read_word(&ee_rtc_cal);
> ee_rtc_cal ist signed und die Funktion erwartet unsigned.
ich ändere
int16_t ee_rtc_cal EEMEM = 1;
der Fehler ist immer noch da!
.....

Aber wie gesagt läuft alles gut durch wenn ich Stefans Änderung
> rtc_cal= eeprom_read_word((uint16_t*)&ee_rtc_cal);
mache. Ist das richtig so? Habe Pointer immer noch nicht verstanden :(

[Norbert (Gast)]

walter schrieb:
>> das liegt daran,int16_t ee_rtc_cal EEMEM = (F_CAL-12800000)*256/100;
>> rtc_cal= eeprom_read_word(&ee_rtc_cal);
>> ee_rtc_cal ist signed und die Funktion erwartet unsigned.
> ich ändere
> int16_t ee_rtc_cal EEMEM = 1;
> der Fehler ist immer noch da!
> .....
>
> Aber wie gesagt läuft alles gut durch wenn ich Stefans Änderung
>> rtc_cal= eeprom_read_word((uint16_t*)&ee_rtc_cal);
> mache. Ist das richtig so? Habe Pointer immer noch nicht verstanden :(

Im Grunde genommen musst du nur

int16_t ee_rtc_cal EEMEM = 1;

ändern in:

uint16_t ee_rtc_cal EEMEM = 1;

dann brauchst du den cast beim Funktionsaufruf auch nicht mehr.

rtc_cal = eeprom_read_word(&ee_rtc_cal);

[Stefan E. (sternst)]

Norbert schrieb:
> Im Grunde genommen musst du nur

int16_t ee_rtc_cal EEMEM = 1;

> ändern in:

uint16_t ee_rtc_cal EEMEM = 1;

Na, ich weiß nicht. Schließlich ist die Variable, die hier im EEPROM 
gespiegelt werden soll, ja tatsächlich (und mit Absicht) signed. Die 
EEPROM-Variable im Gegensatz zum RAM-Pendant unsigned zu machen, würde 
zwar auch funktionieren, aber der Cast beim Funktionsaufruf ist hier
meiner Meinung nach die sauberere Lösung.

walter schrieb:
> Ist das so also korrekt und Peter Dannenberg's Programm fehlerhaft?

Nicht fehlerhaft, nur etwas unsauber.

walter schrieb:
> Wundert mich auch schon die ganze Zeit. Da stehen immer nur die 2
> Warnings und das "Note:" in rot. Kompiliert jedoch alles. Bei einem
> Error würde ja alles stoppen!?
> Scheinbar ist das AVR-GCC oder make irgendwo doch Fehlerhaft.

Das geht weder auf das Konto von AVR-GCC, noch auf das von Make. Das ist 
dann ein Problem der IDE (Code::Blocks), die anscheinend den 
Build-Output falsch interpretiert (nämlich eine Fehlermeldung entdeckt, 
wo keine ist).

[Norbert (Gast)]

Stefan Ernst schrieb:

> uint16_t ee_rtc_cal EEMEM = 1;

> Na, ich weiß nicht. Schließlich ist die Variable, die hier im EEPROM
> gespiegelt werden soll, ja tatsächlich (und mit Absicht) signed. Die
> EEPROM-Variable im Gegensatz zum RAM-Pendant unsigned zu machen, würde
> zwar auch funktionieren, aber der Cast beim Funktionsaufruf ist hier
> meiner Meinung nach die sauberere Lösung.

Das ist aber die Adresse im EEPROM und die werden unglaublich ungern 
negativ;-)

> rtc_cal = eeprom_read_word(&ee_rtc_cal);

rtc_cal erhält die Daten welche im EEPROM gespeichert sind.

[Stefan E. (sternst)]

QNorbert schrieb im Beitrag #2824055
> Das ist aber die Adresse im EEPROM und die werden unglaublich ungern
> negativ;-)

Nein, das ist es eben nicht. Es ist eine Variable im EEPROM, von der 
dann beim Funktionsaufruf die Adresse gebildet wird. Mit dieser Adresse 
hat die signed/unsigned-Sache hier überhaupt nichts zu tun.

[Norbert (Gast)]

Stefan Ernst schrieb:
> Nein, das ist es eben nicht. Es ist eine Variable im EEPROM, von der
> dann beim Funktionsaufruf die Adresse gebildet wird. Mit dieser Adresse
> hat die signed/unsigned-Sache hier überhaupt nichts zu tun.

uint16_t ee_rtc_cal EEMEM = 1;

ee_rtc_cal zeigt auf das zweite Byte im EEPROM.
(Von mir aus auch: ist ein Offset zum Start des EEPROMS.)
 0 wäre das erste Byte, wird aber aus bekannten Gründen ungern genommen. 
Man darf dies durchaus als Adresse *im* EEPROM ansehen.

Die Funktion eeprom_read_word() liest ab der angegebenen 
Position/Adresse zwei Bytes aus und gibt sie als Rückgabewert zurück. 
Diese Position ist immer ein positiver Integerwert, darum uint16_t.
Selbst wenn das EEPROM >32767 wäre und man auf Byte 32768 zugreifen 
würde, wäre der Wert den ich der Funktion übergebe nicht negativ.


Aus der eeprom.h:

/** \ingroup avr_eeprom
    Read one 16-bit word (little endian) from EEPROM address \a __p.
 */
uint16_t eeprom_read_word (const uint16_t *__p) __ATTR_PURE__;

[Norbert (Gast)]

Vielleicht noch einmal anders ausgedrückt:
ee_rtc_cal beinhaltet den Wert der in die EEPROM Adressregister 
EEARH/EEARL geschrieben werden. Diese Werte sind niemals negativ.

Der Parameter __p erwartet etwas das unsigned ist. Wenn da ein signed 
ankommt gibt's die Warnung.

[Stefan E. (sternst)]

Norbert schrieb:
> uint16_t ee_rtc_cal EEMEM = 1;
>
> ee_rtc_cal zeigt auf das zweite Byte im EEPROM.
> (Von mir aus auch: ist ein Offset zum Start des EEPROMS.)
>  0 wäre das erste Byte, wird aber aus bekannten Gründen ungern genommen.
> Man darf dies durchaus als Adresse *im* EEPROM ansehen.

Das ist komplett falsch. Die Variable ee_rtc_cal liegt irgendwo im 
EEPROM (die Adresse wird vom Linker vergeben und könnte hier auch 42 
sein). Die 1 ist der initiale Inhalt für das EEPROM an dieser 
unbekannten Adresse.

Norbert schrieb:
> Die Funktion eeprom_read_word() liest ab der angegebenen
> Position/Adresse zwei Bytes aus und gibt sie als Rückgabewert zurück.

Und diese Adresse ist in diesem Fall die Adresse von ee_rtc_cal, nicht 
der Inhalt.

[Stefan E. (sternst)]

Norbert schrieb:
> Vielleicht noch einmal anders ausgedrückt:
> ee_rtc_cal beinhaltet den Wert der in die EEPROM Adressregister
> EEARH/EEARL geschrieben werden.

Nein.

[Stefan E. (sternst)]

Wovon du die ganze Zeit redest, wäre sowas:

uint16_t adr = 1;

also ohne EEMEM,
und dann

eeprom_read_...(adr);

also ohne &.

[Norbert (Gast)]

Stefan, du hast absolut Recht, Asche auf mein Haupt.

Ich habe vor vielen, vielen Jahren mit dem ICC compiler arbeiten müssen 
(damals noch unter Win) und dort gabe es, wenn ich mich recht erinnere 
zwei verschiedene Möglichkeiten auf das interne EEPROM zuzugreifen. 
Wahrscheinlich hatte ich das noch irgendwo im Langzeitspeicher.:-)
(Löschprozedur ist eingeleitet)

Nun habe ich Aufgrund von Platzbedarf immer separate EEPROM Bausteine 
und nutze demzufolge die Standardroutinen nicht mehr.

Sorry for the confusion.

[walter (Gast)]

> Stefan, du hast absolut Recht
das heißt
> rtc_cal= eeprom_read_word((uint16_t*)&ee_rtc_cal);
ist die saubere Lösung

vielen Dank an alle!

[Norbert (Gast)]

Vielleicht sollte man hier zum Abschluss noch Folgendes erwähnen:

Wenn man sich eine Firmware baut und *.hex sowie *.eep in den
controller brennt und dann nicht mehr anfasst, so ist alles in Ordnung.

Dieser Mechanismus ist aber brandgefährlich, wenn man sich darauf
verlässt das bestimmte Werte an bestimmten Positionen im EEPROM
stehen. ZB. wenn man nachträglich bzw. als Update einen Satz Werte
mit dem Brenner oder per eingebautem Upload nur ins EEPROM schieben 
will.

Wurde die Firmware zwischenzeitlich neu kompiliert/gelinkt und die
Reihenfolge der EEPROM Definitionen geändert, so schreibt man dann an
falsche Positionen.

Sobald Zeilen wie
uint16_t EEMEM ee_3 =  8;
uint16_t EEMEM ee_4 =  4;
getauscht werden (was an der Funktion des Programms
absolut nichts ändert), vielleicht sogar wenn mehrere Objektdateien 
mit solchen Definitionen vorhanden sind, was passiert dann beim linken 
bzw. objcopy?
Ist das (die Reihenfolge/Absolute Adresse im EEPROM) irgendwo definiert, 
bzw. kann man darauf Einfluss nehmen oder müssen externe Programme, die 
Updates als *.eep Dateien erstellen, jedesmal komplett neu gebaut 
werden?

Hier:
http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html
konnte ich nichts zu diesem Thema finden.

[Johann L. (gjlayde)]

Norbert schrieb:
> Vielleicht sollte man hier zum Abschluss noch Folgendes erwähnen:
>
> Wenn man sich eine Firmware baut und *.hex sowie *.eep in den
> controller brennt und dann nicht mehr anfasst, so ist alles in Ordnung.
>
> Dieser Mechanismus ist aber brandgefährlich, wenn man sich darauf
> verlässt das bestimmte Werte an bestimmten Positionen im EEPROM
> stehen.

Ja, auf nicht-spezifizierte Features zu bauen ist immer eine schlechte 
Idee.

[Norbert (Gast)]

Johann L. schrieb:
> Ja, auf nicht-spezifizierte Features zu bauen ist immer eine schlechte
> Idee.

Du möchtest möglicherweise ein oder zwei posts rückwärts lesen, in denen 
ich ausführte das ein anderer Compiler genau so etwas erlaubte.
Ich möchte mich also nicht blind auf irgendetwas verlassen sondern 
fragte explizit:
> Ist das (die Reihenfolge/Absolute Adresse im EEPROM) irgendwo definiert,
> bzw. kann man darauf Einfluss nehmen oder müssen externe Programme, die
> Updates als *.eep Dateien erstellen, jedesmal komplett neu gebaut
> werden?

Das war doch nicht schwer, oder?

[Stefan E. (sternst)]

Norbert schrieb:
> Ist das (die Reihenfolge/Absolute Adresse im EEPROM) irgendwo definiert,
> bzw. kann man darauf Einfluss nehmen oder müssen externe Programme, die
> Updates als *.eep Dateien erstellen, jedesmal komplett neu gebaut
> werden?

Wenn du alle EEPROM-Variablen in einer einzigen Struktur zusammenfasst, 
dann hast du quasi die Kontrolle über die Platzierung.

[Norbert (Gast)]

Stefan Ernst schrieb:
> Norbert schrieb:
>> Ist das (die Reihenfolge/Absolute Adresse im EEPROM) irgendwo definiert,
>> bzw. kann man darauf Einfluss nehmen oder müssen externe Programme, die
>> Updates als *.eep Dateien erstellen, jedesmal komplett neu gebaut
>> werden?
>
> Wenn du alle EEPROM-Variablen in einer einzigen Struktur zusammenfasst,
> dann hast du quasi die Kontrolle über die Platzierung.

Ja, aber größere Projekte, die in versch. Sourcedateien EEPROM Var. 
verwenden, würden jedoch das komplette 'Umarrangieren' erfordern und den 
Code definitiv nicht lesbarer werden lassen.

Also dann doch lieber die avr-libc Funktionen verwerfen und ein paar 
eigene Dreizeiler schreiben. Ist ja kein Hexenwerk.

Trotzdem, Danke!

[Johann L. (gjlayde)]

Norbert schrieb:
> Stefan Ernst schrieb:
>> Wenn du alle EEPROM-Variablen in einer einzigen Struktur zusammenfasst,
>> dann hast du quasi die Kontrolle über die Platzierung.
>
> Ja, aber größere Projekte, die in versch. Sourcedateien EEPROM Var.
> verwenden, würden jedoch das komplette 'Umarrangieren' erfordern und den
> Code definitiv nicht lesbarer werden lassen.

Weitere Möglichkeiten sind beschrieben in
http://lists.gnu.org/archive/html/avr-gcc-list/2012-08/msg00056.html

[Stefan E. (sternst)]

Norbert schrieb:
> Ja, aber größere Projekte, die in versch. Sourcedateien EEPROM Var.
> verwenden, würden jedoch das komplette 'Umarrangieren' erfordern und den
> Code definitiv nicht lesbarer werden lassen.

So unlesbar finde ich ein zentrales EEPROM-Modul nun nicht.

> Also dann doch lieber die avr-libc Funktionen verwerfen und ein paar
> eigene Dreizeiler schreiben. Ist ja kein Hexenwerk.

Was haben diese Funktionen mit der Platzierung zu tun? Du kannst sie ja 
auch mit eigenen Adressen benutzen.
Davon abgesehen, händische Adressen bedeuten ja nicht, dass die 
einzelnen Module dann voneinander unabhängig wären.

[Norbert (Gast)]

@Johann L.
Danke für den Link. Der vierte Vorschlag:
- Use hard-coded addresses like eeprom_read_byte ((const void*) 1);
  this is not nice, not recommended and hard to maintain.
käme meinen Vorstellungen am nächsten.
Seitdem ich auf Linux umstellte, stehen mir leistungsfähige Mechanismen 
(sed/grep/awk) zur Verfügung, die solche Probleme ('hard to maintain') 
für meine Anwendungen auf Null reduzieren würde.

@Stefan Ernst
Letzten Endes wären bei einer erneuten Umstellung auf einen anderen 
Compiler
wiederum ähnliche Probleme zu erwarten. Jedoch einige wenige Dreizeiler, 
sauber dokumentiert, kurze Referenz auf das jeweilige Datenblatt, sowie 
einem /*HARDWARE*/ Tag würden solche Probleme in der Zukunft für mich 
deutlich transparenter machen.

[Johann L. (gjlayde)]

Norbert schrieb:
> @Johann L.
> Danke für den Link. Der vierte Vorschlag:
> - Use hard-coded addresses like eeprom_read_byte ((const void*) 1);
>   this is not nice, not recommended and hard to maintain.
> käme meinen Vorstellungen am nächsten.
> Seitdem ich auf Linux umstellte, stehen mir leistungsfähige Mechanismen
> (sed/grep/awk) zur Verfügung, die solche Probleme ('hard to maintain')
> für meine Anwendungen auf Null reduzieren würde.

Naja, ob sed- Kommandos einfach zu lesen und zu maintenieren sind sei 
mal dahingestellt.

Was spricht gegen --sort-section=name nebst

#define EE(X) __attribute__((section (".eeprom." #X)))

int ee_x EE(x);
int ee_y EE(y);

 
oder
 

#define EE_DECL(X) X __attribute__((section (".eeprom." #X)))

int EE_DECL (ee_a);
int EE_DECL (ee_b);

[Christian K. (microkirsche)]

walter schrieb:
> danke für den Tip!
>
> habe make im Terminal ausgeführt und erhalte die gleichen warnigs und
> errors. (alle meldungen genau gleich  s.o.)
> Es werden sowohl in C::B als auch beim Von-Hand-Make .hex .elf und alles
> drum und dran erstellt. Die .hex allerdings etwas größer als es bem
> AVR-Stduio war.
>
> Aber mit der warning und dem error, die es vorher nicht gab.
>
>> Vorher vielleicht noch überprüfen ob von Windows irgendwelche '\' in den
>> Pfaden geblieben sind.
> was meinst du damit genau? Wo soll ich nach Backslashes suchen??
>
>> oder
>> ob Canonical mal wieder die Debian Pakete soweit verbessert hat bis es
>> nicht mehr läuft ;-)
> ist das jetzt der Fall??  Bin ich der erste dem das auffällt????

Hallo walter,

ich hatte das gleiche Problem mit dem
/usr/include/features.h|324|fatal error: bits/predefs.h: No such file or
directory|
aber erst heute und suchte jetzt im Forum.
Ich arbeite ebenfalls mit Code::Blocks für die AVR und hatte bis vor 
kurzem Ubuntu 10.04. Jetzt mit 12.04 trat dieses Problem auf.
In den Antworten fand ich die Bemerkung von Stefan Ernst gut: "Du musst 
Code::Blocks schon mitteilen, welchen Compiler es benutzen soll."
Und in der Fehlermeldung steht der Pfad drin, wo er suchen möchte! In 
Code::Blocks kann man nicht nur den Compiler einstellen, sondern 
natürlich auch alles mögliche Andere. Da fand ich unter 'Compiler and 
debugger settings' den Reiter 'search directories', dort war bei mir der 
Pfad '/usr/include' eingetragen, wieso auch immer. Das Verzeichnis 
enthält nichts mit dem AVR.
Ich habe dort den Pfad '/usr/lib/gcc/avr' eingetragen und jetzt 
compiliert Code::Blocks wieder alles richtig.
Ich vermute, dass Code::Blocks auto-detecting auf das Verzeichnis das 
erste Verzeichnis mit 'avr' hereinfällt und einen anderen Pfad nicht 
weiter sucht. Der andere Pfad ist ja auch etwas versteckt.
Vielleicht muss man auch in dem Reiter 'Toolchain executables' den Pfad 
eintragen, der klingt wichtiger. Ich habe aber momentan keine Lust das 
auszuprobieren, mit dem richtigen Suchpfad bin ich momentan glücklich

> Das ist ja schon seltsam!"§$/$/§$&//)()=(&%$§
> was ist jetzt angesagt? Debian Pakete installieren?

Grüße,
microkirsche