Hallo Forum, ich möchte insgesamt 1MByte an Daten über SPI an mein Beaglebone senden. Die Daten sind zuvor in 2 x 512kB Speichern gelagert und werden von einem anderen Controller ausgelesen und gesendet. Nun ist mein Problem wie bekomme ich die Daten am schnellsten rüber? Habe versucht die bufsiz im SPIdev Treiber auf 1,2MByte zu setzten. Leider passiert dann nichts mehr. 500kByte am Stück gehen auch nicht. Also bzw. der Buffer scheint so groß zu sein, aber beim SPIdev_test.c (mit Anpassungen) Programm werden keine 512kByte am Stück gesendet. 100kByte am Stück gehen anscheinend. Kann also nicht so eben mal sehen, ob vielleicht doch alles passt und der Buffer groß genug ist. Als Takt werde ich vorerst 24MHz verwenden. Wie kann ich denn nun am besten die Daten rüber schaufeln? Wenn der Buffer klein ist muss ich ja mehrere male den Buffer in eine Datei schreiben und dann erstma wieder auffüllen mit neuen Daten. Was ist mit den 2 Channels bei den SPI Controllern? Das habe ich noch nicht so ganz verstanden, leider ist die Dokumentation auch nicht sehr aufschlussreich... Was eventuell noch gehen würde, den Buffer direkt über mmap auf ne Datei umzuleiten oder?
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!!
Integer overflow bei der länge oder so? Code zeigen :)
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..
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.