Hallo, Wie kann man die einwandfreie Funktion von z.B. einem I2C Bus in einer Schaltung zeigen? Ich habe von meinem Vorgänger ein paar lose Blätter bekommen und dort hat er mit Hilfe von VOH, VOL, VIH, VIL und dessen Toleranzen und einer Messung von High and Low Pegeln (Oszilloskop) kurz skizziert das die Pegel in Ordnung sind. Was mir dazu einfällt ist halt der Umstand das Oszilloskope nicht wirklich toll sind wenn es um Pegel geht. Gibt es da etwas besseres? Oder gibt es da fertige Geräte? Einer der Programmierer meinte man sollte es eher indirekt machen. Schreiben / Lesen und sehen ob das wir das Erwartete erhalten. Wie macht ihr so etwas? Oder simuliert man sowas? Speziell wenn mehrere Teilnehmer da sind. Danke im Vorraus.
Man macht einen "harten" 24h Dauertest mit 95% traffic in einer Klimakammer und schaltet dabei die Stromversorgung zwischen unteren und oberen Limit. Und ja, es gibt auch Normen für solche Tests aka Prototypqualifizierung. Bspw Stanag 4370.
I2C ist notorisch anfällig. Die kleinste Störung kann ihn komplett aus dem Takt bringen. Besonders natürlich weil die 1 nur mittels eines hochohmigen Signals erzeugt wird (Pullup). Wenn du den Bus wirklich verifizieren willst, müsstest du die (garantiert fehlerhafte) Logikschaltung der I2C-Peripherie des Controllers kennen und prüfen was passiert, wenn in jedem Moment ein Bit falsch ankommen kann. Das ist natürlich nicht machbar, weil man darauf keinen Zugriff hat. Du kannst also höchstens validieren, z.B. durch ausführliche Tests. Du kannst versuchen, in jeder Stufe der Kommunikation (Startbit, Adresse, ACK-Bits, Datenbits, Stopbit) eine Störung zu produzieren und sehen wie das System reagiert. Ich kann dir verraten wie es ausgeht: Weil die meisten I2C-Protokolle keinerlei Konsistenzprüfung (CRC o.ä.) haben, werden unbemerkt falsche Daten übertragen. Ein falsch angesteuertes I2C-Gerät kann sich dadurch komplett aufhängen. Auch die I2C-Peripherie mancher Controller (z.B. die alten STM32) kann sich bei sowas komplett aufhängen und muss hart resettet werden. Falls du also nicht ausführliche Checks in Software machst (CRC, Timeouts) und bei Bedarf sowohl die I2C-Peripherie als auch das externe Gerät resettest, ist deine Implementation fehleranfällig. Ich hatte mal ein PCB wo ich alle 30sec das externe I2C-Gerät mittels Reset-Leitung zurückgesetzt habe, weil die ständigen Übertragungsfehler nicht erkannt werden können und das Gerät zum abstürzen brachten. In Version 2 wurde dann SPI verwendet...
Daisy D. schrieb: > Was mir dazu einfällt ist halt der Umstand das Oszilloskope nicht > wirklich toll sind wenn es um Pegel geht. Kommt auf das Oszilloskop an... Und natürlich sind Oszilloskope anerkannte Messmittel, wenn es um Signalintegrität geht. Ganz herausragend ist z.B. das "Augendiagramm", mit dem die Signalqualität von Hochgeschwindigkeitsbussen geprüft wird. Daisy D. schrieb: > Wie macht ihr so etwas? 1. Die Signalintegrität sicherstellen: sieht jedes der beteiligten ICs an seinen Pins das Signal in der Form wie es im Datenblatt des Bausteins für den jeweiligen Pin spezifiziert ist? 2. Sicherstellen, dass das Bit-Timing zu dem passt, was im Datenblatt steht. 3. Bei Raumtemperatur ein Dauerlauf mit Dauerlast über Nacht bzw. übers Wochenende. Am drauffolgenden (Mon)Tag muss die Software "0 Übertragungsfehler" melden. 4. Das selbe im Klimaschrank mit Temperaturzyklen von -20°C bis 100°C. 5. Das selbe mit Vcc an der Untergrenze. 6. Das selbe mit Vcc an der Obergrenze. 7. Zwischendurch auch mal den "EMV-Test des kleinen Mannes": Beitrag "Re: Tiefentladungsschutz mit Attiny und P-Kanal Fet"
:
Bearbeitet durch Moderator
Daisy D. schrieb: > Was mir dazu einfällt ist halt der Umstand das Oszilloskope nicht > wirklich toll sind wenn es um Pegel geht. Doch, sind sie, auf 1% kommt es dabei nicht an. Und das Ankoppeln eines Tastkopfes verschlechtert das Signal höchstens, wenn es dann also immer noch innerhalb der Specs ist, ist zwar nicht gewährleistet, dass der Bus funktioniert, aber es läge dann an einem Baustein der nicht spec-konform reagiert, und nicht am Aufbau.
> Wie kann man die einwandfreie Funktion von z.B. einem I2C Bus in einer > Schaltung zeigen? Wie schon jemand gesagt hat, man kann eine ganze Menge Aufwand treiben um einen digitalen Bus zu spezifizieren/zertifizieren und in bestimmten Anwendungen macht man das auch. Das Problem bei I2C ist aber leider das es dort keine garantierte einwandfreie Funktion gibt. Es kann dir da immer passieren das ein Slave, z.B aufgrund eines Uebertragungsfehlers (Surge) ploetzlich SDA und SCL dauerhaft auf GND zieht und da erst mit einem Powercycle wieder rauskommt. Deshalb hat man ja bei SMB, im Prinzip eine Art I2C, sowohl einen minimal Takt wie auch einen Timeout definiert. Daher brauchst du dir keine weiteren Gedanken machen, alleine mit der Wahl von I2C bist du bereits durchgefallen. .-) Olaf
MaWin schrieb: > Und das Ankoppeln eines Tastkopfes verschlechtert das Signal höchstens Manche haben es schon geschafft, Busse zu bauen, die nur mit angeschlossenem Oszi-Tastkopf liefen... ;-) War natürlich letztlich trotzdem irgendein Timing verletzt.
Daisy D. schrieb: > Was mir dazu einfällt ist halt der Umstand das Oszilloskope nicht > wirklich toll sind wenn es um Pegel geht. Doch, genau dafür sind Oszilloskope da. Sie stellen den Verlauf der Spannung über die Zeit dar. Damit kannst du prüfen, ob die Pegel (LOW/HIGH) im Rahmen sind und ob die Flanken steil genug sind. Auf 1% Genauigkeit kommt es da nicht an, denn ein korrekt gestaltetes Gerät bleibt sowieso weit von den Grenzwerten entfernt. > Einer der Programmierer meinte man sollte es eher indirekt machen. > Schreiben / Lesen und sehen ob das wir das Erwartete erhalten. Diese Trial&Error Methode sagt nichts darüber aus, wie zuverlässig es unter anderen Rahmenbedingungen funktionieren wird. Zum Beispiel wenn sich die Temperatur ein paar Grad verändert. Als zusätzlicher Test in einer Klimakammer macht es allerdings Sinn.
:
Bearbeitet durch User
> Diese Trial&Error Methode sagt nichts darüber aus, wie zuverlässig es > unter anderen Rahmenbedingungen funktionieren wird. Das gilt aber genauso auch fuers Messen mit dem Oszi. Da schaden auch Messungen im Klimaschrank nicht. Da hab ich schon erstaunliches gesehen. Olaf
Hallo, wenn man die I2C Spezifikationen einhält, ist I2C schon zuverlässig. I2C wurde von Philips entwickelt. Die I2C Spezifikationen sollte man sich unbedingt anschauen. https://www.nxp.com/docs/en/user-guide/UM10204.pdf Sollte es bei langen Leitungen zu Problemen kommen, dann geht man einfach mit der Taktfrequenz herunter. Man muß ja nicht immer mit 100 kHz oder 400 kHz arbeiten. Eine Faustformel sagt, Eine Halbierung der Taktfrequenz verdoppelt die Reichweite. mfg Klaus
> wenn man die I2C Spezifikationen einhält, ist I2C schon zuverlässig. I2C > wurde von Philips entwickelt. Es ist zuverlaessig fuer TVs und anderem Consumerkram. Wenn von 100000Kunden fuenf dabei sind die einmal im Jahr den Stecker ihres TVs kurz rausziehen muessen dann ist das nicht weiter schlimm. Wenn der Spurassistent deines Autos jedes Jahr fuenf Leute in den Gegenverkehr lenkt weil I2C haengt ist das nicht akzeptabel. In der Praxis hat man natuerlich haeufig Anwendungen zwischen diesen beiden Extremen. Da muss man halt abschaetzen ob man mit den Problemen leben kann oder nicht. Aber sie lassen sich nicht wegdiskutieren. Aber Leute die eine "einwandfreie Funktion einer Schaltung" jemand anderem beweisen wollen, gehoeren tendenziell zu letzerem und nicht zu kleinen Arduino-Weihnachtsbaumbastlern. .-) Olaf
Daisy D. schrieb: > Wie kann man die einwandfreie Funktion von z.B. einem I2C Bus in einer > Schaltung zeigen? Durch diverse Stresstest. Einfach nur im Labor bei Sonnenschein einschalten ist zu wenig. > Ich habe von meinem Vorgänger ein paar lose Blätter bekommen und dort > hat er mit Hilfe von VOH, VOL, VIH, VIL und dessen Toleranzen und einer > Messung von High and Low Pegeln (Oszilloskop) kurz skizziert das die > Pegel in Ordnung sind. Naja. > Was mir dazu einfällt ist halt der Umstand das Oszilloskope nicht > wirklich toll sind wenn es um Pegel geht. So ein Unsinn! > Gibt es da etwas besseres? Oder gibt es da fertige Geräte? Jaja, die Wundergeräte, die alles aufs Mikrovolt genau messen und am Ende ein Zettel rauskommt, der dich juristisch bis in alle Ewigkeit entlastet. > Einer der Programmierer meinte man sollte es eher indirekt machen. > Schreiben / Lesen und sehen ob das wir das Erwartete erhalten. Das ist ein minimaler Funktionstest. Der ist trivial. > Wie macht ihr so etwas? Mit einem möglichst harten Stresstest. Das kann man nahezu beliebig aufwändig machen. Minimale/Maximale Temperaturen, dito Versorgungsspannungen. Dann mit Störeinkopplungen verschiedenster Art. >Oder simuliert man sowas? Nö. > Speziell wenn mehrere > Teilnehmer da sind. Dann kann/sollte man möglichst stressige Dauerzugriffe machen, was der Bus hergibt. Und dann schauen, ob und wieviele Fehler auftreten (Keine Antwort, fehlerhafte Daten etc.)
Olaf schrieb: > Aber Leute die eine "einwandfreie Funktion einer Schaltung" jemand > anderem beweisen wollen, gehoeren tendenziell zu letzerem und nicht > zu kleinen Arduino-Weihnachtsbaumbastlern. .-) Ja, auch ich kenne solche Projekte. Das erinnerte mich immer an "Per Anhalter durch die Galaxis".😉 Vogonen, Anweisungen in dreifacher Ausfertigung unterschrieben, eingereicht, zurückgereicht, beanstandet, verloren, gefunden, einer öffentlichen Untersuchung unterworfen, wieder verloren und schließlich drei Monate in weichen Torf gesteckt und als Feueranzünder wiederverwendet werden. https://haiopaia.wordpress.com/tag/burokratie/ mfg Klaus
Dieses Herumreiten auf der Temperatur macht mich stutzig. So etwas popeliges wie eine LCD-Ladungspumpe kann den I²C schon stören. Also eher einen Dauertest mit einem kräftigen Störer daneben, aber wichtig dabei: Jede einzelne Übertragung gegentesten, also man muss auch wirklich sicher sein dass die Daten korrekt ankommen (und nicht nur dass überhaupt irgendwelche Daten ankommen). Andere Datenbusse wie SD-bus, USB, CAN haben nach jedem Datenpaket eine Prüfsumme und können somit Fehler erkennen, egal ob sie jetzt durch Temperatur, EMV, Wackelkontakt oder whatever ausgelöst werden; bei I²C wird fast alles durchgewunken...
Programmierer schrieb: > Dieses Herumreiten auf der Temperatur macht mich stutzig. So etwas > popeliges wie eine LCD-Ladungspumpe kann den I²C schon stören. Wenn man NULL Plan von Schaltungsdesign und EMV hat. > Also eher > einen Dauertest mit einem kräftigen Störer daneben, Ja, aber einfach einen "Störer" nutzen ist halbgar. Wenn der Koppelpfad nicht gegeben ist, passiert da nix. Und anders herum, wenn extrem unrealistisch viel einkoppelt, geht gar nix. Das ist nicht so einfach abschätzbar, das brauch einiges an Wissen und Erfahrung.
Falk B. schrieb: > Ja, aber einfach einen "Störer" nutzen ist halbgar. Wenn der Koppelpfad > nicht gegeben ist, passiert da nix. Naja, oder einfach nur wenig, aber nicht nichts. Wenn da einmal pro Stunde ein Bit kippt, muss man den Fall testen. Und wenn man auf gekippte Bits testet, hat man automatisch alle möglichen Quellen für gekippte Bits mit erledigt, nicht nur Temperatur.
> Ja, auch ich kenne solche Projekte. Das erinnerte mich immer an
Genau. Bei jedem Projekt rotieren heute mindestens 1GB an Dokumenten
auf ewig auf irgendwelchen Festplatten und werden niemals mehr
angeschaut. :-D
Olaf
Programmierer schrieb: > Dieses Herumreiten auf der Temperatur macht mich stutzig. Wieso herumreiten, der Arbeitstemperaturbereich ist nun mal Bestandteil der Spec, also muss das Dingens darüber verifiziert werden. Dabei popen wegen der Temperaturdrift div. Bauteilparamtere gern noch andere Fehldimensionierungen auf. > Also eher > einen Dauertest mit einem kräftigen Störer daneben Störer sind i.d R. nicht Betandteil der Spec. also wird darauf nicht getestet. (Ausnahme, das was die EMV bzgl Störeinstrahlung) verlangt Ich glaube, hier wird "Verifikation" mit "robust machen ohne Wissen über erwartbare Störszenarien" verwechselt. > Andere Datenbusse wie SD-bus, USB, CAN haben nach jedem Datenpaket eine > Prüfsumme und können somit Fehler erkennen, > ... bei I²C wird fast alles durchgewunken... Njein, auch bei I2C kann man das Übertragungsprotokoll um eine CRC ergänzen, ist natürlich nicht so bequen wie ne fertige protokollkonforme CRC-Hardware. Die nützt aber auch nichts wenn die Verbindung Scheisse implementiert ist, die kann Störungen nur anzeigen aber nicht beheben. Insofern ersetzt eine CRC keine Hardware-Fach-KnowHow
Programmierer schrieb: > So etwas popeliges wie eine LCD-Ladungspumpe kann den > I²C schon stören. Also eher einen Dauertest mit einem > kräftigen Störer daneben Deswegen testet man ja das gesamte Gerät am Stück. Und für die gegenseitige Beeinflussung benachbarter Geräte gibt es Standards samt Testprozeduren, an die man sich halten sollte, falls man die Standards erfüllen will oder muss.
Danke für die vielen konstruktiven Beiträge Bei einer anderen Firma haben wir das wie von einigen hier vorgeschlagen gemacht. Getestet bis die Schwarte kracht. Meist wurde dazu ein Gerät gebaut welches das eigentliche Gerät zyklisch ansteuert, etc. Das ganze Gebilde wurde dann in die Klimakammer, EMC Kammer, usw. geschoben. Was man halt so brauchte. Die Versorgung wurde ebenfalls variert. Prüfungen können wir nicht einbauen da wir mit Bausteinen kommuniezieren die man nicht programmieren kann. Ein Kollege von mir hat die High und Low Pegel gemessen und kam auf 0.45V und 3.2V. Fuer einen der Teilnehmer sind 0.45 jedoch zu hoch. Danke nochmals
Daisy D. schrieb: > Das ganze Gebilde wurde dann in die Klimakammer, EMC Kammer, usw. > geschoben. Was man halt so brauchte. Die Versorgung wurde ebenfalls > variert. Du solltest dabei bedenken, das Test eigentlich nur grobe Fehler erkennt: Du testest ja nur ein oder auch mehrere Geräte mit Bauteilen, deren Streuung der Daten du nicht kennst. Es kann also durchaus sein, dass später Geräte mit Bauteilen aus anderen Chargen Probleme machen, weil Bauteiledaten an der Grenze des vom Hersteller spezifizierten Bereichs liegen, aber immer noch im erlaubten Bereich. Und diese Fälle gab es bei den Tests bis dato nicht. Da hilft nur saubere Entwicklung nach z.B. der Wost-Case Methode, wo mit der ungünstigsten Kombination der Bauteildaten gerechnet wird. Da ist nicht trivial und ziemlich aufwendig und lässt sich durch Testen nicht ersetzen. Lediglich EMC kann man wohl fast nur durch Testen ermitteln, da die Berechnung oft schwierig ist!?
Hallo Dietrich L, Wost-Case Methode das hoert sich sehr interessant an. Haben wir hier im Forum eventuell Informationsquellen? Ich bin mir nicht 100% sicher wo, aber ich meine gelesen zu haben das selbst Datenblätter nicht bindend sind. LG
:
Bearbeitet durch User
Daisy D. schrieb: > Ich bin mir nicht 100% sicher wo, aber ich meine gelesen zu haben das > selbst Datenblätter nicht bindend sind. Ich gehe davon aus, dass in der Realität nicht alle Bauteile beim Hersteller auf Einhaltung der Min-/Max-Daten getestet werden, sondern nur Stichproben. Dann gibt es mit einer gewissen Wahrscheinlichkeit auch Bauteile, die außerhalb des Toleranzbereichs liegen. In dem Zusammenhang wird dann auch die "Gauss-Verteilung" genannt. Wie weit das bei heutiger Fertigung und allen Herstellern noch gilt weiß ich nicht. Hier wurde das Thema mal diskutiert: Beitrag "Wie sind Widerstandstoleranzen zu interpretieren?" Neben der Worst-Cast-Methode gibt es auch die Monte-Carlo-Methode, die mit den Wahrscheinlichkeiten der Datensteuung rechnet. Das ist aufwendiger, hat aber den Vorteil, dass bei vielen Bauteilen angenommen wird, dass sich Toleranzen auch kompensieren können. Im Endeffekt geht es aber immer um Wahrscheinlichkeiten, denn auch bei Worst-Case können Ausreißer daneben liegen. 100% Sicherheit gibt es im echten Leben halt nie...
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.