Я надеюсь найти некоторую помощь, даже если эта проблема может быть связана не столько с программным обеспечением, сколько с программным обеспечением (посмотрим). Я работаю над кастомной платой на базе процессора Freescales P1021 (ядро ppc, e500v2). Внешняя печатная плата будет подключена и может быть настроена через SPI. Спецификации этой внешней печатной платы считываются, поскольку она ожидает двухбайтовую команду в полнодуплексном режиме и что только последний байт используется для передачи данных обратно в MISO.

Зная это, я в настоящее время работаю над подготовкой некоторых программ для тестирования этого устройства. Итак, я начал с хорошо известногоspi_test программа.

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:~#

Сигнал показывает 608 часов, и кажется, что есть только данные в первой половине. Я решил исследовать и протестировать его с помощью loopback - сокращение MOSI-MISO возвращает данные в буфер rx. Результаты, достижения:

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 BE EF BA AD
F0 0D
root@p1021rdb:~#

Этот сигнал показывает, что вся телеграмма повторяется по любой причине (я не знаю почему). Тем не менее, программа правильно отображает полученные данные в консоли, поэтому может быть так, как ожидал spi_test.

Далее я манипулирую шаблоном, который будет отправлен в этой программе до 2 байтов (для имитации запрошенного формата команды, к которому я стремлюсь) следующим образом:

#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

Но, как я и не ожидал, 32 бита смещены на шину SPI - вместо 16. В течение первых двух байтов MOSI предоставляет оба байта из tx [], а для других 2 байтов он является низким / 0. Вот результаты консольного вывода и сигналов:

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:~#

И даже если я возвращаю MOSI к MISO, данные не принимаются (вывод на консоль все тот же, получая «00 00»):

Я немного поэкспериментирую со всеми параметрами и решаю сменить тестовую программу на полудуплексный режим (только передача):

#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

Поскольку это скомпилировано и выполнено, все как ожидается. SPI_CLK выполняет 16 циклов для 16 битов, а MOSI предоставляет данные, как и ожидалось. Выход Cosole показывает отсутствие полученных данных, а сигналы соответствуют ожидаемым:

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:~#

На самом деле мне кажется, что вместо полнодуплексной передачи в 2 байта я делаю N-байтовую передачу, а затем N-байтовую передачу.

На самом деле есть два вопроса:

Почему передаются 0xAA, 0x81 и 0x00, 0x00?Почему (используя loopback) исходный код может вернуть данные обратно в rx-буферы, но если их уменьшить до 2 байтов, данные не будут получены?