Hallo ihr Experten, Ich habe folgendes Anliegen: Ich möchte eine kleine Menge Daten in einem EEPROM ablegen und bei Bedarf wieder auslesen. So weit, so gut. Nachdem klar war, dass es ein SPI-EEPROM sein muss, hat sich die Frage gestellt, welcher Typ es denn sein soll. Zuerst ist mir ein M93C66 (1kb hielt ich für ausreichend) über den Weg gelaufen, aber der schiebt laut Datenblatt zuerst ein Dummy-Bit heraus, welches verworfen werden muss. Für mich zuviel Frickelei, auch wenn es vielleicht einen ganz speziellen Grund für dieses Verhalten gibt (wäre mal interessant zu wissen warum das so ist). 1kb war mir dann doch etwas zu wenig, also weiter geschaut. Als nächstes hielt ich einen M95040 (4kb) für die richtige Wahl, bis mir beim genaueren Betrachten des Instruction-codes aufgefallen ist, dass das 8. Adressbitt (A8) mitten im instruction-code untergebracht ist (Datenblatt Abschnitt 4.5). Also im höherwertigen Byte von rechts das 3. bit, rechts steht dann das niederwertige Adressbyte! Warum, bitteschön, macht man so etwas? Es ist mir absolut schleierhaft, warum man so umständlich das Befehlsbyte konstruieren muss, nur um eine Speicherzelle zu adressieren. Der M95080 (8kb) zeigt dieses Verhalten nicht, dort kann man ganz gesittet die Bits für den Instruction-code hineinschieben und anschließend die Adressbits. Thema ohne Verrenkungen erledigt. Mir wäre es ganz recht, wenn mir jemand zwei Fragen beantworten kann: 1. Warum wird das so umständlich implementiert? 2. Wir würdet ihr den Befehlscode erzeugen, bzw. das Dummy-Bit beim erstgenannten Bauteil behandeln?
1. selbst wenn das Bit im instruction-code liegt, ist das mit einem einfachen "logischen oder" erledigt 2. der Erste hat keine SPI, sondern eine MICROWIRE Schnittstelle
Das ist irgendwie, ne? schrieb: > Nachdem > klar war, dass es ein SPI-EEPROM sein muss, warum war das klar? Die gibt es natürlich, sind aber heute für Neuentwicklungen eigentlich nicht mehr üblich. Da nimmt man eigentlich entweder für kleinste Datenmengen (paar kB) I2C-EEPROM, für etwas größere (bis ein paar MB) SPI-NOR-Flash und für deutlich größere (GB) dann eMMC mit gemanagetem NAND-Flash. > 2. Wir würdet ihr den Befehlscode erzeugen, bzw. das Dummy-Bit beim > erstgenannten Bauteil behandeln? In einer Treiberfunktion in Deinem Code, die die Bits setzt bzw. entfernt?
Das ist irgendwie, ne? schrieb: > ist). 1kb war mir dann doch etwas zu wenig, also weiter geschaut. Als > nächstes hielt ich einen M95040 (4kb) für die richtige Wahl, bis mir > beim genaueren Betrachten des Instruction-codes aufgefallen ist, dass > das 8. Adressbitt (A8) mitten im instruction-code untergebracht ist > (Datenblatt Abschnitt 4.5). Also im höherwertigen Byte von rechts das 3. > bit, rechts steht dann das niederwertige Adressbyte! Warum, bitteschön, > macht man so etwas? Es ist mir absolut schleierhaft, warum man so > 1. Warum wird das so umständlich implementiert? > 2. Wir würdet ihr den Befehlscode erzeugen, bzw. das Dummy-Bit beim > erstgenannten Bauteil behandeln? Was ist daran unverständlich? Man wollte halt ein Byte einsparen. Und kompatibel zum Vorgänger bleiben. Solange man nur die halbe Kapazität ausnutzt, ist die Ansteuerung absolut identisch mit dem 256 Byte EEPROM. Dasselbe Spielchen bei I2C-EEPROMs, da werden bis zu 3 Adressbits in die I2C-Busadresse hineingepackt. Und erst, wenn man vier braucht, wird ein ganzes zusätzliches Adressbyte eingefügt. Was macht man bei einem uP mit nur 16-Bit Adressbus, wenn man mehr als 64kByte haben möchte? Man klebt halt ein Bankregister dran und wurschtelt mit irgendeiner mehr oder weniger komplizierten Verwaltung herum. Wenn es irgendwo eng wird, kommt halt immer eine mehr oder minder komplizierte Extrawurst dran, statt einen klaren Schnitt zu machen. Typisch pragmatische Lösung.
A. B. schrieb: > Dasselbe Spielchen bei I2C-EEPROMs, da werden bis zu 3 Adressbits in die > I2C-Busadresse hineingepackt. Und erst, wenn man vier braucht, wird ein > ganzes zusätzliches Adressbyte eingefügt. Ich glaube, das hast du falsch verstanden. Adressbits in der I²C Busadresse adressieren nicht den Speicher in einem solchen IC, sondern erlauben es, mehrere dieser EEPROMs am gleichen I²C Bus zu haben. Jedes dieser EEPROMs hat dann z.B. drei Adress-Pins, die man fest(!) beschalten muß und reagiert nur dann auf I²C Nachrichten, wenn die darin enthaltene Adresse mit der extern eingestellten Adresse übereinstimmt.
Fuer ein, zwei kByte nimmt man doch das welches im Controller schon eingebaut ist. Und fuer Externes, nur SPI, denn I2C oder dergleichen ist nur noch muehsam. Es gibt allerdings I2C EEPROMs welche noch zusaetzliche Funktionalitaet eingebaut haben. zB eine Serienummer.
Da ich mit EEPROMs schon ein paar unschöne Dinge erlebt hab (Daten verändert durch Spannungsschwankungen) nehme ich nur noch FRAMs.
Crazy H. schrieb: > Da ich mit EEPROMs schon ein paar unschöne Dinge erlebt hab Muss wohl eher am Benutzer und seinen hervorragenden Schaltungen gelegen haben. Denn ich kenne den Einsatz von tausenden von EEPROMs in professionellen Geräten. Und dort zeigen sich Ausfälle von EEPROMs so marginal wie bei allen anderen digitalen Kleinbauteilen auch.
Axel S. schrieb: > A. B. schrieb: >> Dasselbe Spielchen bei I2C-EEPROMs, da werden bis zu 3 Adressbits in die >> I2C-Busadresse hineingepackt. Und erst, wenn man vier braucht, wird ein >> ganzes zusätzliches Adressbyte eingefügt. > > Ich glaube, das hast du falsch verstanden. Adressbits in der I²C Nein, das habe ich schon richtig verstanden. Man muss halt nur mal die Datenblätter lesen ... > Busadresse adressieren nicht den Speicher in einem solchen IC, sondern > erlauben es, mehrere dieser EEPROMs am gleichen I²C Bus zu haben. Jedes > dieser EEPROMs hat dann z.B. drei Adress-Pins, die man fest(!) > beschalten muß und reagiert nur dann auf I²C Nachrichten, wenn die darin > enthaltene Adresse mit der extern eingestellten Adresse übereinstimmt. Dazu empfehle ich ein bisschen Lektüre: M24C08 (nur ein Adress-Pin, A8 und A9 in der Bus-Adresse), M24M01 (nur zwei Address-Pins, A16 in der Bus-Adresse), M24M02 (nur ein Adress-Pin, dafür A16 und A17 in der Bus-Adresse). Datemblätter z. B. bei www.st.com. Oder http://openocd.zylin.com/#/c/4760/6/tcl/board/cmi2c_nucleo-g071rb.cfg, Zeilen 185-193, der vorletzte Parameter gibt jeweils an, wieviele Adress-Bits in die I2C-Busaddresse "hineingemogelt" werden.
Joggel E. schrieb: > Fuer ein, zwei kByte nimmt man doch das welches im Controller schon > eingebaut ist. Aber nicht jeder Controller hat EEPROM, das ist eher eine aussterbende Art. Man kann natürlich auch den Flash dafr missbrauchen, mache ich jedoch äußerst ungern. Gerd E. schrieb: > Die gibt es natürlich, sind aber heute für Neuentwicklungen eigentlich > nicht mehr üblich. Völliger Blödinn. Manchmal ist - stell dir vor - designtechnisch eine SPI Schnittstelle auf der Leiterplatte super zu erreichen, wohingegen die I²C Pins sich am anderen Ende befinden und nur über Umwege zu erreichen sind oder sogar alle schon belegt.
Wenn das hier nur um die Befürchtung der zu schwierigen Ansteuerung geht, auf github gibt es für jeden EEPROM Typ fertigen Code. Z.B. so etwas: https://github.com/firebull/STM32-EEPROM-SPI
pegel schrieb: > warum kein I2C EEPROM? Gerd E. schrieb: >> Nachdem >> klar war, dass es ein SPI-EEPROM sein muss, > > warum war das klar? Weil ich an mehreren Stellen in der Schaltung auf ein EEPROM schreiben muss. Die kann ich per SS anwählen. I2C funktioniert in meinem Fall nicht, glaubt mir. Joggel E. schrieb: > Und fuer Externes, nur SPI, denn I2C oder dergleichen ist nur noch > muehsam. In meinem Fall noch nicht einmal möglich. Gerd E. schrieb: > In einer Treiberfunktion in Deinem Code, die die Bits setzt bzw. > entfernt? Natürlich. Da ich mit der Arbeit mit EEPROMs allerdings nicht die meiste Erfahrung habe, hätte es ja sein können, dass es dafür ein etabliertes Verfahren gibt. Gerd E. schrieb: > Die gibt es natürlich, sind aber heute für Neuentwicklungen eigentlich > nicht mehr üblich. Da nimmt man eigentlich entweder für kleinste > Datenmengen (paar kB) I2C-EEPROM, Sehe ich anders. Wo I2C nicht funktioniert, aus welchem Grund auch immer, kann es nicht zum Einsatz kommen.
Das ist irgendwie, ne? schrieb: > Wo I2C nicht funktioniert, aus welchem Grund auch > immer, und welcher geheimnisvolle Grund ist das ?
bingo schrieb: > und welcher geheimnisvolle Grund ist das ? WEIL ES EBEN EIN SPI EEPROM IST UND ES DABEI BLEIBT!!! Es ist doch vollkommen Wurscht! Die Schaltung ist vollkommen schnuppe! Sorry, aber es ärgert mich ein bisschen, dass meine Fähigkeiten, eine funktionierende Schaltung zu entwickeln hier in Frage gestellt werden, wo das Thema ein ganz anderes ist. Dir scheint es offenbar nicht klar zu sein, dass SPI und I2C nicht untereinander austauschbar sind und beide ihre spezifischen Vor- und Nachteile haben. Du brauchst auch nicht versuchen, mich zu bekehren, nun auf I2C umzusteigen, nur weil du SPI nicht magst. Mir geht es nicht um die Schaltung, sondern einzig und allein darum, wie man am besten mit diesem EEPROM umgeht.
Das ist irgendwie, ne? schrieb: > WEIL ES EBEN EIN SPI EEPROM IST UND ES DABEI BLEIBT Wer rumschreit, weiss offensichtlich nicht mehr weiter, Herr Entwickler. Wenn ich mit meinem Lamborghini nicht mehr über den Feldweg auf mein Chalet komme, dann verkaufe ich entweder das Chalet oder den Lamborghini, denn den Weg darf ich nicht asphaltieren. Es gibt auch noch weitere Möglichkeiten. Als Entwickler sollte man flexibel sein und wenn Dir die Leute hier helfen sollen, wäre etwas Freundlichkeit zielführender als lautes Herumgezetere.
Ich frage mich, warum man für so ein bisschen Bitschupsen so ein Trubel machen muss? Dann packt man eben das 8te Bit rein, und gut ist. Das sind 5 Minuten Kodieraufwand. Kürzer als hier einen Thread zu eröffnen. Ich habe übrigens gerade ein SPI-Flash beim aktuellen Projekt. 1 Byte Opcode, 3 Byte Adresse, und dann die Daten. Könnte man auch nehmen.
@bingo: Ich habe nicht um Alternativen zu SPI gebeten. Da kannst du jetzt so eingeschnappt sein wie du willst. Die Frage war doch eigentlich klar und deutlich formuliert, oder irre ich mich? Es geht mir auch nicht darum, dass es mir unmöglich erscheint, den entsprechenden Code dafür zu schreiben, sondern nur, was der Hintergrund dieser Implementierung ist und ob sich in diesem Zusammenhang eine bestimmte Vorgehensweise etabliert hat. Das habe ich aber bereits geschrieben. Wenn dein Fiat Panda nicht anspringt, werde ich dir auch nicht dazu raten, ein paar neue Schuhe in einer anderen Farbe zu kaufen und andersrum einzuparken. Das wäre nämlich das Pendant zu deinen bisherigen Antworten. Wer etwas zur Sache beiträgt, wird von mir sehr freundlich behandelt, wenn sich aber herausstellt, dass jemand versucht mein Thema zu verbiegen (so wie du gerade), kann ich auch anders.
Nachtrag: Vielen Dank für alle konstruktiven Antworten. Ich betrachte das Thema hiermit als erledigt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.