Moin moin,
bevor ich jetzt ins Wochenende gehe, hätte ich gerne von euch noch ein
"Wie blöd bist du denn" gehört ;)
Ich habe - neben vielem anderen - in meinem Code folgende Schnipsel:
Die "umgekehrte Reihenfolge" der Parameter ist mMn richtig (andererseits
sitze ich auch schon länger hier vor dem Rechner) - siehe
http://www.gnu.org/savannah-checkouts/non-gnu/avr-libc/user-manual/group__avr__eeprom.html
(oder wurde das erst zwischen 1.6.2 und heute geändert?)
Wo könnte noch ein Fehler liegen, der eeprom_write_block fehlschlagen
lässt, wo eeprom_write_byte an derselben Stelle mit denselben Adressen
einwandfrei funktioniert? (Funktion bzw. Nichtfunktion nachgewiesen
durch avrdude -t ... und dann am Prompt "r eeprom")
Kompiliert wird das ganze (über WinAVR-Makefile) mit
avr-gcc -c -mmcu=atmega32 -I. -g -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=myeeprom.lst -std=gnu99 -DF_CPU=16000000
-MD -MP -MF .dep/myeeprom.o.d myeeprom.c -o myeeprom.o
Meine Version der avr-libc und des avr-gcc stehen oben.
Fällt einem von euch irgendwas typisches ein, das ich vergessen haben
könnte? EEPROM-Waitstates bei 16MHz, die von der einen Funktion
automatisch eingefügt werden, von der anderen nicht, oder sowas? Oder
ist das gar ein bekannter Bug, den ich nur beim googlen nicht gefunden
habe?
Vielen Dank für alle Anregungen,
MfG, Heiko
(Das ganze soll in eine Funktion, die eine Queue von ins EEPROM zu
schreibenden Daten zyklisch abarbeitet - um die Latenzen kürzer zu
halten, kann ich nicht sofort nach Änderung die Änderung ins EEPROM
schreiben - ansonsten könnte ich wunderbar mit eeprom_write_byte leben)
Ich mach mal die Ingrid: Heute habe ich dann auch den Bugtracker für
avr-libc gefunden - und damit den folgenden Bug
http://savannah.nongnu.org/bugs/?22828
Naja, Volltreffer, würde ich mal sagen. Bei 16kB Hex-File muss man ja
mal einen Bug erwischen...
Gibt es einen sinnvollen Weg, doch eeprom_write_block zu nutzen, ohne
dass mir das dann beim nächsten Update um die Ohren fliegt? So in der
Art eines
Ich weiß, dass dieses Beispiel nicht geht, da der Präprozessor wohl kaum
weiß, welche Version der libc der Linker am Ende einlinken will... aber
fällt euch eine halbwegs geschickte Variante außer einer BIG FAT WARNING
ein?
(Gentoo crossdev bietet derzeit noch keine avr-libc >1.6.2 an und ich
habe wenig Lust, sie manuell zu installieren, wenn es sich vermeiden
lässt - vermutlich wohl nicht, dank des eeprom_read_byte-Bugs, in den
ich ja sonst auch laufen werde)
MfG, Heiko
Heiko wrote:
> (Gentoo crossdev bietet derzeit noch keine avr-libc >1.6.2 an und ich> habe wenig Lust, sie manuell zu installieren, wenn es sich vermeiden> lässt - vermutlich wohl nicht, dank des eeprom_read_byte-Bugs, in den> ich ja sonst auch laufen werde)
Naja, Gentoo crossdev ist mittlerweile nicht mehr sonderlich gut
gepflegt, leider. Unter Linux bietet sich derzeit wohl Bingo600's
Script als beste Variante an:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631
Vielen Dank Werner, damit hätte ich überhaupt nicht gerechnet.
1.6.2 ist tatsächlich 10602 :)
Jörg, du hast Recht, crossdev schläft wohl seit einer Zeit recht tief
und fest. Um Alternativen kümmere ich mich aber erst nach meiner
Studienarbeit...
MfG, Heiko
> Unter Linux bietet sich derzeit wohl Bingo600's Script als beste Variante an:
Man braucht im Script getfiles.sh und buildavr-no-insight.sh nur die
1.6.2 durch 1.6.4 ersetzen. Compiliert fehlerfrei und man bekommt die
AVRLibC 1.6.4
Werner
Nur nochmal als Rückmeldung: Ich habe crossdev wohl doch ein wenig
Unrecht getan, seit gestern Abend (auf einen Bugreport hin...) ist auch
1.6.4 in den Repositorys.
MfG, Heiko
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
