Hallo
Ich möchte bei einem ATtiny25 das EEPROM lesen und
schreiben - lesen geht, aber das Schreiben funktioniert nicht...
1
cli();
2
// --- read ---
3
while(EECR&(1<<EEPE));// wait for previous write access
4
EEAR=0x07;// ee size = 128' => HByte not needed
5
EECR|=(1<<EERE);// start read
6
EEByte=EEDR;// read ee data register
7
// --- write ---
8
EEByte=0x88;
9
while(EECR&(1<<EEPE));// wait for previous write access
10
EECR=(0<<EEPM1)|(0<<EEPM0);// set programming mode
11
EEAR=0x08;// ee size = 128' => HByte not needed
12
EEDR=EEByte;// write byte @ address
13
EECR|=(1<<EEMPE);// master prog. enable
14
EECR|=(1<<EEPE);// start write
15
16
sei();
Die C-Code-Zeilen sind genau so, wie sie im µC-Handbuch stehen. Gibt es
irgendwo einen "Trick", etwas, was ich vergessen oder übersehen habe
(Interrupts sind ja schon disabled)? Ich habe gestern den ganzen Tag
nach dem Fehler gesucht, hier in den Foren, via Google usw...
Danke schon mal für Eure Hilfe.
Hallo,
zeig doch mal den "ganzen Code". Noch besser, um irgendwelche
Seiteneffekte deiner Programmierung auszuschließen, leg schnell ein
neues Projekt an, Startpunkt dafür kann gerne ein Beispiel-Projekt von
Atmel zum Thema Eeprom sein. Dann damit die Funktion des Eeproms
überprüfen. Dann Vergleich dein Programm <-> Atmel-Beispiel, daraus
ableiten wo hängt's:)
Gruß Jonas
Hallo Jonas
Werd ich gleich mal machen - meine Original-SW hat einen RT-Scheduler,
verwendet ADC usw. mit den entsprechenden WinAVR-Includes. Ich werde
gleich mal tatsächlch alles rausschmeißen und nur die paar EEPROM-Zeilen
testen.
Michael
So, nun ist der gesamte Code auf ein Minimum reduziert. Anbei ein
Screenshot vom Simulator inkl. Quellcode + Assembler / List-File...
Funktioniert genausowenig wie vorher - lesen geht, schreiben nicht.
@ Joachim:
Auf der Zielhardware konnte ich es noch nicht ausprobieren - die erste
SW-Version ging nicht, aber da können auch noch andere Fehler drin
gewesen sein - war nur ein Schnellschuß.
Wenn ich Dein Simulatorergebnis sehe: Ist eindeutig, bei Dir
funktioniert es.
Ich habe AVR-Studio 4.14 mit WinAVR-20100110. Könnte es an irgendwelchen
Simulatoreinstellungen liegen? Welche wären da ggf. relevant?
Ich such mal, ob es bei Atmel zu Studio 4 eine Versionshistory gibt und
was sich zwischen 4.14 und 4.19 geändert hat.
@ Peter:
Es ist tatsächlich nur genau der C-Code, der weiter oben im Screenshoot
zu sehen ist, kein h-File. Hier nochmals als ASCII-Datei.
Ich schau mir gleich Dein Beispiel an - aber viel einfacher, als das aus
dem µC-Handbuch geht es ja fast gar nicht...
@ Peter:
Vielleicht nicht gerade unsinnig, aber auch nicht hilfreich: Geht mit
genausowenig wie ohne...
@ Joachim:
Ich finde keine Versionshistory, aber ich lade die V19 gerade bei Atmel
runter - ist immerhin drei Jahre jünger, vielleicht ist es tatsächlich
ein Simulatorproblem.
tippex schrieb:> EECR = (0<<EEPM1) | (0<<EEPM0); // set programming mode
Was bewirkt diese Zeile? Was passiert, wenn man eine NULL schiebt (mit
etwas multipliziert oder dividiert)?
> Die C-Code-Zeilen sind genau so, wie sie im µC-Handbuch stehen
Du solltest den Autor züchtigen, 5 Peitschenhiebe.
Hallo Stefan
Kannst Du mir das erklären? Welche O-Stufe sollte ich wählen? Gilt das
für Simulator und Ziel-HW gleichermaßen?
Ich arbeite üblicherweise mit O0 oder O1 - O1 als optimaler Kompromiß
zwischen Speicherplatz und Simulatorfähigkeit. Habe mit dem Beispiel
bislang nur O0 probiert, werde jetzt mal alle Optimierungsstufen
durchprobieren.
Bevor ich V4.19 installiere...
@ Stefan:
Wie gehabt: o0 + o1 gehen im Simulator nicht. Überraschung: o2, o3 + os
funktionieren. Alles noch mit V4.14 . Wie sieht es (voraussichtlich) auf
der Zielhardware aus und was steckt dahinter? Timing, in wiefern?
Alles über o1 hat aber den Nachteil, daß wegen der Optimierung
C-Sourcecodezeilen im Simulator nicht mehr mit dem ASM- / Listfile
übereinstimmen, d.h. die C-SW nicht mehr 1:1 zeilenweise simuliert
werden kann.
@ Joachim:
Welche Optimierungsstufe hast Du mit Deiner V4.19 verwendet?
tippex schrieb:> Wie sieht es (voraussichtlich) auf> der Zielhardware aus
Genauso.
tippex schrieb:> was steckt dahinter? Timing, in wiefern?
1
When EEMPE is set, setting EEPE within four clock cycles will
2
program the EEPROM at the selected address.
tippex schrieb:> Alles über o1 hat aber den Nachteil, daß wegen der Optimierung> C-Sourcecodezeilen im Simulator nicht mehr mit dem ASM- / Listfile> übereinstimmen, d.h. die C-SW nicht mehr 1:1 zeilenweise simuliert> werden kann.
Warum willst du überhaupt eigene EEPROM-Routinen verwenden?
Benutze doch einfach <avr/eeprom.h>, dann hast du auch kein Problem mit
der Optimierung.
tippex schrieb:> Vielleicht nicht gerade unsinnig
Doch.
Unsinnig ist es, weil der Autor sich überhaupt nichts dabei gedacht hat.
Es setzt reservierte Bits, obwohl das Datenblatt 0 empfiehlt.
Und es enabled den EEPROM-Interrupt ohne einen Handler.
Jede Codezeile muß eine Absicht haben, sonst ist sie unsinnig.
tippex schrieb:> Ich arbeite üblicherweise mit O0 oder O1
Das erklärt es.
Ohne Optimierung werden alle Operation auf 16Bit aufgebläht und dann
können die 4 Zyklen nicht mehr eingehalten werden.
Mit -O0 hast Du etwa doppelten Code, doppelten RAM-Verbrauch und
doppelte Laufzeit.
Ich arbeite ausschließlich mit -Os. Warum Ressourcen absichtlich
verschwenden.
Peter
Hallo Leute
So, AVR-Studio V4.19 installiert, Toolchain, usw., dreimal kurz vorm
Nervenzusammenbruch, zwischenzeitliches Microschrott-Trauma - das
übliche halt. Jetzt läuft alles wieder...
Das mit der Compileroptimierung leuchtet mir jetzt ein - man sieht es,
wenn man die verschiedenen Listfiles bei unterschiedlichen
Optimierungsstufen ansieht. Und ab Optimierungsstufe -o2 läuft es jetzt
- im Simulator.
Danke @ ALL ;-)
Werde das ganze jetzt im Kontext der Gesamt-SW ausprobieren, dann auf
der Zielhardware - und dann hier nochmals das Ergebnis posten.
Nochmals Danke
Michael
So, jetzt noch schnell das abschließende Update: Funktioniert genau so,
das Problem waren die Compiler-Optimierungslevel in Bezug auf das
erforderliche EEPROM-Timing.
Danke für die Hilfe.
