Modulare IO-Erweiterung (analog, digital, 1wire...) für den Banana-Pi

schnasseldag
Beiträge: 2
Registriert: Dienstag 14. März 2017, 18:44
Danksagung erhalten: 4 Mal
Status: Offline

Modulare IO-Erweiterung (analog, digital, 1wire...) für den Banana-Pi

Beitragvon schnasseldag » Sonntag 19. März 2017, 19:40

Modulare IO-Erweiterung (analog, digital, 1wire...) für den Banana-Pi


Hintergrund und Motivation
Eigentlich tummle ich mich ja eher bei den „Kollegen“ im Raspberry-Pi Forum (http://www.forum-raspberrypi.de/) herum. Nachdem man nun bei den Herstellern des Banana-Pi prinzipiell etwas mehr Hardware für vergleichbares Geld erhält (vollwertigen Netzwerkcontroller oder auch einen SATA-Anschluß), dachte ich mir, zwei Vertreter der Serie (Banana Pi M1, Banana Pi M2+ EDU) mal ein wenig genauer unter dem Hintergrund einer IO-Erweiterbarkeit unter die Lupe zu nehmen.


Das Problem der Hardwarekompatibilität zwischen Raspberry-Pi und Banan-Pi
Oft heißt es, der/die Banana-Pis wären ja pinkompatibel, was ihre 26-poligen bzw. 40-poligen GPIO-Pfostenbuchsen anbelangt. Leider bedeutet pinkompatibel aber nicht immer „Stecker aufstecken und Software läuft“. Der Stecker paßt zwar und auch Software findet man, aber das Zusammenspiel will dann nicht so recht. Sucht man im Netz, so finden sich haufenweise Beschreibungen für den Raspberry Pi oder aber „Abschriften“ welche auf irgendwelchen sunxi… Treiberdefaultwerten (z.B. 1wire auf Pin 40 anstelle auf Pin 7 der Pfostenbuchse) aufsetzen. Oft ist noch nicht mal die Linuxversion genannt oder auch nur das Modell. Besitzt man nun eine „Raspberry-Pi Hardware“, dann „will die nicht“ - zumindest nicht auf Anhieb.


Raspbian (Kernel 3.4) unter einem Banan-Pi M2+

1wire auf GPIO4 (Pfostenbuchse CON2 Pin 7) in Betrieb nehmen
Hier fangen die Probleme schon mit falschen script.bin Dateien an (ja da lümmelt auch noch eine zweite, unbenutzte Kopie herum), bei denen die Hardwarebelegung des Pin 7 der 40-poligen Pfostenbuchse CON2 laut Schaltplan mit PA06 des SOC verbunden ist, sich im Fex-Dekompilat jedoch auf PA13 zu erkennen gibt. Um es vorweg zu nehmen – die script.bin per bin2fex zu decompilieren, entsprechend zu korrigieren und dann wieder per fex2bin zu compilieren bringt nichts. Auch nicht, wenn man die Datei vorsorglich unter /boot und unter /boot/bananapi/bpi-m2p/linux kopiert.
Was dem ganzen Konstrukt fehlt, ist das Modul w1_sunxi. Der Treiber wird nicht statisch geladen – zum Glück. Standardmäßig arbeitet dieser Treiber auf PA20, was dem Pin 40 unseres M2+ entspricht. Das ist jedoch softwaremäßig inkompatibel zum „Raspi-Standard GPIO4“ (Pin 7). Abhilfe schafft das dynamische laden per /etc/modules mit zusätzlichen gpio-Parametern für den w1_sunxi Treiber. Der gpio-Parameter weist das Modul an, auf GPIO6 (kein Schreibfehler) zu bitbangen.

Der Inhalt von /etc/modules ist um folgende Einträge (Reihenfolge beachten) zu ergänzen:

Code: Alles auswählen

w1_sunxi wire w1-gpio w1-therm
Um den Parameter gpio zu setzen, sollte eine Datei – nennen wir sie „bpi_m2p_load_1wire.conf“ – unter /etc/modprobe.d/ angelegt werden. Diese Datei beinhaltet dann:

Code: Alles auswählen

options w1_sunxi gpio=6
Jetzt funktioniert die 1wire Kommunikation auf Pin7 (also dem „Raspi-Standard GPIO4“, Pfostenbuchse Pin 7).

I2C-Devices
Hier fallen die Unterschiede zum Raspberry-Pi weniger dramatisch aus. Der einzige Unterschied des M2+ zum Raspberry Pi besteht darin, daß das I2C-Device des Raspi auf "/dev/i2c-1" lautet, beim M2+ hingegen auf "/dev/i2c-0". Der Sourcecode ist also nur marginal zu ändern.

SPI-Devices
Man mag es kaum glauben aber der SPI-Bus bedarf keiner Anpassungen!


Bananian (Kernel 3.4) unter einem Banan-Pi M1

1wire auf GPIO4 (Pfostenbuchse CON3 Pin 7) in Betrieb nehmen
Für diese Konfiguration findet man einige Anleitungen im Netz. Der Weg führt hier über die Erweiterung der script.bin Datei, welche es ermöglicht, dem w1-sunxi Treiber den gewünschten GPIO zuzuweisen. Wie der Name der Datei bereits erahnen läßt, handelt es sich um eine Binärdatei, die zunächst in eine Textdatei rückübersetzt wird, um nach entsprechender Änderung wieder in eine Binärdatei übersetzt zu werden. Die Übernahme der Daten erfolgt erst nach einem Neustart des Banana-Pi. Die Datei script.bin verbirgt sich hinter dem Device mmcblk0p1. (Anmerkung – einige Kommandos benötigen sudo-Rechte.)

Code: Alles auswählen

mkdir ~/mytemp mount /dev/mmcblk0p1 ~/mytemp cd ~/mytemp bin2fex script.bin script.fex nano script.fex
Darin muß innerhalb der [gpio_para]-Sektion die Definition des gpio_pin_4 auf PI03 verlinken, wenn wir Pin7 der 26-poligen Pfostenbuchse CON3 verwenden wollen. Fehlt die Sektion [w1_para] komplett, so wäre neben der gpio-Pinnummer 4 auch noch der Sektionsname nachzutragen.

Code: Alles auswählen

[gpio_para] gpio_used = 1 gpio_num = 88 gpio_pin_1 = port:PB20<1><default><default><default> ... gpio_pin_4 = port:PI03<1><default><default><default> ... [w1_para] gpio = 4
Abspeichern, fex-Datei in eine bin-Datei rückcompilieren und neu starten.

Code: Alles auswählen

fex2bin script.fex script.bin reboot
Nun sollte sich neben dem Busmaster auch ein angeschlossener 1wire Sensor erkennen lassen.

Code: Alles auswählen

ls /sys/bus/w1/devices 28-000005344d4e w1_bus_master1
I2C-Devices
Beim M1 hat man sich unter Bananian für das Device 2 entschieden. Also "/dev/i2c-2" und nicht 0 oder 1. Sourcecode ist im Punkt der Devicenummer also ggf. anzupassen.

SPI-Devices
Falls die beiden SPI-Module noch nicht geladen worden sein sollten, so ist der Inhalt von /etc/modules um den folgenden Inhalt zu ergänzen.

Code: Alles auswählen

spidev spi-sun7i
Das häufig unter dem Raspberry-Pi verwendete Device „/dev/spidev0.0“ ist hier pinkompatibel ebenso vorhanden. Änderungen müssen also nicht vorgenommen werden.


Umsetzung auf die Hubo-Hardware
Die vorliegende Untersuchung erfolgte nicht zufällig. Es ist ein wenig schade, wenn eigentlich gute Hardware sich aufgrund „mäßiger Softwareunterstützung“ nur wenig verbreitet. Gerade der M2+ EDU bietet zum Preis eines Raspberry-Pi A+ wesentlich mehr an Rechenleistung und Peripherie. Warum sollte er dann nicht die Basis für Steuerungen und Heimautomationen bilden?
Insofern entstanden diese Untersuchungen, um die Hubo-Hardware http://ftl-auerbach.lima-city.de/Hubo/hubo-hardware/ auch der Familie der Banana-Pi Kleincomputer zugänglich zu machen bzw. zu zeigen, wie die Hardware erschlossen werden kann.

Bei der Hubo-Hardware handelt es sich um eine kaskadierbare IO-Erweiterung für den Einsatz in Hutschienengehäusen. Die Schnittstellen belaufen sich auf analoge Eingänge, digitale Ein- und Ausgänge (offener Kollektor und Relais), Steckoptionen für Echtzeituhrmodule, 1-wire Bus und mehr.

Ein fertiges Raspbian-Image für den M2+ kann hier https://dl.orangedox.com/tv1tye0pfBr9HdhoRJ heruntergeladen werden. Es beinhaltet neben je einem vorkonfigurierten Fhem und openHAB-Server auch mehr als 2 Dutzend C++-Beispiele und eine Bibliothek zur Erstellung eigener Programme http://ftl-auerbach.lima-city.de/Hubo/H ... mentation/. Zwei kleine Beispiele in Python liegen ebenfalls bei. Weitere Informationen finden sich auf meiner Homepage http://ftl-auerbach.lima-city.de/Hubo/d ... fuer-hubo/.

Wer kein fertiges Image einsetzen möchte, der findet analog zu den Raspberry-Pi Installationsscripten auch solche für eine Installation für den M2+.

Anbei noch zwei Bilder, wie das ganze aussehen kann.

Bild
Bild 1: Banana-Pi M1 mit Hubo, 1wire Sensor und Echtzeituhr.

Bild
Bild 2: Banana-Pi M2+ mit 2 kaskadierten Hubos, 1wire Sensor, Echtzeituhr und Relaisoption.


Viel Spaß beim Basteln wünscht…

schnasseldag

Zurück zu „Hardware“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast