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