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

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

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

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

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

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

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

Спасибо. В принципе я услышал всё, что хотел по данному вопросу. Подводя итог можно выделить два основных пути решения проблемы:
1) Дополнительная сигнальная линия с вариантами использования как индикации готовности от слева мастеру, так и в интвертном режиме, когда хост является слейвом. А-ля RTS/CTS/DTR/DSR. Предположительно заведён на аппаратное прерывания хост устройства. Лучший вариант если есть такая аппаратная возможность.
2) Поллинг мастером слейва. Мастер периодически либо постоянно выставляет запрос на данные от слейва тактируя шину в ожидании сигнального байта/пакета готовности обмена. Чисто программный вариант. Степень загрузки основного ядра контроллера мастер устройства при обмене зависит от настроек периферии, а также от наличия аппаратных возможностей для разгрузки основного ядра хост устройства(SPI+DMA+IRQ).

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

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

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