Gleissignalerzeugung mit BananaPi

Aufgabenstellung

Meine Wunschvorstellung ist ein Ethernet <-> CAN -Wandler, der "nebenbei" noch das Gleissignal erzeugt. Der BananaPi hat den CAN-Controller schon drin, beim RaspberryPi müsste ein externer über SPI angeschaltet werden. Der SPI wird dann aber schon für die Gleissignalerzeugung verwendet und beides zusammen passt nicht.

Vorzusehende Signale am BPi:

Realisierung Hardware

Die Beschaltung zum Nutzen der Basisfunktion ist hier abgebildet:

RS232-beschaltung am BPi

Realisierung Software

Die genutzte Software baut auf das im letzten Jahrtausend entstandene DDL, die dann in den SRCP server eingeflossen ist.

Daniel Sigg hat den DDL-Teil, der ursprünglich für die Ausgabe über einen PC-basierten COM-Port entwickelt war, auf SPI umgearbeitet, das mfx-Protokoll hinzugefügt und seine Software veröffentlicht.

Um diesen srcpd auch auf dem BananaPi nutzen zu können, waren weitere Anpassungen notwendig. Dabei habe ich dann auch die srcpd-Anteile weggelassen, die für DDL nicht benötigt werden, die Ansteuerung durch die Clients erfolgt aber weiterhin durch das Simple Railroad Command Protocol. Entwickelt und getestet wird unter Armbian Debian Jessie Stretch  Buster mit Kernel 4.11.6  4.14.70  4.19.20  4.19.25  4.19.38   4.19.62.

Anmerkung:
Bei einem Update von Armbian wurde der Kernel von 4.11.6 auf 4.13.16 hochgezogen und seither heisst das SPI plötzlich anstatt "/dev/spidev32766.0" wie früher "/dev/spidev0.0".

Informationen zum Betrieb der Software

Software-Quellpaket DDL über SPI für BananaPi















Testkonfiguration für Zentrale mit BananaPi

Testkonfiguration für BPi
Die Zahlen stellen die verwendeten Portnummern dar.

Anpassung der Startdateien

Zum automatischen Start aller Funktionen kann man die Datei /etc/rc.local missbrauchen:

# setup virtual CAN interface
	ip link add type vcan
	ip link set vcan0 up

# start gateway for MCS devices and srcpd
	can2lan -m -c /www/config -i vcan0
	srcpd

# for MaeCAN
	can2udp -d 15733 -l 15734 -b 127.0.0.1 -i vcan0
	cd /www/MaeCAN-Server/node && nohup node maecanserver.js 2>&1 > /dev/null &
Bei Verwendung von Gerds Lede Image oder  Gerds OpenWRT Image muss die Datei /etc/init.d/can2lan entsprechend angepasst werden.


Testkonfiguration für Zentrale mit herausgeführtem CAN-Bus

Testkonfiguration X für BPi

Hier kann man ein oder mehrere externe CAN-Geräte mitverwenden. Wenn die Möglichkeit besteht, dass auch einmal kein aktives CAN-Gerät angeschlossen ist, hilft die Option "presume-ack on", um eine Blockade der internen CAN-Kommunikation zu vermeiden:

# setup CAN interface
    ip link set can0 up type can bitrate 250000 presume-ack on restart-ms 10
Anmerkung: "presume-ack" funktioniert nur mit aktuellem CAN-Treiber, z.B. in Gerds OpenWRT Image ab 24.9.2019.


Bedienung über Luci-Weboberfläche

Seit Juni 2020 gibt es bei Verwendung des OpenWRT Images eine Bedienungs-Vereinfachung:

Luci Systemstart

Man muss den basrcpd-Server(1) nicht mehr per Kommandozeile starten und auch das Aktivieren des "presume-ack"-Modus(2) wurde wesentlich vereinfacht (bisher war editieren einer Konfigurationsdatei erforderlich) - das geht jetzt alles über die Luci-Bedienoberfläche im Browser.
Mit dem Start-Knopf kann man das entsprechende Leistungsmerkmal sofort einschalten bzw. per (De)aktiviert-Knopf einstellen, dass es automatisch bei jedem Rechnerstart eingeschaltet wird.


Zusätzliche Informationen

Reaktionszeit bei Temperaturabfrage

Beim Lesen aus dem sys-Filesystem gibt es unter meinem Entwicklungs-Armbian Probleme, während es unter Lede funktioniert: Lesebefehle der "get-Gruppe" arbeiten so schnell (~100µs) wie unter Lede, liefern aber nicht wirklich aktuelle Werte, die der "read-Gruppe" liefern sinnvolle Werte, aber blockieren der Rechner für Hunderte von Millisekunden!
Die Ursache liegt am ultralangsamen Temperatursensor auf dem BPi, der für eine Messung eine halbe Sekunde braucht. Bei Armbian startet der Treiber sun4i_gpadc die Wandlung und blockiert den rufenden Thread bis sie fertig ist, bei Lede veranlasst der Treiber sun4i-ts periodisch alle 2 Sekunden eine Wandlung und speichert das Ergebnis, das er dann bei Anfrage in wenigen Mikrosekunden zur Verfügung stellen kann.
Zum Glück gibt es den sun4i-ts auch bei Armbian, man muss nur verhindern, dass sich der sun4i_gpadc beim Starten vordrängt. Dazu erstellt man eine Datei /etc/modprobe.d/temp-blacklist.conf mit folgendem Inhalt:

# block very slow gpadc to give sun4i-ts the chance for fast temperature reading
blacklist sun4i_gpadc_iio
blacklist sun4i_gpadc

Geänderte Dateien für Armbian Image

Die angepassten Dateien werden zusammen als armbfiles.cpio -Archiv zum Download bereitgestellt.



Die oben aufgeführten Informationen wurden nach bestem Wissen erstellt, jedoch wird jegliche Haftung des Autors für irgendwelche Schäden ausgeschlossen.
Rainer Müller, Stand 20/07/08