Guten Tag,
leider habe ich zu meinem Problem keine direkte Lösung gefunden. Daher
frage ich euch mal.
Seit kurzen arbeite ich mit dem internen EEPROM des ATmega32.
Hierbei habe ich mir dass verhalten mal angesehen,
speichere ich die Ziffer "A",
"eeprom_write_byte((uint8_t*)0,'A');"
wird sie nach alle 255 Bytes wiederholt, aslo 4x. Aus dem grund habe ich
versucht in einem Speicherbereich über 255 zu schreiben. - Warum? weil
ich später für ein Projekt den gesammten bereich benötige. -
Leider erfolglos, die Bytes bleiben unverändert. Vielleicht könnt ihr
mir hier etwas unter die Arme greifen. ^^
PS: Sprache: C auf AVR Studio 4. ich arbeite mit "eeprom.h" definiere
also - selber keine Register.
Liebe grüße
Umbrecht
Und jetzt sollen wieder alle ihre kaputten Glaskugeln auspacken oder
was.
zeig mal deinen Code wie du Daten ins EEPROM speicherst.
Wir sind doch keine hellseher!
#define F_CPU 8000000UL
#include <avr/io.h>
#include <avr/eeprom.h>
int main(void) {
eeprom_write_byte((uint8_t*)400,'A');
while(1) {
}}
So wie oben beschrieben, aber danke für deine aufmerksamkeit schon mal.
Statt "400" nutzte ich auch schon andere Zahlensysteme ( 0x190 ).
Umbrecht schrieb:> eeprom_write_byte((uint8_t*)400,'A');
Bist du sicher das die Parameterübergabe richtig ist?
sollte wohl eher so lauten wenn ich mich nicht irre:
eeprom_write_byte(400,'A'); Also EEprom-Adresse, Wert
Also
eeprom_write_byte( (uint8_t * ) 0x0190 ,'A');
Passt schon laut Simulator. Der 16Bit Wert wird hier ja geCastet.
Umbrecht schrieb:> Statt "400" nutzte ich auch schon andere Zahlensysteme ( 0x190 ).
Hier liegt der Fehler 0x190 wird interpretiert als 0x1900 und da bist
beim Zugriff weit über dem EEPROM Bereich.
Ab 0x0400 ist schluss.
Ärgert sich schrieb:> 0x190 wird interpretiert als 0x1900
Hüstel...
Nullen vorne dran darf der Compiler sich dazu denken, so viel er will,
aber hinten dran nicht. Und daher tut der das auch nicht.
0x0190 ist 0x000000190 ist 0x190 ist dez 400. Nix anderes.
Oliver
Ärgert sich schrieb:> Ab 0x0400 ist schluss.
Habe diesen Wert mal eingetragen also
"eeprom_write_byte((uint8_t*)0x400,'A');"
und den µC gestartet. Anschließend mit "AVR8 Burn-O-MAT V2" den EEPROM
als RAW format auf meinen PC kopiert.
Beim Durchsuchen des files fiel mir auf, dass das 'A' an erster stelle
in der datei steht. Liegt es dran, weil mit 1024 der bereich
überschritten ist?
Daraufhin habe ich "eeprom_write_byte((uint8_t*)0x3FF,'A');" Probiert
also 1023, hier habe ich wieder dass selbe problem, man findet das 'A'
nicht, es steht nicht in der Textdatei.
Was aber auch komisch ist, wenn ich die EEPROM datei umschreibe also auf
meine gewünschten Zeichen, kann ich es erfolgreich hochladen wenn ich
weniger als 256 Byte bzw. Ziffern verwendet habe. Brauche ich mehr kommt
immer ein Error, dass beim schreiben etwas schiefgelaufen ist.
Error: avrdude.exe: verification error, first mismatch at byte 0x0011
0xff != 0x71
avrdude.exe: verification error; content mismatch
Walter T. schrieb:> Du bist sicher, einen ATmega32 zu haben?
Als ich ihn bei Reichelt + 5 anderen gekauft habe stand "ATmega32" da,
auf dem Gehäuse des Prozessors steht ATmega32, ich vermute zu 10% dass
er es sein könnte.
Nein - spaß bei seite, er ist es sicher.
Fuses sind im Anhang, ich habe hier nichts verändert bis auf die Quarz
einstellungen.
@ Umbrecht (Gast)
>Hierbei habe ich mir dass verhalten mal angesehen,>speichere ich die Ziffer "A",>"eeprom_write_byte((uint8_t*)0,'A');"
Was soll das? In C kümmert sich der COMPILER um die Adressen der
Variablen!
>PS: Sprache: C auf AVR Studio 4. ich arbeite mit "eeprom.h" definiere>also - selber keine Register.
Also mach es so wie der Rest der Welt!
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM
Umbrecht schrieb:> auf dem Gehäuse des Prozessors steht ATmega32, ich vermute zu 10% dass> er es sein könnte.
Der Teufel ist ein Eichhörnchen.
Umbrecht schrieb:> Fuses sind im Anhang
BODEN und EESAVE wären schon einmal ein guter Anfang.
Falk B. schrieb:> Was soll das? In C kümmert sich der COMPILER um die Adressen der> Variablen!
Für das Hardkodieren von EEPROM-Adressen kann es auch unter C gute
Gründe geben. Z.B. um einen EEPROM-Dump aufs Display oder UART zu geben.
Und ich finde auch nichts, was dagegen spricht, außer den Komfort, den
die automatische Verwaltung der EEPROM-Adressen bietet.
Walter T. schrieb:> BODEN und EESAVE wären schon einmal ein guter Anfang.
Warum EESAVE? Hierdurch werden alle Bytes des EEPROM bei einem neuen
Programm upload auf 0xFF gesetzt - oder liege ich falsch?
Walter T. schrieb:> Für das Hardkodieren von EEPROM-Adressen kann es auch unter C gute> Gründe geben. Z.B. um einen EEPROM-Dump aufs Display oder UART zu geben.
Dass trifft es.. Mein fehler dass ich es nicht erwähnt habe - Sorry
Falk B. schrieb:> Was soll das? In C kümmert sich der COMPILER um die Adressen der> Variablen!
Das betrifft nur Flash und RAM, da diese vom Linker verteilt werden.
Beim EEPROM nimmt man aber oftmals eine feste Zuweisung, dann kann man
ihn auch über ISP oder Bootloader vorbelegen bzw. auslesen.
Umbrecht schrieb:> Guten Tag,>> leider habe ich zu meinem Problem keine direkte Lösung gefunden. Daher> frage ich euch mal.>> Seit kurzen arbeite ich mit dem internen EEPROM des ATmega32.> Hierbei habe ich mir dass verhalten mal angesehen,> speichere ich die Ziffer "A",>> "eeprom_write_byte((uint8_t*)0,'A');">> wird sie nach alle 255 Bytes wiederholt, aslo 4x.
Wie hast du das festgestellt?
Karl H. schrieb:> Wie hast du das festgestellt?
Ich habe den EEPROM mittels AVR Burn-O-Mat ausgelesen (im Programm die
funktion "Read" beim EEPROM).
In meinem Fall wird dann auf dem Desktop die datei "eeer" angelegt ohne
endung. Sorry für den Namen aber ich war einfallslos.
Diese öffne ich mit Notepadd++ und man kann alle 1024Byte lesen.
Gegebenfalls auch ändern und hochladen mit "Write" aber eben nur bis
Byte 256 danach kommt der Error.
Umbrecht schrieb:> Gegebenfalls auch ändern und hochladen mit "Write" aber eben nur bis> Byte 256 danach kommt der Error.
Was schon mal ein Hinweis darauf ist, dass irgendetwas hardwaremässig
nicht stimmt.
Es gibt keinen Grund, warum du beim Beschreiben des EEPROM einen Fehler
bekommen solltest. Von daher würde ich schon mal dem, was Burn-O-Mat aus
dem EEProm ausliest, nicht mehr über den Weg trauen.
Solange dein Brennprogramm weiss, dass es sich um einen Mega32 handelt,
musst du 1024 Bytes fehlerfrei ins EEPROM schreiben können. Egal welche
Werte. Solange das nicht der Fall ist, würde ich dem alles nicht über
den Weg trauen.
Denkst du dann eher ich sollte einen anderen ATmega32 testen oder ganz
weg von AVR Burno-O-Mat?
Eine Option die mir gerade einfällt, wenn ich z.b. die Adresse 500 des
EEPROM beschreibe, anschließend auslese mit eeprom_read_byte und über
den Uart oder LCD ausgebe. - Werde ich gleich mal ein Programm dafür
schreiben und testen
Karl H. schrieb:> Solange dein Brennprogramm weiss, dass es sich um einen Mega32 handelt,> musst du 1024 Bytes fehlerfrei ins EEPROM schreiben können.
aber nur von 0 bis 0x3ff oder 1023 , mich stören immer noch die vorher
genannten 0x400
Umbrecht schrieb:> Eine Option die mir gerade einfällt, wenn ich z.b. die Adresse 500 des> EEPROM beschreibe, anschließend auslese mit eeprom_read_byte und über> den Uart oder LCD ausgebe. - Werde ich gleich mal ein Programm dafür> schreiben und testen
Wahlweise das gesamte (mit Burnomat geschriebene) EEPROM mal auslesen
und über UART dumpen. Ist ja ein Wenigzeiler.
Umbrecht schrieb:> Warum EESAVE? Hierdurch werden alle Bytes des EEPROM bei einem neuen> Programm upload auf 0xFF gesetzt - oder liege ich falsch?
Neee, andersherum: Der EEPROM-Inhalt wird auch über ein Chip Erase
hinaus aufbewahrt.
Peter D. schrieb:> Das betrifft nur Flash und RAM, da diese vom Linker verteilt werden.> Beim EEPROM nimmt man aber oftmals eine feste Zuweisung, dann kann man> ihn auch über ISP oder Bootloader vorbelegen bzw. auslesen.
Genau das geht auch bei Verwaltung durch den Compiler komfortabel.
uint16_t EEMEM beispiel = 42;
im Source.
Compiler vergibt eine Adresse im Eeprom, Makefile erzeugt passend ein
.eep - HEX-File, avrdude - Aufruf im Makefile kann das eeprom
automatisch beschreiben.
Klappt auch mit vorbelegten Structs, Arrays usw. im EEMEM.
Also, vom ATmega32 funktioniert alles einwandfrei, ich habe ein 'A' in
die Adresse 0x3FF geschrieben und lese sie aus. Zusätzlich auch noch die
Adressen 0x3FE, 0x400 um sicher zu gehen. Herauskommt dass 'A' und 2
Werte mit 255 - was soweit richtig ist.
Was aber nun blöd ist, dass irgendwas mit dem AVR Burn-O-Mat nicht
stimmt..
Soweit schon mal danke für die Hilfe! ^^
Hi
>aber nur von 0 bis 0x3ff oder 1023 , mich stören immer noch die vorher>genannten 0x400
Warum? Damit landet man einfach wieder auf Adresse 0.
MfG Spess
Planlos schrieb:> Peter D. schrieb:>> Das betrifft nur Flash und RAM, da diese vom Linker verteilt werden.>> Beim EEPROM nimmt man aber oftmals eine feste Zuweisung, dann kann man>> ihn auch über ISP oder Bootloader vorbelegen bzw. auslesen.>> Genau das geht auch bei Verwaltung durch den Compiler komfortabel.>> uint16_t EEMEM beispiel = 42;>> im Source.
Das löst das Problem nicht, welches Peter anspricht.
Gerade beim EEPROM will man die Adressen kontrollieren können. Ganz
speziell will man das zb, wenn sich von einer Linkerversion zur nächsten
die Adresszuordnung ändert, du aber einen bereits benutzten AVR mit
intakten Daten im EEPROM auf eine neue Programm Version updaten musst
und zwar ohne dass es beim Lesen aus dem EEPROM zu Datensalat kommt.
Und ja: das hat es schon gegeben, dass eine neuere GCC Version die
Adressvergabe anders gelöst hat.
spess53 schrieb:> Hi>>>aber nur von 0 bis 0x3ff oder 1023 , mich stören immer noch die vorher>>genannten 0x400>> Warum? Damit landet man einfach wieder auf Adresse 0.
Ist die Frage, was der Burn-O-Mat mit der ungültigen Adresse macht.
Aber: im Originalposting war ja von der Adresse 0 die Rede. Die 0x400
sind ja erst später aufgetaucht.
Umbrecht schrieb:> Zusätzlich auch noch die> Adressen 0x3FE, 0x400 um sicher zu gehen.
Das ist Quark, die unterscheiden sich doch im Low-Byte.
Schreibe auf 0x3FF und lies auf 0xFF, 0x1FF, 0x2FF, 0x3FF aus.
Da hast du natürlich recht ^^
Dass Ergebniss stimmt, nur bei 0x3FF kommt der gespeicherte wert.
Habe den burnomat mal auf einem anderen Gerät getestet, hier habe ich
den selben Fehler..
