Хороший последовательный протокол/стек для встроенных устройств?

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

  • Поддержка нескольких устройств. Мы хотели бы иметь возможность поддерживать шину RS485.
  • Гарантированная доставка. Какой-то механизм подтверждения и некоторое простое обнаружение ошибок (CRC16, вероятно, прекрасен).
  • Не master/slave. В идеале, ведомый (-ы) мог бы отправлять данные асинхронно. Это в основном только по эстетическим соображениям, понятие опроса каждого раба не кажется мне правильным.
  • Независимость ОС. В идеале он не будет полагаться на упреждающую многозадачную среду вообще. Я готов уступить это, если я могу получить другие вещи.
  • ANSI C. Нам нужно иметь возможность компилировать его для нескольких разных архитектур.

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

Я собираюсь приступить к реализации протокола с раздвижным окном с включенными ACK и без выборочного повтора, но подумал, что, возможно, кто-то может спасти меня. Кто-нибудь знает о существующем проекте, который я мог бы использовать? Или, может быть, лучшая стратегия?

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

ОБНОВЛЕНИЕ 2
Спасибо за советы по CAN. Я смотрел на него в прошлом и, вероятно, буду использовать его в будущем. Мне бы очень хотелось, чтобы библиотека обрабатывала подтверждения, буферизацию, повторы и т.д. Я предполагаю, что я больше ищу сетевой/транспортный уровень вместо уровня данных/физического уровня.

ОБНОВЛЕНИЕ 3
Похоже, что состояние дел в этой области:

  • Обрезанный стек TCP/IP. Вероятно, начиная с lwIP или uIP,
  • Реализация на основе CAN, вероятно, будет сильно зависеть от шины CAN, поэтому она не будет полезна для других физических уровней. Что-то вроде CAN Festival может помочь на этом пути.
  • Реализация HDLC или SDLC (например, этот). Это, вероятно, маршрут, который мы возьмем.

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

Ответ 1

Рассматривали ли вы HDLC или SDLC?

Там также LAP/D (Протокол доступа к каналу, D-канал).

Uyless Black "Протоколы каналов передачи данных "всегда рядом с моей книжной полкой - вы можете найти там какой-нибудь полезный материал (даже прочесть ТОС и исследовать различные протоколы)

Ответ 2

Я бы предположил, что разумной отправной точкой может быть uIP.

Ответ 3

CAN соответствует ряду ваших критериев:

  • Поддержка нескольких устройств:. Он поддерживает большое количество устройств на одной шине. Однако он не совместим с RS485.
  • Гарантированная доставка:. На физическом уровне используется бит-наполнение и CRC, все из которых реализованы на аппаратных средствах во все большем числе современных встроенных процессоров. Если вам нужно acknlowedgement, вам нужно добавить это сверху.
  • Не master/slave: Нет мастеров или рабов; все устройства могут передавать, когда захотят. Аппаратное обеспечение процессора связано с арбитражем и конкуренцией.
  • Независимость ОС: Не применимо; это низкоуровневая шина. То, что вы положили на это, зависит от вас.
  • ANSI C: Опять же, неприменимо.
  • Скорость:. Обычно до 1 Мбит/с до 40 м; вы можете выбрать свою скорость для своего приложения.

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

Ответ 4

Взгляните на Profibus.

Если вы не хотите использовать master/slave, я думаю, вы должны сделать арбитраж с оборудованием (Canbus, FlexRay).

Ответ 5

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

Уровень Phy может быть RS232, RS485, Ethernet...

Ответ 6

Посмотрите на интернет-сеть микроконтроллеров (MIN):

https://github.com/min-protocol/min

Вдохновленный CAN, но с использованием стандартного оборудования UART, с проверкой контрольной суммы Fletcher и формата кадра для обнаружения ошибок и заполнения байтов для маркировки заголовка кадра.