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:
Zitat von bertr2d2 im Beitrag Preisgünstiger Gleisbox Booster incl. mfx FeedbackCool
Hallo Rainer,
[quote="Rainer Müller" post_id=1723241 time=1504800736 user_id=1332]
Hallo Gerd und weitere Mitleser,Zitat von bertr2d2 im Beitrag Preisgünstiger Gleisbox Booster incl. mfx Feedback
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.

Zitat
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.
Zitat
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.
Zitat
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 [url=]bekannt zu sein[/url]:
2
3
4
5
6
7
8
#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);
Zitat
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
[/quote]
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:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
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".