Adressierung SPI EEPROM

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

Wenn Du es einfach willst, warum kein I2C EEPROM?

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.

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.

"Meine Meining steht fest,
bitte verwirren Sie mich nicht mit Fakten".