Чип-к-чип протокол связи через SPI

Я думаю, что, возможно, вы слишком многого ожидаете от скромного SPI.

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

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

SPI не очень сложный и не гибкий интерфейс и, вероятно, не подходит для тяжелых протоколов общего назначения, таких как TCP / IP. Поскольку «адресация» на SPI выполняется путем физического выбора микросхемы, адресация, присущая таким протоколам, не имеет смысла.

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

В любом случае я предлагаю вам разработать что-то конкретное для вашей цели. Поскольку SPI не является сетью как таковой, вам нужно только средство для адресации потоков на выбранном узле. Это может быть просто STX<thread ID><length><payload>ETX.

Добавлено 27 сентября 2013 г. в ответ на комментарии. Обычно SPI, как следует из названия, используется для подключения к периферийным устройствам, и в этом контексте протокол определяется периферийным устройством. EEPROMS, например, обычно используют общий или, по крайней мере, совместимый командный интерфейс от поставщиков, а интерфейс SPI карты SD / MMC использует стандартизированный тест команд и протокол.

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

Я бы посоветовал вам, если вы хотите использовать общий сетевой стек, абстрагироваться от SPI с драйверами устройств на каждом конце, которые предоставляют SPI стандартный интерфейс потока ввода-вывода (open (), close (), read (), write () и т. д.), то вы можете использовать протоколы PPP и TCP / IP более высокого уровня (хотя PPP, вероятно, можно избежать, поскольку соединение является постоянным). Однако это было бы привлекательно только в том случае, если оба узла уже поддерживали эти протоколы (например, под управлением Linux), в противном случае это потребует значительных усилий и кода с небольшой выгодой и, конечно же, не будет «эффективным».

Я предполагаю, что вы действительно не хотите или не имеете места для полного стека ip (lwip) на микроконтроллере? Это просто звучит как перебор. Почему бы просто не свернуть свою собственную простую структуру пакетов, чтобы переместить элементы данных, которые вам нужно переместить. В зависимости от того, как spi поддерживается с обеих сторон, вы можете или не сможете использовать его для определения кадра для ваших данных, если бы не простой шаблон начала, длина и конечная контрольная сумма и, возможно, шаблон хвоста было бы достаточно для поиска границ пакетов в поток (не отличается от решения для последовательного порта / uart). Вы даже можете использовать для этого решение PPP с шаблоном начала, и я думаю, что шаблон конца с полезной нагрузкой использует двухбайтовый шаблон всякий раз, когда шаблон начала появляется в данных. Я сейчас не помню всех подробностей.

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

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

Я не могу представить, что lwip управляет вашими очередями за вас. Я предполагаю, что вам нужно будет сделать это самостоятельно. различные очереди могут захотеть поговорить с одним драйвером, который имеет дело с одной шиной spi (при условии, что существует одна шина spi с выбором нескольких микросхем). Это также зависит от того, как вы используете интерфейс spi, если вы позволяете руке разговаривать с несколькими микроконтроллерами, и пакеты данных разбиваются на немного от этого контроллера, немного от этого контроллера, так что никому не нужно ждать, чтобы задолго до того, как они получат еще несколько байтов данных. Или весь фрейм должен переместиться с одного микроконтроллера, прежде чем перейти к следующему прерыванию gpio, чтобы вытащить данные этих парней? Короче говоря, я предполагаю, что вам нужно управлять общим ресурсом так же, как и в любой другой ситуации, когда у вас есть несколько пользователей общего ресурса (rtos, полноценная операционная система и т. Д.). Я вообще не помню lwip, но с полнофункциональным интерфейсом приложений сокетов Berkeley пользователь мог писать отдельные приложения, где каждое приложение заботилось только об одном TCP или UDP-порту, а библиотеки и драйверы управляли разделением этих пакетов для каждого приложения, а также все правила для стека IP.

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