Hallo allerseits, kürzlich hatte ich die Idee, ein Microwire-EEPROM 93AA86C (immer im 8-Bit-modus) zur Mikrocontroller-Schaltung (Mega162 mit AVR-GCC) dazu zu bauen, um dort z.B. den Font für ein Grafik-LCD zu speichern. Quelle war dieses Datenblatt hier: http://www.microchip.com/wwwproducts/en/93AA86C http://ww1.microchip.com/downloads/en/DeviceDoc/21797L.pdf Die Umsetzung gelang mir nur teilweise. Es wird ins EEPROM geschrieben, aber beim Lesen erscheint immer nur der halbe Wert der Zahl, die zuvor gespeichert wurde, und die nächste halbe Zahl erscheint erst im übernächsten Zyklus. Somit muß also im Ablauf oder bei der Deklaration meiner Variablen etwas schief gegangen sein. Es gibt da eine besondere Eigenschaft beim Lesen: "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." Wenn nun ein zusätzlicher SPI-Zugriff erfolgt und erst das nächste Byte ausgewertet wird, stimmt es auch nicht. Falls ich eine zusätzliche Taktflanke vor dem Lesen einfüge, stimmt es auch nicht. Zusätzlich fällt beim Betrachten des Signalverlaufs auf dem Oszilloskop auf, daß der Ausgang des EEPROMs genau dann high wird, um "ready" anzuzeigen, wennn das erste Bit des Lesebefehls gegeben wird. Während des Befehls wird der Ausgang dann low und bringt am Ende die zu lesenden Bits raus. Also stmmen die Abläufe nicht. Diese "ready/busy" - Abfrage ist in irgendeiner Appnote nochmal ein eigenes Kapitel. "Data Out (DO) is used in the Read mode to output data synchronously with the CLK input (TPD after the positive edge of CLK). This pin also provides Ready/Busy status information during erase and write cycles. Ready/Busy status information is available on the DO pin if CS is brought high after being low for minimum Chip Select low time (TCSL), and an erase or write operation has been initiated. The Status signal is not available on DO if CS is held low during the entire erase or write cycle. In this case, DO is in the High-Z mode. If status is checked after the erase/write cycle, the data line will be high to indicate the device is ready. Note: After a programming cycle is complete, issuing a Start bit and then taking CS low will clear the Ready/Busy status from DO." In meinem Programm ist CS die ganze Zeit high während des Schreibzugriffs. Oder ist da die Wartezeit noch mit eingeschlossen? Und danach soll man noch den Staus entsperren, indem man ein einzelnes Bit ausgibt? Kann mir da mal bitte jemand helfen, die Korrekturen zu finden? mit freundlichem Gruß
Christian S. schrieb: > um dort z.B. den Font für ein Grafik-LCD zu speichern Die haben doch nur 2kB, das wird knapp. Nimm besser den AT24C512 (I2C) oder AT25F1024 (SPI). Die uralten 93-er EEPROM haben ein ziemlich verqueres Timing, die Umschaltung von Schreiben auf Lesen braucht einen Takt. Ich hatte es damals komplett mit Bitwackeln gemacht, d.h. ohne SPI.
Hallo, mein erster Anlauf war auch mit Bitwackeln, aber komplett erfolglos. Die 1024er setze ich mal auf meine Wunschliste. MfG
Hallo, habe mit das Progrämmlein nochmals vorgenommen. Das Lesen funktioniert inzwischen korrekt. Auch die Abfrage der Busy-Zeit von 3,45 ms am Pin4 funktioniert. Beim Lesen habe ich nach den beiden Bytes zur Adressübertragung das Spi abgeschaltet, einen Taktpuls eingefügt, Spi wieder eingeschaltet und dann das Datenbyte eingelesen. Ist etwas ungewöhnlich, funktioniert aber. Es erscheint nicht mehr nur die Hälfte des Wertes. MfG
Christian S. schrieb: > Das Lesen funktioniert inzwischen korrekt. Auch die Abfrage der > Busy-Zeit von 3,45 ms am Pin4 funktioniert Wenn du nun noch einen Beispielcode hättest hilft das später vielleicht auch jemand anderem ;)
Hallo, anbei der gewünschte verbesserte Code. Man kann es sicher noch eleganter Lösen, aber bei mir funktioniert es so. Diente zu Übungszwecken. Die Namen in beiden Dateien sind ungeeignet, um ohne Änderungen in einem einzigen Programm angewendet zu werden. mit freundlichem Gruß
Christian S. schrieb: > Beim Lesen habe ich nach den beiden Bytes zur Adressübertragung das Spi > abgeschaltet, einen Taktpuls eingefügt, Spi wieder eingeschaltet und > dann das Datenbyte eingelesen. Für das 93C66 habe ich es vor einigen Jahren so implementiert, dass ich das erste gesendete Byte des Lesebefehls einfach um ein Bit nach links geschoben habe. Nicht umsonst tituliert der Hersteller das erste Kommando-Bit als Start-Bit. Führende Nullen werden offensichtlich vom EEPROM ignoriert, so dass das Kommando auch gültig ist, wenn das erste Datenwort nur 7 Bits besitzt. Grüßle Volker
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.