Hallo, was mir soeben aufgefallen ist, gibt es einen Grund warum FRAMs mit I2C nur Kapazitäten bis 1MBit und die mit SPI bis 16MBit haben? Mir fällt spontan kein technischer Grund ein. Interessenshalber in die Runde gefragt. https://www.mouser.de/c/semiconductors/memory-ics/f-ram/?interface%20type=I2C https://www.mouser.de/c/semiconductors/memory-ics/f-ram/?interface%20type=SPI
:
Bearbeitet durch User
Bei SPI geht die max. Taktfrequenz häufig bis 50Mhz oder bei Flash sogar noch höher. Davon kann I2C nur träumen. Ein riesen Speicher, wo man die Daten nur tröpfchenweise rein/raus bekommt, ist meist nicht sooo furchtbar hilfreich.
:
Bearbeitet durch User
Veit D. schrieb: > Mir fällt > spontan kein technischer Grund ein. Man will auf Speicher auch zugreifen, bei (F)RAM typischerweise sogar recht schnell. Und SPI mit 'zig Mbps ist nunmal deutlich schneller als I2C mit maximal 3Mbps (und selbst das ist ja eher schwer erreichbar, realistisch für zuverlässigen Betrieb ist eher was bis 1Mbps). Bezüglich der Schnittstellengeschwindigkeit ist das PushPull halt schwer im Vorteil gegenüber OD mit Pullup. Wenn's langsam sein darf, braucht man halt kein FRAM, dann tut's auch Flash.
Beitrag #7522781 wurde vom Autor gelöscht.
Hallo, mit den Unterschieden der Schnittstellengeschwindigkeiten habt ihr schon recht. Nur muss man ja nicht zwangsweise sehr schnell und viel lesen/schreiben wollen. Man kann ja auch nur viele kleine Datenpakete speichern wollen. Der Zusammenhang zwischen Geschwindigkeit und Kapazität ist in meinen Augen nicht zwangsweise vorhanden. Ich weiß es jedoch nicht besser. Wenn es so sein soll, dann ist es eben so. ;-) Ist auch nicht weiter schlimm.
> was mir soeben aufgefallen ist, gibt es einen Grund warum FRAMs mit I2C > nur Kapazitäten bis 1MBit und die mit SPI bis 16MBit haben? I2C ist im industriellen Bereich wegen seiner etwas fragwuerdigen Zuverlaessigkeit nicht so populaer. Jedenfalls bei Geraeten die 24/7 laufen sollen. Da wird es einfach weniger Kunden geben die sowas kaufen wollen. Vanye
Hallo, das würde mich jetzt noch näher interessieren was an I2C unzuverlässiger ist im Vergleich zu SPI?
Veit D. schrieb: > Hallo, > > das würde mich jetzt noch näher interessieren was an I2C unzuverlässiger > ist im Vergleich zu SPI? Ich habe bei I2C sehr oft die Erfahrung gemacht, dass das Slave gerne mal zickt und den Clock blockiert, sprich auf LOW hält. Da hilft tatsächlich immer ein harter I2C Hardware-Reset. Bei SPI hast du das Problem nicht.
Ob S. schrieb: > Wenn's langsam sein darf, braucht man halt kein FRAM, dann tut's auch > Flash. Kommt drauf an, ob die Zyklenzahl für die Anwendung eine Rolle spielt. Da ist FRAM deutlich im Vorteil.
> das würde mich jetzt noch näher interessieren was an I2C unzuverlässiger > ist im Vergleich zu SPI? I2C kann abstuerzen z.B bei einem EMV Ereignis und dann den ganzen Bus runterziehen. Du kannst den I2C Devices dann keine Kommandos mehr schicken und musst das Geraet ausschalten. Deshalb hat SMB z.B eine minimale Clockspeed. Und ich glaube auch bei I3C wurde da was verbessert. Das ist fuer banale Heimelektronik wohl weitestgehend irrelevant. Aber nimm z.B mal an dein Stromzaehler haette sowas eingebaut oder deine Wasseruhr. Irgendwie kacke wenn die alle 1-2Jahre rumspinnen oder? Die Schnittstelle wurde mal entwickelt damit der Fernseher deines Opas 1980 seine Sender in einem PCF8582 abspeichern kann. Da war eine andere Intention hinter. .-) Vanye
Hallo, hatte einmal was von Peter gelesen das man den Bus nach Absturz freitakten muss/kann. Funktioniert das nicht mit allen Geräten am Bus?
> freitakten muss/kann. Funktioniert das nicht mit allen Geräten am Bus?
Sowas sollte man dringend implementieren, aber geht nur solange die SDA
Leitung betroffen ist. Es gibt aber Devices die ziehen die SCL runter
und dann wars das.
Vanye
Vanye R. schrieb: > Sowas sollte man dringend implementieren, aber geht nur solange die SDA > Leitung betroffen ist. Es gibt aber Devices die ziehen die SCL runter > und dann wars das. > > Vanye Na dann sind das aber genau die Devices die auf die Müllhalde sollten. Ob die FRAM Bausteine sich so verhalten steht noch im Raum. Selbst habe ich das noch nicht erlebt. Gibt es da Erfahrungswerte welche ICs man vermeiden sollte?
Jürgen L. schrieb: > Na dann sind das aber genau die Devices die auf die Müllhalde sollten. Nennt sich Click Stretching. Ob ein Device, z.B. ein beteiligter uC dabei hängen bleiben kann, hängt an der Programmierung (z.B. Aktivierung Watch Dog) Und richtig: Der Programmierer, der das nicht berücksichtigt, sollte dann vielleicht nicht auf die Müllhalde aber noch einmal auf die Schulbank.
:
Bearbeitet durch User
> Na dann sind das aber genau die Devices die auf die Müllhalde sollten. Naja, auch die Loesung mit dem extra Taktzyklen ist nicht so doll weil du es halt wissen und machen musst und weil es dann immer noch dein System mal kurz ungewoehnlich laufen laesst. Sicher besser wie nix! Aber doll ist anders. > Ob die FRAM Bausteine sich so verhalten steht noch im Raum. Selbst habe > ich das noch nicht erlebt. Gibt es da Erfahrungswerte welche ICs man > vermeiden sollte? Ich denke mal alles was Clockstretching kann. Also sagen wir mal Speicherbausteine? Ich selber war mal fasziniert als ich verschiedene Revisionen des Datenblatts vom LM75 verglichen habe wo sie in den neueren sagen wie toll der nun geworden ist nachdem sie ihn verbessert haben. Das wirft fragen zu ersten Chiprevision auf. :) Ein weiteres Problem von I2C im industiellen Umfeld ist natuerlich das man da oefters mal Potentialtrennung braucht. Ich weiss das es mit I2C auch irgendwie geht und ich weiss auch das es da seit kurzem ein SpezialIC fuer gibt. Aber ist doch irgendwie ein Schmerz im Arsch, vor allem wenn du Certificate brauchst. Ich will I2C auch nicht grundsaetzlich schlecht machen. Aber es ist halt eher Consumer und weniger Industrial. Vanye
Vanye R. schrieb: > Es gibt aber Devices die ziehen die SCL runter > und dann wars das. Das sind dann unter der Haube aber MCs, die erstmal in den Interrupthandler springen müssen. Speicher machen das I2C aber in Hardware, d.h. SCL ist als Input definiert. Und ein Input kann sich nunmal nicht auf low ziehen. Daß ein Slave SDA auf low setzt, ist ein regulärer Zustand und muß daher vom Master behandelt werden. Z.B. der Master liest gerade den Slave aus und kriegt ein Watchdogreset, Brownoutreset oder von einer anderen Quelle. Nach dem CPU-Reset weiß der Master natürlich nicht mehr, daß er gerade lesen wollte und muß deshalb SDA prüfen. Die original Philips MCs haben das natürlich behandelt, viele neuere I2C-MCs leider nicht mehr. Hier mal aus dem DB des Philips P89C660: "The SIO1 hardware transmits additional clock pulses when the STA flag is set, but no START condition can be generated because the SDA line is pulled LOW while the I2C bus is considered free. The SIO1 hardware attempts to generate a START condition after every two additional clock pulses on the SCL line. When the SDA line is eventually released, a normal START condition is transmitted, state 08H is entered, and the serial transfer continues." Viele Nachbauer haben sich wohl den I2C-Standard nur mit einem halben Auge angesehen.
Naja, wozu ist denn I2C mal entwickelt worden? Und nächste Frage: Was hat die persönliche Unfähigkeit eines Entwicklers mit I2C zu tun? Also ich verwende I2C z.B. wenn kein Platz da ist (wenige Pins) und die Zeit eine untergeordnete Rolle spielt. Alles was schnell gehen soll, dann SPI. Zuverlässigkeit hat seinen Preis und niemand hindert einen Produktentwickler daran, vorher zu recherchieren und während der Entwicklung intensiv zu testen. Mit einer Testumgebung, wie sie später in der Praxis vorherrschen werden.
> Zuverlässigkeit hat seinen Preis und niemand hindert einen > Produktentwickler daran, vorher zu recherchieren und während der Das Problem von I2C ist aber nicht das es dreimal die Woche ausfaellt, sondern das du 10000 Geraete im Jahr verkaufst und dann 10erboste Anrufe im Jahr bekommst und erstmal keiner so genau weiss was Sache ist und du es auf deinem Schreibtisch nicht reproduziert bekommst. > Viele Nachbauer haben sich wohl den I2C-Standard nur mit einem halben > Auge angesehen. Freut euch da schonmal auf die ersten I3C Devices. Da ist der Standard so komplex das Probleme in den ersten Jahren praktisch garantiert sind. :-D Vanye
Rainer W. schrieb: > Nennt sich Click Stretching. Ob ein Device, z.B. ein beteiligter uC > dabei hängen bleiben kann, hängt an der Programmierung (z.B. Aktivierung > Watch Dog) > > Und richtig: Der Programmierer, der das nicht berücksichtigt, sollte > dann vielleicht nicht auf die Müllhalde aber noch einmal auf die > Schulbank. Ein Slave Device kann ja meinetwegen Clock Stretching machen. Das heißt aber nicht, dass es bis zum Sanktnimmerleinstag SCL blockieren darf. Wenn es das trotzdem macht, würde ich so einen Baustein als fehlerhafte Krücke bezeichnen. Das wäre ja der gleiche Zustand, als wenn ein CAN Controler Knoten einfach mal den dominanten Zustand nie verlassen würde.
1 MBit bekommt man bei i2C mit 2 Adressbytes (plus 1 Bit der I2C-Adresse) unter. Bei 16MBit wäre man inkompatibel. Bei SPI brauchst Du ab 512kBit sowieso 3 Byte.
> Ein Slave Device kann ja meinetwegen Clock Stretching machen. Das heißt > aber nicht, dass es bis zum Sanktnimmerleinstag SCL blockieren darf. Es geht ja nicht um den Normalbetrieb. Da macht niemand einen Fehler und alles ist immer gut. Aber wenn es irgendeine Stoerung, sagen wir mal wegen EMV gab, dann koennen halt Device welche Clock Stretching koennen auch die Clock Leitung runterziehen. Und da ist ja keine krasse MCU mit irgendwelchen Luxus drin sondern eher eine bessere Statemachine und da kann es dann auch mal haengen bleiben. Wenn du jetzt erwartest das es einen Timeout gibt dann bist im Prinzip bei SMB angekommen. Vanye
Vanye R. schrieb: > Das Problem von I2C ist aber nicht das es dreimal die Woche ausfaellt, > sondern das du 10000 Geraete im Jahr verkaufst und dann 10erboste Anrufe > im Jahr bekommst und erstmal keiner so genau weiss was Sache ist und > du es auf deinem Schreibtisch nicht reproduziert bekommst. Da kann ich nicht zustimmen, auch I2C kann super stabil arbeiten. Ich habe mal ein Gerät entwickelt mit Multimaster-I2C, das lief völlig ohne Probleme. Intern wurden mehrere 5kV Spannungen erzeugt und Schaltungsteile waren floatend auf 5kV. Naturgemäß kam es in der Vakuumkammer zu Überschlägen, trotzdem ist der I2C nicht abgekackt. Das Problem war leider, daß Philips von NXP übernommen wurde und NXP hat dann den Großteil der Philips 8-Bitter abgekündigt. Ich bin dann zu Atmel AVRs gewechselt und hab nur noch geflucht, so buggy war deren I2C. Trotz haufenweise Timeouts und Retries lief das Gerät nie mehr so stabil, wie mit Philips. https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html Tekmos hat versucht, den P68C668 als TK68C668 nachzubauen, den hab ich mal auf ne alte Platine gesteckt. Der kam nichtmal über das I2C-Init hinaus, auf dem Display erschien nur "Bus-Error". Die Microchip PICs sollen ja auch viele Funktionen des I2C-Standards nicht implementiert haben. Mir ist jetzt keine MC-Familie mehr bekannt, die eine sauber implementierte Slave- oder Multimasterfunktion hat.
Hallo, ich danke euch für die näheren Informationen. Bruno V. schrieb: > 1 MBit bekommt man bei i2C mit 2 Adressbytes (plus 1 Bit der > I2C-Adresse) unter. > Bei 16MBit wäre man inkompatibel. > Bei SPI brauchst Du ab 512kBit sowieso 3 Byte. Ich weiß nicht ob mit 2 Adressbytes wirklich Schluss ist, dann könnte man mit 16+3 Adressbits immerhin noch Kapazitäten bis 4MBit anbieten.
Ob S. schrieb: > Und SPI mit 'zig Mbps ist nunmal deutlich schneller als > I2C mit maximal 3Mbps (und selbst das ist ja eher schwer erreichbar, > realistisch für zuverlässigen Betrieb ist eher was bis 1Mbps). So ist es. Große Speicher haben nicht nur Taktfrequenz von 80MHz und mehr, sie benutzen auch 2 oder 4 Datenleitungen (DSPI, QSPI), um aus dem Knick zu kommen. Da kann I2C schon lange nicht mehr mithalten. Größer als der AT24CM02 ist nicht mehr sinnvoll.
Peter D. schrieb: > Ob S. schrieb: >> Und SPI mit 'zig Mbps ist nunmal deutlich schneller als >> I2C mit maximal 3Mbps (und selbst das ist ja eher schwer erreichbar, >> realistisch für zuverlässigen Betrieb ist eher was bis 1Mbps). > > So ist es. Große Speicher haben nicht nur Taktfrequenz von 80MHz und > mehr, sie benutzen auch 2 oder 4 Datenleitungen (DSPI, QSPI), um aus dem > Knick zu kommen. Da kann I2C schon lange nicht mehr mithalten. > Größer als der AT24CM02 ist nicht mehr sinnvoll. Darf ich fragen wie ihr rechnet? Wieso sind mit I2C 3Mbps schwer erreichbar!?
Ali K. schrieb: > Wieso sind mit I2C 3Mbps schwer erreichbar!? Probier's aus, vielleicht hast du Glück. Die I2C Bausteine die ich kenne garantieren im Datenblatt jedenfalls maximal 1 MBit/s. Und selbst wenn dein Baustein (den ich nicht kenne) mehr kann muss es dein Controller auch erst mal können, was nicht sicher ist.
Ali K. schrieb: > Wieso sind mit I2C 3Mbps schwer erreichbar!? I2C hat 2 bidirektionale Leitungen für n Chips. "2" ist die Stärke, "bi" die Schwäche (open collector mit Pull-Up). SPI hat 2 + n unidirektionale Leitungen für n Chips. "+n" ist die Schwäche, "uni" die Stärke. Ein niederohmiger Treiber mit 0V oder 3V erlaubt halt schnellere Signalwechsel als ein 2k Pullup.
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.