Gast
#5098183
Es gibt mal wieder was neues: https://www.golem.de/news/i3c-linux-soll-nachfolger-fuer-i2c-und-spi-unterstuetzen-1708-129250.html
Das ist kein Nachfolger, sondern mal wieder eine typische MIPI-Aktion, nämlich ein nicht dokumentiertes Protokoll. Die Protokollspezifikation kann man nur als MIPI-Mitglied zu Gesicht bekommen, das ist bei den "Standards" DSI und CSI nicht anders. Und MIPI-Mitglied kann man nur als Hersteller von Smartphones o.ä. mit entsprechendem finanziellem Einsatz werden.
"Das könnte auch daran liegen, dass die I3C-Spezifikation nicht öffentlich verfügbar sei." Das haben Philips und Motorola seinerzeit aber besser gemacht. Allein für die Verwendung von I²C als Name sind Lizenzen fällig. "The specification is available only to MIPI Alliance members." https://www.mipi.org/specifications/m-phy Die physikalische Ankopplung ist wohl deutlich komplizierter als bei den verglichenen Bussen. Das ist, wie wenn ich sage: ich habe das Flugzeug erfunden. Es wird Autos und LKW ablösen! Fazit: natürlich wird es partiell etwas ablösen (sonst hätte man den aufwand gar nicht treiben müssen). Aber der Fokus von Mipi geht ganz klar in Richtung Kamera und Display. Für ein simples EEPROM ist der PHY zu teuer. Und er wird auch nicht auf jedem µC implementiert werden...
Gast
#5098228
was bisher bekannt ist: 10Mb/s 2-Draht std. IO's ich folgere daraus, dass es sich dabei um eine eine Mischung aus SPI und I2C haldelt: eine bidirektionale Datenleitung und eine Clockleitung , aber nicht mit Pullups gemacht (währe zo langsam) sonder mit PP und Seriewiderständen je nach Leitungslänge... Wenn sie tatsächlich auf eine LVD soundso leitung gehen wie bei CSI dann währe es nicht mit std IO's zu machen ... Sie werden einfach ein "schlaues" protokoll auf eine SPI legen ... meiner meinung nach ok, aber nicht unbedingt von Interesse für uC anwendungen ohne kamera und ohne grosses Display ...
soundso schrieb: > ich folgere daraus, dass es sich dabei um eine eine Mischung aus SPI und > I2C haldelt: eine bidirektionale Datenleitung und eine Clockleitung "MIPI M-PHY uses a differential signaling with an embedded clock" Also ein differentielles Signal, das allein schon die beiden Leitungen braucht. Der Takt ist wie bei der Manchester-Codierung in den Daten "versteckt". Wie gesagt: das bekommt man per Bitbanging nicht hin, deshalb gibt es auch 3 lizenzierbare Phys fürs Silizium...
Gast
#5098242
Ich sehe die Notwendigkeit dafür nicht. Wenn dann müsste I3C preislich auf Augenhöhe mit I2C liegen, denn sonst kann man gleich auf Ethernet gehen. Wird aber bei einem neu geschaffenem Standard kaum möglich sein, schließlich muss damit im Gegensatz zu I2C und Ethernet die Entwicklung noch refinanziert werden. Erinnert irgendwie an Firewire. War mal modern und technisch überlegen (mehr Strom, Datenrate fast genausoschnell), spätestens seit USB 3.0 im Hintertreffen und mit USB 3.1 überflüssig. War auch teurer als USB, weil die Controller komplexer waren/sind. Inzwischen ist das egal, weil für den Massenmarkt kaum noch relevant. USB ist in fast allen Belangen gleichgut oder besser. Kostet weniger, ist schneller und viel verbreiteter.
Gast
#5100740
Ethernet ist aber schon nochmal ein ganz anderes Thema, vor allem im Bezug auf Kabelängen. Ich finde das sehr interessant, frage mich allerdings warum Ich dazu ein lizenziertes Protokoll benötige. Welche Enfteilnehmer beherrschen das schon? Für PCB2PCB kann man den I2C auch nehmen und hochdrehen.
Gast
#5100896
Moin, Rufus Τ. F. schrieb: > Das ist kein Nachfolger, sondern mal wieder eine typische > MIPI-Aktion, > nämlich ein nicht dokumentiertes Protokoll. > > Die Protokollspezifikation kann man nur als MIPI-Mitglied zu Gesicht > bekommen, das ist bei den "Standards" DSI und CSI nicht anders. > > Und MIPI-Mitglied kann man nur als Hersteller von Smartphones o.ä. mit > entsprechendem finanziellem Einsatz werden. Die MIPI-Specs fallen eigentlich immer mal wieder von irgendwelchen Lastwagen. Aber die herstellereigenen Verstümmelungen oder logischen Hirnschüsse, wie auch Registertabellen, usw. muss man wieder erraten. Alles in allem hat so i3c die Chance, zu einem furchtbar nervigen 'Standard' zu werden (also eigentlich: keinem). Bleibt noch für den Kleinanwender, sich mit Referenzdesigns der üblichen Verdächtigen zu behelfen (zB ICE40). Irgendwie uncool...
Gaaaaanz dringend wird ein neuer Standard benötigt. Gibt ja so viele Dinge, die I2C, SPI, I2S, TDM, CAN, RSxxx, Ethernet, USB (1, 2, 3), Lightning, Thunderbolt, Firewire (RIP), HDMI alle nicht können. <ironie aus>
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.