Gleissignalerzeugung mit BananaPi

[Rainer Müller]

Hallo alle,

um das Thema Preisgünstiger Gleisbox Booster incl. mfx Feedback nicht noch weiter zu entführen, habe ich die BananaPi-Programmierung jetzt abgetrennt:

Hallo Rainer,

Hallo Gerd und weitere Mitleser,

Ich habe mal einen Blick in den Code des modifizierten SRCPD von (Herrn) Sigg geworfen. Aufgrund eines Fehlers des RPi Chips muss da wieder einiges abgefangen werden. Zudem muss man dafür Sorgen, das immer genügend Daten über DMA dem SPI zur Verfügung stehen. Ob das mit dem BPi auch so möglich ist (DMA für SPI), weiß ich momentan nicht.
Gruß

Gerd

in der Zwischenzeit habe ich auch einen BananaPi hier und damit experimentiert.

Cool

Da ich eine Entwicklungsplattform wollte und keine Zielplattform habe ich nicht auf LEDE gesetzt, sondern ein Raspbian (3.4.112) genommen, alternativ waren noch Armbian und Bananian mit ähnlich angestaubten Kernels, ohne CAN, aber mit SPI.

zum Entwickeln ist Raspbian sicherlich die bessere Wahl. Aber ich hätte an Deiner Stelle ein Armbian mit Mainlinie Kernel verwendet. Da hast Du dann einen aktuellen Kernel und CAN mit drin.

Die Anzahl der SPI-Anwender scheint nicht groß zu sein, sonst wäre die Implementierung nicht so trostlos. Ein Versuch ein SPI-Paket zu übertragen, scheiterte immer mit "invalid parameter". Eine Suche im Internet zeigte, dass das normal ist, als Abhilfe wurde "Kernel neu compilieren" genannt. Ganz so aufwendig ists aber nicht, ein Compilieren der spidev-Moduls nach Einkopieren einer korrekten Headerdatei in die KernalHeaders genügte.
Der nächste Stolperstein ist die Einstellung der SPI-Frequenz. Der SOC muss die Eingangsfreuenz (hier 86,4MHz) runterteilen mit guter Auflösung bis zum Teiler 512, danach sehr grob. Bei der mfx-Frequenz von 160kHz ergibt sich ein Teiler von 540, also mehr als 512. Der Treiber (spi-sun7i) errechnet als besten Wert 512, stellt aber 256 ein, was zu 337,5kHz führt - mehr als leicht daneben.
Wenn man dagegen per HW-Zugriff am Treiber vorbei den Eingangstakt auf 24MHz zwingt, kommen die benötigten Takte mit guter Genauigkeit.

Genau das scheint der überarbeitete SPI Treiber in einem halbwegs modernen Kernel IMHO zu machen.

Und wenn man eine Paketlänge von GENAU 64Byte nimmt bei Duplexübertragung, hängt sich die ganze Banane auf!

In der Tat, das ist unschön. Scheint aber auch bekannt zu sein:

Code: Alles auswählen

#define SUN4I_FIFO_DEPTH		64
...
	/*
	 * Fill the TX FIFO
	 * Filling the FIFO fully causes timeout for some reason
	 * at least on spi2 on A10s
	 */
	sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);

Aber insgesamt kann man die SIGG-Software bei genügender Leidensbereitschaft auch auf einen BananaPi portieren.

Ich denke, das ist mit vertretbaren Mitteln machbar. Nur würde ich es etwas anders anpacken. Sigg bläht die Pakete bewusst auf, damit eine Befehlsequnz sicher über die Grenze von 96 Bytes kommt damit die Daten beim RPi per DMA übertragen werden. Das ist anscheinend notwendig, weil der RPi2/3 eine kleine Pause zwischen den SPI Daten einlegt, wenn nicht per DMA übertragen wird.
Hast Du mal nachgeschaut, ob der Banana Pi auch so eine Pause macht ?
Wenn nicht, dann ergibt sich wahrscheinlich die Möglichkeit, einen komplette Sequenz in 64-1 Bytes zu packen. Etwas aufwendiger wären dann nur die Protokolle mit variabler Bit-Länge wie DCC und mfx. Hier muss man die Bytes entsprechend erst zusammen schieben. Aber alles kein Hexenwerk und wird ja bei der Übertragung über RS232 von srcpd auch bereits gemacht.


Gruß

Gerd

Dank an Gerd für seinen Link zum aktuellen Armbian, ich hatte letzen Monat nur das mit Kernel 3.4.113 gefunden. Ich habe zwar noch nicht auf das neue Armbian umgestellt, aber mal auf dem PC reingesehen: CAN ist drin, aber was haben die mit SPI gemacht?

Mein Unverständnis beginnt bei den Bezeichnungen sun4i und sun7i. sun4i sollte für die vierte Plattform und sun7i für die siebte (zu der der A20-SOC des BPi gehört), die von der vierten abstammt, sein. Also wenn möglich sun7i nehmen und nur im Notfall sun4i.

Und jetzt wurde in Armbian das Modul spi-sun7i durch das spi-sun4i ersetzt. Letzteres hat zwar diese Taktumschaltung drin von der ich noch nicht weiss, ob die meine Wünsche erfüllt, denn sie kann nur Richtung schnelleren Takts schalten und nicht zurück. Aber dafür fehlt die komplette DMA-Bedienung des SPI: Pakete mit mehr als der FIFO-Größe 64 werden mit "EMSGSIZE" verworfen.

Zusammenfassend:
-RPi mit spi-bcm2835 schaltet ab 96 Byte auf DMA um, bei kleineren Paketen gibts eine Lücke nach jedem Byte.
-BPi mit spi-sun4i kann nur Pakete bis 63 Byte Länge, da nicht DMA-fähig
-BPi mit spi-sun7i macht ab 65 Byte DMA, bis 63 Byte FIFO (ohne Pausen - nochmal nachgesehen ) und bei 64 Byte gibts einen Hänger.

Wobei der Hänger bei 64 Bytes so schlimm auch nicht ist, sah ich ihn doch nur im Duplexfall und den brauchen wir eigentlich gar nicht; bei Nur-Senden gings auch mit 64 Byte. Aber der Treiber könnte auch ab 64 auf DMA umschalten.

Jetzt noch ein paar Messwerte:

Code: Alles auswählen

BananaPi unter Raspbian Jessie Kernel 3.4.112 mit spi-sun7i und SPI Eingangstakt-
umschaltung auf 24MHz: " *((unsigned long*) (gpio+SPI0_CLK_REG)) = 0x80000000;"  

           76922 Baud               137932 Baud               160000 Baud     
  15:   1660 =>   1756µs (  57‰)   964 =>   1023µs (  61‰)   844 =>    851µs (   8‰)
  30:   3220 =>   3240µs (   6‰)  1836 =>   1825µs (  -5‰)  1596 =>   1600µs (   2‰)
  60:   6340 =>   6367µs (   4‰)  3572 =>   3543µs (  -8‰)  3100 =>   3092µs (  -2‰)
 120:  12580 =>  12648µs (   5‰)  7052 =>   7005µs (  -6‰)  6100 =>   6111µs (   1‰)
 240:  25060 =>  25101µs (   1‰) 14012 =>  13865µs ( -10‰) 12100 =>  12100µs (   0‰)
 480:  50020 =>  50052µs (   0‰) 27932 =>  27639µs ( -10‰) 24100 =>  24118µs (   0‰)
 960:  99940 =>  99968µs (   0‰) 55772 =>  55152µs ( -11‰) 48100 =>  48107µs (   0‰)


BananaPi unter Raspbian Jessie Kernel 3.4.112 mit spi-sun7i und SPI mit 
Original-Eingangstakt 86,4MHz:   

           76922 Baud               137932 Baud               160000 Baud     
  15:   1660 =>    936µs (-436‰)   964 =>    454µs (-529‰)   844 =>    428µs (-492‰)
  30:   3220 =>   1506µs (-532‰)  1836 =>    773µs (-578‰)  1596 =>    773µs (-515‰)
  60:   6340 =>   2950µs (-534‰)  3572 =>   1496µs (-581‰)  3100 =>   1488µs (-520‰)
 120:  12580 =>   5817µs (-537‰)  7052 =>   2948µs (-581‰)  6100 =>   2942µs (-517‰)
 240:  25060 =>  11485µs (-541‰) 14012 =>   5788µs (-586‰) 12100 =>   5785µs (-521‰)
 480:  50020 =>  22866µs (-542‰) 27932 =>  11479µs (-589‰) 24100 =>  11479µs (-523‰)
 960:  99940 =>  45628µs (-543‰) 55772 =>  22854µs (-590‰) 48100 =>  22856µs (-524‰)


RaspberryPi unter Raspbian Jessie mit Kernel 4.1.19+ 
 
           76922 Baud               137932 Baud               160000 Baud     
  15:   1660 =>   1954µs ( 177‰)   964 =>   1100µs ( 141‰)   844 =>    961µs ( 138‰)
  30:   3220 =>   3666µs ( 138‰)  1836 =>   2073µs ( 129‰)  1596 =>   1795µs ( 124‰)
  60:   6340 =>   7130µs ( 124‰)  3572 =>   4031µs ( 128‰)  3100 =>   3480µs ( 122‰)
 120:  12580 =>  13004µs (  33‰)  7052 =>   7170µs (  16‰)  6100 =>   6215µs (  18‰)
 240:  25060 =>  25165µs (   4‰) 14012 =>  14119µs (   7‰) 12100 =>  12194µs (   7‰)
 480:  50020 =>  50155µs (   2‰) 27932 =>  28075µs (   5‰) 24100 =>  24225µs (   5‰)
 960:  99940 => 100152µs (   2‰) 55772 =>  55939µs (   2‰) 48100 =>  48243µs (   2‰)

Die drei Tabellen zeigen die Ergebnisse der SPI-Transferzeitmessungen für die bei Sigg verwendeten Frequenzen (Spalten) und verschiedene Paketlängen (Zeilen). Der Wert vor dem Pfeil ist jeweils der errechnete Sollwert, nach dem Pfeil der gemessene Wert und in Klammern die Abweichung in Promille.
Die oberste Tabelle zeigt die erreichbar guten Werte für den BPi mit Taktumschaltung, die zweite die Werte mit Originaltakt. Die Zeiten liegen dabei um mehr als den Faktor zwei daneben, zwischen den beiden oberen Frequenzen wird nicht unterschieden. Die unterste Tabelle ist vom RPi, da sieht man die dreistelligen Promillezahlen bei den kurzen Paketen, die nicht per DMA übertragen werden und deshalb mit Päuschen versehen sind.


Gruß
Rainer

NB:
Bei Bananian steht jetzt "no longer under active development".

[est2fe]

Hallo Rainer,

Frage:
Hat dein BPi noch eine Schnittstelle für RS232 oder XPresNet oder LocoNet frei?
CAN und ETH hat er ja drauf.
Ich suche immer noch nach einer Möglichkeit, meine IB1 mit Zubehör und die
MoBaSbS an den CS2-CAN zu bekommen ohne über einen PC, welcher 3 Zentrale
bedient, zu gehen.

Gruß

est2fe

[Rainer Müller]

Hallo est2fe,

lange nichts mehr von dir gehört. Deine Frage wäre wohl eher was für Gerd, der hat sogar Leiterplatten dafür gemacht, siehe http://lnxpps.de/bpi/. Unten auf der Seite unter "CON3 GPIOs" sieht man, dass es da noch zwei freie serielle Schnittstellen gibt.

Frage:
Hat dein BPi noch eine Schnittstelle für RS232 oder XPresNet oder LocoNet frei?
CAN und ETH hat er ja drauf.

Ich werde erstmal auf eine Lochrasterplatine setzen, weil sich meine Wünsche noch laufend ändern. So weiss ich noch nicht, ob ich intelligente Booster einplane, bei denen der Mikrokontroller außer Spannung, Strom und Temperatur auch die Erkenntnisse eines RDS- und/oder Railcom-Empfängers über CAN ausgibt, oder dumme Endstufen, wo die Rückmeldesignale dann in den BPi müssen - irgendwann werden die Pins knapp.

Gruß
Rainer

[bertr2d2]

Beitrag gelöscht

[bertr2d2]

Hallo est2fe,

Hallo Rainer,

Frage:
Hat dein BPi noch eine Schnittstelle für RS232 oder XPresNet oder LocoNet frei?
CAN und ETH hat er ja drauf.
Ich suche immer noch nach einer Möglichkeit, meine IB1 mit Zubehör und die
MoBaSbS an den CS2-CAN zu bekommen ohne über einen PC, welcher 3 Zentrale
bedient, zu gehen.

ich antworte mal
Der BPi hat 3 rausgeführte UARTs. Ein UART ist für Console.
Der zweite kann über MAX232 als RS232 incl RTS/CTS Hardware-Handshaking genutzt werden.
Die dritte war bisher als RS485 (z.B. Xpressnet) gedacht - ein MAX485 ist auf dem Board vorgesehen. Aber der Allwinner A20 beherrscht keine 9-Bit Kommunikation. Diese muss über Paritity emuliert werden. Das habe ich aber bisher nicht in Angriff genommen. Ich bin mir auch noch nicht sicher, ob sich das wirklich lohnt, wo eine RS485 Umsetzung relativ einfache Lösung über USB möglich ist. An der Unterstützung in Rocrail wurde bereits diskutiert

Loconet wäre dann das letzte Bussystem (von Selectrix abgesehen) was noch fehlen würde. Hier wäre sicher eine externe MCU die bessere (einzige ?) Wahl. Vielleicht auch auf dem preiswerten STM32 Board das für Xpressnet gedacht ist.

Kurz:
Die BPi-Aufsteckplatine bietet S88, CAN, I2C, RS232, ggf. später RS485 (für z.B. Xpressnet). Loconet wird ggf. mal über zusätzliche MCU angebunden.

Gruß

Gerd

[orgel]

Hallo Gerd,

nur eine kurze Anmerkung zu Xpressnet. Xpressnet so wie es in der Beschreibung von Lenz veröffentlicht wurde ist zu alt. Evtl. wäre es besser auf das neuere BiDiB zu setzen. Dieses wird unter andrem von Wolgang Kufer (OpenDCC) entwickelt. Es werden auch schon von anderen Firmen Decoder / Encoder mit BIDIP angeboten. Außerdem wird es von Rocrail, im gegenteil zu Xpressnet in vollem Umfang unterstützt.

Gruß
Uwe

[bertr2d2]

Hallo Uwe,

Hallo Gerd,

nur eine kurze Anmerkung zu Xpressnet. Xpressnet so wie es in der Beschreibung von Lenz veröffentlicht wurde ist zu alt. Evtl. wäre es besser auf das neuere BiDiB zu setzen. Dieses wird unter andrem von Wolgang Kufer (OpenDCC) entwickelt. Es werden auch schon von anderen Firmen Decoder / Encoder mit BIDIP angeboten. Außerdem wird es von Rocrail, im gegenteil zu Xpressnet in vollem Umfang unterstützt.

vielen Dank für Deine Anmerkung. Ob nun aber der RS485 Anschluss für Xpressnet oder B*D*B genutzt wird ist mir egal
Wolgang Kufers Arbeit ist aber auf jeden Fall wirklich Klasse !

Gruß

Gerd

[est2fe]

Hallo Gerd,

LocoNet braucht man vermutlich nicht nativ, wenn man über RS232 und P50X die logischen Schalt- und Fahr-Befehle auch bekommen kann.
(Meine IB1 hat ja eine eingebaute RS232.)
Mir geht es nur um die Weiternutzung der (in meinem Fall 6 (1 x IB1 und 2 x IBC)) Regler, denn ein Verkauf der alten IB-HW lohnt sich nicht wirklich.

Die 6021 habe ich schon über das Interface an der CS2/3 dran. Das klappt soweit auch recht gut. Die Haptik der 90°-Knebel ist einfach von Kind auf drin (ist sozusagen ein UP mit DMA im ROM).

Gruss

est2fe

[Rainer Müller]

Hallo Gerd,

Hallo Rainer,

ich finde es wirklich spannend, was Du machst. Deine Messwerte sind trotz der SPI Merkwürdigkeiten (sun4i und sun7i) vielversprechend.

die noch neueren Versionen des SPI-Teibers sind jetzt besser geworden, so ist die Größe der SPI-Transfers nun in Kernel 4.11.5 von 64 Bytes auf 16 MBytes gestiegen. Die Takteinstellung bei Zeile 273 wurde gegenüber der alten Version leicht verändert.
Einerseits ist es ja gut, wenn der Treiber immer besser wird, aber andererseits muss man bei jedem Kernelupdate Angst vor anderem SPI-Verhalten haben.

Wieso z.B. alle Treiberversionen (z.B. hier) das Flag "Transmit Pause Enable – stop transmit data when RXFIFO full" setzen und dann nicht richtig behandeln können, so dass sich der Treiber aufhängt?

Konntest Du auch schon konkret Züge oder Zubehör damit steuern ?

Bis jetzt habe ich nur Tastköpfe an den Pins des BPi zum SPI-Test und an der Sigg-SW fehlen auch noch die Anpassungen der HW-Zugriffe auf die Pins. Damit geht noch nicht so viel.

Bei dem RPi hatte ich den Ausgang auch mal mit einem Auswerte-PC verbunden und analysiert:

Code: Alles auswählen

   2430 ms: ??? mit 160 Wechseln !
   2440 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP> <REP> <REP>
   2472 ms: MM2 A= 16, F=0, D= 0, X= 3 F1 aus <REP> <REP> <REP>
   2500 ms: ??? mit 160 Wechseln !
   2508 ms: ??? mit 160 Wechseln !
   2516 ms: ??? mit 160 Wechseln !
   2525 ms: ??? mit 160 Wechseln !
   2533 ms: ??? mit 160 Wechseln !
   2540 ms: MFX A07:0 Bake von Zentrale 0xF9812, Opt 0x0 
   2556 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
   2570 ms: DCC Pr.51, Daten: c0 1e b0 6e(OK)  L 30 FG2A:0
   2584 ms: DCC Pr.51, Daten: c0 1e de 00 00(OK)  L 30 FG3:0
   2597 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
   2604 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
   2618 ms: DCC Pr.51, Daten: c0 1e b0 6e(OK)  L 30 FG2A:0
   2632 ms: DCC Pr.51, Daten: c0 1e de 00 00(OK)  L 30 FG3:0
   2644 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2659 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
   2668 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
   2676 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2690 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
   2712 ms: ??? mit 160 Wechseln !
   2722 ms: ??? mit 160 Wechseln !
   2730 ms: ??? mit 160 Wechseln !
   2738 ms: ??? mit 160 Wechseln !
   2746 ms: ??? mit 160 Wechseln !
   2754 ms: ??? mit 160 Wechseln !
   2762 ms: ??? mit 160 Wechseln !
   2770 ms: ??? mit 160 Wechseln !
   2778 ms: ??? mit 160 Wechseln !
   2786 ms: ??? mit 160 Wechseln !
   2794 ms: ??? mit 160 Wechseln !
   2802 ms: ??? mit 160 Wechseln !
   2811 ms: ??? mit 160 Wechseln !
   2821 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP> <REP> <REP>
   2853 ms: MM2 A= 16, F=0, D= 0, X= 4 F2 aus <REP> <REP> <REP>
   2880 ms: ??? mit 160 Wechseln !

Analyse-Kurzerklärung:
MM2 A= 16, F=0, D= 0, X=13 R      bedeutet: Adresse 16, Fkt. aus, D=Geschwindigkeit=0, X=MM2extra=13=rückwärts 
<REP> <REP> <REP>                 bedeutet: wird drei Mal völlig identisch wiederholt
DCC Pr.15, Daten: c0 1e 40 9e(OK) bedeutet: Präambellänge 15, Daten, (OK)=Checksumme stimmt
L 30 S+D:R 0                      bedeutet: L=lange Adresse, S+D=speed+direction-Paket, rückwärts+Wert 0
L 30 FG3:0                        bedeutet: L=lange Adresse 30, FunctionGroup_3=0
MFX A07:0 Bake von Zentrale 0xF9812, Opt 0x0 bedeutet: MFX mit 7-Bit-Adresse 0, UID der Zentrale, Neuanmeldezähler=0

Zuvor hatte ich den Sigg-Code noch etwas präpariert:
- DCC-Puffer wegen befürchtetem Überlauf von 230 auf 256 Byte erhöht
- bei DCC jeweils eine Eins ans Paketende angehängt weil DMA letztes Bit abgeschnitten hat
- Überstromüberwachung wegen unbeschalteter Porteingänge deaktiviert

Die ersten Seltsamkeiten sieht man in der Analyse sofort:
- nur ein Refresh pro 100ms (stammt vom Original-DDL) - Grund unbekannt
- 160 Wechsel => falsch vom Original-DDL übernommenes Füll-Paket (doppelte Frequenz, SPI-Pausen weil Paket zu kurz)

Falls es wirklich klappen sollte, dann wäre die Anbindung von RDS für mfx und DCC Rückmeldung der nächste logische Schritt. Gerne entwickle ich eine neue Platine, wenn Du möchtest.

Gruß

Gerd

Ja, aber vor einer neuen Platine muss erst mal feststehen, welche Signaale wo reinmüssen. Und da die RDS-Signale wohl über jeden Portpin reingehen können, müssen die dahin wo nichts wichtigeres drankommt - also müssen erstmal alle Schnittstellen klar sein.

Gruß
Rainer

[bertr2d2]

Hallo Rainer,

Hallo Gerd,

Hallo Rainer,

ich finde es wirklich spannend, was Du machst. Deine Messwerte sind trotz der SPI Merkwürdigkeiten (sun4i und sun7i) vielversprechend.

die noch neueren Versionen des SPI-Teibers sind jetzt besser geworden, so ist die Größe der SPI-Transfers nun in Kernel 4.11.5 von 64 Bytes auf 16 MBytes gestiegen. Die Takteinstellung bei Zeile 273 wurde gegenüber der alten Version leicht verändert.
Einerseits ist es ja gut, wenn der Treiber immer besser wird, aber andererseits muss man bei jedem Kernelupdate Angst vor anderem SPI-Verhalten haben.

Ich glaube, jetzt scheint aber etwas Ruhe in der Entwicklung des SPI-Treibers eingekehrt zu sein

Bei dem RPi hatte ich den Ausgang auch mal mit einem Auswerte-PC verbunden und analysiert:

Code: Alles auswählen

   2430 ms: ??? mit 160 Wechseln !
   2440 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP> <REP> <REP>
   2472 ms: MM2 A= 16, F=0, D= 0, X= 3 F1 aus <REP> <REP> <REP>
   2500 ms: ??? mit 160 Wechseln !
   2508 ms: ??? mit 160 Wechseln !
   2516 ms: ??? mit 160 Wechseln !
   2525 ms: ??? mit 160 Wechseln !
   2533 ms: ??? mit 160 Wechseln !
   2540 ms: MFX A07:0 Bake von Zentrale 0xF9812, Opt 0x0 
   2556 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
   2570 ms: DCC Pr.51, Daten: c0 1e b0 6e(OK)  L 30 FG2A:0
   2584 ms: DCC Pr.51, Daten: c0 1e de 00 00(OK)  L 30 FG3:0
   2597 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
   2604 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
   2618 ms: DCC Pr.51, Daten: c0 1e b0 6e(OK)  L 30 FG2A:0
   2632 ms: DCC Pr.51, Daten: c0 1e de 00 00(OK)  L 30 FG3:0
   2644 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2659 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
   2668 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
   2676 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2690 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
   2712 ms: ??? mit 160 Wechseln !
   2722 ms: ??? mit 160 Wechseln !
   2730 ms: ??? mit 160 Wechseln !
   2738 ms: ??? mit 160 Wechseln !
   2746 ms: ??? mit 160 Wechseln !
   2754 ms: ??? mit 160 Wechseln !
   2762 ms: ??? mit 160 Wechseln !
   2770 ms: ??? mit 160 Wechseln !
   2778 ms: ??? mit 160 Wechseln !
   2786 ms: ??? mit 160 Wechseln !
   2794 ms: ??? mit 160 Wechseln !
   2802 ms: ??? mit 160 Wechseln !
   2811 ms: ??? mit 160 Wechseln !
   2821 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP> <REP> <REP>
   2853 ms: MM2 A= 16, F=0, D= 0, X= 4 F2 aus <REP> <REP> <REP>
   2880 ms: ??? mit 160 Wechseln !

Analyse-Kurzerklärung:
MM2 A= 16, F=0, D= 0, X=13 R      bedeutet: Adresse 16, Fkt. aus, D=Geschwindigkeit=0, X=MM2extra=13=rückwärts 
<REP> <REP> <REP>                 bedeutet: wird drei Mal völlig identisch wiederholt
DCC Pr.15, Daten: c0 1e 40 9e(OK) bedeutet: Präambellänge 15, Daten, (OK)=Checksumme stimmt
L 30 S+D:R 0                      bedeutet: L=lange Adresse, S+D=speed+direction-Paket, rückwärts+Wert 0
L 30 FG3:0                        bedeutet: L=lange Adresse 30, FunctionGroup_3=0
MFX A07:0 Bake von Zentrale 0xF9812, Opt 0x0 bedeutet: MFX mit 7-Bit-Adresse 0, UID der Zentrale, Neuanmeldezähler=0

das Tool ist sehr interessant; gibt es den Quellcode irgendwo ?

Falls es wirklich klappen sollte, dann wäre die Anbindung von RDS für mfx und DCC Rückmeldung der nächste logische Schritt. Gerne entwickle ich eine neue Platine, wenn Du möchtest.

Ja, aber vor einer neuen Platine muss erst mal feststehen, welche Signale wo reinmüssen. Und da die RDS-Signale wohl über jeden Portpin reingehen können, müssen die dahin wo nichts wichtigeres drankommt - also müssen erstmal alle Schnittstellen klar sein.

ich denke, das vieles schon vorgegeben ist: CAN, RS232, SPI und I2C (u.a. für RDS Chip) wie es bereits jetzt genutzt wird. Du hast aber sicherlich recht - es schadet nicht noch etwas zu warten und zu sehen, was möglich ist und dann die genaue Portbelegung planen, sofern Interesse besteht.

Gruß

Gerd

[Rainer Müller]

Hallo Gerd,

Hallo Rainer,

Hallo Gerd,

Hallo Rainer,

ich finde es wirklich spannend, was Du machst. Deine Messwerte sind trotz der SPI Merkwürdigkeiten (sun4i und sun7i) vielversprechend.

die noch neueren Versionen des SPI-Teibers sind jetzt besser geworden, so ist die Größe der SPI-Transfers nun in Kernel 4.11.5 von 64 Bytes auf 16 MBytes gestiegen. Die Takteinstellung bei Zeile 273 wurde gegenüber der alten Version leicht verändert.
Einerseits ist es ja gut, wenn der Treiber immer besser wird, aber andererseits muss man bei jedem Kernelupdate Angst vor anderem SPI-Verhalten haben.

Ich glaube, jetzt scheint aber etwas Ruhe in der Entwicklung des SPI-Treibers eingekehrt zu sein

Das ist ja wenigstens beruhigend.

Bei dem RPi hatte ich den Ausgang auch mal mit einem Auswerte-PC verbunden und analysiert:

das Tool ist sehr interessant; gibt es den Quellcode irgendwo ?

Das Tool ist Teil einer etwa 20 Jahre alten Sammlung, die ich damals noch als 16Bit-SW und teilweise mit TurboPascal programmiert und immer wieder nachgezogen habe. Die Sourcen habe ich jetzt mal hier bereitgestellt.
Die Abtastung erfolgt mit 88200Hz / 11,3µs, weil mir das für die Frequenzen im Schienensignal schnell genug erschien, ca. 5s Aufzeichnung in 64kByte (wegen der 16 Bit!) passen und ein Soundeditor wie Audacity das oszillografisch darstellen kann.

Code: Alles auswählen

Das Archiv umfasst die Quellcodes folgender Teile:

- fang    => Auffangen eines Datenstroms mittels UART an einem Standard-PC unter Linux
		Schienensignal an RI der ersten seriellen Schnittstelle
- pifang  => Auffangen eines Datenstroms mit einem Raspberry Pi
		Schienensignal an MISO, in cmdline.txt "spidev.bufsiz=65536" einfügen
- dat2wav => Umwandeln des aufgefangenen Datenstroms in eine wav-Datei (Betrachten z.B. mit Audacity)
- diganal => Interpretieren des Datenstroms bzw. der wav-Datei

dat2wav und diganal sind geeignet für Windows- (Visual Studio) und Linux- (gcc) PCs und für Pi.

Aufrufbeispiele:
 dat2wav bpisigg1.dat bpisigg1.wav
 diganal bpisigg1.dat > bpisigg1.txt

In der Zwischenzeit habe ich auch das Signal aus dem BananaPi mit Kernel 3.4.112 / spi-sun7i mit 24MHz Takt analysiert. Das Ergebnis war ähnlich dem des RPi, nur dass wohl der RDS-Trägererkennungspin beim BPi nach oben und beim RPi nach unten gezogen wurde. Deshalb meinte die SW, eine mfx-Erkennung durchführen zu müssen:

Code: Alles auswählen

. . .
2753 ms: MFX A07:0 Such mit 1 Bits von Id-Maske 0x0   +0011+p
2775 ms: MFX  CRC-Fehler 
2781 ms: MFX A07:0 Such mit 2 Bits von Id-Maske 0x0   +0011+p
2803 ms: MFX  CRC-Fehler 
2809 ms: MFX A07:0 Such mit 3 Bits von Id-Maske 0x0   +0011+p
2831 ms: MFX  CRC-Fehler 
2837 ms: MFX A07:0 Such mit 4 Bits von Id-Maske 0x0   +0011+pp
2860 ms: MFX  CRC-Fehler 
2865 ms: MFX A07:0 Such mit 4 Bits von Id-Maske 0x10000000   +0011+pp
2888 ms: MFX  CRC-Fehler 
2894 ms: MFX A07:0 Such mit 5 Bits von Id-Maske 0x10000000   +0011+p
2916 ms: MFX  CRC-Fehler 
2922 ms: MFX A07:0 Such mit 5 Bits von Id-Maske 0x18000000   +0011+
2946 ms: MFX A07:0 Such mit 3 Bits von Id-Maske 0x38000000   +0011+
2972 ms: MFX A07:0 Such mit 2 Bits von Id-Maske 0x78000000   +0011+
2999 ms: MFX A07:0 Such mit 1 Bits von Id-Maske 0xF8000000   +0011+pp  +11111111111111111111k01111111111111111111111111111111111111k+
3029 ms: MM1 A= 60, F=0, D= 0  <REP> <REP> <REP> <REP> <REP> <REP> <REP>
. . .

Auffällig ist, dass die Abfragepakete viel zu dicht nacheinander kommen, das kann die Rückmeldestufe auf dem Decoder final überlasten. Als CRC-Fehler (und andere seltsame Anzeigen wie die vielen Einsen) werden hier die 160-Wechsel-Pakete interpretiert, die sich ohne Schutzzeit zwischen die mfx-Rahmen pressen. Die "+0011+" sind dagegen OK, das ist die Bitfolge, die eine Rückmeldung freigibt.
Aber die Reihenfolge 1 2 3 4 4 5 5 3 2 1 0 ?!

Na ja, in die Logdatei wird mitprotokolliert, kann hoffentlich bei der Problemanalyse helfen:

Code: Alles auswählen

. . .
rai-bpi srcpd[978]: [bus 1] New SID=1 für UID=3772834019                                                 
rai-bpi srcpd[978]: [bus 1] Neue MFX Lok gefunden. UID=3772834019, zugewiesene Adresse=1                 
rai-bpi srcpd[978]: [bus 1] Neuanmeldezähler konnte nicht gespeichert werden                             
rai-bpi srcpd[978]: [bus 1] findBlock Abbruch. readCV fail. SID=1                                        
rai-bpi srcpd[978]: [bus 1] findCA findBlock fail. SID=1, Block=1                                        
rai-bpi srcpd[978]: [bus 1] SID=1, CA=0x1018 in Block 1 nicht gefunden                                   
rai-bpi srcpd[978]: [bus 1] readLokNameFx Abbruch. readCA fail. SID=1                                    
rai-bpi srcpd[978]: [bus 1] MFX Lokname und Funktionen konnten nicht gelesen werden. SID=1 Neuanmeldung  
. . .

Jetzt werde ich dann auf ein Image mit neuem Kernel (4.11.5) umsteigen, sonst muss ich zu viel doppelt machen. Also zukünftige Erkenntnisse nur noch für neues Armbian.

ich denke, das vieles schon vorgegeben ist: CAN, RS232, SPI und I2C (u.a. für RDS Chip) wie es bereits jetzt genutzt wird. Du hast aber sicherlich recht - es schadet nicht noch etwas zu warten und zu sehen, was möglich ist und dann die genaue Portbelegung planen, sofern Interesse besteht.

Gruß

Gerd

OK.

Gruß
Rainer

[Sigg]

Ein paar Erklärungen vom ursprünglichen MFX srcpd Entwickler:

• Ich verwende srcpd mit meinen MFX Erweiterungen auf einer Anlage mit ca. 80 vorhandenen Loks. Es werden alle Formate MM, DCC und MFX verwendet.

• Ich kann keine negativen Folgen der festegestellen Auffälligkeiten beobachten, wenn mir aber jemand sagt, wie die korrekte Abfolge z.B. der 160 Wechsel sein muss, dann kann das natürlich geändert werden.

• Das Einlesen "RDS Rückmeldung vorhanden" für die Ermittlung der MFX UID's erfolgt über SPI MISO. Dies hat den Vorteil, dass keine Timing Anforderungen in der Software berücksichtigt werden müssen, aus dem SPI Buffer können einfach die Bits gelesen werden, die während der Rückmeldepause eingelesen wurden.

• Wenn die "RDS vorhanden" Rückmeldung konstant ansteht hat dies den Effekt, dass eine Lok mit UID=0 erkannt wird.

• Die UID Suche erfolgt rekursiv in der Funktion "sendSearchNewDecoder". Bei jedem Durchgang mit einem Bit mehr. Von da her ist ein Verhalten wie " Reihenfolge 1 2 3 4 4 5 5 3 2 1 0" für mich nicht erklärbar.

• Im Code hat es div. kommentierte "printf". Wenn diese wieder aktiviert werdet, habt ihr mehr Informatinen, was passiert.

Gruss
Dani

[bertr2d2]

Hallo Dani,

erstmal vielen Dank für Deine Arbeit. Du hast durch Deine Arbeit eine OpenSource Zentrale mit mfx Unterstüzung geschaffen !

Ein paar Erklärungen vom ursprünglichen MFX srcpd Entwickler:

• Ich verwende srcpd mit meinen MFX Erweiterungen auf einer Anlage mit ca. 80 vorhandenen Loks. Es werden alle Formate MM, DCC und MFX verwendet.

Cool

• Ich kann keine negativen Folgen der festegestellen Auffälligkeiten beobachten, wenn mir aber jemand sagt, wie die korrekte Abfolge z.B. der 160 Wechsel sein muss, dann kann das natürlich geändert werden.

• Das Einlesen "RDS Rückmeldung vorhanden" für die Ermittlung der MFX UID's erfolgt über SPI MISO. Dies hat den Vorteil, dass keine Timing Anforderungen in der Software berücksichtigt werden müssen, aus dem SPI Buffer können einfach die Bits gelesen werden, die während der Rückmeldepause eingelesen wurden.

das verstehe ich nicht: Werden die Daten denn nicht vom RDS-Chip "dekodiert" und können über I2C abgefragt werden ?

Du hast auf der Eingangsseite des 1:100 Trafos noch Dioden eingebaut. Wozu dienen diese ?

Gruß

Gerd

[Rainer Müller]

Hallo Dani,

schön dass du auch hier bist, dann haben wir den richtigen Diskussionspartner.

Ein paar Erklärungen vom ursprünglichen MFX srcpd Entwickler:

• Ich verwende srcpd mit meinen MFX Erweiterungen auf einer Anlage mit ca. 80 vorhandenen Loks. Es werden alle Formate MM, DCC und MFX verwendet.

• Ich kann keine negativen Folgen der festegestellen Auffälligkeiten beobachten, wenn mir aber jemand sagt, wie die korrekte Abfolge z.B. der 160 Wechsel sein muss, dann kann das natürlich geändert werden.

Vorrangig betrachte ich die Portierung auf den BananaPi, alles was ich da an "Beifang" finde, wird erstmal als Auffälligkeit notiert. Dass deine SW läuft bin ich auch überzeugt, sonst würde ich das Thema Portierung nicht weiter verfolgen.

Die 160 Wechsel sind 20 Bytes 0x55 (an DCC-Einsen erinnernd), die mit Märklintakt gesendet werden, und nach jeweils 8 Bit (nur beim Raspberry Pi wegen nicht-DMA) eine zusätzliche Pause aufweisen. Das Paket entspricht keinem bekannten Protokoll und wird vermutlich von jedem Decoder verworfen. Mein Vorschlag wäre, das Paket ganz wegzulassen und die gewonnene Busbandbreite für schnellere Wiederholung des zyklischen Puffers zu nutzen.

• Das Einlesen "RDS Rückmeldung vorhanden" für die Ermittlung der MFX UID's erfolgt über SPI MISO. Dies hat den Vorteil, dass keine Timing Anforderungen in der Software berücksichtigt werden müssen, aus dem SPI Buffer können einfach die Bits gelesen werden, die während der Rückmeldepause eingelesen wurden.

Der "andere Zustand des offenen Eingangs" soll mir (bzw. einem Portierer zum BPi) als Erinnerung dienen, die Pinkonfigurationen auch zu betrachten. Da kommt jetzt auch das Thema "Device Tree" verstärkt zum Zuge.

• Wenn die "RDS vorhanden" Rückmeldung konstant ansteht hat dies den Effekt, dass eine Lok mit UID=0 erkannt wird.

• Die UID Suche erfolgt rekursiv in der Funktion "sendSearchNewDecoder". Bei jedem Durchgang mit einem Bit mehr. Von da her ist ein Verhalten wie " Reihenfolge 1 2 3 4 4 5 5 3 2 1 0" für mich nicht erklärbar.

• Im Code hat es div. kommentierte "printf". Wenn diese wieder aktiviert werdet, habt ihr mehr Informatinen, was passiert.

Gruss
Dani

Was ich noch in meinem letzten Beitrag anmerkte, war die Anfragehäufigkeit. Es gab schon häufig Anwender, die von Decodern berichteten, bei denen alles ging außer der mfx-Erkennung. Bei diesen Decodern war meistens dir Rückmeldestufe defekt, da diese während der mfx-Rückmeldung ca. 1,5W verheizen muss. Zur Schonung des Decoders sollte eine mfx-Rückmeldung deshalb nicht öfter als etwa alle 100ms angefordert werden.
Das mit der Reihenfolge kann natürlich auch an meiner Testkonfiguration liegen, steht erstmal als Merker. Muss man nochmal genauer ansehen.

Aber ich hab noch was:
Bei DCC-Paketen wird das Paketendebit um eine Flanke zu kurz, da erst die High-Phase und dann die Low-Phase kommt, so dass zwischen der Low-Phase und dem Ruhezustand keine Flanke nach außen geht. Ich habe da mal an jede Paketgruppe eine DCC-Eins angehängt.
Und im ddl_nmra.c habe ich BUFFERSIZE auf 256 erhöht, weil die 230 für meinen fiktiven Testdecoder (lange Adresse, 16 Funktionen) zu kurz war.


Gruß
Rainer

[Sigg]

Hallo zusammen
Zu den Anmerkungen und Fragen:

• Die Füllpakete mit 0x55 könnten tatsächlich weg, wie Rainer geschrieben hat. Sie kommen vom orginal srcpd und haben mich eben noch nicht genug gestört um es zu ändern. Ob sie genau richtig gesendet werden spielt für mich keine Rolle, sie werden ja sowieso von keinem Dekoder ausgewertet.

• Erhöhung ddl_nmra.c BUFFERSIZE -> OK, habe ich übernommen (neues Paket kommt auf meine Webseite)

• Delay für MFX RDS Abfragen: ich hatte noch keine Probleme mit dadurch defekten Dekodern . Wenn das tatsächlich zu einem Problem wird, dann kann eine Verögerung in "sendSearchNewDecoder" für die Neuanmeldung sowie in "readCV" für das Auslesen der Dekoderkonfiguration helfen.

• Brückengleichrichter vor Trafo: Trafo liegt bei mir im Strompfad zum Gleis. JEDER Wechsel der Gleisspannung +/-20V ist für den Trafo OHNE Dioden eine verdammt grosse Stromänderung (je nach Last und Leistungsfähigkeit des Boosters von z.B. +5A auf -5A). Daraus resultiert Sekundär eine Spannung, die sehr viel grösser als das RDS Signal ist und dieses verdeckt. In der Märklin Mobile-Station ist als Endstufe eine Vollbrücke vorhanden, der Trafo befindet sich da VOR dieser Brücke, also im reinen DC Pfad. Da ich Booster mit einer Halbbrücke (+ und - Versorgungsspannung) verwende, funktioniert dies bei mir nicht. Mit den Dioden ist der Gleisstrom fast ein reiner DC, also nach dem Trafo nicht mehr zu sehen. Es sind absichtlich Shottky Dioden um den Spannungsabfall gering zu halten (und man kann ja den Booster etwas "rauf" drehen).

• RDS vorhanden Erkennung, MFX 1 Bit Rückmeldung zur UID Suche: Das ist KEINE für den RDS Chip auswertebare RDS Übetragung. Für eine solche benötigt er zuerst mal eine längere Zeit ein RDS Signal um sich zu synchronisieren. In meiner Schaltung ist deshalb ein extra Komperator vorhanden der das RDS Signal nach Filterung auswertet. Die tatsächliche RDS Übertragung kommt erst dann, wenn Daten Byteweise vom Dekoder zurückgelesen werden.

• RDS Daten: vom RDS Chip, den ich verwendet habe (aus Mobile Station) kommt da leider kein I2C sondern einfach OK, Takt und Daten. Das lese ich dann über "normale" GPIO mit Polling ein...

PS: Warum die Arbeit mit Portierung auf BananaPI? Nehmt doch einfach einen Raspberry...

Gruss
Dani

[Rainer Müller]

Hallo Dani,

Hallo zusammen
...
PS: Warum die Arbeit mit Portierung auf BananaPI? Nehmt doch einfach einen Raspberry...

Gruss
Dani

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

Gruß
Rainer

[Rainer Müller]

Hallo alle,

ich habe mir ein Armbian Debian Jessie mit Kernel 4.11.5 auf meinen BPi gespielt, das beim ersten Update gleich auf 4.11.6 gebracht wurde.
Da ist sowohl ein CAN-Treiber als auch ein SPI-Treiber (spi-sun4i) mit drin. Wieso das SPI "spidev32766.0" heissen muss? "spidev0.0" wäre mir besser über die Finger gegangen, aber es funktioniert und mit seinem Standardtakt von 24MHz passt es für die Aufgabe.

...
Ich denke, das ist mit vertretbaren Mitteln machbar. Nur würde ich es etwas anders anpacken. Sigg bläht die Pakete bewusst auf, damit eine Befehlsequnz sicher über die Grenze von 96 Bytes kommt damit die Daten beim RPi per DMA übertragen werden. Das ist anscheinend notwendig, weil der RPi2/3 eine kleine Pause zwischen den SPI Daten einlegt, wenn nicht per DMA übertragen wird.
Hast Du mal nachgeschaut, ob der Banana Pi auch so eine Pause macht ?
Wenn nicht, dann ergibt sich wahrscheinlich die Möglichkeit, einen komplette Sequenz in 64-1 Bytes zu packen. Etwas aufwendiger wären dann nur die Protokolle mit variabler Bit-Länge wie DCC und mfx. Hier muss man die Bytes entsprechend erst zusammen schieben. Aber alles kein Hexenwerk und wird ja bei der Übertragung über RS232 von srcpd auch bereits gemacht.


Gruß

Gerd

Wenn man die Verdoppelung der Paketlänge rausnimmt, sinkt damit verbunden auch die Schiebefrequenz auf die Hälfte. Bei DCC und mfx würde der Teiler das schaffen, bei MM wird die Grenze für die feine Stufung überschritten:

Code: Alles auswählen

BananaPi unter Armbian Debian Jessie Kernel 4.11.6 mit spi-sun4i:
           38461 Baud                68966 Baud                80000 Baud     
  15:   3220 =>   2835µs (-119‰)  1836 =>   1880µs (  23‰)  1596 =>   1641µs (  28‰)
  30:   6340 =>   5302µs (-163‰)  3572 =>   3629µs (  15‰)  3100 =>   3157µs (  18‰)
  60:  12580 =>  10415µs (-172‰)  7052 =>   7074µs (   3‰)  6100 =>   6174µs (  12‰)
 120:  25060 =>  20664µs (-175‰) 14012 =>  13987µs (  -1‰) 12100 =>  12139µs (   3‰)
 240:  50020 =>  41136µs (-177‰) 27932 =>  27831µs (  -3‰) 24100 =>  24137µs (   1‰)
 480:  99940 =>  82117µs (-178‰) 55772 =>  55554µs (  -3‰) 48100 =>  48178µs (   1‰)
 960: 199780 => 164046µs (-178‰)111452 => 110921µs (  -4‰) 96100 =>  96151µs (   0‰)

SPI_CCTL (Teiler): 
             0x00000900 (512)          0x000010AC (346)          0x00001095 (300)

Aber bei Grobbetrieb ist wenigstens der zusätzliche Faktor-2-Einstellungsfehler im Treiber jetzt weg.
Der Trick direkt am Takt rumzuändern tut nicht mehr so wie beim alten Treiber -> weitere Tests deshalb mit der bekannten Verdoppelung.

Der Programmierer hat den SPI-Treiber spi-sun4i aber wieder nicht richtig getestet. Der 64-Byte-Fehler ist immer noch drin, wie ein Pakettransfer mit 15 bis 1023 Byte Länge zeigt, aber er erzeugt jetzt einen definierten Fehler und führt nicht mehr zum Aufhängen:

Code: Alles auswählen

           76922 Baud               137932 Baud               160000 Baud     
...   
  62:   6548 =>   6591µs (   6‰)  3692 =>   3658µs (  -9‰)  3196 =>   3254µs (  18‰)
  63:   6652 =>   6699µs (   7‰)  3748 =>   3721µs (  -7‰)  3244 =>   3296µs (  16‰)
  64: Error SPI Transfer ioctl: Connection timed out (errno = 110).
Error SPI Transfer ioctl: Connection timed out (errno = 110).
Error SPI Transfer ioctl: Connection timed out (errno = 110).
  65:   6860 =>   6958µs (  14‰)  3868 =>   4017µs (  38‰)  3348 =>   3441µs (  27‰)
  66:   6964 =>   7026µs (   8‰)  3924 =>   3943µs (   4‰)  3396 =>   3404µs (   2‰)
...
localhost kernel: [  911.761703] spi_master spi32766: spi32766.0: timeout transferring 64 bytes@76922Hz for 110(100)ms

Nach einem Blick in den Quelltext wird dann klar, dass maximal 63 Byte sofort ins FIFO kommen (Zeile 319), aber erst bei MEHR als 64 Byte Länge (325) nachgefüttert wird:

Code: Alles auswählen

319	sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
320
321	/* Enable the interrupts */
322	sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TC |
323					 SUN4I_INT_CTL_RF_F34);
324	/* Only enable Tx FIFO interrupt if we really need it */
325	if (tx_len > SUN4I_FIFO_DEPTH)
326		sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TF_E34);

Da wir durch die Verdoppelung ja bei mindestens 96 Bytes sind, stellt dieser Fehler aber kein ernsthaftes Problem dar.

Beim Oszillografieren fiel mir auf, dass am Paketende das letzte Bit etwas (~1,5) länger ausgegeben wird, der MOSI dann auf 0 geht und nach etwa 60µs hochohmig wird. Erst ca 30µs vor dem nächsten Paket wird er wieder stabil 0. Da schaltet der Treiber vermutlich den SPI-Controller aus und ein. Folgerungen sind:
- Um einen ungewollten Wechsel beim Hochohmigwerden zu verhindern, darf man keine Logik an den MOSI schalten, die hochohmig als 1 betrachtet, genau so wenig einen Pullup. Ein "Runterzieher" wäre hier angebracht.
- das verlängerte Schlussbit stört nicht, wenn es eine 0 ist.

Schließlich hängte sich der BPi mehrmals während der ersten SPI-Tests sporadisch auf. Als ich das untersuchen wollte, trat der Effekt dann nicht mehr auf. Hoffentlich steckt da nicht noch was Böses drin.

Äh - der Test mit DDL steht noch aus.

Gruß
Rainer

[Rainer Müller]

Hallo alle,

Äh - der Test mit DDL steht noch aus.

jetzt habe ich ihn durchgeführt: sieht aus wie beim RaspberryPi, die vermeintliche Erkennung von mfx-Paketen ist wieder weg. Die verschiedenen Betriebssystemvarianten schalten wohl die Pullups unterschiedlich.

Hallo zusammen
Zu den Anmerkungen und Fragen:

• Die Füllpakete mit 0x55 könnten tatsächlich weg, wie Rainer geschrieben hat. Sie kommen vom orginal srcpd und haben mich eben noch nicht genug gestört um es zu ändern. Ob sie genau richtig gesendet werden spielt für mich keine Rolle, sie werden ja sowieso von keinem Dekoder ausgewertet.

Wenn ich die Füllpakete probeweise mal von 0x55 auf 0x00 setzte, sieht das schon richtig gut aus:

Code: Alles auswählen

   1178 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
   1212 ms: MFX A07:0 Bake von Zentrale 0xF9812, Opt 0x0 
   1294 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP> <REP> <REP>
   1322 ms: MM2 A= 16, F=0, D= 0, X= 6 F3 aus <REP> <REP> <REP>
   1391 ms: DCC Pr.14, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
   1403 ms: DCC Pr.51, Daten: c0 1e b0 6e(OK)  L 30 FG2A:0
   1416 ms: DCC Pr.51, Daten: c0 1e de 00 00(OK)  L 30 FG3:0
   1426 ms: DCC Pr.14, Daten: ff 00 ff(OK) *IDLE*
   1433 ms: DCC Pr.14, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
   1445 ms: DCC Pr.51, Daten: c0 1e b0 6e(OK)  L 30 FG2A:0
   1457 ms: DCC Pr.51, Daten: c0 1e de 00 00(OK)  L 30 FG3:0
   1468 ms: DCC Pr.14, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   1480 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
   1489 ms: DCC Pr.14, Daten: ff 00 ff(OK) *IDLE*
   1495 ms: DCC Pr.14, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   1508 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
   1620 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP> <REP> <REP>
   1648 ms: MM2 A= 16, F=0, D= 0, X= 7 F4 aus <REP> <REP> <REP>
   1695 ms: MFX A07:0 Such mit 0 Bits von Id-Maske 0x0   +0011+
   1724 ms: DCC Pr.14, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0

• Erhöhung ddl_nmra.c BUFFERSIZE -> OK, habe ich übernommen (neues Paket kommt auf meine Webseite)

Das habe ich mir mal geholt, da hats auch noch ein paar andere Änderungen drin. Noch nicht komplett bei mir reingenommen, da ich ja schon Änderungen für den BananaPi drin hab und die nachziehen muss.

Nun fehlt nur noch die Hardware zum Testen:

Falls es wirklich klappen sollte, dann wäre die Anbindung von RDS für mfx und DCC Rückmeldung der nächste logische Schritt. Gerne entwickle ich eine neue Platine, wenn Du möchtest.

Gruß

Gerd

Ja, aber vor einer neuen Platine muss erst mal feststehen, welche Signaale wo reinmüssen. Und da die RDS-Signale wohl über jeden Portpin reingehen können, müssen die dahin wo nichts wichtigeres drankommt - also müssen erstmal alle Schnittstellen klar sein.

Mit den RDS-Decoderchips siehts nicht mehr gut aus, sie sind bei keiner "Bastlerquelle" mehr gelistet. Vor etwa zehn Jahren wurden sie mit in Komplettradio-Chips integriert, womit sie für unseren Zweck unbrauchbar wurden. Und im Zeitalter von DAB braucht man auch keine RDS-Chips mehr.

PT2579, SAA/SC6579 (Märklin, Dani), TDA7330 (ich), und TDA7479 sind alle ausgelistet (Lieferstatus ROT), TDA7478 als "nicht für Neuentwicklungen" GELB markiert, nur LC72725KV von onsemi steht noch auf GRÜN. Hoffentlich gibts auch eine Bezugsquelle dafür. Immerhin ist der LC72725KV der einzige von mir gefundene RDS-Chip, der laut Datenblatt auch mit 3,3V arbeitet und damit direkt an den BPi angeklemmt werden kann.


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

Habe ich was vergessen?


Gruß
Rainer

[bertr2d2]

Beitrag gelöscht

[Rainer Müller]

Hallo Gerd,

Hallo Rainer,

es freut mich, das Du an dem Thema dran bleibst.

naja, ab und zu werde ich auch bei der Brio-Holzeisenbahn benötigt.

Aber ich frage mich, ob man dem RDS Chip nicht auch gleich eine kleine MCU zur Dekodierung bei Seite stellt.
Ich hatte bisher immer den SAA6588 (I2C Interface) im Kopf. Aber das scheint ein Exot zu sein. Die MCU könnte dann noch ein paar andere Funktionen mit übernehmen (S88, Xpressnet etc pp.) ...

Gruß

Gerd

Für den mfx-Empfänger gibts verschiedene Möglichkeiten falls man mehrere Booster verwenden will:
- einen Empfänger an einem Booster (in diesem Booster oder in der Zentrale); die anderen Booster speisen in den ersten über eine mfx-Brücke
- einen Empfänger in der Zentrale; die an jedem Booster ausgekoppelten Signale werden vor dem Empfänger zusammengeführt.
- einen Empfänger (mit MCU) pro Booster; die Signale werden z.B. über den CAN-Bus zusammengeführt zur Zentrale gesendet.

Eine ähnliche Problematik ergibt sich für die Railcom-Unterstützung:
- traditionelle Erzeugung der Austastlücke im Booster mit MCU durch Auswertung des Schienensignals
- oder Verteilung des in der Zentrale erzeugten Austastlücken-Signals an alle Booster
- wie erfolgt die Zusammenführung der Railcom-Datensignale bei mehreren Boostern?

Bin ich froh, dass mir bisher eine Endstufe genügt.


Gruß
Rainer

[Sigg]

Hallo zusammen
Habe in meiner srcpd Implementierung das Thema "Lok Refresh Cycle" verbessert:

• Wenn keine neuen Kommandos anstehend sind werden unterbruchsfrei Lok-Refreshs gesendet, wenn mindestens eine Lok vorhanden ist.
• Wenn eine Lok vorhanden ist und Lok-Refreshs gesendet werden, werden keine 0x55 Pakete mehr gesendet.
• Keine Pause vor und nach MFX und DCC Paketen, Pause ist nur bei MM Paketen notwendig. MFX und DCC haben dazu eine Sync-Präambel.
• Da ich ca. 80 angemeldete Loks habe dauert es, wenn sonst keine neuen Befehle anstehen, ca. 10s bis ein Lok-Refresh wiederholt wird. Deshalb werden Refreshs von Loks mit neuen Kommandos (Timeout 60s) für den Refresh bevorzugt (jeder 2. Refresh ist dafür reserviert) behandelt. Da nie alle meine Loks gleichzeitig fahren ist damit ein Refresh von Loks in Betrieb alle paar Sekunden vorhanden.

Zum Thema Verfügbarkeit von RDS Chips:
Wie in meinem MFX Schema beschrieben habe ich den SC6579 aus einer defekten Mobild-Station ausgebaut. Eine Alternative könnte der LC72725 sein. Diesen gibt es zumindet bei www.avnet.com noch in grösseren Stückzahlen (es werden auch Preise für mehr als 20000 Stück angegeben, falls mal jemand eine grössere Serie bauen will ). Vorteil dieses Chips ist, dass er 128Bit Buffer für die empfangenen Daten hat und der Clock für das Auslesen im Slave-Mode von "aussen" kommen kann -> kein Polling notwendig.
Da ich aber im Moment mit meinem SC6579 gut leben kann, habe ich ihn jedoch nie getestet.
Das Problem bei avnet ist nur, dass ihr da auch gleich 2000 Stück bestellen müsst...
5 dieser Chips habe ich hier (vor dem SC6579 Ausbau über meinen Brötchengeber bestellt), 4 davon könnt ihr haben, wenn ihr wollt.

Gruss
Dani

[Rainer Müller]

Hallo,

jetzt habe ich zum ersten Mal eine MM-Lok über den BananaPi bewegt, allerdings hakelt es noch stellenweise. Die Kurzschlussabschaltung z.B. ist noch nicht aktiv.

Das Problem bei avnet ist nur, dass ihr da auch gleich 2000 Stück bestellen müsst...
5 dieser Chips habe ich hier (vor dem SC6579 Ausbau über meinen Brötchengeber bestellt), 4 davon könnt ihr haben, wenn ihr wollt.

da Gerd ja auch Leiterplatten verkauft, müsste er über die Stückzahlen besser Bescheid wissen als ich, aber bei den 2000 kann man sicher ein paar Nullen weglassen.

Hallo zusammen
Habe in meiner srcpd Implementierung das Thema "Lok Refresh Cycle" verbessert:

• Wenn keine neuen Kommandos anstehend sind werden unterbruchsfrei Lok-Refreshs gesendet, wenn mindestens eine Lok vorhanden ist.
• Wenn eine Lok vorhanden ist und Lok-Refreshs gesendet werden, werden keine 0x55 Pakete mehr gesendet.
• Keine Pause vor und nach MFX und DCC Paketen, Pause ist nur bei MM Paketen notwendig. MFX und DCC haben dazu eine Sync-Präambel.
• ...

Das seht jetzt wirklich viel besser aus, da ist was los auf der Leitung. Mein Analyseprogramm muss ich jetzt nachbessern, das hat ein Problem mit mfx-Paketen ganz dicht hinter DCC-Paketen.
Dass jetzt die MM-Pakete ohne Pause vorne im Puffer stehen, hat mich auf ein Problem beim BaPi hingewiesen: das erste Bit im Paket dauert länger, deshalb sollten alle Pakete mit einer 0 beginnen. Somit muss ich jetzt wohl für den BaPi "forken".

@Dani: Die Prozedur "refresh_loco_one" bleibt auf mfx hängen, wenn mfx freigegeben, aber noch keine mfx-Lok angemeldet ist - dann kommen wieder die 0x55.


Gruß
Rainer

[bertr2d2]

Hallo Rainer,

jetzt habe ich zum ersten Mal eine MM-Lok über den BananaPi bewegt ...

Das Problem bei avnet ist nur, dass ihr da auch gleich 2000 Stück bestellen müsst...
5 dieser Chips habe ich hier (vor dem SC6579 Ausbau über meinen Brötchengeber bestellt), 4 davon könnt ihr haben, wenn ihr wollt.

da Gerd ja auch Leiterplatten verkauft, müsste er über die Stückzahlen besser Bescheid wissen als ich, aber bei den 2000 kann man sicher ein paar Nullen weglassen.

Ich denke nicht, das es so viele Platinen werden Wie gesagt, bei Mouser, wo ich ab und zu bestelle, haben sie auch den LC72725KV in kleineren Mengen ...

Gruß

Gerd

[Sigg]

@Dani: Die Prozedur "refresh_loco_one" bleibt auf mfx hängen, wenn mfx freigegeben, aber noch keine mfx-Lok angemeldet ist - dann kommen wieder die 0x55.

Wie ist "hängen" zu verstehen? OK, gebe zu, dass ich keine Test ganz ohne Loks gemacht habe...
"refresh_loco_one" gibt im Return Value eigentlich zurück, ob es einen Refresh zum senden gab oder nicht. Wenn nicht werden absichtlich 0x55 gesendet, um kein DC am Gleis zu haben.
Wenn MM-Protokoll aktiviert ist, dann hat es immer einen Refresh (Lok 81/0). Wenn KEIN MM-Protokoll aktiviert ist, nur DCC und/oder MFX und KEINE Lok angemeldet ist, dann kommen bewusst wieder die 0x55. Aber nur dann, sobald eine Lok vorhanden ist ist es vorbei mit 0x55.

Gruss Dani

[Rainer Müller]

Hallo Dani,

@Dani: Die Prozedur "refresh_loco_one" bleibt auf mfx hängen, wenn mfx freigegeben, aber noch keine mfx-Lok angemeldet ist - dann kommen wieder die 0x55.

Wie ist "hängen" zu verstehen? OK, gebe zu, dass ich keine Test ganz ohne Loks gemacht habe...
"refresh_loco_one" gibt im Return Value eigentlich zurück, ob es einen Refresh zum senden gab oder nicht. Wenn nicht werden absichtlich 0x55 gesendet, um kein DC am Gleis zu haben.
Wenn MM-Protokoll aktiviert ist, dann hat es immer einen Refresh (Lok 81/0). Wenn KEIN MM-Protokoll aktiviert ist, nur DCC und/oder MFX und KEINE Lok angemeldet ist, dann kommen bewusst wieder die 0x55. Aber nur dann, sobald eine Lok vorhanden ist ist es vorbei mit 0x55.

Gruss Dani

ich hatte alle drei Protokolle aktiv.
Ohne MM-Decoder habe ich nicht getestet, aber wenn alle MM durch waren, wurde in der Prozedur refresh_loco_one die Variable busComplete auf true und danach protocol_refresh auf DCC gesetzt.
Waren alle DCC-Decoder durch, oder wenn bei keinem vorhandenen das idle_packet gesendet war, wurde busComplete auf true und danach protocol_refresh auf MFX gesetzt.

Soweit in Ordnung, aber:
Bei keinem MFX-Decoder bleibt die Variable adr auf 0, der Block "if (adr > 0) ..." wird nicht ausgeführt und busComplete und refreshGesendet bleiben false. Damit wechselt protocol_refresh nie mehr, sondern bleibt auf MFX, obwohl es ja keinen MFX-Decoder gibt, und ab diesem Zeitpunkt ist dann der Rückgabewert bei jedem Aufruf "false".
Somit erhält kein Decoder mehr einen Refresh, es werden (außer neuen Infos) nur noch die "160-Wechsel"-Pakete gesendet.

Man könnte das beheben durch Abschalten von MFX, aber dann kann sich ja die erste mfx-Lok nie anmelden.

Gruß
Rainer