Anzeige:
Ergebnis 1 bis 14 von 14

Thema: Fragen zur Schnittstellenbelegung Raspberry

  1. #1
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975

    Fragen zur Schnittstellenbelegung Raspberry

    Hallo zusammen,

    bevor ich mich in horrende Unkosten stürze, hätte ich gerne Eure Bestätigung, dass ich da nicht auf dem Holzweg bin mit meinem Vorhaben.

    Für meine Wetterstation habe ich einen Raspberry 3, an dem am I2C ein Helligkeitssensor arbeitet. Die Pins des Sensors mit den Bezeichnungen SCL und SDA sind mit den entsprechenden Pins am Raspi verbunden (GPIO2 bzw GPIO3), Masse und Versorgungsspannung ebenfalls (Sonsor liefert seit längerem Daten, läuft also).

    Nun möchte ich meine Station um einen Blitzsensor vom Typ AS3935 erweitern, ebenfalls ein I2C-Sensor. Die vorgeschlagene Pin-Belegung zum Raspberry ist hier beschrieben, es werden wieder SCL und SDA vom Raspi verwendet. Ist das okay, die beiden Sensoren dann an diesen Pins parallel zu betreiben (ich habe keine Ahnung von Bus-Systemen, vermute aber, dass es genau dafür gedacht ist).

    Zusätzlich braucht es eine Spannungsversorgung, das ist klar, aber wofür ist "IRQ", der am Raspi auf GPIO17 gelegt wird? Warum hat das der Helligkeitssensor nicht?

    Den Helligkeitssensor lese ich per cron alle 5 Minuten mittels eines Python-Prgramms aus. Den Blitzsensor kann man auch laut verlinkter Seite per Python auslesen.
    Muss ich hier irgendwie sicherstellen, dass sich die beiden Programme nicht in die Quere kommen? ich würde nämlich den Blitzsensor im Sekunden-Takt auslesen wollen (oder zumindest in der kürzest möglichen Wiederholrate).

    Was meint ihr?

    Danke

    michel_vaclav
    Visit me at fehrmich.spdns.de

  2. #2
    Registrierter Benutzer
    Registriert seit
    Jul 2009
    Ort
    Meißen
    Beiträge
    267
    Guten Morgen!
    Zitat Zitat von michel_vaclav Beitrag anzeigen
    Nun möchte ich meine Station um einen Blitzsensor vom Typ AS3935 erweitern, ebenfalls ein I2C-Sensor. Die vorgeschlagene Pin-Belegung zum Raspberry ist hier beschrieben, es werden wieder SCL und SDA vom Raspi verwendet. Ist das okay, die beiden Sensoren dann an diesen Pins parallel zu betreiben (ich habe keine Ahnung von Bus-Systemen, vermute aber, dass es genau dafür gedacht ist).
    Jedes I2C-Gerät hat eine fest eincodierte Adresse (die aber meistens über externe Pins noch um ein paar Stellen veränderbar ist). Nur 2 Geräte mit der gleichen Adresse am selben I2C-Bus machen mit Sicherheit Probleme!
    Da dieser AS3935 offenbar 2 Adresspins (A0 und A1) hat, sollte es passen.

    Zitat Zitat von michel_vaclav Beitrag anzeigen
    ... aber wofür ist "IRQ", der am Raspi auf GPIO17 gelegt wird? Warum hat das der Helligkeitssensor nicht?
    Da spekuliere ich mal:
    Einem Helligkeitssensor ist es (rein physikalisch) egal, ob Du Polling im 1s- oder 10s- oder 100s-Takt machst. Ein Blitz ist aber so kurz, das dem angeschlossenen Gerät unverzögert über Interrupt mitgeteilt werden muss, dass da was war!
    Jedes Polling könnte (wegen der Kürze des Ereignisses) ins Leere laufen?

    Gruß, FM_81
    Ein Mann, der wollte fangen einen Barsch, das Wasser stand ihm bis zum Knie!
    (Du musst bis Frühjahr warten, da kommt Hochwasser, dann reimt es sich von selbst!)

  3. #3
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975
    Der Sensor ist da und schon das erste Problem. Ich habe ihn analog zu dieser Anleitung verdrahtet. Die Pin-Beschriftung ist ja nahezu identisch. VCC auf 3.3V, GND auf Ground, SCL auf Pin 5 vom Raspi, (falsch MISO) MOSI auf Pin 3 vom Raspi, IRQ auf Pin 17 und SI auf 3.3V, um I²C zu verwenden.
    Leider meldet sich das Teil aber nicht. i2cdetect -y 1 liefert:
    Code:
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    Keine Fehlermeldung, nix.
    Alterantiv könnte man das Teil wohl auch mit SPI auslesen, damit kenn ich mich noch weniger aus.
    Ein ls -la /dev/spidev0.* liefert:
    Code:
    crw-rw---- 1 root spi 153, 0 Jul 26 20:32 /dev/spidev0.0
    crw-rw---- 1 root spi 153, 1 Jul 26 20:32 /dev/spidev0.1
    Kann ich daraus schlussfolgern, dass da schon was erkannt wurde?

    Leider hab ich keinen anderen Sensor zur Hand um zu prüfen, ob ich überhaupt in der Lage bin, an diesem Raspi die I²C-Schnittstelle zu benutzen.
    Wie kann ich das noch prüfen?
    Außerdem: der Sensor wurde ohne Datenblatt ausgeliefert, im Internet find ich zu diesem Hersteller leider nix. Aber ich denke, er ist identisch zu dem in der Anleitung.
    Geändert von michel_vaclav (30.07.18 um 18:27 Uhr)
    Visit me at fehrmich.spdns.de

  4. #4
    Registrierter Benutzer
    Registriert seit
    Jul 2009
    Ort
    Meißen
    Beiträge
    267
    Die verlinkte Anleitung scheint von 2015 zu sein, k.A. ob da schon jemand an Overlays dachte?
    I2C-Bus ist entweder über raspi-config (sollte gehen wenn Du das halbwegs aktuelle Standard-Raspbian verwendest) oder über Einträge in der '/boot/config.txt' (das bei vielen anderen Systemen) aktiviert?
    U.U. musst Du auch noch das Modul 'i2c_dev' in der '/etc/modules' nachtragen.

    Gruß, FM_81
    Ein Mann, der wollte fangen einen Barsch, das Wasser stand ihm bis zum Knie!
    (Du musst bis Frühjahr warten, da kommt Hochwasser, dann reimt es sich von selbst!)

  5. #5
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975
    Der I2C-Bus geht ja prinzipiell, weil i2cdetect ja ordnungsgemäß funktioniert. Auch das besagte Modul wäre geladen. Einzig: Es wird keine Adresse angezeigt, wenn der Sensor dran hängt.
    Kann es an der Leitungslänge liegen? In Vorbereitung auf die spätere Verwendung hab ich vier Meter Klingeldraht (nicht verdrillt) verwendet.
    Geändert von michel_vaclav (28.07.18 um 17:15 Uhr)
    Visit me at fehrmich.spdns.de

  6. #6
    Registrierter Benutzer
    Registriert seit
    Jul 2009
    Ort
    Meißen
    Beiträge
    267
    Zitat Zitat von michel_vaclav Beitrag anzeigen
    VCC auf 3.3V, GND auf Ground, SCL auf Pin 5 vom Raspi, MISO auf Pin 3 vom Raspi, IRQ auf Pin 17 und SI auf 3.3V, um I²C zu verwenden.
    MOSI, nicht MISO ist für den I2C-Anschluss angegeben! Sowohl in der verlinkten Anleitung und auch im Datenblatt des IC https://duckduckgo.com/l/?kh=-1&uddg...Datenblatt.pdf

    Oder war es nur ein Schreibfehler ...?

    Gruß, FM_81
    Ein Mann, der wollte fangen einen Barsch, das Wasser stand ihm bis zum Knie!
    (Du musst bis Frühjahr warten, da kommt Hochwasser, dann reimt es sich von selbst!)

  7. #7
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975
    Das war in der Tat kein Schreibfehler, hatte ich vorher schon rausgefunden und korrigiert.
    Auch die Kabellänge hab ich jetzt auf 20cm verkürzt, ohne Erfolg.
    Visit me at fehrmich.spdns.de

  8. #8
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975
    Update: hab mir von einem "Profi" helfen lassen mit folgendem Ergebnis: Der Blitzsensor ist wohl defekt. Wahrscheinlich hab ich ihn geschrottet bei meinen zahlreichen Versuchen. Aber: Es hätte in der Beschaltung gar nicht funktionieren können. Man muss zusätzlich die Pins A0 und A1 (Adresspins) auf High setzen, um eine zulässige Adresse zu erhalten.
    Mal sehen: das nächste Teil ist bestellt.
    Visit me at fehrmich.spdns.de

  9. #9
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975
    Den neuen hab ich etwas pfleglicher behandelt und siehe da: läuft, auch mit drei Meter Kabel.
    Visit me at fehrmich.spdns.de

  10. #10
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975
    Hallo zusammen,

    jetzt habe ich doch Probleme mit der ganzen Geschichte. Offensichtlich kommen sich meine drei Sensoren in die Quere beim Benutzen des I2C-Busses.
    Für zwei der drei Sensoren konnte ich das Problem relativ einfach lösen mit folgendem Ansatz:

    Zwei Sensoren werden alle 5 Minuten per Cronjob ausgelesen, daher habe ich in das jeweilige Python-Programm eine Abfrage nach einem Flag eingebaut. Kurz gesagt: Wird die Abfrage eines Sensors getriggert, prüft das Programm zunächst das Vorhandensein einer Datei namens ic2flag.txt in /dev/shm. Ist diese Datei nicht vorhanden, wird sie angelegt mit dem Inhalt "False".
    Im weiteren Verlauf der Abarbeitung wird dann an geeigneter Stelle vor dem Auslesen des Sensors geprüft, ob der Inhalt der oben genannten Datei "False" ist. Falls ja, wird der Inhalt auf "True" gesetzt und das Programm fortgesetzt. Vor Beendigung des Programms wird dann der Inhalt der Datei wieder auf "False" gesetzt.
    Sollte nun bei der Prüfung der Datei vor Auslesen des Sensors "True" zurückgegeben werden, so wird einfach ein Delay von 5 Sekunden zusätzlich gesetzt, bevor der Sensor ausgelesen wird.

    Diese Vorgehensweise funktioniert tadellos, wie mir die Logfiles dazu anzeigen (ich protokolliere die Wartezeiten, sofern sie auftreten, separat).

    Mein Blitzsensor ist aber offensichtlich anders gestrickt. Dieser wird einmalig gestartet und läuft dann permanent. Muss er ja auch, weil er ja Blitze in Echtzeit beobachtet. Daher müsste ich jetzt in dem zugehörigen Python-Programm diese Abfrage nach Gesetztsein des Prüfungsflags unterbringen. Allerdings verstehe ich den Programmcode nicht, somit weiß ich nicht, an welcher Stelle ich das am Besten unterbringe. Daher bitte ich um fachkundigen Rat.

    Im Anhang die Datei "blitze.py", die einmalig gestartet wird. Diese importiert eine weitere Datei namens "RPi_AS3935.py", die offensichtlich sehr viel mehr macht.
    Wenn ich das richtig interpretiere, dann wird aus blitze.py je nach Status aus der zweiten Datei eine Sequenz aufgerufen. Ich hatte schon an verschiedenen Stellen die Prüfung der Datei /dev/shm/i2cflag.txt eingebaut und versucht, das auch zu loggen. Ich habe jedoch noch keine geeignete Stelle gefunden.

    Wo würdet ihr die Prüfung hinsetzen?

    BTW.: hänge ich den Blitzsensor an einen anderen Raspberry ohne zusätzliche I2C-Sensoren, dann läuft das Blitzezählen beliebig lange.

    Vielen Dank schon mal an alle, die sich da reindenken.

    michel_vaclav
    Angehängte Dateien Angehängte Dateien
    Visit me at fehrmich.spdns.de

  11. #11
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.314
    Ganz am Ende, ist eine Endlosschleife, dort.

    Aber du solltest den Code vermutlich etwas umbauen. Wie du ja bemerkt hast, hast du ein Zugriffs Problem, die üblichen Schlagworte dazu: semaphore, mutex, "process synchronization"

    Für Python 3 im speziellen:
    https://docs.python.org/3/library/asyncio-sync.html - semaphoren und mutexe; üblicherweise für einen Prozess
    https://docs.python.org/3/library/mu...ween-processes - synchronization-between-processes

    https://sourceforge.net/p/raspberry-...n/wiki/Inputs/ - für die Python GPIO API

    Du hast ja schon einen System weit gültigen Mutex erzeugt (Inhalt ist etwas abweichend - üblich ist eine PID), du willst also alle drei Anwendungen "synchronisieren" - nicht nur die beiden ohne Events.
    Da gibt es jetzt viele Optionen.

    Entweder du baust deine Blitzerkennungsanwendung so um, dass diese auch "pollt", aus der API:
    Zitat Zitat von https://sourceforge.net/p/raspberry-gpio-python/wiki/Inputs/
    ...
    wait_for_edge() function
    ...
    Code:
    # wait for up to 5 seconds for a rising edge (timeout is in milliseconds)
    channel = GPIO.wait_for_edge(channel, GPIO_RISING, timeout=5000)
    if channel is None:
        print('Timeout occurred')
    else:
        print('Edge detected on channel', channel)
    ...
    Könnte man wohl anstelle von 'GPIO.add_event_detect' nehmen.

    Alternativ, event handle abschalten:
    Remove event detection
    If for some reason, your program no longer wishes to detect edge events, it is possible to stop them:
    Code:
    GPIO.remove_event_detect(channel)
    Ich denke es macht außerdem Sinn, die drei in einem Prozess laufen zu lassen und die Threads abzugleichen, bin mir da gerade nicht ganz Python sicher, aber idR ist das synchronisieren so deutlich billiger bzw. schneller. Das Timing solltest du dabei möglichst optimieren, in 5 Sekunden könnten mehr als 12.000.000 Events verarbeitet werden, so lange sollter die Blitzerkennung natürlich nicht aus bleiben und da es ja schnell sein soll, würde auch ich dir zu Threads raten, damit du nicht auf auf den sehr langsam Speicher runter musst ("Festplatte"), was bei Prozess übergreifenden Themen fast immer der Fall ist.

    In der Community herrscht da übrigens Uneinigkeit was die richtige Lösung ist: https://www.raspberrypi.org/forums/v...c.php?t=135928 # las dich da nicht von den csharp Zeug ablenken, .Net hat viel mehr im Standard, ua ein autosynch und außer "bla bla gefährlich" habe ich da nichts konkretes gelesen - und multi irgendwas ist halt immer "bla bla gefährlich"


    ----------
    Evt. zu drüber, aber ich habe mal eine verteilte Anwendung mit http://zeromq.org/ und Python codiert, sehr angenehme Erfahrung - http://zguide.zeromq.org/page:all#Si...s-PAIR-Sockets so als Ordnerschicht...


    [edit]oder doch einfach mehrere Busse machen - https://www.instructables.com/id/Ras...e-I2c-Devices/ - vielleicht kann dir dein Profi da ja noch den einen oder anderen Tipp geben, klingt aber doch noch dem Ende aller synch Sorgen
    Geändert von nopes (12.11.18 um 23:20 Uhr)
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  12. #12
    Registrierter Benutzer Avatar von michel_vaclav
    Registriert seit
    Jan 2003
    Ort
    daheim
    Beiträge
    975
    Hallo nopes,
    habe bei weitem noch nicht alles gelesen geschweige denn verstanden. Allerdings habe ich jetzt mal den Ansatz verfolgt und die Abfrage nach dem besagten Flag in die Endlosschleife gebaut. Und per Logging auch überprüft, hat soweit auch funktioniert.
    Allerdings, wenn das Programm dann länger läuft, crashed es doch wieder mit folgender Fehlermeldung:
    Code:
    Traceback (most recent call last):
      File "blitze.py", line 50, in handle_interrupt
        reason = sensor.get_interrupt()
      File "/home/user/RPi_AS3935.py", line 56, in get_interrupt
        self.read_data()
      File "/home/user/RPi_AS3935.py", line 242, in read_data
        self.registers = self.i2cbus.read_i2c_block_data(self.address, 0x00)
    IOError: [Errno 121] Remote I/O error
    Traceback (most recent call last):
      File "blitze.py", line 129, in <module>
        noise = sensor.get_noise_floor()
      File "/home/user/RPi_AS3935.py", line 80, in get_noise_floor
        self.read_data()
      File "/home/user/RPi_AS3935.py", line 242, in read_data
        self.registers = self.i2cbus.read_i2c_block_data(self.address, 0x00)
    IOError: [Errno 110] Connection timed out
    Ich kann damit leider gar nichts anfangen. Nur dass es nicht in der Endlosschleife zu passieren scheint.

    Was bedeutet dieser Fehler?

    michel_vaclav
    Angehängte Dateien Angehängte Dateien
    Visit me at fehrmich.spdns.de

  13. #13
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.314
    Ich vermute, dass das nicht alles auf einmal laufen kann bzw. es noch Dinge gibt, die parallel laufen, es aber nicht dürfen.

    Nun wolltest du es ja offensichtlich ordnen, aber was passiert, du registrierst vor den beiden endlos Schleifen am Ende ein Event Handler, diese Events haben halt immer gemeinsam, dass es immer um etwas neben dabei läufiges geht. Nicht zwingend, ist es so, dass ein Event von außen, also in deine Anwendung rein gereicht wird - Klicks auf Schaltflächen erzeugen zB Events in der eigenen Anwendung. Bei dir kommt der Event aber von außen, irgendwas sagt deinem Python Programm, dass was ausgelesen werden soll.
    Kommt nun so ein Event, hast du praktisch zwei Stellen deines Programms am laufen, die eine ist irgendwo in den Loops am Ende, die andere im Handler, aber nur der Teil am Ende achtet auf pollenden Anwendungen (es wird auch nicht verhindert, dass Events bearbeitet werden, während die Schleifen unten was mit dem Bus machen, denke aber nicht, dass das dein Problem ist). Es wird halt nicht die Messung verzögert sondern nur das nachstellen des Sensors.

    Die "einfache" Variante die mir dazu gerade in den Sinn kommt. Verzichte auf den Event Handler - Logik in die Schleifen am Ende schieben, dabei drauf achten, dass es keine Dinge gibt die ewig warten - wait_for_edge.

    Wohl etwas besser. Dein Poll-Anwendungen melden aktuell nur das sie den Bus nutzen. Wenn sie aber erst den Bus anfordern und warten bis dürfen, dann lesen, dann den Bus freigeben, könntest du alles synchronisieren. Erstellst du dann noch eine Anwendung und ordnest innerhalb der Anwendung, wann wer dran ist, dabei musst dann auch nicht mehr auf das Dateisystem runter - jeder Sensor kriegt einen Thread bzw. Worker, Verwaltung findet außerhalb statt.

    -----------
    Das Thema mehrere Busse wird dir nicht helfen, das hilft nur, wenn du mehrere Sensoren mit der selben Adresse hast.
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  14. #14
    Benutzter Registrierer
    Registriert seit
    Feb 2004
    Beiträge
    2.277
    Moin,

    Ich seh' da 2 Dinge, die potentiell Probleme machen koennen:

    1.) Der I2C Bus ist gedacht, um Chips auf einer Platine miteinander zu verbinden. Nicht ueber irgendwelche meterlangen Klingeldrahtverbindungen. Das kann vielleicht manchmal sogar funktionieren, muss aber nicht. Kann auch oft auf unangenehm subtile Weise schiefgehen.

    2.) Geraete, die einen IRQ ausloesen, der dann via I2C acknowledged werden muss. Das ist eigentlich ein Oxymoron, denn der I2C Bus ist superlangsam und bei der Verarbeitung und Ack des IRQ sollte es hurtig zur Sache gehen. Also auch potentiell Quelle fuer Probleme.

    Gruss
    WK
    Das ist aber zu viel zum Lesen und ich will, dass er einfach kompeliert!

Ähnliche Themen

  1. openssuse auf dem raspberry pi3 ?
    Von Dono im Forum System installieren und konfigurieren
    Antworten: 8
    Letzter Beitrag: 19.03.18, 16:23
  2. zattoo mit raspberry?
    Von pibi im Forum Fernsehen
    Antworten: 10
    Letzter Beitrag: 22.07.16, 12:38
  3. NAS mit Raspberry und USB RAID.
    Von Schendi im Forum stationäre Hardware
    Antworten: 9
    Letzter Beitrag: 09.10.13, 22:53
  4. Raspberry Pi GPU Treiber
    Von pulsar im Forum Mobiles Linux, Notebook, PDA
    Antworten: 0
    Letzter Beitrag: 07.10.13, 22:41
  5. DBI und DBD::mysql auf Raspberry
    Von I-Master im Forum System installieren und konfigurieren
    Antworten: 1
    Letzter Beitrag: 20.07.13, 15:09

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •