Hallo! Ich besitze seit geraumer Zeit ein Atmel NGW100 und möchte nun ein Projekt realisieren, bei dem das RFM12 Modul zum Einsatz kommt (echt super ding). Zur Ansteuerung des RFM12 Moduls verwende ich am NGW100 spidev (konfiguriert in setup.c + buildroot): static struct spi_board_info spi0_board_info[] __initdata = { { .modalias = "mtd_dataflash", .max_speed_hz = 8000000, .chip_select = 0, }, { .modalias = "spidev", .max_speed_hz = 20000000, .chip_select = 1, }, }; Nach der Kompilierung entdeckte ich hier im Forum das Programm von Bendedikt K. und modifizierte es so, dass es eigentlich funktionieren müsste (tut es aber nicht!!, Code im Anhang). Als Vorlage für die Änderung habe ich das Beispielprogramm vom spidev-Treiber verwendet. Hardwaremäßig hätte ich auch alles richtig angeschlossen. Nun wollte ich fragen, ob schon jemand Erfahrungen im Umgang mit NGW100 + SPI Module gemacht ??
Explizit mit dem NGW100 nicht , aber mit dem Grasshopper und diversen ARMen. Was geht denn nicht? Kommt auf dem SPI an NGW100 etwas raus? Schickt das RFM12 etwas zurück? Die Bits schon am Oszi,LA abgezählt und decodiert? Gehört in den spi_ioc_transfer tr Struct nicht auch noch dein SPI Mode mit rein (CPHA/CPOL) ?
Hi, wie der Zufall so will, bin ich gerade genau an der gleichen stelle. Ich versuche ebenfalls mit dem NGW100 + buildroot 2.3.0 ein rfm12b Modul anzusteuern. Ich möchte das jedoch nicht mit spidev realisieren, sondern möchte einen eigenen kleinen Kernel Treiber für das rfm12 Modul schreiben. Ich denke damit ist es einfacher das Modul später in verschiedenen Programmen anzusprechen da die Behandlung des IRQ's vom Kerneltreiber verwaltet wird. Gruß Jörn
Ich würde das auch als Kernel Modul machen. Für mein erstes SPI Kernel Modul habe ich den LTV350 Treiber vom STK1000 abgeändert, der ist schön übersichtlich und exportiert gleich zwei weitere Platform Devices mit. BTW: Kennt ihr das ? https://www.zerties.org/tiki-index.php?page=Funk2Duo
mhm nicht schlecht ... ich habe mir heute die Signale mal auf das Oszilloskop geholt und feststellen müssen, dass nichts ausgegeben wird. Also hab ich die SPI-Testdatei kompiliert und es funktionierte, bei meinem Programm ist es nämlich daran gelegen, dass nur 1 Wert nicht übertragen werden kann (zumindest sehe ich so dass). Also habe ich ins Array einen 2 Wert immer mitübertragen und es funktionierte. Leider hatte ich noch keine Zeit die Kommunikation mit dem RFM12 zu testen. Im Setup.c kann ich default Werte setzten (Mode, Clockphase, Clockpolarität). Muss ich aber nicht machen. Falls ich Zeit finde werde ich mir schon mal das Kerneltreiber programmieren ansehen.
@Claude Schwarz Danke für den Tipp. Hatte bislang vergeblich nach einem guten Beispiel gesucht. Ich habe allerdings noch nicht ganz verstanden an welcher stelle im Treiber definiert wird wo auf welchem PIN CS angeschlossen wird. Oder wie man festlegt welchen Interrupt PIN man zusätzlich benutzen möchte... Hier nochmal kurz der Treiber des LTV350 und meine Board setup.c LTV350 http://rafb.net/p/05IMcS42.html setup.c http://rafb.net/p/K09w3k72.html Ich hoffe du kannst mir auf die Sprünge helfen. Gruß Jörn
Hallo Jörn, der LTV350 (Oder dein Treiber) muss in den
1 | static struct spi_board_info spi0_board_info[] __initdata = { |
2 | {
|
3 | .modalias = "mtd_dataflash", |
4 | .max_speed_hz = 8000000, |
5 | .chip_select = 0, |
6 | },
|
7 | };
|
Struct deiner setup.c eingetragen werden. Genauso wie der Dataflash Treiber hat auch der LTV350 Treiber eine Funktion
1 | static int __devinit ltv350qv_probe(struct spi_device *spi) |
in der der Treiber die Infos aus dem spi0_board_info Struct übergeben bekommt. Chipselects , IRQ, SPI Bus Frequenzen und SPI Modus werden überlicherweise im spi0_board_info Struct mit angeben (.irq = ...). Es gibt aber auch Treiber (wie der Dataflash Treiber) die das SPI Setup selbst machen. Das alles , oder besser gesagt das Treibermodell, ist recht ausführlich in /Documentation/driver-model/platform.txt erklärt. PS: Als Buchtipp kann ich ISBN 0-13-239655-6 empfehlen. Gibt auch ein paar Seiten zu SPI und liest sich angenehmer als LDD3
Ok soweit hab ich das verstanden, aber welcher PIN wird denn durch .chip_select = 0 genau zugeordnet? Mir fehlt hier irgendwie sowas wie PORTB,0 oder so...
wenn du wie oben in dem Codebeispiel von Claude die SPI0 auswählst, kann der CS 0 (genauer: SPI0 - NPCS[0] ) nur PA03 des AP7000 sein. Die Pin-Zuordnungen findest du hier: http://www.atmel.com/dyn/products/datasheets.asp?family_id=682 und zwar in dem Summary-Datenblatt unter 7.7.1 Gruß Udo
@Udo Danke genau das fehlte mir noch... Im NGW100 Schaltplan waren die CS Signale auch schon entsprechend eingetragen, nur ich konnte mir beim besten willen nicht vorstellen das nur 3 CS Pinne zur Verfügung stehen... ? Ist es denn trotzdem möglich einen beliebigen anderen PIN zu verwenden? Gruß Jörn
Jede SPI-Einheit des AP7000 hat 4 CS-Ausgänge: SPI0 - NPCS[0] bis SPI0 - NPCS[3] und SPI1 - NPCS[0] bis SPI1 - NPCS[3] Ob alle Pins beim NGW100 rausgeführt sind, weiß ich jetzt nicht. Sicher kannst du als CS einen anderen, beliebigen GPIO-Pin als die vorgesehenen nehmen, aber den musst du dann selbst bedienen.
Hallo! Ich habe noch eine Frage: Weiß jemand, ob spidev, nur 8Bit Paketgröße unterstützt ? (weil beim Einstellen von 16Bit im bits Feld im spidev_test.c File erhalte ich an MOSI immer nur High)
Hallo nochmal! Derzeit kann ich schon Daten mit dem RFM12 über mein C-Programm versenden, nur mit dem Empfangen klappts noch nicht so toll. Ich habe die Kommunikation zwischen 2 NGW mit RFM12 Modul versucht, wenn ich das empfangene Byte bis zu einer gewissen Zeit am anderen Board nicht auslese aus dem RFM-Modul ist es nicht mehr hier, d.h. übertrage ich jetzt nur ein Byte und hole dieses zu spät ab bekomme ich 0 aus dem Empfangsbuffer. Wenn ich das zu übertragene Byte dauernd sende erhalte ich den richtigen Wert, weil ich ja dann den Buffer dauernd beschreibe. Hat irgendwer eine Idee woran das liegen kann bzw. wie man das Problem löst (konfiguriert müsste das RFM Modul richtig sein)??
Kenne mich mit dem RFM12 nicht aus ... aber kann es sein das du den Empfänger nur anschaltest wenn du in der Main rf12_rxdata aufrufst? Die zwei Boards / RFM12 laufen ja Asynchron , wie merkt Board2 dann das Daten auf dem Äther sind?
1 | void rf12_rxdata(int fd, unsigned char *data, unsigned char number) |
2 | {
|
3 | unsigned char i; |
4 | rf12_trans(fd, 1, 0x82C8); // RX on |
5 | .....
|
6 | rf12_ready(); |
7 | rf12_trans(fd, 1, 0x8208); // RX off |
8 | }
|
Genau da liegt mein Problem, weil i keine Ahnung habe wie ich das implementieren kann. Denn wie weiß das Board, welches Daten empfangen soll, wann Daten vom anderen Board gesendet werden.
Hi, Soweit ich weiß, schaltet das rfm12 Modul einen Ausgang high oder low sobald Daten im Buffer sind. Dies lässt sich dann sehr elegant mit einem Interrupt fähigen Eingang abfragen. Gruß Jörn
Bitte 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.