Spero di trovare aiuto anche se questo problema potrebbe essere più hardware di software (vedremo). Sto lavorando su una scheda personalizzata basata sul processore Freescales P1021 (ppc, core e500v2). Un PCB esterno sarà connesso e potrebbe essere configurato da SPI. Le specifiche di questo PCB esterno vengono lette mentre attende un comando a 2 byte in modalità full duplex e che solo l'ultimo byte viene utilizzato per trasferire i dati su MISO.Spidev non scrive/legge simultaneamente utilizzando ioctl
Sapendo questo attualmente lavoro per preparare alcuni pezzi di software per testare questo dispositivo. Così ho iniziato con il noto programma spi_test.
[email protected]:~# ./spi_test -D /dev/spidev32766.3
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00
[email protected]:~#
Il segnale mostra 608 orologi e sembra ci sono solo dati nella prima metà. Decido di indagare e testarlo con loopback: shorcutting MOSI-MISO esegue il loop dei dati nel buffer rx. I risultati:
[email protected]1021rdb:~# ./spi_test -D /dev/spidev32766.3
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D
[email protected]:~#
Questa segnali rivela che l'intero telegramma viene ripetuto per qualsiasi motivo (non so perché). Tuttavia, il programma mostra correttamente i dati ricevuti nella console, quindi potrebbe essere come se lo spi_test lo prevedesse.
Inoltre ho manipolare il modello che verrà inviato a questo programma fino a 2 byte (per simulare il formato di comando richiesto io lo scopo per) come questo:
#ifdef ORIG
uint8_t tx[] = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0x40, 0x00, 0x00, 0x00, 0x00, 0x95,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xDE, 0xAD, 0xBE, 0xEF, 0xBA, 0xAD,
0xF0, 0x0D,
};
#else
uint8_t tx[] = {
0xAA, 0x81,
};
#endif
Ma come non mi aspettavo 32bit sono spostati out to SPI bus - invece di 16. Durante i primi due byte MOSI fornisce entrambi i byte dal tx [] e per gli altri 2 byte è basso/0. Ecco i risultati di output della console e segnali:
[email protected]:~# ./spi_test_2bytes -D /dev/spidev32766.3
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
00 00
[email protected]:~#
E anche se io di loopback MOSI di miso non vengono ricevuti dati (output della console è ancora lo stesso di ricezione "00 00"):
io gioco un po 'con tutti i parametri e decido di cambiare il programma di prova per utilizzare half duplex (trasmettere solo) modalità:
01.235.164,106174 millionsPoiché questo è compilato ed eseguito, le cose sono come previsto. SPI_CLK esegue 16 cicli per 16 bit e MOSI fornisce i dati come previsto. Uscita cosole non mostra i dati ricevuti ed i segnali sono come previsto:
[email protected]:~# ./spi_test_2bytes -D /dev/spidev32766.3
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
00 00
[email protected]:~#
In realtà mi sembra che invece di fare 2 byte pieno trasferimento duplex faccio una trasmissione N byte seguito da un byte N ricevi.
In realtà ci sono due domande:
- Perché 0xAA, 0x81 e 0x00, 0x00 si trasmette?
- Perché (utilizzando il loopback) il codice originale è in grado di recuperare i dati nei buffer rx ma se ridotto a 2 byte non vengono ricevuti dati?
Messaggio le immagini altrove e aggiungere link a loro nella risposta - un utente più alto rappresentante può quindi modificare la risposta di includerli –
controllerò oggi, se spidev è stato compilato con SPI_MASTER_HALF_DUPLEX bandiera abilitato che costringe il dispositivo spi a half duplex. – stede
SPI_MASTER_HALF_DUPLEX non è stato impostato. – stede