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

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?

> 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

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

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

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.

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?

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.

1

#define F_CPU 16000000

2

#include <avr/io.h>

3

#include <avr/sleep.h>

4

#include <avr/interrupt.h>

5

#include <avr/eeprom.h>

6

#include <util/delay.h>

7

#include <avr/pgmspace.h>

8

9

int main()

10

{

11

  uint16_t ee_rtc_cal, rtc_cal;

12

  const uint16_t *p = &ee_rtc_cal;

13

14

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

15

  rtc_cal++;

16

}

1

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.

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

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

1

#include <avr/eeprom.h>

2

3

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

4

5

uint16_t EEMEM ee_rtc_cal;

6

7

int main(void)

8

{

9

  uint16_t rtc_cal;

10

11

  rtc_cal = eeprom_read_word(&ee_rtc_cal);

12

13

  rtc_cal++;

14

  return 0;

15

}

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,

1

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

2

rtc_cal= eeprom_read_word(&ee_rtc_cal);

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

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

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

1

int16_t ee_rtc_cal EEMEM = 1;

ändern in:

1

uint16_t ee_rtc_cal EEMEM = 1;

dann brauchst du den cast beim Funktionsaufruf auch nicht mehr.

1

rtc_cal = eeprom_read_word(&ee_rtc_cal);

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

1

/** \ingroup avr_eeprom

2

    Read one 16-bit word (little endian) from EEPROM address \a __p.

3

 */

4

uint16_t eeprom_read_word (const uint16_t *__p) __ATTR_PURE__;

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

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

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