I2C-Überwachung ohne Mikrocontroller [geschlossen]

Ich versuche, Daten von einem I2C-verbundenen Berührungssensor zu lesen. Genauer gesagt der Azotec IQS266 . Ich habe vor, alle Einstellungen so vorzuprogrammieren, wie ich sie haben möchte, und sie danach nicht mehr anzufassen. Darüber hinaus gibt es wirklich nur einen Speicher, an dem ich interessiert bin, die Gesteninformationen des Trackpads bei TP_FLAGS (0x02, Offset 0).

Das bringt mich zu der Frage: Wie könnte ich eine einzelne Speicheradresse eines einzelnen Geräts auf einer I2C-Leitung ohne die Verwendung eines Mikrocontrollers überwachen? Nehmen wir zum Beispiel an, ich wollte 8 LEDs entsprechend den 8 Bits an Informationen aufleuchten lassen, die an dieser Adresse gespeichert sind, wenn das Azotec-Gerät ein Bereitschaftssignal erzeugt.

Ich stimme zu, dass ein Mikrocontroller am sinnvollsten wäre, aber es gibt einige Fälle, in denen Sie ihre Verwendung vielleicht lieber vermeiden würden. Bestimmte Aufsichtsbehörden werden schwieriger zu handhaben, wenn Sie „Software“ in ein Design einführen, und es kann vorteilhaft sein, einfache Daten von einem I2C-fähigen Gerät mit einem eher „hardwarebasierten“ Ansatz zu erhalten. Ist es möglich, ein I2C-Gerät auf eine bestimmte Adresse zu überwachen und seine Informationen im Wesentlichen in eine parallele GPO-Ausgabe umzuwandeln?

Es scheint, dass das Gerät erwartet, dass es einen I2C-Master gibt (dh es arbeitet als Slave, p13 des Datenblatts, erster Absatz), also kann ich sowieso nicht sehen, wie ich ein FPGA bauen kann, um die Informationen daraus zu bekommen.
Mit digitalen Logikchips sollte es durchaus machbar sein, aber was auch immer Sie sich einfallen lassen, es wird teurer und viel größer als ein Mikrocontroller sein, ist das akzeptabel?
Es ist sehr unwahrscheinlich, dass Sie dafür ein spezielles Gerät finden werden, zumindest keins, das keine Software benötigt. Es ist möglich, wenn der Befehl gut bekannt ist, diskrete TTL-Logik zu verdrahten, um dies zu tun, aber die Komplexität eines solchen Designs wird hoch sein. Im Allgemeinen sind solche einfachen Schnittstellengeräte die Domäne von PLD/FPGA, PIC und für große Mengen ASIC. Andernfalls, wenn dies ein kritisches Projekt ist, werden Sie besser dran sein, eine weitere Abstraktionsebene abzuziehen und einen benutzerdefinierten Trackpad-Controller mit analoger oder paralleler Schnittstelle zu implementieren, der für Ihre Anwendung geeignet ist.
Sie könnten sich CPLDs ansehen. Aber sie könnten die gleichen Vorschriften wie Mikrocontroller haben.
Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da es eine absurd unlogische Risikoanalyse ist, kapazitive Berührungen (und schlimmer noch, Berührungsgesten) zuzulassen, aber Software für den engen Zweck der Interpretation zu verbieten
„Absurd unlogisch“ beschreibt leider den aktuellen Stand der Einteilung zwischen Software und Hardware bei der Herstellung eines Medizinprodukts. Dies sind jedoch die Überlegungen/Einschränkungen, die ich berücksichtigen muss. Ich würde wirklich lieber nur ein Mikro verwenden und damit fertig sein. Aber es wäre interessant, wenn es eine Möglichkeit gäbe, dies zu umgehen
Die Einhaltung der FDA kann einen absurd machen, @Chris.
Um ehrlich zu sein: Wenn Ihnen die Verwendung von Software durch externe Anforderungen untersagt ist, dann ist es eine unverantwortliche Handlung Ihrerseits, einer Verwendung von etwas zuzustimmen, das nachweislich noch weniger vertrauenswürdig ist und sich tatsächlich routinemäßig als absolut unzuverlässig erweist. Sicher haben Sie gesehen, wie ein Touch-Gerät falsche Ereignisse und zahlreiche falsche Gesten erzeugt hat? Die einzig vernünftige Möglichkeit, Touch in einem kritischen System zu verwenden, besteht darin, eine Menge Software hinzuzufügen , um durch zusätzliche Benutzerinteraktion zu bestätigen, dass die Aktion wirklich das ist , was der Benutzer will.
Du scheinst Gesten nicht zu mögen, fair genug. Und ja, es gibt zahlreiche Beispiele für berührungsempfindliche Geräte, die Fehlalarme erzeugen, aber ich bin mir nicht sicher, ob jede berührungsempfindliche Aktivität ein „Haben Sie wirklich X gemeint?“ erfordern sollte. Stilbestätigung vom Benutzer. Am Ende des Tages weiß ich nicht, was ich nicht weiß, und es ist möglich, dass es da draußen eine einfache Alternative gibt, mit der ich diese Arbeit ohne Mikro erledigen kann. Ich glaube nicht, dass das vom Thema abweicht, ich denke, einen seltsamen Anwendungsfall wie diesen zu untersuchen, wäre ein Zweck dieses Forums. Außerdem stimme ich den FDA-Vorschriften möglicherweise nicht zu, aber meine Aufgabe ist es, sie zu befolgen
Nein. Wenn Sie sich Ingenieur nennen wollen, müssen Sie sich weigern , etwas Unangemessenes zu bauen. Wenn die Software für diese Anwendung unsicher ist, ist die Berührung zehnmal so hoch, und insbesondere dann, wenn die Verwendung von Software zur Plausibilitätsprüfung der Berührungsereignisse nicht zulässig ist.
Unangemessenes kann hier offen für Interpretationen sein, Sie haben keine Ahnung, welche anderen Sicherheitsvorkehrungen in das System eingebaut sind
Entweder können die Schutzvorrichtungen mit falschen und verpassten Ereignissen umgehen, oder sie können es nicht. Wenn sie können, ist speziell Software in der Touch-Kette sinnvoll. Ist dies nicht möglich, ist eine Berührung absolut unzulässig und es verstößt gegen die Berufspflicht, beim Aufbau zu diesem Zweck mitzuhelfen.
Ehrlich gesagt Chris, ich stimme dir zu. Vielleicht hätte ich die Frage so formulieren sollen: "Gibt es eine Alternative zu dieser Sache, die ich wahrscheinlich tun werde (ein Mikro verwenden), an die ich nicht gedacht habe?" Aber ich denke nicht, dass die Frage selbst völlig unbegründet ist. Ich mache einen Job und suche nach Optionen. das ist es. Die Antworten unten, die auf die Längen hingewiesen haben, die ich auf mich nehmen müsste, sind sehr aufschlussreich, viel mehr als nur zu sagen: "Schlechte Frage, Thema verfehlt, schalte sie aus".
Der Grund, warum es nicht zum Thema gehört, ist, dass die Suche nach der Frage ein unangemessener Versuch einer vorgetäuschten Einhaltung ist – das Problem ist völlig künstlich –, das nur von diesen Einschränkungen angetrieben wird, eine Aufsichtsbehörde zu täuschen, damit sie etwas akzeptiert, das oberflächlich dem Buchstaben entspricht, aber nicht der Absicht entspricht Regulierung, nicht eine, die in verantwortungsvollem Design vorkommt. Sie müssen dies ablehnen, nicht weil die Alternativen zu Software schwierig sind , sondern weil sie noch verantwortungsloser sind als Software, die eine Gesundheitsfilterung implementiert.
Ich habe nicht die jahrelange Erfahrung, um die Leute zu hinterfragen, die diese Vorschriften gemacht haben. Aber ich weiß, was geht und was nicht. Das ist alles, was ich so früh in meiner Karriere habe. Ich werde meinen Vorgesetzten weiterhin um Software-Support drängen, weil ich, wie gesagt, der gleichen Meinung bin, dass dies der bessere Weg ist. Aber hey, jemand hat vielleicht gesagt: „Oh, kennst du den XYZ-Teil von TI nicht? Und dann wäre es gut gewesen. Die Antworten, die zeigen, wie kompliziert die Realität ist, stärken meine Auseinandersetzung mit meinem Vorgesetzten
Es ist ein entscheidender Teil Ihrer Arbeit als Ingenieur, Fragen zu stellen. Ihre hypothetische I2C-Engine mit fester Funktion wäre nicht im Entferntesten "in Ordnung" gewesen, da sie immer noch das größere Risiko der groben Unzuverlässigkeit der Berührung unberücksichtigt lässt. Wenn Sie nicht bereit sind, „nein“ zu sagen und wegzugehen, sind Sie nicht in der Lage, diese Art von Arbeit zu erledigen.
Nun, jetzt sind wir wirklich vom Thema abgekommen, und ich habe nicht den Repräsentanten, um zum Chat zu wechseln.
Wir sind nicht im Entferntesten vom Thema abgekommen. Tatsächlich sind wir beim wichtigsten möglichen Thema. Alles andere ist zweitrangig, wenn Sie bei Ihren Bemühungen verantwortungsbewusst sind.
Ok Kumpel, wenn ich das nächste Mal nachschaue, ob es Alternativen zu einem mir unbekannten Design gibt, was soll ich tun? Ich habe Anbieter kontaktiert, meine Google- und IEEE-Suche durchgeführt und als letzten verzweifelten Versuch dachte ich, ich könnte hier in meiner Freizeit etwas posten und sehen, ob die kreativen Leute von Stack Exchange eine verrückte Idee hatten. Was ist der bessere Weg, um nach Designalternativen zu suchen?
Wenn das Ziel darin besteht, die Sicherheitsvorschriften zu umgehen, sollten Sie "nein" sagen und nicht nach cleveren Ausweichmanövern suchen. Alternativen sind für technische Probleme. Im Gegensatz dazu läuft Ihre Frage auf "Wir wollen etwas grob Unverantwortliches tun, aber die Aufsichtsbehörde macht es uns schwer, bitte helfen Sie mit"
Erwischt. Danke. Aber ich würde nicht wissen, ob es eine legitime Alternative oder ein "Ausweichen" gibt, bis ich frage. Dank der anderen Antworten ist es jetzt klar.
@Brandon Nur eine Randnotiz: Wenn Sie der Hersteller des Geräts sind und sich in der IEC 62304-Welt befinden, denken Sie daran, dass alle Software auf der Risikobewertung basiert, die Sie für ein medizinisches Produkt sowieso benötigen . Die Norm legt nicht fest, was ein akzeptables Risiko ist, es ist Sache des Herstellers, dies zu bestimmen. Wenn der Touchscreen unkritisch ist, dann könnte man die Software in Klasse A machen und nicht so viel Kopfschmerzen haben.

Antworten (5)

Ich bin mir nicht sicher, ob es ein vorhandenes Produkt gibt, das das tut, was Sie wollen. Wenn Sie eine benutzerdefinierte Lösung entwerfen möchten, könnten einige Optionen Folgendes umfassen:

  1. Verwenden Sie programmierbare Logik wie ein kleines CPLD, um die I2C-Schnittstelle zu implementieren, und lassen Sie eine Zustandsmaschine die Busaktivität verfolgen, um die gewünschten Daten zu erfassen.

  2. Wie Nr. 1, aber verwenden Sie einen dedizierten Chip wie den PCA8584 (I2C zu paralleler Brücke), um die schwere Arbeit für das I2C-Protokoll zu übernehmen, und lassen Sie ein CPLD die Aktivitätsüberwachung auf höherer Ebene übernehmen. Dieser Chip hat einen Snoop-Modus, in dem er garantiert nichts auf dem I2C-Bus treibt und ihn zerstörungsfrei überwacht.

  3. Verwenden Sie einen Mikrocontroller mit einem ähnlichen I2C-Snoop-Modus wie den LPC1769. Ich weiß nicht, ob die Implementierung dieser Funktionalität in Hardware (auf dem Chip) es Ihnen ermöglichen würde, die Vorschriften über Software zu umgehen, da ein Softwarefehler sie aus dem Snoop-Modus herausnehmen und fehlerhaften I2C-Verkehr einführen könnte. Das ist also ein bisschen weit hergeholt.

Deine reine Hardwarelösung ist: 1 Eprom SST39VF010, 1x 74HC4060, 1x 74HC4094. 2xR, 2xC. Kosten ~ 1 $ Die Eprom-Pins sind SDA, SCL, CLK4094, RST4094 . 4094-Daten verbinden sich mit SDA. Der Bitstream, der Ihren Azotec liest, wird im Flash gespeichert und vom 4060-Zähler in einer Endlosschleife ausgetaktet. Wenn die Azotec-Daten ausgelesen werden, werden sie in den 4094 getaktet. Der Bitstrom benötigt 20-30 Bytes pro I2C-Byte, geschätzte 256 Bytes.

(Silego Greenpak Mixed Logic + SPI-Speicher könnte eine 2-Chip-Lösung sein).

Das Azotec-Produkt selbst ist höchstwahrscheinlich etwas mit interner Firmware, wie die meisten komplexen I2C-Slave-Geräte, sodass Ihre zugrunde liegende Idee etwas strittig wird.

Ein Mittelweg besteht darin, ein kleines Mikro genau wie Eprom + Zähler zu verwenden, aber anstatt programmgesteuert zu lesen und zu schreiben, geben Sie einfach seriell einen Steuerbitstrom aus, der das tut, was Sie wollen. Das Mikroprogramm wird zu einer einfachen Dump-Schleife, vielleicht nur 20 Wörter lang. Es kann mit einer zyklomatischen Komplexität von 1 unter Verwendung eines externen LED-Schieberegisters oder 2 (vielleicht 1) implementiert werden, wenn LEDs vom Mikro angesteuert werden, und kann formal als korrekt bewiesen werden. Der Bitstrom ist eine unveränderliche gespeicherte Sequenz ohne Verzweigungen und kann daher durch erschöpfendes Testen der einen möglichen Sequenz als richtig bewiesen werden.

Unser Produkt BL233C ist in der Lage, ein eigenständiger I2C-Redirector zu sein, um zu tun, was Sie wollen, einen I2C-Sensor zu lesen, ihn minimal zu verarbeiten und auf ein anderes I2C-Anzeigegerät zu schreiben.

Es hat natürlich auch eine zugrunde liegende Firmware, aber wie der Sensor kann es einem Rezensenten als zuverlässiger Chip erscheinen (na ja, das ist es natürlich) und nicht als Softwaresystem. Dies ist nicht unvernünftig - Spezialisten wie wir und Azotech sollten über ausgereiftere und daher besser debuggte Produkte verfügen, als es Ihr eigenes Programm bei der erstmaligen Bereitstellung sein würde.

Oh, das gefällt mir! Interessantes Gerät.

wenn Sie „Software“ in ein Design einführen

Software: Ein Programm, das von einem Prozessor interpretiert wird.

Was Sie brauchen, ist Folgendes:

  • Fragen Sie das Register über I²C ab (der Sensor "sagt" nicht von selbst. Er muss gefragt werden), was bedeutet, dass Sie dieselbe Signalfolge über den I²C-Bus senden
  • Ändern des Zustands von 8 Ausgängen, basierend auf den Signalen, die der Sensor als Antwort auf den I²C-Bus sendet

Schlechte Nachrichten: Das ist ein programmatischer Ablauf, und wir haben festgestellt, dass es sich um ein Programm handelt, indem wir einfach die Spezifikationen dessen aufgeschrieben haben, was Sie wollen. Sie müssen sich mit Software befassen, egal was passiert.

Wenn Sie beispielsweise Folgendes implementiert haben:

  • Sendesequenz auf SDA und SCL
  • Umschalten auf SDA-Sampling, wenn sich SCL ändert
  • Speichern der SDA-Werte in einem Schieberegister
  • Stellen Sie die LEDs gemäß dem Schieberegister ein

Zyklus in logischer Hardware, herzlichen Glückwunsch, Sie haben einen sehr anwendungsspezifischen Prozessor gebaut, der ein vierstufiges Programm ausführt.

Es ist wirklich der Punkt, an dem Sie sagen, dass dies ein Job für einen Mikrocontroller ist. Und wirklich, was denkst du, wie viele Prozessorkerne sind in diesem Touchpad? Ich würde davon ausgehen, dass es mindestens einer ist, aber wenn ich einen entwerfen müsste, wären es tatsächlich zwei verbundene Mikrocontroller. Also, wenn Ihre Aufsichtsbehörde ein Problem mit Mikrocontrollern hat: Pech gehabt.

Eine mit Hardware implementierte sequentielle Operation wird nicht als Software betrachtet.
Das ist ein fairer Punkt. Ehrlich gesagt ergibt sich dies alles aus den sehr unterschiedlichen Interpretationen dessen, was „Hardware“ und was „Software“ ist, insbesondere in der Welt der ISO-gesteuerten Medizinprodukte. Es ist alles ziemlich grau (einige Leute haben FPGA-implementierte Zustandsmaschinen als Hardware interpretiert, während andere sie aufgrund dessen, was diesen Code erstellt hat, als Software interpretiert haben), ich erkunde nur meine Optionen
@Brandon, nach dieser Logik "... als Software aufgrund dessen, was diesen Code erstellt hat" , ist jeder Hardware-IC "Software", da das Design aller harten Logik- / Masken- / Herstellungsschritte unter Verwendung riesiger Softwarepakete erfolgt.
Ja, es ist dumm. Es ist nicht meine Regel
@Brandon, ich denke, die Unterscheidung / Besorgnis könnte darin bestehen, ob der eingebrannte "Mikrocode" manipuliert oder extern geändert werden kann. Dies könnte eine berechtigte Sorge sein. Dann könnte eine Zustandsmaschinensteuerung, die aus einem einmaligen, benutzerdefinierten, maskenprogrammierten Speicher besteht, eine Lösung sein.
So etwas ergibt für mich Sinn. Ich interpretierte es fast als ein Rückverfolgbarkeitsproblem. Sie können alle möglichen Eingänge in eine einfache digitale Schaltung einspeisen und die Ausgänge beobachten. Ein FPGA implementiert eine einfache digitale Schaltung, also sollten Sie in der Lage sein, dasselbe zu tun, aber vielleicht könnten die unbenutzten Gatter einen seltsamen Randfall verursachen. Und dann ist die Software etwas darüber abstrahiert ... Aber ich mag Ihren Punkt über externe Manipulationen
Die Beweisbarkeit der Korrektheit ist die zentrale Frage. (Manipulation ist ein separates Thema). Zustandsmaschinen können aus demselben Grund nicht beweisbar sein wie Software. Zustandskomplexität ist das Problem. Jetzt kann diese Aufgabe in direkter Reihenfolge erledigt werden, also ist es nachweislich richtig, wenn es so gemacht wird. (auch wenn Sie eine mcu verwenden, um es zu implementieren)

Die hardwarebasierte Lösung für Ihre kleine I2C-Steuersequenz wird als "nichtflüchtiges FPGA" oder ein gutes CPLD bezeichnet. Sie entwerfen einen seriellen Konverter in einem beliebigen VHDL, weisen/konfigurieren einen Teil des Speichers innerhalb von CPLD und erstellen einen kleinen Sequenzer, um die Bytes aus Ihren vordefinierten I2C-Daten auszuführen. Alles ist eine vorkompilierte Zustandsmaschine, keine Software.

Wenn eine nicht autorisierte Umprogrammierbarkeit im Vordergrund steht, kann ein ROM-basiertes FSM eine Lösung sein.

Nicht wahr. Eine FPGA-Konfiguration ist auf jeden Fall "Software" Und ziemlich offensichtlich, wenn man den Umfang der Aufgabe betrachtet, diese praktisch nutzbar zu machen.
Wenn Sie bedenken, dass der Kern der Sache die Beweisbarkeit ist, dann leiden FPGAs darunter, dass sie nicht beweisbar sind (wegen der versteckten Compiler-Schichten). Durch die gleiche Maßnahme kann ein Mikroprozessor verwendet werden, um ein System zu implementieren, das eine zyklomatische Komplexität von 1 hat, dh einen einzigen unverzweigten Pfad, und somit beweisbar korrekt sein kann.

Die Alternative zu "Software" in einem Digitalen ist eine endliche Zustandsmaschine. Dies wurde hier diskutiert . Wenn Sie sowohl Software als auch FSM wirklich vermeiden möchten, müssen Sie vollständig analog vorgehen (z. B. LM3914 zum Ansteuern der LEDs).

I2C-Überwachung ohne Mikrocontroller [geschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 1v