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 mit Kernel 4.11.6  4.14.70  4.19.20  4.19.25  4.19.38.

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.

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



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 19/07/07