Чип для протокола обмена чипами по SPI

Question

Я пытаюсь разработать эффективный протокол связи между микроконтроллером с одной стороны и процессором ARM на многоядерном чипе TI с другой стороны через SPI.

Требования к необходимой протокола:

1 - Multi-сессия с очередями поддержки, так как у меня есть несколько отправка/прием потоков, так что это будет более одного приложения, используя этот протокол связи и мне нужен протокол для обработки очередей этих запросов (я буду держать буфер, если очередь передачи, но мне нужен протокол для управления очередями).

2 - Работает под SPI в качестве базового протокола.

3 - Простая проверка ошибок.

В этой теме: «Simple serial point-to-point communication protocol», PPP был рекомендованным вариантом, однако я вижу, что PPP выполняет только часть задания.

Я также нашел проект Lightweight IP (LwIP) с PPP через последовательный порт (который я предполагаю, что я могу использовать его через SPI), поэтому я подумал о возможности использования любых протоколов верхнего уровня, таких как TCP/UDP, выполняйте остальные необходимые задания. К счастью, я нашел TI, включая LwIP, как часть своего Ethernet-коммутатора в пакете стартеров, который, как я полагаю, облегчает портирование, по крайней мере, на стороне чипа TI.

Итак, мои вопросы:

1 - Справедливо ли использовать LwIP для этой схемы связи? Разве это не приведет к большим накладным расходам из-за заголовков IP-адресов, которые не нужны для связи по точкам (на уровне чипа) и убивают пропускную способность?

2 - Будет ли TCP или любой аналогичный протокол, находящийся в LwIP, обрабатывать очереди запросов на передачу, например, если я запрашиваю передачу через сокет, пока канал связи занят передающим/принимающим запросом для другого сокета (сеанса) другого thread, будет ли это управляться стеком протокола? Если да, то какой уровень протокола управляет?

3 - Является ли их более эффективным протокольным стеклом, чем LwIP, который соответствует вышеуказанным требованиям?

Update 1: Чем больше очков, чтобы рассмотреть

1 - SPI является единственным доступным вариантом, я использую его с имеющимся GPIOs для указания мастера, когда ведомые имеют данные для передачи.

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

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

4 Какие протоколы более высокого уровня обычно можно использовать над SPI для установки нескольких сеансов и решения очереди или составления расписаний?

Update 2: Другой полезной нить «A good serial communications protocol/stack for embedded devices?»

Update 3: Я имел взгляд на протоколе Modbus, по-видимому, чтобы определить уровень приложений затем непосредственно канальном слой для последовательной линии связи, который звучит, чтобы пропустить ненужные накладные расходы на уровни сетевых ориентированных протоколов.

Считаете ли вы, что это будет лучший вариант, чем LwIP по назначению? Кроме того, существует широко используемая реализация с открытым исходным кодом, такая как LwIP, но для Modbus?

Answer 1

Я думаю, что, возможно, вы ожидаете слишком много скромного 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), иначе это будет значительным усилием и кодом для небольшой пользы и, конечно, не будет «эффективным».

Answer 2

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

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

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

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

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