c - Spidev do not write/read simultaneously using ioctl -


i hope find if issue might more hardware software related (we'll see). i'm working on custom board based on freescales p1021 processor (ppc, e500v2 core). external pcb connected , configured spi. specifications of external pcb reads expects 2-byte command in full duplex mode , last byte used transfer data on miso.

knowing work prepare pieces of software test device. started known spi_test program.

root@p1021rdb:~# ./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 root@p1021rdb:~# 

pic1

the signal shows 608 clocks , seems there data in first half. decide investigate , testing loopback - shorcutting mosi-miso loops data rx buffer. results:

root@p1021rdb:~# ./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 ef ba ad f0 0d root@p1021rdb:~# 

pic2

this signals reveals, whole telegram repeated reason (i don't know why). however, program shows received data in console correctly, may spi_test expected it.

further manipulate pattern sent in program down 2 bytes (to simulate requested command format aim for) this:

#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 

but did not expect 32bits shifted out spi bus - instead of 16. during first 2 bytes mosi provides both bytes tx[] , other 2 bytes low/0. here results of console output , signals:

root@p1021rdb:~# ./spi_test_2bytes -d /dev/spidev32766.3 spi mode: 0 bits per word: 8 max speed: 500000 hz (500 khz)  00 00 root@p1021rdb:~# 

pic3

and if loopback mosi miso no data received (console output still same receiving "00 00") :

pic4

i play around bit parameters , decide change test program use half duplex (transmit only) mode:

#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     uint8_t rx[array_size(tx)] = {0, };     struct spi_ioc_transfer tr = {         .tx_buf = (unsigned long)tx, #ifdef orig               .rx_buf = (unsigned long)rx, #else       .rx_buf = 0, #endif 

as compiled , executed thing expected. spi_clk cycles 16 times 16 bits , mosi provide data expected. cosole output shows no received data , signals expected:

root@p1021rdb:~# ./spi_test_2bytes -d /dev/spidev32766.3 spi mode: 0 bits per word: 8 max speed: 500000 hz (500 khz)  00 00 root@p1021rdb:~# 

pic5

pic6

actually seems me instead of doing 2 bytes full duplex transfer n byte transmit followed n byte receive.

actually there 2 questions:

  1. why 0xaa, 0x81 , 0x00, 0x00 transmitted?
  2. why (using loopback) original code able data in rx buffers if reduced 2 bytes no data received?

well, post quiet overwhelming. read few parts , got in touch spi on linux. however, mentioned in https://www.kernel.org/doc/documentation/spi/spidev async read/write not available in userspace. afaik read/write wrapper around fcntl. you'll need write own kernel module achieve async i/o.


Comments

Popular posts from this blog

android - getbluetoothservice() called with no bluetoothmanagercallback -

sql - ASP.NET SqlDataSource, like on SelectCommand -

ios - Undefined symbols for architecture armv7: "_OBJC_CLASS_$_SSZipArchive" -