um das Thema Preisgünstiger Gleisbox Booster incl. mfx Feedback nicht noch weiter zu entführen, habe ich die BananaPi-Programmierung jetzt abgetrennt:
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?bertr2d2 hat geschrieben: ↑Fr 8. Sep 2017, 10:37 Hallo Rainer,CoolRainer Müller hat geschrieben: ↑Do 7. Sep 2017, 17:12 Hallo Gerd und weitere Mitleser,
in der Zwischenzeit habe ich auch einen BananaPi hier und damit experimentiert.bertr2d2 hat geschrieben: ↑Di 2. Mai 2017, 09:17
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ß
Gerdzum 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.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.Genau das scheint der überarbeitete SPI Treiber in einem halbwegs modernen Kernel IMHO zu machen.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.In der Tat, das ist unschön. Scheint aber auch bekannt zu sein:Und wenn man eine Paketlänge von GENAU 64Byte nimmt bei Duplexübertragung, hängt sich die ganze Banane auf!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);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.Aber insgesamt kann man die SIGG-Software bei genügender Leidensbereitschaft auch auf einen BananaPi portieren.
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
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 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".
)
Cool 