SLP - последовательный протокол, Еще один велосипед Опции

[Огурцов]

Цель - разработка, испытания, некая стандартизация.
Как думаете, будет ли интересен сабж ?

[umup]

как-то все сложно и запутанно, какие-то stuff-коды и т.п...
я сделал проще - полудуплексный протокол с пакетами переменной длины и станд. заголовком :

заколовок пакета:

u16 packet_size - размер (включая CRC),
u8 node_from - адрес узла-отправителя,
u8 node_to - адрес узла-получателя,
u16 cmd - команда/тип пакета,
......... - данные пакета, индивидуальные для каждой команды,
u16 crc - к.с. пакета (так как нет никакого стаффинга, считается на лету при приеме/передаче каждого байта).

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

есть библ. на С на контроллеров (прием/передача встраиваются в преорывания RX,TX, плюс прерывание таймера для контроля тайм-аута приема и паузы перед передачей отв. пакета, вся обработка - в осн.цикле по флагам готовности пакета), библ. на Питоне для приема/передачи/расшифровки пакетов.

[Огурцов]

u16 crc - к.с. пакета (так как нет никакого стаффинга, считается на лету при приеме/передаче каждого байта).

Да, CRC считается только от данных, без учета стаффинга, поэтому тоже "на лету".

packet_size - зло. Я долго бился над его оптимизацией, а теперь, отказавшись, понимаю, что без него все гораздо прямее.

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