asm Code für EEPROM 93C86

[Bruno M. (brumay)]

Hallo,
ich versuche ein EEPROM 93C86 (Datenblatt im Anhang) mit einem ATMega16 
auszulesen und habe mir dafür einen asm Code gebastelt (siehe Anhang).

Leider stimmen Ein- und Ausgabe nie überein. Jetzt weiß ich nicht, ist 
das EEPROM defekt oder liegt es an meinem Code.

Kann jemand helfen?

[Christian S. (roehrenvorheizer)]

Hast Du das dumme Zerobit beachtet?

"A dummy zero bit precedes the 8-bit (If ORG pin is low or A-Version 
devices) or 16-bit (If ORG pin is high or B-version devices) output 
string."

MfG

[Bruno M. (brumay)]

> Hast Du das dumme Zerobit beachtet?

Eigentlich müßte es damit erschlagen sein:

read:                  ;READ
  ldi    Flag, 0x02
  rcall   opcode            ;opcode 10
  rcall  address            ;Adresse ist vorgegeben
  ldi    temp, 2
  mov    cnt, temp          ;2 bytes je Adresse
  !! rcall  Takt !!
read_loop:
  rcall  read_byte

d.h. ein Takt vor der eigentlichen Leseroutine

[S. Landolt (Gast)]

Sehe ich das richtig, dass in §address 9 Adressbits ausgegeben werden - 
warum nicht 10?

[... (Gast)]

Mit einem PICkel waer das nich passiert.
Da tuts der Code von Mikrotschip.

[Bruno M. (brumay)]

> warum nicht 10?

Du stellst aber schwierige Fragen! Ich habe keine Ahnung warum da 9 
steht. Das habe ich natürlich sofort geändert. Leider hat sich am 
Ergebnis nichts geändert. Ich bekomme immer nur 0xFFFF

[S. Landolt (Gast)]

Ich kann aus dem Datenblatt nicht herauslesen, dass das 'chip deselect' 
nach §writeall_exit zulässig ist, würde also, zumindest vorläufig, statt 
der Abfrage auf Ready/Busy einfach ein rcall WAIT_50ms anfügen.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

> Ich bekomme immer nur 0xFFFF
Das ist typischerweise der Inhalt bei leeren EEPROMs. Kann also sein, 
daß schon das Schreiben schiefgeht.

Ich muß mal schauen ob ich noch ein Fetzen Code für 93C EEPROMS habe.

Edit:
Du kannst es mal damit probieren. Das habe ich mal benutzt um diese 
EEPROMS aus Motorsteuergeräten auszulesen, der Code ist nicht sonderlich 
optimiert. Die Delays musst Du Dir selber bauen, die waren auch sehr 
konservativ ausgelegt, da mir Geschwindigkeit bei den paar Bytes 
unwichtig war.

[Bruno M. (brumay)]

> Ich kann aus dem Datenblatt nicht herauslesen, dass das 'chip deselect'
> nach §writeall_exit zulässig ist

Sorry für die Verwirrung. Ich muß gestehen, daß ich mir dieses 
Datenblatt nicht so genau angesehen habe, da ich davon ausgegangen war, 
daß sie alle gleich sind. Mein EEPROM entspricht dem anliegenden 
Datenblatt und das unterscheidet sich genau in diesem Punkt.

Mir ist aber auch nicht ganz klar, was passiert wenn ich §writeall nutze 
und dann nur 2 bytes übergebe, wie ich es gemacht habe. Entscheidend ist 
es aber nicht, da sich §write genau so verhält.


> Du kannst es mal damit probieren

Vorab schon mal danke, aber das muß ich erst verdauen.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Mach mit Ruhe. Wie gesagt das ist ein Quick'n'Dirty-Ansatz, der nichts 
weiter können mußte, um diese 93C56-EEPROMs zu lesen und zu beschreiben. 
Wenn die 256 Byte oder wieviel das waren dabei 10 Sekunden dauern, dann 
ist das halt so. Da gibts bestimmt viel Optimierungspotential und es 
kann auch sein, daß für die Adressierung der großen 93C-Typen noch ein 
oder zwei Adressbits hinzugefügt werden müssen. So genau habe ich das 
Protokoll jetzt nicht mehr im Kopf. Um die Methodik zu erkennen oder 
dieses Write-Enable (EWEN) sollte es aber reichen.

[Bruno M. (brumay)]

Hallo Ben,

in der Zwischenzeit habe ich deinen Code auf meine Verhältnisse angepaßt 
(siehe Anlage) und siehe da, es funktioniert. Allerdings noch mit einem 
kleinen Schönheitsfehler. Das erste gelesene Byte ist OK, aber beim 
zweiten sind die 2 LSBs immer 11, egal welche Adresse ich wähle und 
welchen Wert ich reinschreibe.
Ich habe schon alles mögliche versucht, komme aber nicht dahinter.
Kannst du dir vorstellen, woran das liegt?

[Bruno M. (brumay)]

Noch ein Nachtrag:
Wenn ich z.B. 3 Adressen 3 mal nacheinander schreibe, bekomme ich 
folgende Ausgaben:

10101010 10101011 ; 10010010 10010011 ; 00100100 00100111
10101010 10101000 ; 10010010 10010011 ; 00100100 00100111
10101010 10101001 ; 10010010 10010011 ; 00100100 00100111

wobei das erste Byte immer korrekt ist.

[S. Landolt (Gast)]

Zur Abwechslung mal eine vielleicht dumme Frage: an welcher 
Programmstelle wird dieses "dummy zero bit" abgehandelt? Ich finde sie 
nicht.

[Bruno M. (brumay)]

> Zur Abwechslung mal eine vielleicht dumme Frage: an welcher
> Programmstelle wird dieses "dummy zero bit" abgehandelt? Ich finde sie
> nicht.

Wie heißt es so schön: Dumme Fragen gibt es nicht!

Am Code von Ben habe ich nur das unbedingt Nötige geändert. Ich habe 
daher auch zum zero bit nichts eingefügt. Trotzdem wird aber anscheinend 
richtig gelesen??

In meinem Code, mit dem ich ebenfalls lesen kann, hatte ich ja vor der 
Leseroutine einen Takt eingefügt. Wie ich aber festgestellt habe, reicht 
das nicht. Ich habe daher wie folgt geändert:

read_byte:
  clr    Dat_low
  ldi    temp, 8
  mov    cnt1, temp
  rcall  Takt
  rcall  WAIT_1ms
  in    temp, PinA        ;Zero bit
read_byte_loop:                
  rcall  Takt
  rcall  WAIT_1ms
  in    temp, PinA
  andi  temp, 8            ;Wert DO Pin
  lsr    temp            ;zum LSB verschieben
  lsr    temp
  lsr    temp
  or    Dat_low, temp        ;Daten übernehmen
  dec    cnt1
  tst    cnt1
  breq  read_loop_exit
  lsl    Dat_low            ;nach links verschieben für nächsten Wert
  rjmp  read_byte_loop  
read_loop_exit:
ret
read_exit:
  cbi    PORTA, CS
ret

[S. Landolt (Gast)]

Vorab: ich habe kein solches EEPROM, kann mich folglich nur auf das 
stützen, was Sie liefern, also die beiden Datenblätter und Ihr Programm.

Bei Letzterem nehme ich die aktuelle Version, also die von Ben 
Stromkraft abgeleitete, und da sehe ich nichts von "dummy zero bit"; es 
gibt dort auch kein Label read_byte, also ist mir unklar, wie&wo ich den 
zuletzt gezeigten Programmteil einfügen soll; falls sich dies aber auf 
Ihre ursprüngliche Version bezieht, nun, die hat ja offenbar gar nicht 
funktioniert.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Hast Du daran gedacht, daß der 93C86 zwei Adressbits mehr braucht als 
die kleineren 93C56? Muss mir Deinen Code mal durchlesen, aber testen 
kann ich ihn im Moment nicht.