Определяет ли протокол SPI, сколько тактовых импульсов ведущее устройство должно отправить ведомому?

Я пытаюсь реализовать устройство SPI в Verilog. У меня много проблем с координацией ведущего и ведомого, поскольку иногда (с моим текущим внедрением) ведущее устройство SPI не отправляет достаточное количество тактовых импульсов ведомому устройству, чтобы оно могло завершить свою обработку.

Например, это может произойти, если ведомое устройство реализовано так, что его конечный автомат имеет больше состояний, и он перестает получать тактовые импульсы до завершения своего цикла.

Я мог бы изменить свою реализацию, чтобы эти два устройства были скоординированы с точки зрения тактовых импульсов, однако это означает, что главный разработчик должен знать реализацию. детали ведомого (и всех потенциальных ведомых). Мне это вообще не кажется правильным.

Определяет ли протокол SPI, сколько именно импульсов ведущий должен передать подчиненному при отправке, например, одного байта? Если нет, то как любое ведущее устройство SPI совместимо с любым ведомым? Можно ли отправить тонну импульсов (например, 64 импульса на 1 байт) подчиненному устройству на всякий случай?

Ого, хороший вопрос! Вроде смотря кто их стандартом называет. Я нашел статью в Википедии , Intel утверждает, что их стандарт таков: «Этот стандарт поддерживает стандартные циклы памяти с длиной данных от 1 байта до 4 килобайт». Я не уверен, почему не 4 бита на 1 М байт.
@jay, что ты имеешь в виду под «циклами памяти»? Я понимаю, что они говорят, что вы можете отправить от 1 байта до 4 КБ данных, но я все еще не вижу, сколько всего тактов должно быть отправлено.
SPI отсчитывает по одному такту для каждого бита данных, поэтому байт занимает 8 тактов. Таким образом, 4 КБ x 8 = 32 КБ тактов.
Вам нужно посмотреть техническое описание устройства, которым вы пытаетесь управлять. В нем есть все правила. В общем: следуйте протоколу, указанному в техническом описании устройства. Обычно транзакция SPI «сбрасывается», когда мастер переводит выбор ведомого из неактивного в активное, а затем отправляется определенное количество часов, согласно таблице данных.
Некоторым ведомым устройствам требуется минимальное количество байтов или требуется отправка «фиктивного» байта.
«это означает, что мастеру-исполнителю необходимо знать подробности реализации подчиненного устройства (и всех потенциальных подчиненных устройств)» — ну, и да, и нет. Например, аппаратному обеспечению SPI на микроконтроллере не нужно знать обо всех возможных ведомых устройствах, обычно достаточно просто иметь аппаратную функцию для синхронизации байта в сети. (плюс, возможно, буферизация для скорости) Затем программное обеспечение может обрабатывать данные конкретных ведомых устройств, используемых в устройстве, ему уже нужны специфичные для устройства знания о том, что представляют собой данные, поэтому знание, например, нужно ли отправить фиктивный байт, не является огромное бремя.

Ответы (4)

Мастер SPI не несет ответственности за то, чтобы внутренний конечный автомат ведомого устройства получал «достаточное количество» тактовых импульсов. Все, за что отвечает мастер, — это один тактовый импульс на бит, передаваемый на ведомое устройство или от него — вот и все.

Если вашему подчиненному устройству требуется дополнительное тактирование, то вам решать, как управлять своей реализацией таким образом, чтобы это поддерживалось - возможно, вы указываете какое-то минимальное количество байтов, которые должны быть переданы (даже если некоторые из них являются "фиктивными" байтами), или, может быть, у вас есть для предоставления внешних часов подчиненному устройству в дополнение к часам SPI.

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

SD-карта в режиме SPI использует кадрирующие байты. Вы получаете определенный повторяющийся байт, затем байт кадра, затем байты данных. Не такая уж и страшная модель.
Интересно, почему относительно небольшое количество устройств SPI предоставляют средства сброса конечного автомата «кадра» при удерживании CS на низком уровне, например, путем отправки трех последовательных нарастающих фронтов на MOSI, в то время как CLK находится на низком уровне? Для приложений, которым требуется только одно периферийное устройство SPI, это позволит сохранить вывод ввода-вывода на управляющем микроконтроллере.
@supercat, дешевле просто привязать CS к линиям сброса некоторых компонентов, чем реализовать счетчик?
@supercat - возможно, потому, что это наложило бы дополнительные требования на обработку простых ведомых устройств в стиле сдвигового регистра.
Как правило, устройства SPI получают два тактовых сигнала: один для обработки байта, а другой — для обработки его конечного автомата? Будет ли это плохой практикой? Будет ли лучше отправлять кадрирующие байты, как описано выше, для экономии энергии?
@Martel По моему опыту, синхронизация ведомого SPI зависит от того, сколько дополнительных часов (если есть) требуется устройству для выполнения своих внутренних задач. Если требуется всего несколько дополнительных тактовых импульсов в дополнение к тем, которые были необходимы для передачи данных, то часто используется метод «фиктивных байтов», когда пара дополнительных байтов передается с бессмысленными данными только для обеспечения этих тактовых импульсов. Если ведомому устройству требуется много дополнительных тактовых импульсов (или непрерывное тактирование), то у него будут либо собственные внутренние часы, либо дополнительный тактовый вывод.

Ответ на любой вопрос о протоколе SPI: протокола SPI не существует! Это простейший из возможных способов передачи последовательных данных, по сути просто сдвиговый регистр. Взгляните на типичный SPI-модуль в микроконтроллере, и вы увидите проблемы, связанные с отсутствием стандарта (например, какой край захватить).

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

SPI не является протоколом в том смысле, который вы имеете в виду.

Это всего лишь интерфейс для автоматической последовательной передачи битов, чаще всего кратных восьми, для передачи байтов между устройствами.

Конечно, это протокол в том смысле, что все стороны должны договориться о том, как отправлять данные, включая такие вещи, как фаза синхронизации, чтобы знать, на каком фронте загружаются данные и какова полярность холостого хода.

Кроме того, устройства должны использовать протокол битов или байтов, чтобы знать, что означают биты и байты.

По сути, если вашему приемнику SPI требуется определенное количество битов, то передатчик SPI должен передавать это количество битов, не больше и не меньше. Вам решать, что содержат эти биты и как работает ваш приемник SPI, если правильное количество битов не передается.

Реакция подчиненного устройства на передачу MOSI полностью зависит от вас, поскольку вы разрабатываете поведение подчиненного устройства.

Если передача является единственным временем (когда кадр активен), для ответа ведомого устройства оно либо должно настроить свое поведение, чтобы закончить во время кадра, либо оно должно реализовать и описать это поведение, чтобы мастер, использующий эту возможность, синхронизировался. Данные MOSI достаточно длинные (данные-заполнители), чтобы позволить ведомому устройству завершиться.

В этом суть.

Пример того, где я видел это, находится в части Microsemi SmartFusion 2 (MS2090):

На самом деле это не так уж странно или необычно. Microsemi M2S090 имеет аналогичное состояние при опросе файлов HW_STATUS. MOSI отправляет 0xFF, и во время тактирования команды данные MISO содержат ответ. В том же кадре во время тактирования команда MOSI не после 0xFFтактирования подчиненному.

Сравните отличие с другими командами, где после синхронизации полезной нагрузки MOSI мастер сохраняет кадр активным, синхронизирует больше данных MOSI, чтобы ведомое устройство могло ответить на какое-то требование. Мастер — это то, что поддерживает активность фрейма, и, пока он активен, он поддерживает работу часов.

Это ваш дизайн и, следовательно, ваши требования.

Что я сделал для сравнения, так это запустил несколько плат Arduino M/S и оценил поведение. Я использовал этот сценарий, чтобы проверить ожидание реакции ведомого устройства на команду/данные MOSI.

РЕДАКТИРОВАТЬ: Если подумать, это не полностью зависит от вас. На самом деле существуют стандарты, вокруг которых строятся сторонние поставщики. Если вы полностью уверены, что ваш огороженный сад использования FPGA и SPI изолирован, делайте, что хотите. Но если какое-либо стороннее устройство предназначено для подключения и обмена данными с вашим мастером , необходимо позаботиться о поведении мастера во время передачи SPI. (Я имею в виду Mode, и есть статьи в Википедии и т. Д. Об этом, а также в вашем описании вашего кремния было бы еще лучше посмотреть).