Daten Übertragung über SPI (bufsiz, takt, multichannel??)

Eine Datei? Wozu soll das gut sein? Du kannst ja direkt vom Buffer auf 
das spidev schreiben.. in handlichen stückchen..

Ok, ich erklärte es nochmal genauer.

Ich habe einen Controller mit 2 x 512kbyte Speicherbausteinen.
Den gesamten Inhalt des Speichers möchte ich per SPI an mein Beagleboard 
senden.

Meine überlegeung war nun, da ja spidev nur Master kann...
Ich ziehe den CS auf low und fange an zu takten.. der Controller 
wiederrum schickt mir den Inhalt des 1. Speicherchips und darauf direkt 
den des 2.

Dabei sage ich vorher über den Kernel Parameter meinem SPIDEV das der 
Buffer für das SPI z.B 1,2Mbyte groß sein soll. Also so groß, dass der 
komplette Speicher des Controllers reinpasst (+ bissel "Angstspeicher" 
bzw eventuell Header für eigenes Protokoll...)

Wenn alles da sist wird CS auf high gezogen und mein Beaglebone schreibt 
den gesamten Buffer in eine Datei auf der SD-Card.


Nun ist es aber so, dass wenn ich den Buffer entsprechend groß mache 
funktioniert das spidev_test.c Programm nicht mehr.

Der Buffer wird in /sys/modules/spidev/parameters/bufsiz aber 
entsprechend Konfiguriert angezeigt.

Der große Buffer erlaubt es mir also, das ich keine pausen beim 
Empfangen machen muss um erstmal den Buffer zu leeren.

Jetzt wüsste ich gern warum es nicht geht. Bzw. wie man es sonst besser 
macht`?

Eine Lösung wäre halt kleine häppchen und immer wieder den Buffer 
leeren...

Die andere wäre halt eventuell über mmap() (muss mich da aber noch 
schlau machen ob sowas geht) oder aber irgendwas mit den 2 Channels des 
Beaglebone.
Da hab ich mich auch noch net schlau gemacht. Sozusagen Buffer des 1. 
Channels wird gefüllt dann wird schnell umgeswitcht auf den Buffer des 
2. Channels. Der 1. Buffer wird geleert usw.

Wie überträgt man so eine Datenmenge am besten bzw. schnellsten??

(Ich geh jetzt mal davon aus das der Controller schnell genug die Daten 
aus den Speicherbausteinen in seinen SPI DMA bekommt...)

Oh Beaglebone Black nicht Beagleboard!!

Mit Archlinux!

Integer overflow bei der länge oder so? Code zeigen :)

Code ist im Anhang.

Achja als .dts file nehme ich :

https://github.com/jadonk/cape-firmware/blob/master/dts/BB-SPIDEV0-00A0.dts

aber dann die Frequenz auf 48MHz gesetzt...


Wobei ich anscheinend gar nicht mehrere Channel nutzen kann. Und im 
Datenblatt steht, das wenn beide Channel aktiv sind wird der FIFO nicht 
genutzt. Vielleicht sollte ich das dts abändern auf dieses hier:

http://elinux.org/BeagleBone_Black_Enable_SPIDEV


Wobei ich bisher dachte das original im Archlinux bereits enthaltene 
wäre besser...

Beagle Newbie schrieb:
> Code ist im Anhang.

1

  uint16_t i = 0;

2

  srand(0);

3

  for(i=0; i<524288; i++)

Oh, hab ich nicht drauf geachtet....


Hatte ich nur mal eben eingebaut um das Array zu belegen...
Muss ich morgen nomma abändern und schaun ob es dann geht...


Ist diese Art mit dem großen Buffer denn sinnvoll? Oder ratet Ihr zu 
einer anderen Methode?

Vor allem wo liegt der unterschied bei den 2 .dts files?

Bissel raff ich aber warum das eine 2 Channels definiert und das andere 
nicht versteh ich nicht. Wobei ja bei beiden spidev 1.0 spidev1.1 
auftauchen.

Irgendwie ist die Dokumentation im Bereich Device Tree Overlay und auch 
Linux Kernel Treiber sehr dürftig..

Bisher bin ich halt Datenblätter von Microchip gewöhnt da weiß ich setze 
das Bit und das und das passiert... Hier bei den Sachen muss man ewig 
rumsuchen was genau was macht und meißtens im Code sogar.

Und je nach Kernel Version ändert sich da auch was..

Dts ist pain in the ass.. :(