Update 10.04.24: Verwendung GPIO ABI und nicht mehr sysfs für GPIO Zugriff.
Aktuelle, stabile Version 1.5.0.
Nachdem ich nun langsam aber sicher genug habe von Fehlersuche mit Speicherüberläufen im alten srcpd C-Code habe ich mich dazu entschieden, einen neuen srcpd in RUST zu schreiben. Der Einstieg in RUST ist für einen langjährigen JAVA, C/C++ Programmierer zwar schon etwas „zäh“ und hat mir einiges an Durchhaltewille abverlangt. Aber: wenn es mit RUST mal compiliert, dann funktioniert es auch (meistens) .
Einschränkungen:
- Auf SRCP Seite is nur das implementiert, was ich brauche, siehe Doku.
- Es wird nur DDL mit Ausgabe über SPI (z.B. Raspberry PI) unterstützt
Was es kann:
- DCC Servicemode, Lesen (Programmiergleis) & Schreiben (Prog. und Hauptgleis) CV’s.
- MM Protokolle, DCC, MFX.
- MFX Lesen und Schreiben Lokparameter, automatische Lokanmeldung mit auslesen Lokname und Funktionen.
Servicemode für MFX. - Es ist schnell! Optimierung der Protokollausgabe, wenn z.B. ein Protokoll eine Pause verlangt (z.B. DCC zwischen zwei Paketen an die selbe Adresse 5ms, MM5 zwischen den Paketen für 28 FS 50ms), dann wird nicht einfach gewartet sondern andere Pakete eingeschoben. Es wir keine Millisekunde verschenkt. Das ist gegenüber dem Orginal srcpd spürbar (zumindest bei meiner Anlage mit ca. 80 Loks).
- S88 Bus (auch nur über SPI).
- Konfigurierbare Oszi Triggermöglichkeit bei S88 Veränderungen, Ausgabe GA, GL, SM Kommandos.
Hallo Daniel,
nach einem ‚apt upgrade‘ von raspbian 12 (bookworm) mag der srcpd (1.4.0) nicht mehr. Beim Start kommt folgende Meldung:
srcpd V1.4.0 http://www.siggsoftware.ch
Raspberry PI: in /boot/config.txt core_freq=250 und core_freq_min=250 setzen!
Dies ist notwendig um einen stabilen und für S88 keinen zu hohen SPI Clock zu haben.
[05.04.2024 18:11:10.841 INFO srcpd] Neuer SRCP Server ddl auf Bus 5
[05.04.2024 18:11:10.844 INFO srcpd::srcp] srcp start port=4303
[05.04.2024 18:11:10.846 INFO srcpd::srcp] Start SRCP Server: 0.0.0.0:4303
[05.04.2024 18:11:10.848 INFO srcpd::srcp] Warte auf SRCP Server Client
thread ‚DCC Prog Thread‘ panicked at src/srcp_dcc_prog.rs:78:10:
GPIO_MFX_RDS_QAL konnte nicht geöffnet werden: Os { code: 22, kind: InvalidInput, message: „Invalid argument“ }
stack backtrace:
thread ‚DCC Prog Thread‘ panicked at src/srcp_dcc_prog.rs:78:10:
GPIO_MFX_RDS_QAL konnte nicht geöffnet werden: Os { code: 22, kind: InvalidInput, message: „Invalid argument“ }
thread ‚DDL_Thread‘ panicked at src/srcp_devices_ddl_power.rs:98:10:
GPIO 3 konnte nicht geöffnet werden: Os { code: 22, kind: InvalidInput, message: „Invalid argument“ }
Hier gibt es ein Problem beim Öffnen des GPIO. Das simple Testprogramm
fn main() {
let mut gpio22 = gpio::sysfs::SysFsGpioInput::open(22).unwrap();
println!(„GPIO22: {:?}“, gpio22.read_value().unwrap());
}
liefert den gleichen Fehler:
sudo ./target/debug/gpio-test
thread ‚main‘ panicked at src/main.rs:4:60:
called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: „Invalid argument“ }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Nutzt der crait gpio das GPIO sysfs? GPIO SysFs ist schon länger deprecated markiert….
Ich hoffe sehr, du hast eine Idee 😉
Danke dir schon mal und viele Grüße,
Joern
Hallo Joern
Das ist ein Problem.
RUST „Crate gpio“ nutzt tatsächlich das sysfs GPIO Interface.
Und ja, das gibt es nicht mehr mit Raspbian 12 (bookworm).
Ich habe keine andere, konfortable Möglichkeit als „Crate gpio“ gefunden um mit RUST auf GPIO Pins zuzugreifen.
Entweder warten bis jemand ein neues RUST GPIO Interface baut oder selbst umbauen. 🙁
Gut habe ich noch nicht gewechselt. Ich bleibe also vorerst beim alten Rasbian.
Sorry, ich kann Dir im Moment keine andere Lösung anbieten.
Gruss Dani
Hallo Joern
Habe eben crate „gpio-cdev“ gesehen. Diese verwendet nicht mehr sysfs.
Werde den entsprechenden Umbau in Angriff nehmen.
Gruss Dani
Hallo Joern
Umbau auf gpio-cdev ist erfolgt, V1.5.0 steht zur Verfügung.
Sollte damit nun auch auf Raspbian 12 ohne sysfs GPIO funktionieren.
Gruss Dani
Hallo,
gibt es denn die SW https://siggsoftware.ch/wordpress/category/javaestw/ noch?
Wie kann diese mit anderer Steuer-SW kombiniert werden
Ja, diese SW gibt es noch und sie wird von mir noch weiter entwickelt.
Das ist die SW, die ich für meine Modellbahn verwende.
Sie unterstützt das SRCP Protokoll und kann mit beliebigen srcpd Servern zusammenarbeiten.
Ich benutzte jedoch nur noch meine SRCPD RUST Implementierung.
SET 5 POWER ON
1702661882.042 200 OK 5 POWER
GET 5 POWER
1702661901.051 100 INFO 5 POWER OFF
Wie wird das Feedback „Power on“ in den Pi übertragen? Der 6015 Booster hat dafür gar keinen Ausgang. Gibt es einen Work-Around?
Gruß, Joern
Hallo Joern
Wenn „siggmode“:
– Booster ein mit Impuls an „RTS“ (GPIO27 =Pin13)
– Booster aus mit Impuls an „DTR“ (GPIO4 =Pin7)
– Rückmeldung von Booster ein/aus an „CTS“ (GPIO3 =Pin5)
Ohne „siggmode“:
– Booster ein/aus Dauersignal an „DTR“ (GPIO4 =Pin7)
– Rückmeldung von Booster ein/aus an „DSR“ (GPIO2 =Pin3)
– Konfiguration ob Low oder High an „DSR“ Off/On bedeutet über „dsr_invers“
– Verzögerung Reaktion Ausschalten über „shortcut_delay=xxxx“
Habe ebene gesehen, dass meine Beschreibung in „srcpd.pdf“ falsch ist. Wird gleich korrigiert.
Anschluss 6015 Booster ist z.B. hier beschtrieben, inkl. Rückmeldung: http://home.snafu.de/mgrafe/Anleitung_Server.htm
Gruss Dani
Hi Dani,
Perfekt, funktioniert ausgezeichnet! Damit schalte ich das erste mal MM GA per SRCP. Besten Dank!
Gruß, Joern
Hi Dani,
hab deinen srcpd in RUST auf einem Pi 1 am Laufen:
pi@raspberrypi:~ $ sudo work/srcp/srcpd-rust-16112023/target/debug/srcpd -n
srcpd V1.2.0 http://www.siggsoftware.ch
Raspberry PI: in /boot/config.txt core_freq=250 und core_freq_min=250 setzen!
Dies ist notwendig um einen stabilen und für S88 keinen zu hohen SPI Clock zu haben.
[14.12.2023 18:27:25.766 INFO srcpd] Neuer SRCP Server ddl auf Bus 5
[14.12.2023 18:27:25.773 INFO srcpd::srcp] srcp start port=4303
[14.12.2023 18:27:25.777 INFO srcpd::srcp] Start SRCP Server: 0.0.0.0:4303
[14.12.2023 18:27:25.788 INFO srcpd::srcp] Warte auf SRCP Server Client
[14.12.2023 18:29:52.712 INFO srcpd::srcp] SRCP Server neuer Client:127.0.0.1:52574
[14.12.2023 18:29:52.715 INFO srcpd::srcp] Warte auf SRCP Server Client
Das ist die srcpd.conf
[srcp]
port = 4303
bus = 5
spiport = /dev/spidev0
maerklin
#dcc
#mfx=1021970
#mfx_reg_count_file = /etc/srcpd.regcount
siggmode
timeout_shortcut_power_off = 10000
shortcut_delay = 500
s88 ist auskommentiert
Im telnet-Terminal gebe ich folgendes zu Protokoll:
SET PROTOCOL SRCP 0.8.2
ok
SET CONNECTIONMODE SRCP COMMAND
ok
SET 5 POWER ON
ok
INIT 5 GA 5 M
ok
SET 5 GA 5 0 1 250
ok
Ein Oszi ist mit Single-Trigger-Funktion am Pi Pin 19 (MOSI) angeschlossen. Mindestens nach dem letzten SET hätte ich einen Trigger erwartet. Kommt aber nicht. Scope ohne Trigger zeigt auf Pin 19 konstant 2,72V.
Was läuft hier schief?
Gruß, Joern
Noch eine Ergänzung: Im telnet Terminal gebe ich auch ein „GO“ als dritten 3. Befehl – hatte ich vergessen, oben zu schreiben…
Hallo Joern
wahrscheinlich geht der POWER ON nicht.
Es wird mit siggmode ein Feedback erwartet, dass der Booster On ist.
Mach mal GET 5 POWER.
Gruss Dani