Kann jemand über Erfahrungen mit I3C (nicht I2C!) berichten? Egal, ob als I3C-Controller/Master oder I3C-Target/Slave. Vielleicht mit einem erwerbbaren Mikrocontroller, bei dem man auch Beispiel-Sourcen bekommt? Vielleicht ein Mikrocontroller, der auch als I3C-Target/Slave funktioniert? Oder evt. ein USB<->I3C Converter, den man an einem PC oder Raspi betreiben kann? Einige I3C-Hubs/Target/Slaves von NXP: https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/i3c-interface-devices:I3C I3C on Linux with NXP i.MX 93: https://docs.nxp.com/bundle/AN14005/page/topics/i3c_support_in_linux.html Mit STM32H5: https://wiki.st.com/stm32mcu/wiki/Getting_started_with_I3C https://binho.io/blogs/i3c-articles/stmicro-launches-stm32h5-mcu-first-with-i3c-peripheral https://www.st.com/resource/en/application_note/an5879-introduction-to-i3c-for-stm32h5-series-mcu-stmicroelectronics.pdf https://www.st.com/resource/en/application_note/an5927-i3c-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf
Martin M. schrieb: > Kann jemand über Erfahrungen mit I3C (nicht I2C!) berichten? Wozu sollte man I3C verwenden? Um alles komplizierter zu machen? I3C ist so unnötig wie ein Kropf. Ist vielleicht so ähnlich zu sehen wie DVD vs. Blu Ray. Wer macht auf dem Computer Blu Ray? Ich brauch's nicht ....
Wastl schrieb: > Wozu sollte man I3C verwenden? Um alles komplizierter zu machen? Das würde ich auch meinen. Vielleicht kann hier mal jemand den Appetit wecken...
Wastl schrieb: > I3C ist so unnötig wie ein Kropf. Diese Diskussion hatten wir vor 28 Jahren auch schon einmal. Dabei ging es allerdings nicht um I3C, sondern um USB.
Naja, USB war anfangs auch recht lahm, aber alle paar Jahre gab es eine Erweiterung. Heute ist es vor allem ein (gesetzlich vorgeschriebenes) Ladekabel fürs Handy, und Ersatz für Netzwerkkabel, Drucker und serielle Schnittstelle in einem. Man kann aber auch einen Ventilator damit betreiben, incl. flimmernder Beleuchtung.
Rainer W. schrieb: > USB Naja das war schon etwas grundlegender neu. Eine einheitliche Schnittstelle die vieles ersetzt. Davon ist I3C doch weit entfernt.
Die Kaffeetassen-Warmhalteplatte für USB hatte ich noch vergessen. Und Power-Banks mit 5V, die gab es davor auch nicht.
Ich danke euch für den Vergleich mit USB. Aber mir geht es explizit um Erfahrungen, die schon mal jemand mit I3C (3!) gemacht hat. Bitte beschränkt euch auf I3C und lagert eure Diskussionen, ob sinnvoll oder nicht in einen eigenen Beitrag aus! Wenn ihr keine Erfahrung mit I3C habt, dann verhaltet euch hier einfach mal ruhig. Danke!
Martin M. schrieb: > Wenn ihr keine Erfahrung mit I3C habt, > dann verhaltet euch hier einfach mal ruhig. Wenn du eine Begründung oder Anwendung lieferst warum du dich für I3C interessierst dann würde die Diskussion in eine andere Richtung laufen und Leute motivieren einen hilfreichen Beitrag zu hinterlassen. Solange du aber nur theoretisches Interesse hast und herum- philosphieren willst wird da kein fruchtbarer Austausch zustande kommen. Ohne mich mit der neuen Materie jemals auseinandergesetzt zu haben würde mich jetzt interessieren warum jemand I3C an- wenden bzw. benutzen will und welchen Vorteil es gibt oder welcher "Druck" dahinter steckt diesen Standard verwenden zu wollen/müssen.
Gerhard H. schrieb: > Wastl schrieb: >> Wozu sollte man I3C verwenden? Um alles komplizierter zu machen? > > Das würde ich auch meinen. Ich nicht unbedingt. > Vielleicht kann hier mal jemand den Appetit wecken... Nunja, ich versuche es mal (aus meiner Sicht): 1) Der Hauptvorteil: I3C-Master können auch mit I2C-Slaves umgehen. Somit muss man also die unzähligen liebgewonnen I2C-Peripheriegeräte nicht wegwerfen, sondern kann sie weiter benutzen und zwar an demselben Bus, über den I3C auch die im Folgenden aufgezählten weiteren Vorteile ausspielen kann. Diese stehen aber natürlich nur für I3C-Slaves zur Verfügung. 2) Interruptsignalisierung innerhalb des Busses. Das ist ein ziemlich geiles Feature. Bei I2C braucht man dazu zusätzliche Signale und zwar für jeden Slave, der einen Interrupt auslösen können soll, eins. Deswegen wird vielfach auf diese Signalisierung verzichtet und die Clients dümmlich gepollt. Das ist teuer, kostet Rechenzeit, Busbandbreite und Energie. 3) Weit höhere Bitraten möglich, die deutlich in den Bereich hineinragen, der bisher SPI vorbehalten war. Und im Gegensatz zu SPI gibt es den völligen Wildwuchs der Übertragungsformate hier nicht. 4) Dynamische Adressierung. Das vermeidet potentiell viele Probleme, die das statische Verfahren bei I2C schafft. Allerdings weiss ich nicht, wie das genau funktioniert. Ich vermute aber mal, dass die sich durchaus auch Gedanken darüber gemacht haben, wie man gleichartige Clients entsprechend ihrer physischen Position gezielt Adressen zuweisen kann. Ansonsten wäre das eine echte Luftnummer. Aber wie schon gesagt: ich weiss es (noch) nicht. Der Hauptnachteil ist aus meiner Sicht: Das Protokoll ist im Gegensatz zu I2C NICHT offen. Nur eine Teilmenge wird veröffentlicht, um in den Genuss der vollen Infoflut zu kommen, muss man Mitglied dieser unsäglichen Mafia werden, die sich MIPI-Alliance nennt. Und das kostet ein kleines Vermögen.
Ob S. schrieb: > muss man Mitglied dieser > unsäglichen Mafia werden, die sich MIPI-Alliance nennt Und damit ist I3C 'raus.
Ex-Kollege hatte das mal im wöchentlichen Meeting vorgestellt. Konkrete Designs mit I3C waren von ihm noch nicht gemacht wurden, wurden aber für die nahe Zukunft erwartet, da I3C bei MIPI angesiedelt ist und es einige aktuelle Designs mit MIPI (Mobile Industry Processor Interface Alliance ) gibt. Wobei MIPI eigentlich kein eigenes Interface ist, sondern ein Konsortium mehrerer Firmen, die diverse Standards vereinbart haben. Zu diesem Konsortium gehören Intel, Apple, ARM, AMD, ... . Wenn also Erfahrung mit MIPI gab dann hies das eigentlich MIPI-CSI Also eher nix für Bastler-µC, nur wer im Bereich MIPI (Viseo) unterwegs ist, hat ne gewisse Wahrscheinlichkeit sich mit I3C beschäftigen zu müssen. Anbei der link zu einer AppNote vierer FPGA-Herstellers zum MIPI Interface: https://docs.amd.com/v/u/en-US/xapp894-d-phy-solutions https://www.latticesemi.com/en/Solutions/Solutions/SolutionsDetails02/MIPISolutions https://cdrdv2-public.intel.com/666639/an754-683092-666639.pdf https://www.microsemi.com/document-portal/doc_download/136292-ac460-building-mipi-csi-2-applications-using-smartfusion2-and-igloo2-fpgas-application-note
:
Bearbeitet durch User
> Der Hauptnachteil ist aus meiner Sicht: Das Protokoll ist im Gegensatz > zu I2C NICHT offen. Das Hauptnachteil ist eher das dieses Protokoll so komplex ist das die ersten Implementationen seitenweise Erratas fuellen werden. .-) Vanye
Harald K. schrieb: > Ob S. schrieb: >> muss man Mitglied dieser >> unsäglichen Mafia werden, die sich MIPI-Alliance nennt > > Und damit ist I3C 'raus. Nicht zwingend. Auch z.B. SD-Cards benutzen ein Protokoll, was nur in Teilen öffentlich ist. Das tut ihrer breiten Verwendung (auch in den Sektoren von Hobby bis KMU) aber keinen Abbruch. Kommt eben stark darauf an, welche Teile des Protokolls öffentlich sind und welche nicht. Wenn das bei I3C analog zu SD-Card nur irgendwelches Kopierschutz-Gebabbel betrifft, ist das zwar ärgerlich, aber eben kein Grund, das Protokoll nicht zu verwenden. Das stört dann nur die, die diese Funktionalität auch verwenden wollen. Und wenn die an die Mafia löhnen müssen, habe ich kein Mitleid. Es ist eben so, das der eine Gangster den anderen bezahlen muss, wenn er seine Dienste in Anspruch nimmt. War schon immer so.
Martin M. schrieb: > Aber mir geht es explizit um Erfahrungen, > die schon mal jemand mit I3C (3!) gemacht hat. Ich tippe mal: Keiner. Ob S. schrieb: > Nunja, ich versuche es mal Verbindlichen Dank. Vorurteil bestätigt. Ich sehe aus Bastler-Sicht bislang keinen praktischen Vorteil.
:
Bearbeitet durch User
Vanye R. schrieb: > Das Hauptnachteil ist eher das dieses Protokoll so komplex ist das > die ersten Implementationen seitenweise Erratas fuellen werden. .-) Nunja, ich kann mich an die ersten Jahre von USB in den 90ern noch sehr gut erinnern. Da hat auch fast nix funktioniert. I3C hat viele Analogien zu dieser frühen USB-Zeit. Allerdings: USB war von Anfang an vollständig offen. Und (wahrscheinlich auch genau deshalb) hat es sich über die Jahrzehnte doch zu einem durchaus gut brauchbaren System gemausert. Ich neige also immer noch dazu, die nur teilweise Öffentlichkeit deutlich stärker negativ zu bewerten als die Disfunktionalität der frühen Implementierungen. Das könnte schon noch was werden.
Ob S. schrieb: > Da hat auch fast nix funktioniert. I3C hat viele Analogien zu dieser > frühen USB-Zeit. I2C funktioniert bis heute nicht perfekt. Interessant wirds mit I3C sollte sich die Software-Ansteuerung entsprechender Peripherie-Module gegenüber I2C vereinfachen - bei mindestens gleich robuster Anbindung ... Über Komponenten-Preise wurde noch gar kein Wort verloren.
Gerhard H. schrieb: > Vorurteil bestätigt. Full Ack. Harald K. schrieb: > Und damit ist I3C 'raus. Full Ack. Ich habe solche Eigenschaften befürchtet, und daher: Wastl schrieb: > Wozu sollte man I3C verwenden? Um alles komplizierter zu machen? > I3C ist so unnötig wie ein Kropf. ... und ich werde I3C die nächsten 20 Jahre nicht brauchen.
Gerhard H. schrieb: > I2C funktioniert bis heute nicht perfekt. Das ist wahr. Liegt aber nur daran, dass der Standard einen ganz wichtigen Punkt NICHT vorgeschrieben hat, der für ein Bussystem aber von ganz grundlegender Bedeutung ist: Es gibt unerklärlicherweise keinen Timeout und keine Vorgabe, dass Peers nach Ablauf dieses Timeout den Bus zwingend freizugeben haben. Alle anderen "Probleme" mit dem I2C-Bus habe nur Leute, die einfach nicht programmieren können und/oder nicht in der Lage sind, die Hardware normgerecht umzusetzen.
Wenn man mit MIPI oder I3C was machen will oder eher muss, wuerde ich den Griff zum FPGA empfehlen. Lattice und Gowin hat z.B. IP-Cores, zu den Details der Simulation allerdings kann ich nichts sagen. Gowin kann kein HDR. Der Vorteil ist dabei grundsaetzlich, dass man - wenn die Cores als Simulationsmodelle vorliegen - zumindest das Interfacing in die Simulation stecken kann anstatt einen teuren Osci am uC anhaengen zu muessen. Das bisschen Chip ist in den meisten Anwendungen billiger als sich mit NDAfreudigen Herstellern rumzuaergern und am Schluss trotzdem keine Hilfe zu kriegen. Also: die FAE festnageln. Ob S. schrieb: > Der Hauptnachteil ist aus meiner Sicht: Das Protokoll ist im Gegensatz > zu I2C NICHT offen. Nur eine Teilmenge wird veröffentlicht, um in den > Genuss der vollen Infoflut zu kommen, muss man Mitglied dieser > unsäglichen Mafia werden, die sich MIPI-Alliance nennt. Und das kostet > ein kleines Vermögen. Oder man guckt sich auf chinesischen Codeforen um, da wird ein NDA nicht so eng gesehen.
Gerhard H. schrieb: > Ich sehe aus Bastler-Sicht bislang keinen praktischen Vorteil. Wie auch sollte man solch ein bestechend einfaches Interface sowie Protokoll verbessern können (bis auf die erwähnte kleine Macke des Timeouts)?
Wastl schrieb: > Gerhard H. schrieb: >> Ich sehe aus Bastler-Sicht bislang keinen praktischen Vorteil. > > Wie auch sollte man solch ein bestechend einfaches Interface > sowie Protokoll verbessern können (bis auf die erwähnte kleine > Macke des Timeouts)? Du hast offensichtlich nicht gelesen (oder verstanden), was ich über die Vorteile geschrieben habe. Insbesondere nicht den Sachverhalt, dass diese Vorteile natürlich erst mit der Verfügbarkeit entsprechender I3C-Slaves nutzbar werden können. Ist halt wirklich ganz genau so, wie es auch bei USB zu Anfang war: Es gab eben keine USB-Geräte und viel hat nicht funktioniert, also war USB viele Jahre lang der "useless serial bus". Und was ist heute? Es würde mich nicht sehr wundern, wenn I3C eine ähnliche Entwicklung bevorsteht. Wenn der Standard vollständig offen wäre, würde ich sogar darauf wetten, dass das die Zukunft für die interne Gerätekommunikation ist.
Ob S. schrieb: > Der Hauptnachteil Vor ungefähr einem Jahr habe ich noch kaum etwas an Sensoren gesehen. Jetzt gibt es da wohl schon einiges an Hardware. Siehe hier: https://binho.io/blogs/i3c-reference/i3c-devices Allerdings glaube ich schon, dass das in absehbarer Zeit dann auch offen gelegt wird. Ich denke die Industrie hat erkannt, dass viele Innovationen gerade aus der Bastler Szene kommen. Nachtrag: Ich habe mir gerade einige Sensoren angeschaut. Auch preislich liegen die im Rahmen. Da die ja auch sowieso I2C können, würde ich für die eine oder andere Anwendung da schon drauf zugreifen. Vielleicht gibt es dann auch bald µCs dazu, die I3C können. Auf jeden Fall war der kleinste Gyro-Sensor der Welt (wie sie ihn nannten) schon beeindruckend klein.
:
Bearbeitet durch User
https://www.elektroniknet.de/automation/industrie-40-iot/i3c-hat-probleme-von-ic-beseitigt.209008.html Ob S. schrieb: > Deswegen wird vielfach auf diese Signalisierung verzichtet und die > Clients dümmlich gepollt So ein wenig an den Haaren herbeigezogen erscheint mir das Argument schon. Wo bitte wird denn "dümmlich gepollt"? Die Dokumentation eines Sensors offenbart doch, in welchem zeitlichen Abstand neue Werte zur Verfügung stehen. Danach richtet sich der Entwickler und fertig. Unter dem Strich scheint mir obig verlinkte Zusammenfassung allein auf mehr Kommunikations-Speed hinauszulaufen. Wo man das wirklich braucht gut und schön. Wenn mir aber mein Sensor sowieso nur alle paar Zehntel- bis Sekunden einen Wert liefern kann ist es belanglos.
> Ich denke die Industrie hat erkannt, dass viele Innovationen gerade aus > der Bastler Szene kommen. Reines Wunschdenken und sehr eigenwillige/selbstgefällige Interpretation des Begriffs "Innovation". Seit 1976 ist aus der Bastler-Ecke nichts Wesentliches gekommen. https://youtu.be/S5AfgrykSqg?t=1008 Realistisch betrachtet gibt es nur den umgekehrten Weg, die Innovation aus der Industrie sickern in die Bastelszene. Könnte man auch als eine Form der "Resteverwertung" betrachten.
> I2C funktioniert bis heute nicht perfekt.
Ja, aber dieses Problem wird ja mit I2C gleich mitgeloest.
Faszinierend ist aber das es mit SMB ein I2C kompatibles Protokoll
gibt das sich auch nie so krass richtig durchgesetzt hat obwohl die
das Timeoutproblem geloesst haben. Das scheint aber die meisten
gar nicht zu interessieren obwohl es fuer mich der Grund ist das
I2C im professionellen Entwicklungen nicht eingesetzt werden kann
weil die Geraete halt 24/7 laufen muessen.
Und was die Bastler angeht, die meisten sind doch fuer I2C zu
faul/unfaehig und koennen nur fertige Libaries nutzen, Teilnehmer
dieser Diskussion natuerlich ausgenommen. Die werden dann I3C nutzen
sobald es ihre Librarie kann.
Und wie ich schon sagte, zumindest in der Anfangszeit erwarte ich grosse
Probleme und dann sitzen die erst recht hilflos vor dem Oszi.
Oh und unsere schicken Oszi koennen das ja aktuell auch nicht
dekodieren.
Ich denke auch das wir noch ein paar interessante Applikationen zum
Thema Terminierung und EMV bei gemischtem Busbetrieb lesen werden.
Vanye
Wastl schrieb: > Wie auch sollte man solch ein bestechend einfaches Interface > sowie Protokoll verbessern können Bestechend einfach ist ein simples analoges Interface. Schon I2C verlangt gewisse Rumhampeleien im Code trotz spezifischer Peripherie-Module. Ich seh's jetzt mal aus unterster Hardware-Perspektive. Wenn sich genau das nicht verbessert und parallel der Betrieb unproblematischer wird (ich erinnere an die Millionen I2C Pullup- Dimensionierungs- Hilferufe im Web) bringts aus meiner bescheidenen Bastlersicht keinen handfesten Vorteil. Zu befürchten steht allerdings, daß sich alles (mit mehr Speed) nur weiter verkompliziert. Warten wir ab, bis I3C wirklich in gängigen Controllern auftaucht. Es kann sich ja nur noch um Jahre handeln...
Vanye R. schrieb: > Oh und unsere schicken Oszi koennen das ja aktuell auch nicht > dekodieren. Der Saleae LA soll es schon können, allerdings wird es der erste Premium Bezahldekoder :( https://support.saleae.com/protocol-analyzers/supported-protocols Da müssen es schon ganz tolle I3C devices sein das man ausgerechnet diese nehmen sollte.
> Und was die Bastler angeht, die meisten sind doch fuer I2C zu > faul/unfaehig und koennen nur fertige Libaries nutzen, Teilnehmer > dieser Diskussion natuerlich ausgenommen. Die werden dann I3C nutzen > sobald es ihre Librarie kann. +1, ACK Wobei dieses Forum gerade diese "Bequemen"/Hardware-Ignoranten anzieht. Zwei aktuelle Beispielsthreads aus der I2C - Ecke: Beitrag "Es wird nur ein I2C Gerät erkannt" Beitrag "I/O Erweiterung einfach erklärt" Vielleicht sollte man zwischen Bastler und Hobbyisten unterscheioden und dabei die genialen Impovisationskünstler unter den Studenten/Azubis nicht ignorieren. > Und wie ich schon sagte, zumindest in der Anfangszeit erwarte ich grosse > Probleme und dann sitzen die erst recht hilflos vor dem Oszi. > Oh und unsere schicken Oszi koennen das ja aktuell auch nicht > dekodieren. Und das obwohl es auch Open-Source-Scopes gibt, bei denen man beliebige Funktionen selbst nachprogrammieren kann. Oder man lässt über die abgespeicherte Aufzeichnung ein kleines Skript drüber rutschen.
BTW: da eine Fachvortrag zu I3C aus dem Jahre 2017 ! https://community.nxp.com/t5/Technology-Days-Training/Overview-of-the-I3C-Interface-Successor-of-the-Well-Known-I2C/ta-p/1117473?attachment-id=11072
Bradward B. schrieb: > Realistisch betrachtet Nehmen wir den 3D-Druck. Chuck Hall hat erst nach seinem Patent eine Firma gegründet. Und dass die Dinger heute schon relativ gut funktionieren, das kommt durch die vielen Bastler. Um nur ein Beispiel zu nennen. MP3 wurde zwar an einer Uni entwickelt, aber nur, weil einer den Doktor-Vater des Erfinders ans Bein gepinkelt hatte und meinte, dass sie etwas nicht möglich wäre. Es war auch keine industrielle Forschungsaufgabe. Wenn man so will, kam es auch aus dem Basteltrieb heraus zu MP3
Frank O. schrieb: > Bradward B. schrieb: >> Realistisch betrachtet > > Nehmen wir den 3D-Druck. Chuck Hall hat erst nach seinem Patent eine > Firma gegründet. > Um nur ein Beispiel zu nennen. > MP3 wurde zwar an einer Uni entwickelt, aber nur, weil einer den > Doktor-Vater des Erfinders ans Bein gepinkelt hatte und meinte, dass sie > etwas nicht möglich wäre. StartUp-Gründungen und Doktorarbeiten an der FhG zähle ich nicht zu den "Bastelarbeiten". > Und dass die Dinger heute schon relativ gut > funktionieren, das kommt durch die vielen Bastler. Ne, Methoden fürs "Fast Prototyping" wie 3D Druck wurden eher durch die Automobil-Industrie (Formal-1 Kohlefaser-Cockpit Fertigung), Medizintechnik-Prothesenbau gepushed, die Batler kamen dann Jahrzehnte später und ahmten im Wesentlichen den Industrie Nodelltischlern nach. Inzwischen gibt es "Modelltischler/-macher" wohl nicht mehr als eigenständige Berufsausbildung. > Es war auch keine industrielle Forschungsaufgabe. > Wenn man so will, kam es auch aus dem Basteltrieb heraus zu MP3 Was an einer FhG entsteht ist eine Industrienahe Forschungsaufgabe, einfach mal bei den FhG-Motiven nachlesen.
:
Bearbeitet durch User
Gerhard H. schrieb: > Kommunikations-Speed hinauszulaufen Irgendwo fängt man immer an. Es geht ja nicht um den einen Sensor, wenn noch ein Display dran hängt und viele Sensoren, dann sieht die Sache schon wieder anders aus. Wenn etwas schneller und besser wird und das alte System trotzdem unterstützt, ist das erstmal nicht schlecht, wie ich finde.
Frank O. schrieb: > und besser wird Das ist der springende Punkt. Das muss sich in der Gesamtheit aller Rahmenbedingungen erst noch erweisen. Die Prorität "Vereinfachung" hat technische Entwicklung selten. Daraus folgt auch logisch Vanye R. schrieb: > Und was die Bastler angeht, die meisten sind doch fuer I2C zu > faul/unfaehig und koennen nur fertige Libaries nutzen *** Frank O. schrieb: > Es geht ja nicht um den einen Sensor, wenn noch ein Display dran hängt > und viele Sensoren, dann sieht die Sache schon wieder anders aus. Sicherlich. Mit anziehenden Anforderungen hat Speed natürlich zunehmende Vorteile. Sehr oft ist die Situation aber auch nicht gegeben. Wenn dann I3C zum Nachteil gereicht ist nichts gewonnen. Im Hochspeed-Bereich, gerade bei der Display-Ansteuerung oder dem Empfang von Kamerabildern gibts dann aber auch zunehmende Konkurrenz zu vielen anderen Möglichkeiten und Verfahren.
Ob S. schrieb: > muss man Mitglied dieser > unsäglichen Mafia werden, Klingt wie der Grund, warum sich VHS (JVC) statt beta (Sony) durchgesetzt hat: Beta war das bessere Videosystem, aber VHS-Geräte durften in Linzenz produziert werden. Beta hat dann im professionellen Videobereich als BetaCAM die Nische erobert. Vuielleicht gibt es ja einen Industriezweig, der I³C "pusht".
Bei I2C gibt es die Reset Signalabfolge, wenn der Master erkennt dass das Device nicht mehr korrekt arbeitet, so kann man das ganze mit dieser Reset Seignalfolge wieder zurück holen. Der Timeout dazu macht der Master in der Programmierung alleine (Software). Und wenn der Master kaputt geht kann man diese Peripherie mit einem internen Reset (dieser einen Peripherie, nicht des ganzen Prozessors) ebenfalls wieder zum Leben erwecken. Diesen Timeout dazu kann man ebenfalls im Programm errechnen und die Funktion durchführen. Ich habe das schon einige male so implementiert und damit läuft der Prozessor zuverlässig 24/7. Ob jetzt der Temperaturwert (in meinem Fall) mal ein paar Sekunden nicht kommt ist unwichtig, wichtiger ist es dass er überhaupt wieder kommt. Zum unkkritische Messerte ein zu lesen und Pins beim Prozessor zu sparen ist I²C perfekt geeignet.
:
Bearbeitet durch User
J. S. schrieb: > allerdings wird es der erste Premium > Bezahldekoder :( Den Fehler machen die nicht zweimal. Software war klasse und anfangs sicher ziemlich alternativlos. Dass dann Leute daher kamen und für 3Euro einen LA anboten, der deren Software nutzen konnte (habe ich auch gemacht :-)), war sicher nicht deren Ziel.
Markus M. schrieb: > Zum unkkritische Messerte ein zu lesen und Pins beim Prozessor zu sparen > ist I²C perfekt geeignet. Es muss geeignet sein wenn es den gewünschten Sensor nur mit diesem Interface gibt :) Markus M. schrieb: > kann man diese Peripherie mit einem internen Reset ... ebenfalls wieder zum Leben > erwecken I2C Modul aus/einschalten und neu versuchen ist dazu meine Methode. Da blieb noch nie was dauerhaft hängen, zumindest was mein kleines Spektrum verwendeter Sensoren betrifft. In der Regel gilt: Wenns einmal läuft dann läufts!
Bradward B. schrieb: > Wobei dieses Forum gerade diese "Bequemen" Was ist an bequem falsch? Wenn die Hardware so funktionieren würde, dass du nur den Sensor an deinen Controller stöpseln musst und die Hardware das alles schon kann, würdest du lieber erst eine Library programmieren? Bequemlichkeit ist ein wesentlicher Triebmotor für den Fortschritt; schon immer gewesen. Warum ist Arduino so nach vorne gegangen und wie viele haben das mit den Platinen mittlerweile übernommen? Willst du auch ein Windows-Programm bis zum Prozessor runter programmieren, ohne die Layer dazwischen? Wenn du andere Felgen für dein Auto haben willst, kaufst du die doch auch und baust die nicht selbst. Warum soll jeder für die Kommunikation mit einem Sensor seine eigene Lib schreiben, wenn das schon einer getan hat? Wir sind eine arbeitsteilige Gesellschaft und schon bei der Jagd waren wir dadurch in den Anfängen der Menschheit erfolgreich. Eigentlich hatte wir die schlechtesten Voraussetzungen, um uns an die Spitze der Nahrungskette zu setzen. Es ist allgemein anerkannt, dass wir nur durch unser gemeinsames Handeln so weit gekommen sind.
:
Bearbeitet durch User
> Bei I2C gibt es die Reset Signalabfolge, wenn der Master erkennt dass > das Device nicht mehr korrekt arbeitet, so kann man das ganze mit dieser > Reset Seignalfolge wieder zurück holen. Nur in den Faellen wo du keinen Slave hast der dir SCK runterzieht. Was glaubst du wohl wieso die bei SMB den Timeout eingebaut haben? Weil es auch anders geht und sie Langweile hatten? Vanye
Ob S. schrieb: > 2) Interruptsignalisierung innerhalb des Busses. Das ist ein ziemlich > geiles Feature. Bei I2C braucht man dazu zusätzliche Signale und zwar > für jeden Slave, der einen Interrupt auslösen können soll, eins. > Deswegen wird vielfach auf diese Signalisierung verzichtet und die > Clients dümmlich gepollt. Das ist teuer, kostet Rechenzeit, > Busbandbreite und Energie. Nun, bei I2C könnte man einfach Multimaster mit kollisionsfreier Arbitrierung verwenden, wenn ein Slave dringend was sagen will. Wir hatten das lange Zeit in einem Gerät im Einsatz und es hat auf Anhieb hervorragend funktioniert (24/7). Die Buslast war gering und die Reaktionszeit extrem kurz. Nur hat dann leider Philips/NXP seine 8051 mit I2C vollständig abgekündigt. Eine Umrüstung auf Atmel ATmega8 und AT89LP51RD2 ist dann gründlich in die Hose gegangen, die sind definitiv nicht als Multimaster geeignet. Mit Haufen Timeouts, Retries ging eine Notlösung, allerdings mit unterirdischen Antwortzeiten. Wir habe dann das Gerät auf CAN umrüsten müssen.
Peter D. schrieb: > Wir habe dann das Gerät auf CAN umrüsten > müssen. Moin Peter! Wenn der TO die kurze Frage erlaubt: Wie fängt man am besten mit CAN an. Ich wollte vor Jahren damit anfangen (du weißt um meine Geschichte), aber da fand ich nicht den richtigen Einstieg. Für mich wäre das wirklich sehr interessant, da das in meinem Arbeitsumfeld auch alles CAN ist. Ich bedanke mich schon mal bei dir und den Teilnehmern für die Zwischenfrage.
Vanye R. schrieb: >> Bei I2C gibt es die Reset Signalabfolge, wenn der Master erkennt dass >> das Device nicht mehr korrekt arbeitet, so kann man das ganze mit dieser >> Reset Seignalfolge wieder zurück holen. > > Nur in den Faellen wo du keinen Slave hast der dir SCK runterzieht. > Was glaubst du wohl wieso die bei SMB den Timeout eingebaut haben? > Weil es auch anders geht und sie Langweile hatten? > > Vanye Genau. Das "Rausklocken" hängender Slaves hilft leider nur unter bestimmten Bedingungen. Wenn sich deren Statemachine nur auf Register-Ebene verhakelt hat. Ist das hingegen auf der PHY-Ebene in einem ungünstigen Moment passiert, dann hilft nur eins: PowerCycle. Und das ist hardwaremässig relativ aufwendig. Aber in allen kommerziellen Anwendungen letztlich die einzige wirklich zuverlässige Lösung. Zumindest für alle Devices, die keinen expliziten Reset-Anschluss haben. Und das sind leider recht viele. Das Schlimme ist: ein einziges Target ohne expliziten Reset nötigt typisch dazu, die ganze Härte eines PowerCycle für den gesamten Bus vorzusehen. Weil die Dinger sich halt auch im desolaten Zustand allein über die Einspeisung aus den Pullups hinreichend speisen können, um diesen desolaten Zustand unbeirrbar bis in alle Ewigkeit beizubehalten...
Ob S. schrieb: > wenn das hingegen auf der PHY-Ebene in einem ungünstigen Moment passiert Vermutlich aber nur bei komplexeren Verschaltungen. Sind Dir bestimmte, besonders anfällige Busteilnehmer bekannt?
> Vermutlich aber nur bei komplexeren Verschaltungen. Sind Dir bestimmte, > besonders anfällige Busteilnehmer bekannt? In den neueren Datenblaetten des LM75 kannst bemerkungen dazu finden das er gegen sowas besonders robust sei. Das laesst mich vermuten das dies frueher nicht der Fall war. Und das sind vermutlich auch alles Probleme die nur in den internen Erratas der Hersteller stehen die sie nicht nach aussen geben. Vanye
Ob S. schrieb: > Das "Rausklocken" hängender Slaves hilft leider nur unter > bestimmten Bedingungen. Nun, das hilft schon mal bei sämtlichen Slaves ohne Controller, bei denen SCL nur Input ist, also bei PCFxxx, MCP23016, 24Cxxx usw. Typisch sind aber nicht die Slaves die Ursache, sondern Leitungsprobleme oder Firmwareprobleme der Master bzw. deren Controller. Das Rausklocken behebt also nur die Wirkung, nicht aber die Ursache. Es gibt leider viele µCs, wo ernsthafte Bugs im I2C-Controller vorliegen, z.B. ATmega8. Daher sollte man immer in die Software (Master und Slave) ein Timeout mit programmieren. Was ich bisher an Atmel µC mit I2C probiert habe, da war I2C keine Freude. Also auch die AT89C51xxx haben ernsthafte Macken. Ob sich das mit den ständig neuen AVR-Serien von Microchip verbessert hat, kann ich nicht sagen. https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html Ob S. schrieb: > Das Schlimme ist: ein einziges Target ohne expliziten Reset nötigt > typisch dazu, die ganze Härte eines PowerCycle für den gesamten Bus > vorzusehen. Daß wirklich nur ein harter Power off hilft, habe ich noch nie erlebt. Kannst Du dazu was näheres sagen?
:
Bearbeitet durch User
Frank O. schrieb: > Wie fängt man am besten mit CAN an. Das ist nicht kompliziert. Angefangen haben wir mit dem Siemens C50C. Der hat 15 MOBs (message objects). Die kann man wahlweise zu Senden oder Empfangen initialisieren. Bekommen MOBs den gleichen ID, dann werden sie quasi als Empfangspuffer nacheinander befüllt. Wir haben aber noch zusätzlich einen Message-FIFO im SRAM angelegt. Später haben wir den AT89C51CC03 und den AT90CAN128 verwendet. Der CAN-Controller ist bei allen 3 gleich aufgebaut, d.h. auch 15 MOBs. Zur Programmierung gibt es nicht viel zu sagen. Man setzt die Timingregister für die gewünschte Baudrate und initialisiert die MOBs. Und dann wartet man auf die Interrupts. In den Codebeispielen findet man alles nötige. Ich finde es sogar einfacher als RS-485, da man sich keine komplexen Protokolle ausdenken muß. Damit ein Paket nicht mehr durchkommt, müssen schon extreme Störungen auftreten (Kabel gerissen, VCC ausgefallen).
Peter D. schrieb: > Ob sich das mit den ständig neuen AVR-Serien von Microchip verbessert > hat, kann ich nicht sagen Meine I2C-Anbindung (Asm) eines HYT271 an einen Mega4809 hat mich noch nie im Stich gelassen, entsprechendes dürfte für alle I2C Module neuerer AVRs gelten- und ebenso für mindestens die älteren Mega88 die ich im Dauerbetrieb habe. Zumindest wenn dort Fehler detektierbar sind werden sie mit einem Neustart des I2C Moduls zuverlässig weggebügelt. Wir weichen nun erheblich vom I3C Thema ab- mangels Erfahrungen dürfte es dazu allerdings nicht mehr als aktuelle Werbe-Aussagen geben.
> Es gibt leider viele µCs, wo ernsthafte Bugs im I2C-Controller > vorliegen, z.B. ATmega8. Korrekt. Selbst bei normalen I2C haben schon viele Controller die eine oder andere Schwachstelle und wenn es dann noch Multimaster oder Slavebetrieb gibt dann schwillt die Errataliste bereits erstaunlich an. Tja und dann kommt jetzt I3C wo es noch um einige dB komplexer wird. :-) > Daher sollte man immer in die Software (Master > und Slave) ein Timeout mit programmieren. Klar, komischerweise sehe ich aber im Source im Netz nur so Dinge wie while(!Flag_blabla); ...und die meisten lesen den Source noch nicht mal durch.... Vanye
Ich staune immer wieder, wie es Philips bloß gelungen ist, auf Anhieb einwandfrei funktionierende µCs mit I2C herzustellen, sowie eine gut lesbare Spezifikation zu veröffentlichen. Der Beispielcode von Philips war auch sehr gut. Ich hatte ihn mit nur geringen Anpassungen übernommen.
ST/NXP hat einen informativen Beitrag: https://www.st.com/resource/en/application_note/an5879-introduction-to-i3c-for-stm32-mcus-stmicroelectronics.pdf https://www.nxp.com/docs/en/application-note/AN14005.pdf
> Ich staune immer wieder, wie es Philips bloß gelungen ist, auf > Anhieb einwandfrei funktionierende µCs mit I2C herzustellen, Weiss eigentlich einer was das allererste IC mit I2C war? PCF8574? Irgendein EEPROM fuer TV? Ich denke mal Microcontroller wird wohl ein MCS51 Derivat gewesen sein? Ich muesste auch irgendwo noch eine Stange mit 256Byte Ram haben. Ich glaube das war das erste IC das sie damals abgekuendigt haben. :-D Vanye
Vanye R. schrieb: > Tja und dann kommt jetzt I3C wo es noch um einige > dB komplexer wird. :-) Jetzt? Abwarten. Wurde vor immerhin 8 Jahren vorgestellt. Was hat sich in der Zwischenzeit auf den Märkten und in Controllern getan? Nicht allzuviel würde ich sagen. Vom Speed her positioniert sich I3C ja zwischen I2C und SPI. Letzteres bliebe da gegenüber I3C meine bevorzugte Wahl. Noch schneller. Viel einfacher. Längst in jedem Controller verfügbar.
Na ja, 8 Jahre sind bei solchen Sachen nicht gerade schnell, aber auch nicht so langsam und wie wir feststellen konnten, die Zahl der Sensoren, die auch I3C können, sie wächst. Abwarten. Was wir auch feststellen können, dass schnell mal ein neues Pferd vor der Tür steht und da es schon dort steht, wird es irgendwer reiten. Sieht man immer wieder, zB. bei ESP32. Die Dinger sind billig und schön machen die nicht nur noch WiFi, sondern werden (zumindest im Hobbybereich) als vollständige Lösung eingesetzt. Allerdings und das sieht man an der Kombination I2C/I3C, dass die Industrie auch nicht unbedingt auf dieses Pferd setzt.
> Was hat sich in der Zwischenzeit auf den Märkten und in Controllern > getan? Nicht allzuviel würde ich sagen. Naja, es nimmt alles seinen langsamen sozialistischen Gang. :) Aber meine Insiderinfos besagen das da gerade einiges passiert und du kannst jetzt ja auch sowohl Controller wie Devices von verschiedenen Herstellern kaufen. Sie versuchen es also... > Vom Speed her positioniert sich I3C ja zwischen I2C und SPI. Ja, da haette ich eigentlich auch mehr oder garnix erwartet... Das meiste I2C-Zeug ist ja schnarchlahm und muss auch garnicht schneller sein! Es gibt natuerlich Zeug wo man es schneller haben will, nehmen wir mal einen AD-Wandler. Aber will ich mir dann den Busoverhead antun? Will auf demselben Bus dann noch andere Devices rumduempeln haben? Eher nicht. Gibt es es wirklich Anwendungen wo man mehr wie 3-4 I2C Bausteine an einem Bus braucht? Mir faellt gerade nix ein. Ich frage mich ja schon immer wer die 2-9 I2C-Busse braucht die man in einem modernen Controller so finden kann. Mir ist das insgesamt alles zuviel Nische als das ich mich Frage ob sich das durchsetzt. Was ich dagegen nicht jeden Tag aber doch regelmaessig brauche ist Potentialtrennung. Das ist mit I2C schon ein Schmerz im Arsch, mit I3C vermutlich nochmal eine ordentliche Steigerung... Ich hab ja manchmal den Verdacht die Hersteller haben heute die Moeglichkeit soviel Zeugs in ihren Controllern reinzumachen das denen die Ideen fuer neues ausgegangen sind. :) Vanye
Der Grund, warum wir damals (1995) auf Multimaster-I2C gesetzt haben, war ja gerade, daß man eben nicht ständig pollen muß, sondern die Slaves jederzeit selber sprechen können. Damit hatten wir geringe Buslast, schnelle Antwortzeiten und wenig CPU Auslastung. Daß inzwischen Philips sich davon verabschiedet hat und andere Hersteller das I2C gründlich verkackt haben, konnten wir ja nicht ahnen. Riesige Datenraten sind überhaupt nicht nötig. Es hätte völlig gereicht, das I2C gleich zuverlässig, wie bei Philips zu machen. Aber die I2C Implementierungen einfach schrottig zu lassen und ein komplett neues I3C Pferd aufzuzäumen, ist mal wieder typisch. Ich sehe darin keinen Sinn. Und ich glaube auch nicht, daß z.B. bei der neuen tinyAVR® 2 Family die I2C Fehler korrigiert worden sind. Bei uns ist nun der Drops gelutscht mit CAN. Zu I2C/I3C führt kein Weg mehr zurück.
Vanye R. schrieb: > Ich hab ja manchmal den Verdacht die Hersteller haben heute > die Moeglichkeit soviel Zeugs in ihren Controllern reinzumachen > das denen die Ideen fuer neues ausgegangen sind Oh da hätte ich aber noch reichlich Ideen, die dem Programmierer das Leben deutlich einfacher machen könnten :) Stichwort mehr Automatiken, mehr Intelligenz... Die Antwort der Hersteller besteht leider allzuoft im Ausbau der Konfigurationsorgien. I3C lässt da nichts Besseres erwarten. Peter D. schrieb: > Und ich glaube auch nicht, daß z.B. bei der neuen tinyAVR® 2 Family die > I2C Fehler korrigiert worden sind Du glaubst, Peter. Ich weiß, daß der Ansteuer- Mechanismus ein anderer ist, die Hardware demzufolge geändert. Fehler konnte ich noch keine feststellen, auch die Errata meines bevorzugten AVR-DD enthalten nichts dergleichen.
> Bei uns ist nun der Drops gelutscht mit CAN. Zu I2C/I3C führt kein Weg > mehr zurück. Wenn du Anwendungsszenarien hast wo du I2C durch CAN ersetzen kannst, dann bist du IMHO auch sehr weit vom eigentlichen Gedanken dieses Bussystems weg. > Oh da hätte ich aber noch reichlich Ideen, die dem Programmierer das > Leben deutlich einfacher machen könnten :) Irgendwas kann einem immer einfallen, aber eigentlich muss ich immer gaehnen wenn ich neue Controller sehe. Und ich kenne wirklich niemanden der gedacht hat das I2C krass verbessert werden muss, ausnahme ein Timeout in den Slaves. Vanye
Vanye R. schrieb: > Und ich kenne > wirklich niemanden der gedacht hat das I2C krass verbessert > werden muss, ausnahme ein Timeout in den Slaves. Als Lib- Anwendersicht möglicherweise. Die Vereinfachung der Ansteuerung auf unterstem Hardware- Level käme aber immer auch den Leveln weiter oben mit verbesserten Treibern zugute. Trotzdem wird lieber wieder eine neue Sau, ein neues "I3C Feature" mit Kinderkrankheiten durchs Dorf getrieben. Schon daß die Spezifikation nur teilweise offen liegt zeigt doch, daß a) dem Entwickler das Leben nicht einfacher gemacht wird und b) die Doku= die Komplexität sicher viel umfangreicher ausfällt.
Harald K. schrieb: > Ob S. schrieb: >> muss man Mitglied dieser >> unsäglichen Mafia werden, die sich MIPI-Alliance nennt > > Und damit ist I3C 'raus. Irgendwann kommt einer und postet die Infos bei GitHub.
> Die Vereinfachung der Ansteuerung auf unterstem Hardware- Level käme > aber immer auch den Leveln weiter oben mit verbesserten Treibern zugute. Das hat doch nichts mit der Busdefinition zutun. Das ist Sache der Hardwareimplementation des Hersteller und da gibt es solche und solche Loesungen. > Schon daß die Spezifikation nur teilweise offen liegt Was konkret fehlt denn? Ich hab jetzt erstmal nicht den Eindruck als wenn man da viel Geheimhalten kann, einfach weil dann kein Debugging mehr moeglich ist. Das ist ja nicht wie bei SD wo man einfach bestimmte Kommandos komplett weglassen kann. Dafuer ist I3C dann IMHO doch etwas zu primitiv. > Irgendwann kommt einer und postet die Infos bei GitHub. Fuer industrielle Entwickler irrelevant weil du das kaum in dein Projekt ziehen willst und Bastler sind fuer verbreitung und Marktdurchdringung irrelevant. Vanye
Vanye R. schrieb: > Das hat doch nichts mit der Busdefinition zutun Nein. Aber mit der letztendlichen Praxis. > Bastler sind fuer verbreitung und > Marktdurchdringung irrelevant. Wird gerne unterschätzt. Professionelle Entwickler sind oft auch -du ahnst es- Bastler! > Was konkret fehlt denn? Ich hab jetzt erstmal nicht den Eindruck > als wenn man da viel Geheimhalten kann, einfach weil dann kein > Debugging mehr moeglich ist Das ist weiter oben behauptet worden. Doch würde ich Dir Recht geben: Was sollte da geheim bleiben? Ob das Debugging allerdings angesichts viel höherer Frequenzen so einfach bleibt?
Vanye R. schrieb: >> Irgendwann kommt einer und postet die Infos bei GitHub. > > Fuer industrielle Entwickler irrelevant weil du das kaum in dein > Projekt ziehen willst und Bastler sind fuer verbreitung und > Marktdurchdringung irrelevant. Und du glaubst wirklich dass jede Firma diese Sourcen ignorieren wird? KMUs suchen sich passende Codes zusammen, damit sie das Ziel ereichen was der Kunde möchte. Und wenn dann auf GIT noch die Lizenz als MIT gekennzeichnet ist, wunderbar.
> Wird gerne unterschätzt. Professionelle Entwickler sind oft auch -du > ahnst es- Bastler! Nee. Glaub mir ich kenne reichlich. Der Prozentsatz ist klein einstellig. > Ob das Debugging allerdings angesichts viel höherer > Frequenzen so einfach bleibt? Ach, 12.5Mhz ist eigentlich keine Frequenz. Aufwendiger wird das Debugging weil auf dem Bus komplexere Zustaende herrschen. Aber auch wegen dem Uebergang Opendrain zu PushPull. Da will man dann sein Scope wieder analog auf der Leitung haben und will auch sehr gerne eine gute Busdekodierung im Scope haben und man will hoffen das die fehlerfreier ist wie die Bauteile die man dann damit debuggt. Interessant ist die Frage: Wieso zur Hoelle nur maximal 12.5Mhz? Warum nicht 50? Ich meine man muss das ja nicht ausnutzen. Ich denke mal da waer man dann nicht mehr physikalisch kompatibel zu I2C gewesen. Soll heissen man wuerde den Bus terminieren wollen, was man bei SPI ja gerne macht, aber das vergurkt dir dann die Pegel im OpenDrainmodus. Also wird 12.5 wohl das maximale sein was machbar ist. Und das wiederum heisst das du sehr gerne den Bus erstmal analog abschnorchelst ob deine Implementation wirklich gut ist. So jedenfalls meine Therorie. BTW: Gibt es schon Vorstellungen zur maximalen Leitungslaenge? Einmal quer ueber den Weihnachtsbaum wohl eher nicht... > Und du glaubst wirklich dass jede Firma diese Sourcen ignorieren wird? Wir reden nicht von Sourcen sondern vom I3C Standard. Vanye
Vanye R. schrieb: > Interessant ist die Frage: Wieso zur Hoelle nur maximal 12.5Mhz? Warum > nicht 50? Ich meine man muss das ja nicht ausnutzen. Ich denke mal da > waer man dann nicht mehr physikalisch kompatibel zu I2C gewesen. Genau. Im reinen I3C-Betrieb (also unter Verzicht auf die Anbindung von I2C-Slaves am gleichen Bus) sind 33Mhz spezifiziert.
Vanye R. schrieb: >> Und du glaubst wirklich dass jede Firma diese Sourcen ignorieren wird? > > Wir reden nicht von Sourcen sondern vom I3C Standard. Du vielleicht! Oder hast du die Einleitung zu diesem Thema gar nicht gelesen oder gar verstanden? Ob S. schrieb: > Der Hauptnachteil ist aus meiner Sicht: Das Protokoll ist im Gegensatz > zu I2C NICHT offen. Nur eine Teilmenge wird veröffentlicht, um in den > Genuss der vollen Infoflut zu kommen, muss man Mitglied dieser > unsäglichen Mafia werden, die sich MIPI-Alliance nennt. Und das kostet > ein kleines Vermögen. Und wer macht das Protokoll am Ende? RICHTIG! Der uC. Und wie? Durch sein Programm! Woher kommt es? Diese Antwort kannst du (sofern du schlau genug sein solltest) selbst beantworten.
> Und wer macht das Protokoll am Ende? RICHTIG! Der uC. Und wie? Durch > sein Programm! Woher kommt es? Diese Antwort kannst du (sofern du schlau > genug sein solltest) selbst beantworten. Ich hasse es ja zu solchen Worten greifen zu muessen, aber bist du zu wenig klug fuer diese Welt? Das Protokoll macht in diesem falle die MIPI Alliance wie du selber gequotet hast. Die Implementation macht der Hersteller der MCU der den Verilog Code dafuer schreibt. Das Programm nutzt das am ende alles nur. Wenn du es nur nutzt dann darfst du bloed sein und schreibst einfach ein paar Werte in Register und die maximal Bloeden kopieren sich dann das sogar noch von GIT. Aber wenn du ein Problem hast und dein Oszi auf dem Bus steckt dann musst DU das Protokoll verstehen damit du Fehler finden kannst. Vanye
Vanye R. schrieb: > aber bist du > zu wenig klug fuer diese Welt? I B N D B! Man merkt das du nur aus der Theorie kommst. Herablassend, besserwisserisch und keine Ahnung wie es in der Firmenwelt zugeht. Du bist der perfekte Politiker.
:
Bearbeitet durch User
Dieser Thread wird seit 1 Woche zugespamt. Viele der Beiträge nehmen keine Rücksicht auf meine initiale Frage. Dem Webmaster ist es auch egal, was damit passiert. Gemeldete Beiträge werden nicht bearbeitet. Ich danke explizit allen, die sich Mühe gegeben haben, etwas zum Thema I3C zu posten. Dann nehme ich meinen Beitrag auch her, und schreibe rein, was ich gerade schreiben will. Das Verhalten vieler hier ist eine Zumutung! Ich hatte auch schon mal darauf hingewiesen, ( Beitrag "Re: Jemand schon mal I3C (nicht I2C!) genutzt?" ) aber es juckt ja doch niemand!
:
Bearbeitet durch User
Hallo, hier habe ich Ergebnisse von einer Umfrage aus dem Hause STMicroelectronics: https://www.instagram.com/tam.hanna/reel/C68cCzgNOmu/ Tam
Martin M. schrieb: > Viele der Beiträge nehmen keine Rücksicht auf meine initiale Frage Darauf gabs eine klare Antwort: Gerhard H. schrieb: > Martin M. schrieb: >> Aber mir geht es explizit um Erfahrungen, >> die schon mal jemand mit I3C (3!) gemacht hat. > > Ich tippe mal: Keiner. Was langt Dir daran nicht? Es ist wie es ist, da lässt sich nichts erzwingen. Vielmehr besagt es auch was über I3C: Der alles überzeugende Brüller ists bislang eben nicht! Daß sich in der Folge eine Diskussion ums weitere Umfeld der Geschichte- und zwar explizit auch um den erfolgreichen Vorgänger entwickelt sollte doch niemanden überraschen. Der gibt vielleicht sogar eine Antwort warum der Nachfolger seit Vorstellung 2016 nicht in die Gänge kommt: Die 2er Technik ist für sehr viele Fälle ausreichend und simpler beherrschbar... Komplexere Technik um der Technik willen?
Gerhard H. schrieb: >> Ich tippe mal: Keiner. Wenn ausdrücklich nach Erfahrung gefragt wurde und keiner Erfahrung hat, dann sind > 50 Antworten schon ganz enorm. In der Überschrift steht explizit "(nicht I2C!)". Muss ich denn eine Diskussion off-topic zumüllen, wenn ich zum Thema direkt nichts beizutragen habe? Macht doch dann einfach euren eigenen Beitrag auf. Kostet doch nichts! Themenvorschläge für eure neuen Beitrage: "Warum hat sich I3C nicht durchgesetzt?" "Was ist heute noch an I2C Mist?" "Wer kennt USB?" "Wer weiß sonst nichts mit seiner Zeit anzufangen?" "Findet sonst noch jemand Mist, dass xxx Geld kostet?" Schönen Sonntag!
:
Bearbeitet durch User
Martin M. schrieb: > Muss ich denn eine Diskussion off-topic zumüllen Offtopic ist immer relativ. Zuweilen finden sich offtopic sogar Anregungen welche die Sicht ontopic in ein ganz neues Licht setzen. Ansonsten scheinst Du in Foren noch nicht oft unterwegs gewesen zu sein. Daß Dich Null Antworten "mit I3C Erfahrung" mehr befriedigt hätten wage ich ebenfalls zu bezweifeln.
Gerhard H. schrieb: > Die 2er Technik ist für sehr > viele Fälle ausreichend und simpler beherrschbar... Komplexere Technik > um der Technik willen? Wenn dir die 2er Technik ausreicht, dann nimm sie um Gottes Willen. Mir geht es darum, herauszufinden, ob ich die 3er Technik für etwas Neues einsetze. Mir sind Fehler egal, die schon seit 20 Jahren im Controller X sind. Ich nehme Controller X nicht! Die 3er Technik bietet scheinbar Features, die die 2er Technik nicht hat und deshalb finde ich es wichtig, sich zu informieren und evt. auch Versuche in die Richtung zu unternehmen. Ich mache die 2er Technik deshalb auch nicht schlecht, weil sie genauso ihre Daseinsberechtigung hat, eben für andere Einsatzfälle und unter Berücksichtigung von Spezialitäten, die man beachten muss.
:
Bearbeitet durch User
Martin M. schrieb: > deshalb finde ich es wichtig, sich zu informieren Legitim. Nur darfst Du (hier) nichts erwarten was die Materie schlicht (noch) nicht hergibt.
> Mir geht es darum, herauszufinden, ob ich die 3er Technik für etwas > Neues einsetze. Dann beweg entweder deinen Hintern und lese die Datenblaetter selber oder ruf einen von uns morgen frueh an. Ich denke so ab 200Euro/h kann man ueber eine ordentliche Marktanalyse reden. Hier aber bist du in der Kneipe... Oder ruf deine FAEs an. Die werden dir schon sagen das alles toll ist. Vanye
Gerhard H. schrieb: > Ansonsten scheinst Du in Foren noch nicht oft unterwegs gewesen zu sein. Nicht kritikfähig? Auf persönlichen Angriff schalten, wenn man mit Kritik konfrontiert wird? Normalisieren von Schwachsinn? In dem Forum wird immer Schwachsinn gepostet, dann darf ich dies auch? Man darf nicht vergessen, dass es sich hier um ein Hobby-Forum handelt, nicht um ein Forum einer Firma oder eines Spezialthemas. Aber das Forum ist auch immer das, was die Benutzer daraus machen.
Es gibt hier im Forum viele Beiträge, in denen mit viel Aufwand und Zeit enorm viel erreicht worden ist. Ich finde es toll, wenn Leute ihre Projekte vorstellen, herausgefundene Infos teilen, anderen Leuten mit Rat und Tat weiterhelfen. Oder auch die Artikelsammlung: https://www.mikrocontroller.net/articles/Hauptseite
:
Bearbeitet durch User
Martin M. schrieb: > Nicht kritikfähig? Auf persönlichen Angriff schalten, > wenn man mit Kritik konfrontiert wird? Ich glaube Du redest von Dir! Nicht vorschnell auf andere übertragen bitte. Martin M. schrieb: > Ich finde es toll, wenn Leute ihre Projekte vorstellen, > herausgefundene Infos teilen, anderen Leuten mit Rat und Tat > weiterhelfen. Wie löblich. Doch nochmal zum Mitschreiben: Wo Erfahrungen (noch) nicht gemacht wurden können sie auch nicht geteilt werden.
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.