Hallo Rainer,
[quote="Rainer Müller" post_id=1723241 time=1504800736 user_id=1332]
Hallo Gerd und weitere Mitleser,
Zitat
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.
[/quote]Cool 
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
)
