Я пытаюсь создать эффективный протокол связи между микроконтроллером с одной стороны и ARM-процессором на многоядерном чипе TI с другой стороны через SPI.
Требования для необходимого протокола:
1 - Многосеансовый с поддержкой очередей, поскольку у меня есть несколько потоков отправки/получения, поэтому это протокол будет иметь более одного приложения, и мне нужен протокол для обработки очередей этих запросов (я буду держать буфер если передача является очередью, но мне нужен протокол для управления планированием очередей).
2 - Работает с SPI в качестве базового протокола.
3 - Простая проверка ошибок.
В этом потоке: Простой последовательный протокол связи точка-точка", PPP был рекомендованным вариантом, однако я вижу, что PPP выполняет только часть задания.
Я также нашел проект Lightweight IP (LwIP) с PPP через последовательный порт (который я предполагаю, что я могу использовать его через SPI), поэтому я подумал о возможности использования любых протоколов верхнего уровня, таких как TCP/UDP, чтобы сделать остальные требуемые рабочие места. К счастью, я нашел TI, включая LwIP, как часть своего Ethernet-коммутатора в пакете стартеров, который, как я полагаю, облегчает портирование по крайней мере на стороне чипа TI.
Итак, мои вопросы:
1 - Действительно ли использовать LwIP для этой схемы связи? Разве это не приведет к большим накладным расходам из-за заголовков IP-адресов, которые не нужны для связи по точкам (на уровне чипа) и убьют пропускную способность?
2 - Будет ли TCP или любой аналогичный протокол, находящийся в LwIP, обрабатывать очередь запросов на передачу, например, если я запрашиваю передачу через сокет, в то время как канал связи занят передачей/получением запроса для другого сокета (сеанса) другого потока, будет ли это управляться стек протоколов? Если да, то какой уровень протокола управляет им?
3 - Является ли их более эффективным стек протоколов, чем LwIP, который соответствует вышеуказанным требованиям?
Обновление 1: Больше точек для рассмотрения
1 - SPI - единственный доступный параметр, я использую его с доступными GPIO, чтобы указывать ведущему, когда подчиненный имеет данные для отправки.
2 - Текущий реализованный (нестандартный) протокол использует DMA с SPI и формат сообщения "STX_MsgID_length_payload_ETX" с фиксированной длиной фрагментов сообщения, однако основным недостатком текущей схемы является то, что мастер ждет ответа на сообщение (а не фрагмент) перед отправкой другого, что убивает пропускную способность и не использует полный дуплексный характер SPI.
3. Улучшение этой точки заключалось в использовании своего рода почтового ящика для приема фрагментов, поэтому длинное сообщение может быть прервано более высоким приоритетом, так что фрагменты одного сообщения могут поступать не последовательно, но проблема в том, что этот дизайн приводит к усложнению ситуации, особенно, что у меня нет большого количества ресурсов для многих буферов для использования подхода почтового ящика на стороне контроллера (мастера). Поэтому я подумал, что это похоже на то, что я изобретаю колесо, создавая стек протоколов для простой ссылки на точку, которая может быть неэффективной.
4 Какие протоколы более высокого уровня обычно можно использовать над SPI для установления нескольких сеансов и решения очереди/планирования сообщений?
Обновление 2: Еще один полезный поток Хороший протокол/стек последовательной связи для встроенных устройств?
Обновление 3:. Я просмотрел протокол Modbus, он, как представляется, задает прикладной уровень, а затем уровень канала передачи данных для последовательной связи по линии, что позволяет пропустить ненужные служебные данные сетевых протоколов слои.
Считаете ли вы, что это будет лучший вариант, чем LwIP по назначению? Кроме того, существует широко используемая реализация с открытым исходным кодом, такая как LwIP, но для Modbus?