Guten Abend, ich hoffe jemand kann mir beim Raspberry Pi mit OS12 Bookworm helfen. Ich habe mir eine kleine C++ App für den Raspberry Pi und dessen CLI erstellt. Ich polle hier zwei LoRa-Funkmodule (434 und 868 MHz / RFM98 und RFM95). Diese sind auf dem SPI und verwenden den CS0 sowie CS1 (Pin 8 und Pin 7) sowie DIO0 und DIO1 (hier 25/24 und 16/12). Verwende die RadioLib von JGromes: https://github.com/jgromes/RadioLib Das merkwürdige: Ich muss den CS0 und CS1 mit "RADIOLIB_NC" initialisieren, weil der RPi-Kernel wohl die Pins besetzt. Zusätzlich kann ich die DIO0 und DIO1 nicht abfragen. Ich muss also die Module pollen um zu erkennen ob Daten anliegen. Daher ist hier kein CAD (channel activity detection) möglich. Auch kein interruptgesteuerten Aufruf der Empfängerroutine über DIO0. DIO0 wird vom Modul hier nicht gesetzt. Kommt ein Paket, bleibt es 0. Brücke ich den GPIO mit 3v3, so geht der Eingang auf high. GPIO 25: level=0 func=INPUT pull=DOWN GPIO 25: level=1 func=INPUT pull=DOWN (gekürzt) raspberry@raspberrypi:~/LoRaHAM $ raspi-gpio get BANK0 (GPIO 0 to 27): GPIO 25: level=0 func=INPUT pull=DOWN GPIO 24: level=0 func=INPUT pull=DOWN GPIO 16: level=0 func=INPUT pull=DOWN GPIO 12: level=0 func=INPUT pull=DOWN Die IOs sind also auf Pull-Down und müssen high werden, sobald DIO einen Interrupt auslöst. Was ist der Grund, weshalb ich hier die DIO0 und DIO1 nicht ausgelöst bekomme? Quellcode anbei Anmerkung: in Python geht es!
Wenn man mit einem Raspberry Pi z.B. die Hardware-SPI-Schnittstelle nutzen möchte, sollte man das in config.txt angeben. Passend zur Betriebsart der Schnittstelle (ob mit oder ohne /CS-Signale etc.) mit einem passenden Overlay. Für einen Raspberry Pi 4 sieht das z.B. so aus:
1 | dtparam=spi=on |
2 | dtoverlay=spigen-rpi4 |
Im Verzeichnis "overlays" der Bootpartition wird dann noch die Datei spigen-rpi4.dtbo erwartet. Dann kann das geladene Betriebssystem die SPI-Schnittstelle über den zugehörigen Devicetreiber zur Verfügung stellen -- und man frickelt dann nicht mit irgendwelchen GPIO-Geschichten herum. Der Devicetreiber stellt /dev/spigen0.0 und /dev/spigen0.0 zur Verfügung und kann mit verschiedenen IOCTL-Codes konfiguriert werden, z.B. SPI_IOC_WR_MODE oder SPI_IOC_WR_MAX_SPEED_HZ. Die sollten in linux/spi/spidev.h zu finden sein. Oder hab' ich Dein "Diese sind auf dem SPI und verwenden den CS0 sowie CS1" komplett missverstanden?
Harald K. schrieb: > Oder hab' ich Dein "Diese sind auf dem SPI und verwenden den CS0 sowie > CS1" komplett missverstanden? Guten Abend, wäre möglich, aber ich hab vergessen zu erwähnen das natürlich in der config.txt dtparam=spi=on aktiv ist. Ohne könnte ich mit der RadioLib gar keine Verbindung zum LoRa-Funkmodul aufbauen. Und auch das Python-Skript würde nicht funktionieren.
Guten Morgen! Ich habe die Lösung gefunden: nach dtparam=spi=on muss dtoverlay=spi0-0cs gesetzt werden. Zudem war mein Code auch falsch, da ich: PiHal* hal_433 = new PiHal(0); // SPI0 PiHal* hal_868 = new PiHal(1); // SPI1 statt PiHal* hal_868 = new PiHal(0); // SPI0 gesetzt habe. Jetzt funktioniert: Module mod_433 = Module(hal_433, 8, 25, 5, 24); Module mod_868 = Module(hal_868, 7, 16, 6, 12); Interessant dabei war, dass das 868er Modul über SPI1 angesprochen wurde und funktionierte.
Alexander W. schrieb: > dtoverlay=spi0-0cs Aha. Das bedeutet, daß Du die /CS-Leitung(en) für die SPI-Schnittstelle selbst "von Hand" bedienst:
1 | Name: spi0-0cs |
2 | Info: Don't claim any CS pins for SPI0. Requires a device with its chip |
3 | select permanently enabled, but frees a GPIO for e.g. a DPI display. |
github.com/raspberrypi/firmware/blob/master/boot/overlays/README
Guten Morgen zusammen! Harald K. schrieb: > Aha. Das bedeutet, daß Du die /CS-Leitung(en) für die SPI-Schnittstelle > selbst "von Hand" bedienst: Nein, das bedeutet, dass RadioLib die /CS-Leitungen selbst bedienen möchte. Um ein funktionierendes Programm zu bekommen, habe ich zuerst die CS (NSS) über "RADIOLIB_NC" definiert. Das müsste -1 sein und schaltet die Nutzung ab. Da hat aber die Abfrage über DIO0 und DIO1 nicht funktioniert. DIO0 wollte ich verwenden, um zu sehen ob im RX-Puffer Daten vorhanden sind. DIO1 für Channel Activity Detection (CAD). Hier würde ich sehen ob auf der Frequenz und dessen Parameter bereits was los ist. Zusätzlich kann ich über RSSI schauen ob überhaupt jemand da sendet. Das funktionierte alles nicht und ich musste die Daten aus dem Modul pollen was natürlich die Prozessorlast steigerte. Ich bin noch relativ neu im RPi und dessen Programmierung. Deshalb fällt es mir auch schwerer eine passende GUI in kurzer Zeit aufzusetzen. Ziel diesmal: APRSthurday (auf LoRa-APRS Frequenz) mit einer kleinen eigenen C++ GUI (GTK4) auf dem Raspi (LoRaPAD) zu bedienen. In Python habe ich das bereits. Falls Interesse am LoRa-Funk bzw Amateurfunk mit LoRa besteht, kann sich gerne jeder bei mir melden. Falls Ulm nicht zu weit weg ist, kann ich gerne auch zum OV-Abend einladen!
Alexander W. schrieb: > Nein, das bedeutet, dass RadioLib die /CS-Leitungen selbst bedienen > möchte. Eben. Genau das. Das ist "von Hand" bedienen. Die Alternative dazu ist, daß das die SPI-Hardware selbst macht. Und das kann der RPi.
Harald K. schrieb: > Eben. Genau das. Das ist "von Hand" bedienen. Die Alternative dazu > ist, daß das die SPI-Hardware selbst macht. Und das kann der RPi. Ahh, ich habe das "von Hand" so verstanden, dass ich in meinem Code die Pins selbst setze ;-) Ich habe auch die RadioLib Doku noch mals durchgesehen und keinen Hinweis darauf gefunden, dass man dies beim RPi beachten muss. Ich werde auf Github einen Hinweis hinterlassen, damit andere nicht auch so lange suchen müssen.
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.