[PheeL 0]

Интересует, какие есть варианты протокола обмена по шине SPI, когда Master и Slave разные по производительности устройства, и необходимо на принятие пакета от мастер-устройства выдавать пакет подтверждения об успешном приёме(т.е. как минимум проверить crc пакета. иными словами, мастер тактирует шину, а слейв ещё не готов отдать ответ). А также вариант, когда слейв исполняет команду и должен сигнализировать мастеру о готовности передачи пакета с данными. Пока есть только вариант с дополнительной сигнальной линией индикации от слейва к мастеру. Есть ли програмный вариант протокола обмена по синхронным шинам для решения подобных проблем?

[Слесарь 9]

Интересует, какие есть варианты протокола обмена по шине SPI, когда Master и Slave разные по производительности устройства, и необходимо на принятие пакета от мастер-устройства выдавать пакет подтверждения об успешном приёме(т.е. как минимум проверить crc пакета. иными словами, мастер тактирует шину, а слейв ещё не готов отдать ответ). А также вариант, когда слейв исполняет команду и должен сигнализировать мастеру о готовности передачи пакета с данными. Пока есть только вариант с дополнительной сигнальной линией индикации от слейва к мастеру. Есть ли програмный вариант протокола обмена по синхронным шинам для решения подобных проблем?

Обычно ведомый сообщает ведущему о том что он готов получить новые данные по хардовому прерыванию и ведущий прерывается раз такое дело чтоб передать новые данные ведомому.

А программный протокол SPI делал когда не изучил еще модуль SPI контроллера, как сильно я тогда заблуждался, все давно реализовано в "железе".

[igorle 0]

Стандартных решений - два.

1) Чисто программное - чтение регистров из слэйва. Например один - для чтения crc последней команды записи. Другой регистр - статус. Передав команду, мастер сначала проверяет что команда прошла успешно (по crc), а потом начинает поллить (периодически считывать) регистр статуса

 

2) Если есть техническая возможность - используют еще одну дополнительную линию для получения прерывания по готовности

 

Обычно производители SPI устройств закладывают возможность обоих вариантов, а в дальнейшем пользователь смотрит - может ли он использовать прерывания, или нет.

[Lagman 1]

AD7793 после конфигурирования на непрерывную выдачу результата сигнализирует о новом значении выдавая импульс (The DOUT/RDY falling edge can be used as an interrupt to a processor, indicating that valid data is available)на MISO.

[SBE 1]

Похожая проблема у меня возникала при соединении двух МК через SPI. В отличие от аппаратных slave устройств, на которые ориентирован SPI, ведомый МК может быть не готов к обмену, может не иметь жесткого тайминга по обработке пакета или команды и т.д.

Наиболее изящным решением стало использование выдающего команды хоста как SPI-slave, с дополнительной линий запроса на обмен вместо дополнительной линии индикации готовности. Тогда ведомый МК, будучи SPI master, может притормозить обмен под свою скорость обработки команды.

 

 

[PheeL 0]

Спасибо. В принципе я услышал всё, что хотел по данному вопросу. Подводя итог можно выделить два основных пути решения проблемы:

1) Дополнительная сигнальная линия с вариантами использования как индикации готовности от слева мастеру, так и в интвертном режиме, когда хост является слейвом. А-ля RTS/CTS/DTR/DSR. Предположительно заведён на аппаратное прерывания хост устройства. Лучший вариант если есть такая аппаратная возможность.

2) Поллинг мастером слейва. Мастер периодически либо постоянно выставляет запрос на данные от слейва тактируя шину в ожидании сигнального байта/пакета готовности обмена. Чисто программный вариант. Степень загрузки основного ядра контроллера мастер устройства при обмене зависит от настроек периферии, а также от наличия аппаратных возможностей для разгрузки основного ядра хост устройства(SPI+DMA+IRQ).

[igorle 0]

Все правильно. Из личного опыты - если программистов не принуждать, то они норовят имплементировать только поллинг. Даже если линия интераптов разведенеа. Им так проще.

[vladimir_orl 0]

Вот тоже по долгу службы занимаюсь этим вопросом. Вот что узнал.

 

В конце посылки из 8 бит мастер переводит линию LCLK в 3 состояние для того чтобы слэйв со своей стороны сигнализировал об ошибках поднятием этой линии в 1. Так что переход в 1 после перерыва - это просто мастер снова выставил 1 на тактовой линии.

[Мур 1]

On 7/12/2013 at 7:25 AM, vladimir_orl said:

В конце посылки из 8 бит мастер переводит линию LCLK в 3 состояние для того чтобы слэйв со своей стороны сигнализировал об ошибках поднятием этой линии в 1. Так что переход в 1 после перерыва - это просто мастер снова выставил 1 на тактовой линии.

Таким же образом можно такой трюк сделать и по линии CS...  (если всего 2 устройства в обмене).

 

Если совместить 2 возможности аппаратной поддержки взаимного информирования в паре Master\Slave, которые легко обеспечивают кадрирование информации, то не сложно сделать на ПЛИС удобный обмен по 4м проводам, который при обмене при тактировании на 50МГЦ 16-разрядными посылками SPI дает  пропускную способность в 5.4 МБайт\Сек одновременно в обе стороны.

Причем обе стороны будут взаимно информированы с задержкой в 370нСек.

Просто сделал за пол дня на VHDL такой дизайн...  В Ква18.0

     Остается чувство досады от неуклюжести микроконтроллеров со стандартными SPI и не возможности ими формировать более тонкие события в аппаратных дебрях интерфейса.

И все это неизбежно отражается на затраты в их ПО. Поллинг это жуть!

SPI_FIFO002.qar