Gleissignalerzeugung mit BananaPi

Bereich für alle Themen rund um Modellbahn-Software, sowie der nötigen Hardware (PCs, Bildschirme, etc.).

Sigg
Beiträge: 9
Registriert: Mi 13. Sep 2017, 21:31
Nenngröße: H0
Stromart: digital
Kontaktdaten:
Schweiz

Re: Gleissignalerzeugung mit BananaPi

#26

Beitrag von Sigg » Mo 30. Okt 2017, 22:20

Jetzt habe ich es kapiert, "refresh_loco_one" ist korrigiert, wenn ein Protokoll (MFX odr DCC) aktiviert ist, aber keine Lok vorhanden ist, wird nun mit dem nächsten Protokoll weiter gemacht und nicht für immer und ewig kein Refresh mehr gesendet.
Update steht am üblichen Ort bereit: http://siggsoftware.ch/wordpress/srcpd- ... iterungen/

Gruss Dani

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#27

Beitrag von Rainer Müller » Fr 3. Nov 2017, 10:59

Hallo Mitleser,
Sigg hat geschrieben:
Mo 30. Okt 2017, 22:20
Jetzt habe ich es kapiert, "refresh_loco_one" ist korrigiert, wenn ein Protokoll (MFX odr DCC) aktiviert ist, aber keine Lok vorhanden ist, wird nun mit dem nächsten Protokoll weiter gemacht und nicht für immer und ewig kein Refresh mehr gesendet.
Update steht am üblichen Ort bereit: http://siggsoftware.ch/wordpress/srcpd- ... iterungen/

Gruss Dani
danke für das Update, habe ich bei mir mit reingenommen.

Nachdem ich in der Zwischenzeit beim Testen bin und auch die Kurzschlussabschaltung jetzt aktiv ist, mal ein Bild zum Anschluss des Boosters an den BaPi:
Bild
Am Sub-D9 habe ich folgende Signale:
- TXD gibt die Polarität des Schienensignals (pos. -> Mittelleiter pos.)
- RTS schaltet den Booster ein wenn positiv
- RXD wird z.Zt. nicht genutzt
- CTS zeigt an, dass Booster OK wenn positives Potential angelegt wird

und BaPi-seitig jeweils: Steckerpin / Port / Funktion


Ursprünglich wollte ich den RS232-Treiber mit 5V versorgen um die 3V3 zu schonen. Aber da die BaPi-Entwickler beim Runterfahren nur die 3V3 abschalten und die 5V anlassen, gibts da komische Potentiale: im Ergebnis Plus am Mittelleiter, so dass alle Loks (ohne deaktivierbaren Analogbetrieb) losrasten bis der Stecker gezogen wurde :mrgreen: . Nach Änderung der Versorgung auf 3V3 tritt dieses Phänomen nicht mehr auf.

Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#28

Beitrag von Rainer Müller » So 12. Nov 2017, 12:02

Hallo Gerd und weitere Mitleser,

den für den BPi angepassten Quellcode kann man hier erhalten. Allerdings ist da noch Nacharbeit und Optimierung notwendig, erstmal soll er nur zeigen, dass das Prinzip funktioniert.
Angedachte Aktivitäten sind z.B.:
- Rausschmeissen von "totem Code" zur Übersichtlichkeit (z.B. zur Ansteuerung von COM-Ports in PCs)
- Interface des DDL-Teils überarbeiten damit nicht nur das srcp zur Steuerung unterstützt wird
- ...

Eigentlich wollte ich das bisher unter Armbian 5.31 entwickelte srcpd auch testweise auf Lede bringen und hatte mir Gerds Lede-Image vom 17. August geholt (einfach Ausschalten ohne Runterfahren ist toll). Dass ich da nicht bis ans Ziel komme war klar, schließlich fehlen dort der SPI-Treiber und die Pin-Konfigurationsanpassungen.

Ein Rüberkopieren von ausführbaren Binärdateien klappte nicht wegen der Abhängigkeiten, also habe ich den gcc nachinstalliert zum Compilieren auf dem Zielsystem. Aber selbst kleinste Programme gingen nicht ohne Änderungen, so muss man wegen Native gcc uses softfp by default, should be hardfp jeden gcc-Aufruf mit "-mfloat-abi=hard" garnieren.
Damit und mit der Installation einiger weiterer Pakete aus dem Lede-Pool lassen sich alle Dateien im basrcpd compilieren. Beim Linken dann findet der Linker in der libxml2 leider die dort enthaltenen Symbole nicht und bemängelt unzählige "undefined references" auf die libxml2-Symbole. Ein Austausch gegen die libxml2 von Armbian zeigt, dass es wohl an der lib liegt, führt aber zu neuen Versionsproblemen.
Man kann sich natürlich auch fragen, wieso die Konfigurationsdatei ausgerechnet im xml-Stil aufgebaut sein muss, insbesondere wenn man die Konfiguration auch über die Weboberfläche ermöglichen will.
Rainer Müller hat geschrieben:
Mi 25. Okt 2017, 18:19
Mein Analyseprogramm muss ich jetzt nachbessern, das hat ein Problem mit mfx-Paketen ganz dicht hinter DCC-Paketen.
Das ist hier nachgezogen.


Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#29

Beitrag von Rainer Müller » Do 7. Dez 2017, 19:02

Hallo,

für alle, die die BananaPi-SW selbst aus den Quelldateien erzeugen wollen, gibts jetzt bei mir die Nikolausedition. Sie beinhaltet vorzugsweise das Ausmisten von unbenutztem historischem Code und Konfigurationsoptionen ohne wesentlichen funktionalen Einfluss. Enthalten sind auch die Änderungen, die Gerd für die Lede-Anpassung eingebracht hat.

Zur Anpassung an die Zentralenkonfiguration hat der Parameter "enable_checkshort_checking" in der Konfigurationsdatei jetzt die Möglichkeiten: no / yes / inverse
- no = keine Kuzschlussabschaltung, CTS wird nicht beachtet
- yes = erwartet positives Signal auf CTS für Betrieb (nach Inverter CTS2 = GND)
- inverse = erwartet negatives Signal auf CTS für Betrieb (nach Inverter CTS2 = VCC)

Diverse andere Parameter (aus der "DCC mit UART"-Optimierungskiste) sind entfallen, da sie für die SPI-Version nicht mehr benötigt werden.

Hinzugekommen ist beim Programmaufruf die "p"-Option, die Logausgaben parallel sofort auf der Konsole ausgibt, also z.B.:
srcpd -np

Weiterhin bastle ich an einem rudimentären Webauftritt, der alle Info zusammenfassen soll.


Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#30

Beitrag von Rainer Müller » Fr 12. Jan 2018, 18:38

Hallo alle,

es geht weiter, zwar nicht mit neuem Code, sondern mit den Testergebnissen des bestehenden.
Getestet habe ich mit einem modifizierten dtcltiny als srcp-Client.

MM1 und MM2 sehen mit der Analysesoftware ordentlich aus, und die entsprechend angesteuerten Loks arbeiten korrekt.

DCC ist laut Analysesoftware OK, ein etwas angestaubter LoPi1 im Prüfstand lässt sich steuern.
Programmierung im Hauptgleismodus sieht laut Analyse im Bytemodus (Schreiben 0x22 ins CV 32) so aus:

Code: Alles auswählen

   2142 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2154 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
*  2163 ms: DCC Pr.15, Daten: 1e ec 1f 22 cf(OK)  K 30 POM CV = 32, WRI 22
   2173 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
*  2185 ms: DCC Pr.15, Daten: 1e ec 1f 22 cf(OK)  K 30 POM CV = 32, WRI 22
   2195 ms: MFX A07:5 Ping an Decoder 0x1E240  +0011+
   2222 ms: MFX A07:0 Such mit 0 Bits von Id-Maske 0x0   +0011+
   2249 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
und hier noch der Bitmodus (Setzen von Bit 3 im CV 29):

Code: Alles auswählen

   2382 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2394 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
*  2403 ms: DCC Pr.15, Daten: 1e e8 1c fb 11(OK)  K 30 POM CV = 29, BIT 3 WRI 1
   2414 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
*  2420 ms: DCC Pr.15, Daten: 1e e8 1c fb 11(OK)  K 30 POM CV = 29, BIT 3 WRI 1
   2430 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
   2438 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
Probleme bereitet dagegen der Programmiergleismodus, der zwar im Protokoll definiert ist, aber z.B. eine Auswertung zum Ansteuern eines Umschalters noch nie im srcpd realisiert war. Zusätzlich ist die Paketerzeugung für die Untermodi im basrcpd noch nicht von UART auf SPI umgestellt.
Die Parameterprüfung könnte auch noch besser sein, so führt z.B. ein BIT auf 7 zu setzen zu einem OK, ebenso das 9te von 8 zu modifizieren!

mfx ist ewas aufwändiger zu testen, da es normalerweise von srcp-Clients nicht unterstützt wird, und die Anmelde-HW für das Projekt noch nicht definiert ist.
Hier die Adresszuweisung (5) für einen mfx-Decoder:

Code: Alles auswählen

   3812 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
   3821 ms: MFX A07:5 V3:0 F16:0 
   3828 ms: MFX A07:5 V3:0 F16:0 
   3839 ms: MM1 A= 60, F=0, D= 0  <REP> <REP> <REP>
   3867 ms: MFX A07:5 Ping an Decoder 0x1E240  +0011+
*  3894 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0x1E240 
*  3903 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0x1E240 
   3913 ms: MFX A07:0 Such mit 0 Bits von Id-Maske 0x0   +0011+
   3944 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP>
   3958 ms: MM2 A= 16, F=0, D= 0, X= 4 F2 aus <REP>
   3972 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
und noch die Fahrbefehle an ihn:

Code: Alles auswählen

   1838 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
   1854 ms: MM1 A= 60, F=0, D= 0  <REP> <REP> <REP>
*  1882 ms: MFX A07:5 V7:3 F16:0 
*  1890 ms: MFX A07:5 V7:3 F16:0 
   1898 ms: MFX A07:5 Ping an Decoder 0x1E240  +0011+
   1924 ms: MFX A07:0 Such mit 0 Bits von Id-Maske 0x0   +0011+
*  1952 ms: MFX A07:5 V7:3 F16:0 
*  1960 ms: MFX A07:5 V7:3 F16:0 
*  1968 ms: MFX A07:5 V7:4 F16:0 
*  1975 ms: MFX A07:5 V7:4 F16:0 
   1986 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP>
   2000 ms: MM2 A= 16, F=0, D= 0, X= 3 F1 aus <REP>
   2014 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
Ob das periodische Wiederholen der Adresszuweisung alle 11s durch den Server sinnvoll ist? Im Decoder kann das je nach Speichertechnologie und Intelligenz der Speicherroutine auch zu schneller Zellalterung führen.

Gruß
Rainer


Sigg
Beiträge: 9
Registriert: Mi 13. Sep 2017, 21:31
Nenngröße: H0
Stromart: digital
Kontaktdaten:
Schweiz

Re: Gleissignalerzeugung mit BananaPi

#31

Beitrag von Sigg » Di 16. Jan 2018, 22:06

Hallo Rainer
Zur periodischen Wiederholung der MFX Adresszuweisung:
Ich habe bei mir nur das DCC Programmiergleis mit MFX Rückmeldung ausgestattet.
Da ich 3 Booster im Einsatz habe war mir der Aufwand, diese Rückmeldung über die ganze Anlage zu haben, zu gross.
Dazu kommt, dass die Störungen duch die Umschaltung der Boosterspannung immer schlimmer werden (trotz Gleichrichter vor Trafo), je grösser der Fahrstrom wird. Auf dem Prog.Gleis befindet sich normalerweise genau ein Fahrzeug, was mir die Sache wesentlich einfacher gemacht hat.
Grosser Nachteil ist natürlich, dass ein Fahrzeug, dass die Adresszuordung "vergessen" hat (war auf anderer Anlage, hatte gerade kein Strom als der Neuanmeldezähler inkrementiert wurde) damit nie mehr neu angemeldet werden konnte, es extra auf das Programmiergleis musste.
Dieses Problem habe ich mit dem periodischen Versenden der Adresszuordung umgangen.
Ich hoffe natürlich, dass die Dekoder so schlau sind und merken, wenn eine Adresszuordnung noch gleich ist.
Eine andere Möglichkeit wäre noch die Adresszuordung durch den SRCP Client bei Bedarf auszulösen. Das müsste aber noch ins SRCP Protokoll.

Gruss
Dani

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#32

Beitrag von Rainer Müller » Fr 19. Jan 2018, 20:06

Hallo Dani,
Sigg hat geschrieben:
Di 16. Jan 2018, 22:06
Hallo Rainer
Zur periodischen Wiederholung der MFX Adresszuweisung:
...
Dieses Problem habe ich mit dem periodischen Versenden der Adresszuordung umgangen.
Ich hoffe natürlich, dass die Dekoder so schlau sind und merken, wenn eine Adresszuordnung noch gleich ist.
Das hoffe ich zwar auch, aber nachdem jetzt dann mit Esu, Märklin, bald evtl. Uhlenbrock und Piko vier verschiedene Hersteller zugange sind, ist die Möglichkeit groß, dass einer was anders macht.
Sigg hat geschrieben:
Di 16. Jan 2018, 22:06
Eine andere Möglichkeit wäre noch die Adresszuordung durch den SRCP Client bei Bedarf auszulösen. Das müsste aber noch ins SRCP Protokoll.

Gruss
Dani
Bei Märklin darf laut der Protokollspezifikation nur das Masterbediengerät "MFX Verify", "MFX Bind" usw. auslösen, was bei SRCP der Client wäre. Da hast du eine andere Aufgabenteilung eingebaut mit einem selbstständigeren srcpd. Ich muss mir mal die Vor- und Nachteile überlegen vor ich da was ändere; vom offiziell spezifizierten SRCP sind wir eh schon weg.

Gruß
Rainer


Sigg
Beiträge: 9
Registriert: Mi 13. Sep 2017, 21:31
Nenngröße: H0
Stromart: digital
Kontaktdaten:
Schweiz

Re: Gleissignalerzeugung mit BananaPi

#33

Beitrag von Sigg » So 4. Mär 2018, 17:45

Hallo zusammen
Habe in meiner srcpd Implementierung nun das Thema MFX Adresszuordnung geändert.
Diese wird nun nicht mehr konstant repetiert sondern jeweils einmalig nach einem Power-Up (Booster-Go) sowie bei Empfang eines SRCP Lok-Init Kommandos gesendet. Somit kann ein SRCP Client die Adresszuordnung bewusst (auch mehrfach) auslösen.
Denke, damit sollten die Lokdekoder, auch wenn sie so blöde implementiert sind, dass sie immer wieder neu speichern, kein Problem mehr haben.

Gruss
Dani

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#34

Beitrag von Rainer Müller » Mo 25. Jun 2018, 17:10

Hallo,

für den basrcpd gibt es mal wieder ein Update .
Wichtigste der Änderungen ist die Möglichkeit der mfx-Adresszuweisung via SRCP ("MFX Bind").
Rainer Müller hat geschrieben:
Fr 19. Jan 2018, 20:06
...
Sigg hat geschrieben:
Di 16. Jan 2018, 22:06
Eine andere Möglichkeit wäre noch die Adresszuordung durch den SRCP Client bei Bedarf auszulösen. Das müsste aber noch ins SRCP Protokoll.

Gruss
Dani
Bei Märklin darf laut der Protokollspezifikation nur das Masterbediengerät "MFX Verify", "MFX Bind" usw. auslösen, was bei SRCP der Client wäre. Da hast du eine andere Aufgabenteilung eingebaut mit einem selbstständigeren srcpd. Ich muss mir mal die Vor- und Nachteile überlegen vor ich da was ändere; vom offiziell spezifizierten SRCP sind wir eh schon weg.
Ich habe mich dafür entschieden, ablaufmäßig möglichst dicht an der MCS-Protokollspezifikation zu bleiben, um möglichst einfach sowohl CAN- als auch SRCP-Clients abfangen zu können; die Adresszuweisung erfolgt nur noch auf Anforderung und nicht mehr periodisch.

Das neue hinzukommende SRCP-Kommando mfx-Bind hat die Syntax:

Code: Alles auswählen

> SET <bus> SM <addr> BIND <lokUid>

beispielsweise so:
> SET 1 SM 5 BIND 4294927222
< 1529570199.368 200 OK
entspricht funktional genau folgendem CAN-Kommando:

Code: Alles auswählen

> 17:48:09.883   CAN  0x00040300  [6] FF FF 63 76 00 05       MFX Bind: MFX UID 0xFFFF6376 MFX SID 5
< 17:48:09.886   CAN  0x00050300  [6] FF FF 63 76 00 05       MFX Bind: MFX UID 0xFFFF6376 MFX SID 5
Die Signalanalyse zeigt dann:

Code: Alles auswählen

...
2171 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0xFFFF6376 
2181 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0xFFFF6376 
...
Eine Abfrage mit

Code: Alles auswählen

> VERIFY <bus> SM <addr> BIND <lokUid>

also im konkreten Beispiel:
> VERIFY 1 SM 5 BIND 4294927222
< 1529570209.011 200 OK

beziehungsweise 
> 17:48:09.909   CAN  0x00060300  [6] FF FF 63 76 00 05       MFX Verify: MFX UID 0xFFFF6376 MFX SID 5
< 17:48:09.915   CAN  0x00070300  [7] FF FF 63 76 00 05 7B    MFX Verify: MFX UID 0xFFFF6376 MFX SID 5 ASK-Verhältnis 123
wird z.Zt. mangels mfx-Rückmeldehardware stets positiv beantwortet.

Damit lassen sich jetzt mfx-Decoder über beide Arten von Clients erfolgreich bedienen.

Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#35

Beitrag von Rainer Müller » So 1. Jul 2018, 09:47

Hallo,

noch als Ergänzung zu meinem letzten Beitrag die Liste der offenen Punkte:

mfx-Rückmeldung
Die Adresszuweisung kann man natürlich nur durchführen, wenn die UID bekannt ist, mangels Rückmeldehardware lässt sich das beim basrcpd noch nicht automatisieren. Außerdem ist Decoderauslesen nicht möglich, blindes Schreiben könnte man jedoch implementieren.

Schienensignal
Manchmal noch ungewollte Gruppen von Polaritätswechseln, sollten noch raus.

Adresse gegenüber LocID
Die internen Verwaltungsdaten werden noch SRCP-gemäß über Adressen verwaltet. Damit identische Adressen in unterschiedlichen Protokollen genutzt werden können (z.B MM 5 und mfx 5 gleichzeitig), muß die Verwaltung auf LocID (also im Beispiel 0x0005 und 0x4005) umgestellt werden.

DCC-Programmierung
Wie schon früher festgestellt, bereitet der Programmiergleismodus Probleme, der zwar im Protokoll definiert ist, aber z.B. eine Auswertung zum Ansteuern eines Umschalters noch nie im srcpd realisiert war. Die Paketerzeugung für die Untermodi im basrcpd ist noch nicht von UART auf SPI umgestellt, aber zwischenzeitlich stillgelegt um Hänger bei versehentlichem Ansprechen zu vermeiden.
Die Parameterprüfung könnte auch noch besser sein, so führt z.B. ein BIT auf 7 zu setzen zu einem OK, ebenso das 9te von 8 zu modifizieren!

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!

Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#36

Beitrag von Rainer Müller » Fr 10. Aug 2018, 09:19

Hallo,

es geht langsam weiter, hier erst mal eine Skizze meiner Testkonfiguration:
Bild
Die Zahlen stellen die verwendeten Portnummern dar.


Einer meiner offenen Punkte ist geklärt:
Rainer Müller hat geschrieben:
So 1. Jul 2018, 09:47
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:

Code: Alles auswählen

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

blacklist sun4i_gpadc_iio
blacklist sun4i_gpadc
Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#37

Beitrag von Rainer Müller » Mo 3. Sep 2018, 17:56

Hallo,

das ist jetzt entsprechend angepasst in der neuen Version 1809:
Rainer Müller hat geschrieben:
So 1. Jul 2018, 09:47
Adresse gegenüber LocID
Die internen Verwaltungsdaten werden noch SRCP-gemäß über Adressen verwaltet. Damit identische Adressen in unterschiedlichen Protokollen genutzt werden können (z.B MM 5 und mfx 5 gleichzeitig), muß die Verwaltung auf LocID (also im Beispiel 0x0005 und 0x4005) umgestellt werden.
Das bedeutet, dass nun
- identische Adressen in unterschiedlichen Protokollen genutzt werden können
- die höchste Adresse größer als die Anzahl der möglichen Adressen sein darf.

Was ich in meinem letzten Beitrag noch vergessen habe zu erwähnen:
ich habe auch die Version 1806 in Gerds Lede-Image vom 30 Juni 2018 getestet, und sie funktionierte genau so wie unter Armbian - so wie es sein soll.


Gruß
Rainer


bertr2d2
InterCity (IC)
Beiträge: 981
Registriert: Di 9. Okt 2012, 15:11
Nenngröße: H0
Stromart: digital
Alter: 52

Re: Gleissignalerzeugung mit BananaPi

#38

Beitrag von bertr2d2 » Do 6. Sep 2018, 09:40

Hallo,
Rainer Müller hat geschrieben:
Mo 3. Sep 2018, 17:56
... das ist jetzt entsprechend angepasst in der neuen Version 1809:
neueste Version kann nun auch per Upgrade im OpenWRT/Lede Image geladen werden.

@Rainer,
vielen Dank für die neue Version :-)

Gruß

Gerd
Nicht vergessen: SRSEII nutzt nun Rocail mbus anstatt mgbox !

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#39

Beitrag von Rainer Müller » Mo 10. Sep 2018, 18:41

Hallo Gerd,

besten Dank fürs Übernehmen.
bertr2d2 hat geschrieben:
Do 6. Sep 2018, 09:40
Hallo,
Rainer Müller hat geschrieben:
Mo 3. Sep 2018, 17:56
... das ist jetzt entsprechend angepasst in der neuen Version 1809:
neueste Version kann nun auch per Upgrade im OpenWRT/Lede Image geladen werden.

Gruß

Gerd
Upgrade hat hervorragend geklappt, ich habe jetzt auch basrcpd 1809 auf Lede - und natürlich den Betriebstest mit der Anlage gleich gemacht. Kein Unterschied zwischen den Betriebssystemen feststellbar.

Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#40

Beitrag von Rainer Müller » Mo 21. Jan 2019, 20:10

Hallo Mitleser,

lasst beim Armbian-Update Vorsicht walten. In meiner Testumgebung ging gestern beim Update der Kernel von 4.14.84 auf 4.19.13 und dabei erhielt ich auch einen neuen DeviceTree - mit dem Erfolg, dass kein SPI mehr tut und damit auch kein basrcpd.
In dem DT-Overlay fehlen schon im Installationspaket Dateien für den a20-spi.

Vorübergehende Abhilfe gelang, indem ich aus einer Sicherungskopie den alten DeviceTree wieder nach /boot kopiert und den Link dtb auf das Verzeichnis mit dem alten Inhalt gesetzt habe.

Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#41

Beitrag von Rainer Müller » Mo 25. Feb 2019, 19:19

Hallo,

es gibt mal wieder eine neuen Version 1902 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Verbesserungen sind:
- verbesserte Datenübernahme bei mehreren Clients
- eigene UID in Power-Antworten über CAN-Bus wenn Kommando an alle
- Stopp/Go-Abfrage über CAN-Bus hinzugefügt
- Dummyantwort vom MCS-Gateway auf Stellbefehle damit keine Blockade des MCS-Clients
- Schreiben von mfx-CV über CAN-Bus

Von Armbian-Seite wurde durch ein erneutes Update (jetzt auf Kernel 4.19.20) das berichtete Problem gelöst:
Rainer Müller hat geschrieben:
Mo 21. Jan 2019, 20:10
... ging gestern beim Update der Kernel von 4.14.84 auf 4.19.13 und dabei erhielt ich auch einen neuen DeviceTree - mit dem Erfolg, dass kein SPI mehr tut und damit auch kein basrcpd.
Es gab wohl noch weitere SPI-Anwender die lahmgelegt wurden ...


Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#42

Beitrag von Rainer Müller » Mi 6. Mär 2019, 18:15

Hallo Mitmacher,

nachdem Gerd einen neuem OpenWrt-Kernel zum Testen bereitgestellt hatte, musste ich hier feststellen, dass es damit ein Problem beim srcpd gibt:
Prinzipiell läuft der basrcpd, gibt aber beim Start auffallend viele Meldungen über "Interrupted system call" aus. Bei usleep ist das eher als Schönheitsfehler einzustufen, aber beim MCS-Gateway triffts ein select, und da habe ich wohl die Fehlerbehandlung vermurkst: oft friert der Thread ein.
Dafür gibt auf die Schnelle eine neuen Version 1903 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Verbesserungen sind:
- Korrektur der Fehlerbehandlung im MCS-Gateway
- Erweitern von gleichlautenden Fehlermeldungen (z.B. um Zeilennummern) damit besser unterscheidbar
- Verbesserung bei wiederholter Kurzschlussbehandlung


Gruß
Rainer


bertr2d2
InterCity (IC)
Beiträge: 981
Registriert: Di 9. Okt 2012, 15:11
Nenngröße: H0
Stromart: digital
Alter: 52

Re: Gleissignalerzeugung mit BananaPi

#43

Beitrag von bertr2d2 » Do 7. Mär 2019, 08:53

Hallo Rainer & Andere,
Rainer Müller hat geschrieben:
Mi 6. Mär 2019, 18:15
Dafür gibt auf die Schnelle eine neuen Version 1903 des basrcpd auf meiner Gleissignalerzeugungs-Seite.
ist im neuesten Image eingearbeitet und steht zum Download bereit. Enpacken nicht vergessen ;-)

Gruß

Gerd
Nicht vergessen: SRSEII nutzt nun Rocail mbus anstatt mgbox !

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#44

Beitrag von Rainer Müller » Fr 8. Mär 2019, 21:22

Hallo,
bertr2d2 hat geschrieben:
Do 7. Mär 2019, 08:53
Hallo Rainer & Andere,
Rainer Müller hat geschrieben:
Mi 6. Mär 2019, 18:15
Dafür gibt auf die Schnelle eine neuen Version 1903 des basrcpd auf meiner Gleissignalerzeugungs-Seite.
ist im neuesten Image eingearbeitet und steht zum Download bereit. Enpacken nicht vergessen ;-)

Gruß

Gerd
alles was mir auffiel und mehr ist darin jetzt gelöst:
- MCS startet jetzt immer, auch nach "Interrupted system call"
- mein Netzwerk wird nicht mehr durch den dnsmasq irritiert
- der SPI-Treiber kann jetzt auch 64er-Pakete
- als knaller ein neues Begrüßungslogo :D

Einzige neue Kleinigkeit: die Konfigurationsdatei für den basrcpd heisst jetzt im Image "srcpd.conf-spi0". Sie muss entweder in "srcpd.conf" umbenannt werden oder der basrcpd muss mit der f-Option gestartet werden:
"srcpd -f srcpd.conf-spi0".

Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#45

Beitrag von Rainer Müller » Sa 4. Mai 2019, 14:22

Hallo,

es gibt mal wieder eine neuen Version 1905 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Anlass ist die Korrektur der falschen Fahrtrichtung bei mfx, da im Protokoll SRCP die 1 als vorwärts, in mfx aber die 1 als rückwärts betrachtet wird. Bei diesr Aktion habe ich gleich noch diverse Optimierungen bei der Digitalsignalerzeugung und Verbesserungen bei der Parameterprüfung für SRCP eingeführt.

Beim Testen fiel mir dann noch auf, dass mein Analyseprogramm keine Stellbefehle anzeigen konnte, weder für MM noch für DCC. Eine erweiterte Version ist hier im Unterverzeichnis "diganal" verfügbar.


Gruß
Rainer

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#46

Beitrag von Rainer Müller » So 9. Jun 2019, 09:14

Hallo,

als Vorbereitung für eine größere Bereinigung der Digitalsignalerzeugung (DDL) habe ich am Unterbau gearbeitet, zu finden unter Version 1906 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Änderungen in Version 1906:

- das Stellen der Magnetartikel über das MCS-Gateway ist jetzt eingebaut mit Synchronisation zwischen SRCP- und MCS-Clients, d.h. man sieht z.B. das Umschalten einer Weiche in einem Client, wenn man das im anderen veranlasst. (Allerdings schaltet die Weiche dann im spdrs60 hart ohne die Umlaufanimation).

- die SRCP-Parameterprüfung wurde auf die Möglichkeit von 32 Funktionen erweitert, bisher waren es 29 für NMRA/DCC. Die tatsächliche Behandlung von 32 Funktionen folgt aber erst im Zuge der oben genannten Bereinigung.

- nebenbei habe ich die Anzahl der Warnhinweise von cppcheck bei "angefassten" Modulen reduziert


Gruß
Rainer


bertr2d2
InterCity (IC)
Beiträge: 981
Registriert: Di 9. Okt 2012, 15:11
Nenngröße: H0
Stromart: digital
Alter: 52

Re: Gleissignalerzeugung mit BananaPi

#47

Beitrag von bertr2d2 » So 9. Jun 2019, 15:40

Hallo Rainer,
Rainer Müller hat geschrieben:
So 9. Jun 2019, 09:14
Hallo,

als Vorbereitung für eine größere Bereinigung der Digitalsignalerzeugung (DDL) habe ich am Unterbau gearbeitet, zu finden unter Version 1906 des basrcpd auf meiner Gleissignalerzeugungs-Seite.
vielen Dank für das Update. Ich habe die neueste Version in die OpenWRT/Lede Images integriert. Die Images sind über die etablierten Links abrufbar.

Gruß

Gerd
Nicht vergessen: SRSEII nutzt nun Rocail mbus anstatt mgbox !

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#48

Beitrag von Rainer Müller » So 7. Jul 2019, 16:40

Hallo,

und schon wieder gibt es eine neue Version 1907 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Um mich bei Korrekturen und Änderungen nicht immer wieder im DDL-Dickicht zu verlaufen, habe ich bei den voneinander abhängigen Threads (nur einer kann gleichzeitig auf das SPI) aufgeräumt:
Die bisher verwendeten Threads
- thr_sendrec_DDL (Senden geänderter Werte)
- thr_refresh_cycle (Senden von Wiederholungen)
- thr_delayedGAReset (Abschalten von Magnetartikeln nach Zeit)
- thr_mfxManageThread (periodische MFX-Aktivitäten)
wurden zum neuen Thread "thr_Manage_DDL" zusammengefasst. Dadurch konnte ich auch die Einschaltzeitbegrenzung für die Schaltdecoder auf "nicht ablaufblockierend" umstellen.

Sonstige Änderungen in Version 1907:
- Bei MFX können jetzt 32 Funktionen bedient werden anstatt bisher 16 (von Dani übernommen und angepasst)
(allerdings nur mit Gleissignalanalysator getestet, da ich keine Lok mit mehr als 16 Funktionen habe)

- Bei MM1 wurde die Verwendung des alten Funktionsprotokolls ermöglicht, d.h. bei Einstellung MM1 mit 5 Funktionen werden die zusätzlichen 4 mit doppelter Frequenz (Stichwort "Funktionen mit 40 kHz") gesendet.

- Das durch diverse Änderungen irrtümlich entfallene Abspeichern des Neuanmeldezählers wird wieder durchgeführt.

- Anlass von Warnhinweisen von cppcheck beim Modul srcp-gl.c beseitigt

- Im Headerfile "platform.h" musste ich das Symbol für den Mehrfacheinbindeschutz ändern, weil irgendwo anders das nach Systemupdate plötzlich auch definiert wird. Da kommt man ins Grübeln, wenn eine Headerdatei zwar gelesen wird, aber ihr Inhalt vom Compiler als nichtexistent betrachtet wird.


Gruß
Rainer


Sigg
Beiträge: 9
Registriert: Mi 13. Sep 2017, 21:31
Nenngröße: H0
Stromart: digital
Kontaktdaten:
Schweiz

Re: Gleissignalerzeugung mit BananaPi

#49

Beitrag von Sigg » Mi 7. Aug 2019, 20:48

Hallo
Ich habe mit meiner srcpd MFX Implementierung immer wieder mal folgendes Problem:
Eine MFX Lok nimmt nach Booster Aktivierung keine Kommandos an, reagiert nicht.
Auch das erneute Senden einer Schienenadresse hilft nicht. Nur wenn der Booster (der Strom) ausgeschaltet wird nimmt die Lok dann nach erneutem Einschalten wieder Kommandos an.
Ich habe keine Ahnung an was das liegen kann, was hier falsch läuft. Hat jemand von euch schon solche Erfahrungen gemacht?

Gruss Dani

Benutzeravatar

Threadersteller
Rainer Müller
InterRegio (IR)
Beiträge: 172
Registriert: Do 29. Jun 2006, 10:30
Nenngröße: H0
Wohnort: Korntal
Kontaktdaten:

Re: Gleissignalerzeugung mit BananaPi

#50

Beitrag von Rainer Müller » Fr 9. Aug 2019, 09:50

Hallo Dani,
Sigg hat geschrieben:
Mi 7. Aug 2019, 20:48
...
Auch das erneute Senden einer Schienenadresse hilft nicht. Nur wenn der Booster (der Strom) ausgeschaltet wird nimmt die Lok dann nach erneutem Einschalten wieder Kommandos an.
Ich habe keine Ahnung an was das liegen kann, was hier falsch läuft. Hat jemand von euch schon solche Erfahrungen gemacht?

Gruss Dani
eigentlich sollte ein mfx-Dekoder nach Empfang der Zentralen-UID und Zuweisung einer Schienenadresse aktiv sein. Bei mir hat das bisher immer geklappt, aber meine Stichprobe ist auch überschaubar.

Betrifft das bei dir immer den gleichen Dekoder oder einen Typ oder evtl nur eine Firmwareversion oder kann das reihum bei jedem passieren?

Gruß
Rainer

Antworten

Zurück zu „Software und Hardware“