mikrocontroller.net

Forum: Compiler & IDEs [avr-libc 1.6.2] [avr-gcc 4.3.2] eeprom_write_block nicht für einzelnes Byte nutzbar?


Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#include <inttypes.h>

#include <avr/io.h>
#include <avr/eeprom.h>

uint8_t eeLCDBacklight EEMEM = 50;

uint8_t LCDBacklight;

void sendToEEPROM(void)
{
   // funktioniert nicht
   // eeprom_write_block(&LCDBacklight, &eeLCDBacklight, 1);
   // funktioniert
   eeprom_write_byte(&eeLCDBacklight, LCDBacklight);
}

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

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
#ifdef AVR_LIBC_1.6.2
eeprom_write_block(&eeLCDBacklight, &LCDBacklight, 1);
#else
eeprom_write_block(&LCDBacklight, &eeLCDBacklight, 1);
#endif

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

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch, weiss er
#if (__AVR_LIBC_VERSION__ == 10602UL)
...

Ob jetzt v1.6.2 wirklich "10602" ist weiss ich nicht, kannst du dir aber 
ausgeben lassen ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&f...

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.