pgmspace.h|1067|error: unknown type name ‘uint_farpt

[phil (Gast)]

Hallo und Frohe Ostern,

ich hab n problem mit meinem Atmega32 und zwar wenn ich n array mit 
Hilfe von pgmspace in den Flash schreiben will bekomm ich immer den 
Fehler:

const uint16_t laenge[] PROGMEM =
{
    100, 500, 500, 500, 350, 150, 500, 350, 150, 650, 150,
    500, 500, 500, 350, 150, 500, 350, 150, 650, 150,
    500, 300, 150, 400, 200, 200, 125, 125, 250, 250,
    250, 400, 200, 200, 125, 125, 250, 250,
    125, 500, 375, 125, 500, 375, 125, 650
};

/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h|1067|error: 
unknown type name ‘uint_farptr_t’|

Kennt jemand das Problem oder sieht meinen Fehler? Ich hab auch schon 
danach gegoogelt aber nichts gescheites gefunden.
Bin dankbar für jede Antwort.

Philipp

[phil (Gast)]

PS:
in der pgmspace.h steht als Kommentar hinter der "Fehlerstelle":

/* program memory can't change */

[phil (Gast)]

push! Niemand ne Idee???

[Timmo H. (masterfx)]

Vermutlich ist irgendwo anders im Code noch ein Fehler. Kann man mal 
ALLES sehen?

[phil (Gast)]

hi, danke für die antwort,

das komplette programm is ewig lang... und es kann auch nicht an ner 
anderen stelle liegen, weil ich das auskommentier dann geht es ja... 
Muss ich vielleicht dem compiler noch bestimmte parameter übergeben?

[phil (Gast)]

also irgendwie is wohl doch n fehler im Code. Auf nem anderen Rechner 
hab ich genau das selbe problem...
Anbei die betroffenen files...

danke im vorraus philipp

PS: Ja ich weiß mein codestil ist schrecklich und die global.h ist total 
überlagert...

[Stefan E. (sternst)]

phil schrieb:
> Anbei die betroffenen files...

Und was ist "pgmspace1.h"?

[phil (Gast)]

achso ja.. ich habs da nur mit der aktuellen version von: 
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html 
versucht, aber die ist genau die gleiche wie dir bei mir in 
avr-verzeichnis sprich pgmspace1.h = pgmspace.h

[phil (Gast)]

also hier nochmal das komplette projekt als zip mit der standard 
pgmspace.h

[phil (Gast)]

ich hab auch gerade bemerkt, dass der fehler kommt sobald ich die 
pgmspace.h includiere also hat wohl wirklicht nichts mit dem PROGMEM zu 
tun

[g457 (Gast)]

main.c Zeile 176 kommentiert eine '}' aus. Wenn man die reinnimmt (und 
ds1307test.c der Rundablage zuführt) gehts(tm).

[phil (Gast)]

ups, ja da war wohl noch n fehler...
aber bei mir kommt immernoch:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h|1067|error: 
unknown type name ‘uint_farptr_t’|

[g457 (Gast)]

> aber bei mir kommt immernoch:

hab mir eben gcc 4.7.2 installiert - damit gehts ebenfalls. Stell mal 
sicher, dass Deine avr-libc nicht korrumpiert ist. Vielleicht auch mal 
von der Konsole bauen versuchen (nicht CodeBlocks - vielleicht ist da 
was im Argen).

[Timmo H. (masterfx)]

Bei mir gehts auch.

[phil (Gast)]

hey nochmal,
ersmal vielen dank. Und die Frage ist mir jetzt n bissel peinlich, aber 
mit der terminal-befehl von gcc-avr hab ich das noch nie gemacht.
Wie sag ich denn da, dass er alle .c files in dem ordner kompielieren 
soll?

[g457 (Gast)]

quick'n'dirty:

avr-gcc -Wall -DF_CPU=16000000UL -mmcu=atmega32 -Os -o main *.c

..ds1307test.c entsorgen nicht vergessen!

..wers mit obigem Archiv nachstellen will:

$ rm -rf wecker ; mkdir wecker ; cd wecker ; unzip ../wecker.zip >/dev/null ; rm -f ds1307test.c ; sed -i 's!//    }!}!g;' main.c ; avr-gcc -Wall -DF_CPU=16000000UL -mmcu=atmega32 -Os -o main *.c ; file main
main.c: In function ‘main’:
main.c:95: warning: unused variable ‘mmold’
main: ELF 32-bit LSB executable, Atmel AVR 8-bit, version 1 (SYSV), statically linked, not stripped

[phil (Gast)]

ok seltsam, hat tatsächlich nicht gemeckert wegen der pgmspace.h ist die 
main -datei die da jetzt erstellt wurde eigentlich das .hex file das ich 
direkt mit avrdude auf n atmega übertragen kann?

Dann muss es doch aber irgendeine compiler-einstellung von code-blocks 
sein... kennt jemand ne gute gui für avr-gcc für linux?

[g457 (Gast)]

> ist die main -datei die da jetzt erstellt wurde eigentlich das .hex file
> das ich direkt mit avrdude auf n atmega übertragen kann?

Nein, aber fast(tm):

$ avr-objcopy -O ihex main main.hex

> Dann muss es doch aber irgendeine compiler-einstellung von code-blocks
> sein... kennt jemand ne gute gui für avr-gcc für linux?

könnte auch eine der temporären Dateien sein. Wirf mal bin/ und obj/ 
weg. ..afair auch noch *.depend und *.layout..

[g457 (Gast)]

ich seh grad Du nutzt EEPROM-Automatismen - dann musst Du jenen Bereich 
extra rumkopieren:

$ avr-objcopy -O ihex -R .eeprom -R .eesafe main main.hex
$ avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex main main.eep.hex

[phil (Gast)]

ok danke für den befehl.
das mit den löschen von den ordnern/files hat leider nichts gebracht.
hab jetzt auch schon alles einstellung bei "Build options" unter 
code-blocks so eingestellt wie in der in dem gcc-avr-befehl ( bis auf 
das -o (kann ich nicht finden)) und kommt immernoch der befehl... 
seltsam seltsam...

[phil (Gast)]

ok... 'räusper.. muss zugeben, dass von dem code ziemlich viel hier vom 
forum und auch von anderen libraries kopiert hab. daher die frage, was 
sind EEPROM-Automatismen?

[g457 (Gast)]

> was sind EEPROM-Automatismen?

$ grep -e EEMEM *.*
main.c:int16_t ee_rtc_cal EEMEM = (F_CAL-12800000)*256/100;        // Kalibrierung für RTC, Frequenzfehler in 1/1000 Hz

..scheint aber nirgends genutzt zu werden..

[Daniel G.cm. (Gast)]

/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h|1067|error:
unknown type name ‘uint_farptr_t’|

War bei Mir ein Fehler auf Debian in Codeblocks und konnte so behoben 
werden:

1.) Konsole Öffnen
2.) Befehl "sudo pico /usr/lib/avr/include/avr/pgmspace.h"
3.) <inttypes.h> mit "../inttypes.h" ersetzen
4.) STRG+X  Y  ENTER

[Daniel G.cm. (Gast)]

Also einfach gesagt einfach in der pgmspace.h <inttypes.h> mit 
"../inttypes.h" ersetzen

[Amateur (Gast)]

@Daniel

Konntest Du den Toten wirklich nicht ihre wohlverdiente Ruhe lassen?

[Eberhard A. (0815_bastler)]

wäre es nicht besser den den korrekten Fundort zum Suchpfad 
hinzuzufügen. So müssen die Headerdateien nicht geändert werden und es 
funktioniert auch bei einer neuen Version der Lib's.
Das Problem taucht bei Codeblocks wohl auch auf, weil es auf die falsche 
inttypes.h zugreift.