Forum

Einloggen | Registrieren | RSS  

bastelix(R)

30.09.2017,
01:33
 

Optimales I2C-Protokoll für Funk-Sensor-Empfänger? (Computertechnik)

Servus Zusammen,

ich hätte gerne ein paar Meinungen zu einer I2C-Schnittstelle, also genauer dazu wie sich der Slave am sinnvollsten via I2C auslesen lässt.

Hintergrund: Ich möchte die Nachrichten von verschiedenen 433MHz-Sendern mit einem PI (Banana/Raspberry/Sonstwas halt ein SoC-Board mit GPIO unter anderem I2C und Linux als Betriebssystem) empfangen und verarbeiten. Die Sender verwenden RH_ASK, dessen Empfang sich mit einem PI nicht direkt wirklich gut realisieren lässt. Darum bin ich auf die Idee gekommen einfach einen µC als Hilfsprozessor zu verwenden. Der µC empfängt die Nachrichten, puffert diese und lässt sich dann via I2C auslesen.

Wozu ich jetzt gerne eine zweite, dritte ... 2^8te Meinung hätte: Wie gestalte ich die Schnittstelle zum Auslesen der Nachrichten am schönsten (also am sinnvollsten zu verwenden).

Einfach eine Nachricht zu puffern und darauf waren bis sie abgerufen wird macht wenig Sinn, da Empfang und Auslesen asynchron erfolgen. Ein Interrupt für einen Puffer der nur eine Nachricht zwischenspeichern kann macht hier auch wenig Sinn.

Folgendes habe ich mir überlegt:

Option 1: Per I2C wird periodisch abgefragt ob es Daten zu lesen gibt. Die Rückgabe ist true (es gibt Daten) oder false (nix neues). Dann werden so lange Daten ausgelesen bis es keine Daten mehr gibt.
Beim Überlauf des Puffers wird einfach der Reihe nach überschrieben, so gehen die ältesten Daten zuerst verloren. Oder die neusten Daten werden verworfen bis wieder ein Puffer-Platz frei ist (halte ich hier für weniger sinnvoll)

Option 2: Per I2C wird periodisch abgefragt ob es Daten zu lesen gibt. Die Rückgabe ist eine Zahl zwischen 0 und X (X vermutlich 255) welche als Bitmuster interpretiert werden muss. Dabei steht jede Binärstelle für ein Register und jede eins im Bitmuster zeigt noch nicht ausgelesene Daten. Dann werden einfach die Register die mit eins markiert sind abgefragt. Beim Auslesen wird das Register zurückgesetzt. Geschrieben wird in alle Register die grad als Frei markiert sind. Beim Überlauf des Puffers... Das nächstbeste Register überschreiben (oder auch hier neuere Daten verwerfen)

Option 3: Hab ich noch nicht, bin aber für Vorschläge offen ;-)

Zusätzlich könnte der µC noch einen Pin-Interrupt auf dem PI triggern, sobald frische Daten vorhanden sind. Dann müsste der PI nicht ständig pollen sondern nur auf einen Interrupt reagiert und alle verfügbaren Daten auf einmal abholen. Aber das ändert nichts daran wie das Ding dann ausgelesen wird.

Welche Option würde euch als Benutzer des ICs der die Sensordaten empfängt und puffert besser gefallen?
Oder kennt ihr etablierte Module die so etwas ähnliches machen und könnt mir eine Tipp geben wie man das elegant löst (also sie wie der Hersteller oder eben nicht so wie der Hersteller)?

Btw. Den Prototyp für Option 1 hab ich schon mal zusammengehackt und auf einem Arduino mit einem Banana PI getestet. Läuft soweit. Bin mir nur nicht sicher ob das auch die eleganteste Lösung ist.

Gerald Hellinghaus

01.10.2017,
18:08

@ bastelix

Optimales I2C-Protokoll für Funk-Sensor-Empfänger?

Das hängt von der Buslast ab. Wenn Du keine Probleme hast, den Sensor immer etwas öfters und idealerweise auch mit einem Vielfachen dessen Datenerzeugungsfrequenz abfragen, um es filtern und plausibilsieren zu können. Beim I2C geht ja schnell mal was schief, wenn sich ein Slave und dann der Master aufhängt. Das passiert vor allem in verseuchten Umgebungen.

bastelix(R)

03.10.2017,
18:33

@ Gerald Hellinghaus

Optimales I2C-Protokoll für Funk-Sensor-Empfänger?

» Das hängt von der Buslast ab. Wenn Du keine Probleme hast, den Sensor immer
» etwas öfters und idealerweise auch mit einem Vielfachen dessen
» Datenerzeugungsfrequenz abfragen, um es filtern und plausibilsieren zu
» können. Beim I2C geht ja schnell mal was schief, wenn sich ein Slave und
» dann der Master aufhängt. Das passiert vor allem in verseuchten Umgebungen.
Ich war da auf die reine Software-Schnittstelle fixiert. Buslast und Störungen hatte ich garnicht auf dem Schirm.

Die Datenerzeugungsfrequenz könnte man abhängig von der Anzahl der Sensoren etwas steuern, sofern man damit noch im Bereich sinnvoller Messintervalle bleibt.

Für den Fall Bus-Absturz muss ich mir noch was überlegen (vermutlich Hard-Reset des µC), hatte ich öfter als ich versucht habe einen ATTiny mit Software-I2C an den PI zu hängen.

Ich lasse den Ringpuffer und die API jetzt mal wie sie sind und konzentriere mich mal auf die anderen Parameter (Buslast, Datenerzeugungsfrequenz, Busstabilität, ...) und mach mal nen Lasttest. Den Ringpuffer kann ich später immer noch auf wahlfreien Zugriff umstellen.

Danke für die Hinweise!