Ни то, ни другое - НИКОГДА не ссылаться на "промышленных автоматизаторов" в качестве хоть какого-то авторитета.

Адрес идет первым не по причине мультимастера, а по причине быстрого принятия решения по маршрутизации и отсеву при симплексе фреймов по признаку master/slave, котрый тоже
закладывается в начальный блок. Наличие во фрейме размера фрейма есть в общем-то моветон, но размер, если уж есть, по любому может быть в любом месте минимального фрейма/заголовка.

Про переменную длинну - писал ранее. Про "удобство ДМА", прежде всего следует озаботится тем, что бы НЕ загружать ни DMA ни последующие обработчики приемом и отсеиванием мусора.

Глупостей и ошибок всегда можно наделать до бесконечности и еще чуть чуть. Но разумных и продуманно-сбалансированных вариантов ничтожно мало

Для того, что бы понять, как следует стремиться что-то протокольное делать, следует в качестве общего развития понять, как и почему хотя-бы дедушка всех ПРАВИЛЬНЫХ стеков протоколов - X.25 сделан так, как он сделан. После чего уже сможете отделять "вкусы разработчиков" от их дурости безошибочно.


Это НЕ идеал. Это одна узкая точка зрения в вашем случае "ДМА". Как минимум одну причину НЕ иметь размер первым байтом уже назвал.

А вот давайте не будем придумывать новые термины. Ибо если не знаете протоколов, то и термины применяйте общепринятые...
8b/10b можно даже не обсуждать...
Можно поговорить о 9-м бите "чет-нечет", как в MSC51. В микроконтроллере это легко, а вот в хосте не очень...

Ну так назовите этот самый "разумный". Или это недостижимая мечта вроде коммунизма?

Из общеизвестных сходу вспоминаются:
MODBUS (ASCII/RTU)
SLIP (CSLIP)
WAKE
...
?

разделение на фреймы:
SLIP (RFC1055)
https://tools.ietf.org/html/rfc1055

просто, стандартно, надежно. Внутри- по вкусу (у меня, например, дополнительно код в начале и CRC16 в конце, а между ними данные в соответствии с кодом).

Тут я позволю себе обратить вминание на то, что это была моя личная точка зрения основанная на личном практическом опыте:

Я не претендую на истинность и не считаю себя большим авторитетом. Ну, да и ладно


Вот с этим я совершенно согласен.


Не возьмусь рекомендовать что-то конкретное,
т.к. считаю, что задача и область применения устройства, для которого выбирается протокол, определяет его структуру.
Невозможно придумать один универсальный протокол подходящий на все случаи жизни.

Случай из жизни.
Лет 7 назад мы с коллегой решили разработать новый универсальный протокол для применения в приборах нашей фирмы
(для конкретной области применения, а не вообще),
написали свои пожелания, я все продумал, написал проект, обсудили, утвердили.
Я его даже реализовал в ОДНОМ макете, который не пошел дальше макета. И все, лежит, уже интегрированый в наши тестовые программы.
Всем замечательный протокол, очень гибкий. Но немного сложноват в реализации.
Так что мы так и применяем то, что уже применяли на фирме лет 20 - минималистический протокол с коротким фиксированным пакетом.
А где нужно больше данных гонять, начали применять по просьбе заказчиков MODBUS, хотя мне и сильно не нравиться его регистровая направленность.

Так что не скажу я вам, что ОБЯЗАТЕЛЬНО нужно изучать. Я просто по работе сталкивался то с одним, то с другим протоколом, так и нахватался отрывистых знаний.
Теоретического курса по протоколостроению никогда не слушал.

Я, естественно, тоже писал по своему опыту.

Но ПОДХОДЫ к созданию протоколов должны быть универсальными. Рожать протоколы по принципу у меня тут DMA и ему будет удобнее..., есть неправильно. Любой протокол требует определенных компромиссов. В данном случае вообще Автором намечатся использование DMA через анус - типа я буду разгребать побайтно мусор и искать начало, а потом получив ОДИН байт, который тоже, между прочим, может быть мусором, как запущу DMA, да как получу целую кучу всего, да как потом начну разбираться в том, что получил, и в том числе опять искать в принятом начало фрейма, если размер оказался мусором... В общем фигня зачем-то поставленая во главу протокола.



Совет, какой смотреть и вникать в ОБЩИЕ принципы многоуровневого построения протоколов, уже был.

Тихий ужас. ASCII хоть фрейминг имеет, правда огромной ценой.

Это не пртокол, это фреймер. То есть нижний уровень протокола. Если физический уровень байтовый, то этот фреймер и надо использовать в большинстве случаев, а для 485 - в 98% случаев.

Слиповский фреймер с небольшими надстройками в стиле MODBUS. Как прямая альтернатива модбасовскому выкидышу - отлично. На продвинутость, естественно, не перетендует.

Это смотря какой микроконтроллер....
Недавно делал опцию отображения содержимого LCD 320x240x4bpp на МК в окно приложения под виндой. Соответственно - периодическая передача содержимого видеоОЗУ (по обновлению оного) в комп по
USB.
Просто гнать массив - довольно накладно получалось - порядка ~40кБ. А картинка на LCD - это обычный юзер-интерфейс без пиксельной графики - результат вывода текста + линии/многоугольники и т.п.
Сделал сжатие картинки на лету на МК - стало гораздо бодрее
Траффик упал в неск. раз и МК не помер. Ресурсов это заняло немного. А сжатие - сплошные манипуляции с битами и преобразование в битовый поток.
Хотя МК канеш не AVR - LPC4370 с тактовой до 204МГц


Годится только для "железного" UART, коих на ПК практически не осталось.
Как только пропускаем эти пакеты через UART-USB - все ваши разделения идут лесом.
А если автор захочет этот поток например через GPRS-канал пропустить с его непредсказуемыми задержками???......

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

См. посто №1: "Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR."

Не смешивайте уровни обработки. Драйвер DMA не должен никак зависеть от протокола в котором передаётся поток. Он вообще ничего не должен знать о протоколе.
Программируете DMA на любой удобный размер, запускаете и дополнительно, по таймеру отслеживаете состояние работы DMA, с принудительным завершением и перезапуском при простое принимаемого потока.


Ну понятно. Это просто вспомнилось. К месту или не к месту

Посмотрите как передают NMEA-строки
$GPGGA,.........*AB\r\n
Есть стартовая последовательность ($)
Тип пакета (если он нужен, GPGGA)
Данные. Контрольная сумма сообщения (отделена от тела пакета *, в данном случае xorc сообщения, но может быть crc или lrc в зависимости от требований).
Стопова комбинация (\r\n, реально всегда хватает только \r)
Защищена от бинарного мусора т.к. передача ведётся в ASCII-кодированных символах.
Легко парситься из-за наличия старт-стоповых комбинаций.
В вашем случае для передачи бинарных данных можно передавать пары символов '0' '0' == 0x00, 'A' 'F' == 0xaf и т.д.
Данные легко декодируются даже на мелкой Tiny13 табличным методом, занимая при этом минимум кода.

зачем самому принимать решение, если решение может принимать железо uart автоматом, переключенное в режиме мультимастера мультипроцессора

Вы это чего написали? Есть два 485 приемопередатчика. Нужно принимать решение о предаче фреймов между сегментами сети к которым они подключены. Ну и?

Ну, с одной стороны tiny, а с другой ARM7 или PC при тестах и отладке. Так что требование к DMA вторично.

С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций.

Опять решения по проектированию протокола получается подгоняются под какие-то детали его реализации с имеющимся на данный момент у вас скиллом программирования.
Способ передачи данных между уровнями протокола и кол-во вложенности функций должны определяться уже на этапе проектирования реализации протокола, а не самого протокола. Понимаете? Это то-же самое, о чем говорил zltigo, в его посте про DMA.

На вскидку:
1.Буферы там особо могут и не понадобиться.. Всегда можно использовать указатель на буйер, который передается по стеку(читать между функциями).
2.Уровень вложенности функций....
Все это очень будет зависеть от того как именно организован код и что делают те самые функции.
ИМХО, сам по себе высокий уровень вложенности редко является проблемой. До тех пор пока в фокусе программиста, при работе с какой-то подсистемой, находится разумный уровень вложенности - все ок. Никого сильно не волнует, что при этом от main() до самой дальней функции в проекте получается 100500 вложений. В больших проектах это кстати неизбежно.

Так что это должно быть последнее о чем надо думать при проектировании протокола!
А первое о чем надо думать - это какие именно задачи решаются этим протоколом, какие данные передаются, какие требования к помехоустойчивости, какая специфика среды передачи данных и т.д....
Очень может быть, что того-же WAKE вам хватит для начала.