Banana Pi IO Erweiterung - Hubo geht fremd

  • Banana Pi IO Erweiterung - Hubo geht fremd

    Motivation

    Auch auf die Gefahr hin, von den Himbeerfreunden gesteinigt zu werden, interessierte es mich doch, wie gut oder schlecht es um die angebliche Hardwarekompatibilität der Banana Pi‘s im Vergleich zu den Raspberry Pi‘s steht. Insofern klemmte ich einen Hubo an die Pfostenleisten eines Banana Pi M2+ sowie eines Banana Pi M1. Wie so
    oft, ist es nicht die Hardware, sondern die Software, die einen beschäftigen kann...



    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
    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
    options w1_sunxi gpio=6



    Jetzt funktioniert die 1wire Kommu
    nikation 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
    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.
    Abspeichern, fex-Datei in eine bin-Datei rückcompilieren und neu starten.


    Code
    [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
    fex2bin script.fex script.bin
    reboot


    Nun sollte sich neben dem Busmaster auch ein angeschlossener 1wire Sensor erkennen lassen.

    Code
    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
    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
    Es ist ein wenig schade, wenn die eigentlich gute BPI 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 auch der Familie der Banana-Pi Kleincomputer zugänglich zu machen bzw. zu zeigen, wie die Hardware erschlossen werden kann.


    Ein fertiges Raspbian-Image für den M2+ kann >>> hier <<< 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. Zwei kleine Beispiele in Python liegen ebenfalls bei. Weitere Informationen finden sich auf meiner Homepage.


    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 aussieht.



    [Blocked Image: http://hubo.lima-city.de/BPI/BPI-M1-Hubo.jpg]
    Bild 1: Banana-Pi M1 mit Hubo, 1wire Sensor und Echtzeituhr.


    [Blocked Image: http://hubo.lima-city.de/BPI/BPI-M2P-Hubo.jpg]
    Bild 2: Banana-Pi M2+ mit 2 kaskadierten Hubos, 1wire Sensor, Echtzeituhr und Relaisoption


    Viel Spaß beim Basteln wünscht…


    schnasseldag

  • Hallo Schnasseldag,


    ich habe es immer schon gewusst, gehofft, geahnt, dass Dein Hubo viel viel mehr kann, als nur einen Raspberry Pi bei Laune zu halten!


    Ich bleibe gespannt, was Du als nächstes herausfinden wirst!


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.