Hallo liebe Gemeinde,
Ich habe einen ATSAM4E8C und bekomme einfach die SPI-Kommunikation nicht
zum laufen, könnt Ihr mir bitte helfen. Ich verzweifele langsam :-(((((
Vielleicht beschreibst du ja mal, was du genau getan hast? Und
natürlich auch, an welcher Schnittstelle du das SPI hängen hast
(SPI oder USART), ob es Master oder Slave ist, wer die Gegenstelle
ist, etc. pp.
Lass dir doch nicht alles aus der Nase ziehen, oder auch:
Netiquette.
Helmut W. schrieb:> Ich habe einen ATSAM4E8C und bekomme einfach die SPI-Kommunikation nicht> zum laufen, könnt Ihr mir bitte helfen
Wie stellst du das fest und was willst du ueberhaupt per spi ansprechen?
Hallo
also ich habe den ATSAM4 und BMI160. Diese möchte ich gern per SPI kein
USART ansprechen. Ich hab mitlerweile ein Beispiel gefunden und es
implementiert, ohne Fehler. Doch leider ist kein Takt zu erkennen mit
dem Oszi. Ich nutze ASF.
status_code_t status;
uint8_t dataTx[4],dataRx[4];
sprintf(dataRx,"0x00");
uint32_t mySPIselect = 5;
uint32_t myBaudRate = 100000;
spi_flags_t mySPIflags = SPI_MODE_3;
struct spi_device mySPI = {.id = 0};
// Insert system clock initialization code here (sysclk_init()).
sysclk_init();
board_init();
configure_buttons();
spi_master_init(SPI);
spi_master_setup_device(SPI, &mySPI, mySPIflags,
myBaudRate,mySPIselect);
spi_enable(SPI);
while(1)
{
sprintf(dataTx,"0x00");
status = spi_write_packet(SPI, &dataTx, sizeof(dataTx));
spi_read_packet(SPI,&dataRx, sizeof(dataTx));
}
Helmut W. schrieb:> Diese möchte ich gern per SPI kein> USART ansprechen.
Nee, das hast du komplett falsch verstanden: auch mit der USART kann
man SPI machen.
Du benutzt aber offenbar den SPI-Modul selbst, als Master.
> Ich nutze ASF.
Damit kann ich dir leider nicht helfen. Um diesen undurchdringlichen
Koloss mache ich immer einen großen Bogen.
Wichtig ist (und keine Ahnung, ob dir das ASF diesen Job mit den
genannten Zeilen bereits abnehmen würde), dass du die PIO auch
passend definierst, also PA12 - PA14 auf Peripheral A und trotzdem
noch (je nach Funktion) Input oder Output, und dazu den korrekten
Pin für das NPCSn mit entsprechendem Peripheral. (Was genau da
eine 5 sein soll, die du benutzt, habe ich keine Idee. Es gibt nur
NPCS0 bis NPCS3, aber die können auf verschiedene Pins gemappt werden.)
Nicht zu vergessen natürlich, dass du im Power Manager die
Taktversorgung für den SPI-Block aktivieren musst. Wiederum keine
Ahnung, ob ASF dir das abnimmt oder nicht.
Genau dieses „keine Ahnung“ sowie der entsprechende Aufwand, das
händisch irgendwo zu recherchieren, ist einer der Gründe, warum ich
ASF nicht mag. Das ist so ein „du musst eigentlich gar nicht wissen,
was wir hier für dich tun, wir machen das schon!“-Prinzip, mit dem
ich mich schlicht nicht wohl fühle.
Hallo Jörg Wunsch,
ich würde auch auf ASF verzichten, könntest du mir vielleicht ein
Beispiel für die SPI kommunikation zusenden? Damit wäre mir sehr
geholfen ;-)
VG
Naja, so schlüsselfertig, wie die ASF vorgibt zu sein, natürlich nicht.
Das, was ich hier habe, ist proprietärer Code, den ich so erstmal
nicht rausgeben kann.
Das Prinzip daraus habe ich dir aber skizziert, in erster Linie musst
du halt die PIO-Pins konfigurieren. Das heißt, für jeden der Pins
das entsprechende Bit im PIO_PER setzen (PIO Enable), danach das
passende Bit im PIO_OER setzen (Output enable) oder im PIO_ODR (Output
disable, also Input) sowie PIO_ABCDSR1/PIO_ABCDSR2 konfigurieren, je
nach gewünschter Funktion (bei Funktion A wäre in beiden Registern
das jeweilige Bit auf 0 zu setzen).
Das eigentliche Aktivieren des SPI-Moduls ist nicht viel:
(„NPCS“ ist dabei die Nummer des Select-Signals, von 0 bis 3,
entsprechend NPCS0 … NPCS3.)
und deaktivierst es mit
1
SPI->SPI_CR|=SPI_CR_LASTXFER;
Ein Byte wird geschrieben mit
1
SPI->SPI_TDR=byte;
Warten, bis du wieder schreiben kannst:
1
while(!(SPI->SPI_SR&SPI_SR_TXEMPTY)){}
Lesen mit:
1
byte=SPI->SPI_RDR;
So fürchterlich viel isses nicht, ich hoffe mal, ich habe jetzt
nichts übersehen … (bei uns im Code gibt's dann immer noch
#ifdef-Alternativen für den Betrieb mit USART im SPI-Mode).
Hallo Jörg,
vielen Dank schonmal für deine Hilfe ;-).
Aber igendetwas ist noch komisch. Hier ist meine Port-Konfiguration:
1
#define SPCK PIO_PA14
2
#define MOSI PIO_PA13
3
#define MISO PIO_PA12
4
#define CS_DS PIO_PA11
5
6
PIOA->PIO_PER=(1<<11)|(1<<12)|(1<<13)|(1<<14);//Enable PIO for GPIO
7
PIOA->PIO_OER=(1<<11)|(1<<13)|(1<<14);//Enable port pin for output
8
PIOA->PIO_ODR=(1<<12);//Enable port pin for input
9
PIOA->PIO_ABCDSR[0]=0x00000000;// peripheral A
10
PIOA->PIO_ABCDSR[1]=0x00007800;// peripheral A
Jetzt liegt der Takt auf MISO und nicht SPCK, hast du eine Idee ?
Wenn ich nehmlich PA12 ändere in PA14 dan geht es und der Takt ist auf
SPCK.
Aber PIO_ODR ist doch das Register in dem Inputs definiert werden?
Vielen Dank für deine Hilfe!!!
VG
Helmut W. schrieb:> Aber igendetwas ist noch komisch. Hier ist meine Port-Konfiguration:>>
1
>#defineSPCKPIO_PA14
2
>#defineMOSIPIO_PA13
3
>#defineMISOPIO_PA12
4
>#defineCS_DSPIO_PA11
OK, also NPCS0 (PA11) als Select-Signal, das ist dessen Function A.
> PIOA->PIO_PER = (1<<11)|(1<<12)|(1<<13)|(1<<14);//Enable PIO for GPIO
PIO_PDR, du willst sie ja schließlich nicht als PIO-Pins haben,
sondern als Peripheral-Pins.
> PIOA->PIO_OER = (1<<11)|(1<<13)|(1<<14);//Enable port pin for output> PIOA->PIO_ODR = (1<<12); //Enable port pin for input
Ich bin mir aus dem Bauch raus nicht ganz sicher, ob man das überhaupt
noch wirklich bei der PIO konfigurieren muss, oder ob das automatisch
so gesetzt wird, wenn man die peripheral function aktiviert.
> PIOA->PIO_ABCDSR[0] = 0x00000000; // peripheral A> PIOA->PIO_ABCDSR[1] = 0x00007800; // peripheral A
Erstens würde ich an deiner Stelle hier nicht auf Hex-Zahlen
schwenken, sondern die (1<<11)|(1<<13)| ...etc.-Notation beibehalten,
damit man das besser sieht.
Aber: da gehören überall Nullen an die entsprechenden Stellen
rein, denn so, wie das da steht, aktivierst du gerade für all diese
Pins die Funktion C! Das könnte natürlich schon mal dein Problem
sein.
Also:
> Jetzt liegt der Takt auf MISO und nicht SPCK, hast du eine Idee ?
Nö, wieso?
> Wenn ich nehmlich PA12 ändere in PA14 dan geht es und der Takt ist auf> SPCK.
Den Satz verstehe ich nicht.
> Aber PIO_ODR ist doch das Register in dem Inputs definiert werden?
Genauer gesagt: das Register, in dem man die Output-Funktion
abschaltet (output disable register).
Dann schreib doch mal ein komplettes, compilierbares Minimalbeispiel,
mit dem es bei dir nicht funktioniert.
Eventuell fände ich morgen sogar einen Moment Zeit, das zu testen.
Ich hätte hier auch noch ein SAM4S Xplained Pro liegen, die SPI ist
da identisch zum SAM4E.
Mir ist noch aufgefallen, dass du natürlich das CSR noch einstellen
musst. Da werden unter anderem Dinge wie die Taktrate festgelegt.
Rudolph schrieb:> Lag es jetzt wirklich daran, dass SCBR nicht gesetzt wird? :-)
Ich vermute schon. Laut Datenblatt steht der Vorteiler auf 0, was
vermutlich bewirkt, dass eben genau kein Takt erzeugt wird.
SPI->SPI_CSR0[0] = SPI_CSR_SCBR(42) | SPI_CSR_BITS_8_BIT;
könnte da schon gut helfen, ggf. noch NCPHA und CPOL, falls der
Zielschaltkreis das braucht.
ergibt den angehängten Screenshot (Einmal-Trigger direkt nach dem
Booten, also die Werte 0, 1, 2, ..., 5 werden ausgegeben).
Ich hoffe, du kannst das als funktionierendes Minimalbeispiel
akzeptieren. ;-)
Hallo lieber Jörg,
eine Frage habe ich leider doch noch, auch mit der Gefahr das Ich
gesteinigt werde.
Wenn ich im SPI_CSR_SCBR ein anderes CS wähle bzw. 1 oder 2,
funktioniert es nicht mehr kein Takt nix, trotz das ich die anderen
Register angepasst habe.
Dein Code sieht etwas wirr aus: die anderen NPCSx-Signale liegen
größtenteils auf peripheral function B, die hast du aber nirgends
ausgewählt.
Nichtsdestotrotz ist es mir auf die Schnelle nicht gelungen, die
recht komplexe Logik und den Variantenreichtum hinter all diesen
Chipselect-Signalen zu verstehen. Im SPI_MR gibt es noch ein Feld
namens PCS, ich habe das Gefühl, das hat damit zu tun. Vielleicht
guckst du dir den zugehörigen Sourcecode im ASF mal an, möglicherweise
versteht man den Kram im Datenblatt dann besser.
Oder du lebst einfach mit NPCS0. :-)
Hallo Jörg,
da muss ich dich leider korrigieren die meisten Liegen auf peripheral
function A, ich werde jetzt mal schauen ob mir es gelingt die anderen zu
selektieren. Trotzdem vielen Dank für deine Bemühungen. ;-)
VG
Helmut W. schrieb:> die meisten Liegen auf peripheral function A
Nein, die NPCSn mit n != 0 liegen größtenteils auf peripheral B.
Ausnahme: PA31 (benutzt du in deinem Beispiel nicht) und PB14 (Port B
hast du gleich gar nicht drin).
Nichtsdestotrotz, ich hatte es gestern abend mit PA3 probiert (weil
der auf meinem Xplained Pro ganz gut greifbar ist), aber ich habe es
trotzdem auf Anhieb nicht geschafft, das hinzubekommen. Du musst da
wirklich mal durch den ASF-Source hindurchwuseln, was sie im SPI_MR
noch setzen, damit man das zugehörige PCS-Signal tatsächlich aktiviert
bekommt. Bei n = 0 (wie in meinem Originalbeispiel der Fall) scheint
es halt eher zufällig so zu passen, dass das Select dann auch wirklich
generiert wird. Lies die mal im Datenblatt die Ausführungen zu
“Peripheral Selection” durch, dann weißt du, worauf ich hinaus will.
Ohne selektierten Slave wiederum tickert die SPI offensichtlich gar
nicht erst los.
Ich kann aber jetzt erstmal keine weitere Zeit da hinein investieren.
Ich bin dann noch gespannt, was das Ethernet zu Deinem Layout meint. :-)
Der CAN sollte ja ohne Probleme laufen.
Wenn das Datenblatt an der Stelle besser ist als beim SPI, das fand ich
jetzt schon verhältnismäßig grausam wie man sich da die Infos zusammen
stückeln muss - beim AVR kann Atmel das besser.
Dabei ist der ATSAM4E eigentlich schon gut abgehangen.
Rudolph R. schrieb:> Dabei ist der ATSAM4E eigentlich schon gut abgehangen.
Ja, aber auch die Peripherals sehen halt alle ein wenig angestaubt
aus. Ich frage mich ernsthaft, ob wohl jemals jemand auf die Idee
gekommen ist, tatsächlich einen SPI-Bus mit 16 Slaves über einen
externen Adressdekoder zu betreiben …
Die neueren SAMs (SAMD und Konsorten) sehen in dieser Hinsicht
deutlich moderner aus.
Jörg W. schrieb:>> Dabei ist der ATSAM4E eigentlich schon gut abgehangen.>> Ja, aber auch die Peripherals sehen halt alle ein wenig angestaubt> aus.
Ich meinte mehr, dass die Doku etwas seltsam ist dafür das die genug
Zeit dafür hatten.
Aber vielleicht ist das jetzt auch so, man soll ja das AFS benutzen.
> Die neueren SAMs (SAMD und Konsorten) sehen in dieser Hinsicht> deutlich moderner aus.
Mal schauen, wann die C21 verfügbar werden.
Rudolph R. schrieb:> Ich meinte mehr, dass die Doku etwas seltsam ist dafür das die genug> Zeit dafür hatten.
Wenn die Teile erstmal raus sind, bekommt da niemand mehr Zeit
zugestanden, die Doku zu überarbeiten. Da gibt's nur noch Bugfixes
dann.
> Aber vielleicht ist das jetzt auch so, man soll ja das AFS benutzen.
ASF kam erst sehr viel später (für die SAM3 findet man teilweise auch
nicht „richtige“ Appnotes, die nicht nur ein Doku-Abklatsch vom ASF
sind), wird aber mittlerweile halt als das Allheilmittel gepriesen.
Ich brauche eine Hilfe zu spi Kommunikation zwischen Gerät und bmi160
sam4e8c sensors.I nahm Bezug von Ihrem code.I habe einige Fragen.
Brauche ich, um die Sensoren zu initialisieren? Wie kann ich mehr als 4
Sensoren sprechen?
Brauche ich, um die Schreib- und Lesefunktionen von bmi160_support.c und
bmi160.c?