ATTiny85 und avrdude: EEPROM auslesen nur jedes zweite Byte

Meine Glaskugel sagt, daß Du als "byte" int16 definiert hast.

Code in Prosa, wie kommt man nur darauf?
Glaskugel sagt, Du speicherst als int.

Hallo zusammen,

es geht hier gar nicht um den Code. Wie gesagt: Die Daten werden korrekt 
ins EEPROM geschrieben, korrekt ausgelesen und neu geschrieben (jeweils 
mit LED überprüft). Was nicht klappt, ist das Auslesen mittels avrdude.

Ich programmiere in Assembler, habe also keine Probleme mit den 
Datentypen...

Viele Grüsse,
Simon

Simon E. schrieb:
> Ich programmiere in Assembler, habe also keine Probleme mit den
> Datentypen...

Na gut, dann schau Dir mal Zeile 42 an.

...und in welchem Format wird denn in den EEPROM geschrieben?

1 Byte?? Oder 2 Byte??

Fragen über Fragen - die alle hier schon gestellt wurden, nur mit 
anderen Worten. Und mit dem avrdude hat das erstmal herzlich wenig zu 
tun.

Problem gelöst - danke an S. Landolt für den entscheidenden Hinweis!

Fürs Protokoll: Ich lag mit meiner Analyse daneben, der avrdude 
funktioniert einwandfrei. Asche auf mein Haupt und ja, es wäre schneller 
gegangen, wenn ich den Code einkopiert hätte... auch wenn ich nach wie 
vor nicht weiss, was genau logisch/mathematisch falsch war. Hab eine (in 
meinen Augen funktional identische) Alternative ausprobiert und 
schwupps, klappt alles.

Vielleicht weiss das ja jemand? (Diesmal mit Code.)

Ich habe in r17 den Wert, der ins EEPROM soll, in r18 und r19 die 
low/high-Bytes der Adressen (und nein, sie sind nicht vertauscht).

Ich inkrementiere die Adresse in jedem Schritt so (Snippet aus dem alten 
Code):

1

ldi r16, 0   ; dummy zero for adding with carry

2

inc r18      ; low byte ==> das ist offenbar schon ein Fehler, weil inc kein Carry setzt (laut Datenblatt nur Z,N,V), aber da ich nur von 0-200 zähle, sollte ein nicht gesetztes Carry keinen Unterschied machen (hätte ich gedacht). Falsch ist es trotzdem. Sollte subi r18, -1 sein, denke ich.

3

adc r19, r16 ; high byte, add carry

Das führt dazu, dass jedes ZWEITE Byte an die richtige Stelle im EEPROM 
geschrieben wird und jedes ANDERE ZWEITE Byte sehr viel weiter hinten 
(oberhalb von Position 256, nicht exakt - die genaue Stelle weiss ich 
nicht mehr). r18/r19 scheinen also immer hin und her zu springen. Ich 
verstehe nicht warum.

Alternativ hab ich folgendes probiert, das einwandfrei funktioniert:

1

  ldi ZH, 0  ; low(EEPROM address)

2

  ldi ZL,  0 ; high(EEPROM address)

3

  ldi r17, 1 ; Data to be written to EEPROM

4

5

  ; Write data to first 200 bytes in EEPROM

6

  DLoop1:

7

    rcall EEPROM_write  ; Write r17 to EEPROM address H:L r19:r18

8

    adiw Z, 1           ; Increment address

9

    mov r18, ZL

10

    mov r19, ZH

11

    inc r17             ; Increment data to be written

12

    cpi r17, 200        ; Stop after 200 writes

13

    brne DLoop1

14

15

  ; Verify data in first 200 bytes of EEPROM by reading them and writing them to second 200 bytes

16

  ldi r20, 200

17

  ldi ZH, 0 ; Reset EEPROM address

18

  ldi ZL, 0

19

  DLoop2:

20

    mov r18, ZL

21

    mov r19, ZH

22

    rcall EEPROM_read   ; Read EEPROM data from H:L r19:r18 into r17

23

24

;    rcall DEBUGr17 ; Ausgabe von r17 (Data von EEPROM) als Blinken auf LED

25

26

    adiw Z, 50          ; Go to address x+200 - adiw accepts only values <60??? Found nothing about this in datasheet.

27

    adiw Z, 50          ; Go to address x+200

28

    adiw Z, 50          ; Go to address x+200

29

    adiw Z, 50          ; Go to address x+200

30

    mov r18, ZL

31

    mov r19, ZH

32

    rcall EEPROM_write  ; Store r17 here

33

34

    sbiw Z, 49          ; Increment to next address

35

    sbiw Z, 50

36

    sbiw Z, 50

37

    sbiw Z, 50

38

    dec r20             ; Count down, do this 200x

Nach dieser Erkenntnis wäre es vermutlich sinnvoll, wenn ich meinen 
EEPROM_write und EEPROM_read auf die Nutzung von ZH/ZL umschreiben 
würde, dann spar ich mir die Kopiererei...

Weiss jemand, wo das mit der Werte-Obergrenze beim adiw dokumentiert 
ist?

Viele Grüsse,
Simon

Stimmt. Danke!