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:
- Basisfunktion
- Ausgang Schienensignal
- Ausgang Boosteraktivierung
- Eingang Fehlerzustand
- mfx-Unterstützung
- Eingang RDS-Takt
- Eingang RDS-Daten
- Eingang RDS-Qualität
- Eingang RDS-Trägererkennung
- Programmiergleisunterstützung
- Ausgang Gleisumschaltung
- Eingang Stromdetektor
- Railcom-Unterstützung
- Ausgang Austastlücke
- Eingang Railcom-Daten
- Eingang Aufgleisrichtung
Realisierung Hardware
Die Beschaltung zum Nutzen der Basisfunktion ist hier abgebildet:
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 Bullseye mit Kernel
4.11.6 4.14.70 4.19.20 4.19.25 4.19.38
4.19.62 5.10.60 5.10.63 5.15.48 5.15.93.
Informationen zum Betrieb der Software
Software-Quellpaket DDL über SPI für BananaPi
Testkonfiguration für Zentrale mit BananaPi
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
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:
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
und führt danach "update-initramfs -u" aus:
# 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 23/07/19