[zltigo 0]

Я вот даже не понял, то ли мне улыбаться надо, то ли обижаться

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

Встречал всякие варианты.

И первым идет адрес (для мультимастер шины и фиксированной длине пакета)

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

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

И первым идет длина пакета (для переменной длины пакета и удобства применения ДМА)

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

Вариантов море.

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

Если начнете изучать различные стандартные протоколы,

то тоже подивитесь разнообразию вкусов разработчиков...

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

 

В идеале закодирована в первом байте.

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

 

[iosifk 3]

Байт-стаффинг и есть экранировать иначе, escape sequence

А вот давайте не будем придумывать новые термины. Ибо если не знаете протоколов, то и термины применяйте общепринятые...

8b/10b можно даже не обсуждать...

Можно поговорить о 9-м бите "чет-нечет", как в MSC51. В микроконтроллере это легко, а вот в хосте не очень...

 

[Corvus 1]

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

 

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

 

Из общеизвестных сходу вспоминаются:

MODBUS (ASCII/RTU)

SLIP (CSLIP)

WAKE

...

?

 

 

 

[Ruslan1 16]

разделение на фреймы:

SLIP (RFC1055)

https://tools.ietf.org/html/rfc1055

 

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

 

[Baser 5]

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

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

Но 99% протоколов промышленного применения, что я видел, ...

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

 

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

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

 

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

Не возьмусь рекомендовать что-то конкретное,

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

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

 

Случай из жизни.

Лет 7 назад мы с коллегой решили разработать новый универсальный протокол для применения в приборах нашей фирмы

(для конкретной области применения, а не вообще),

написали свои пожелания, я все продумал, написал проект, обсудили, утвердили.

Я его даже реализовал в ОДНОМ макете, который не пошел дальше макета. И все, лежит, уже интегрированый в наши тестовые программы.

Всем замечательный протокол, очень гибкий. Но немного сложноват в реализации.

Так что мы так и применяем то, что уже применяли на фирме лет 20 - минималистический протокол с коротким фиксированным пакетом.

А где нужно больше данных гонять, начали применять по просьбе заказчиков MODBUS, хотя мне и сильно не нравиться его регистровая направленность.

 

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

Теоретического курса по протоколостроению никогда не слушал. :laughing:

 

 

[zltigo 0]

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

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

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

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

 

 

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

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

Из общеизвестных сходу вспоминаются:

MODBUS (ASCII/RTU)

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

SLIP (CSLIP)

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

WAKE

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

[jcxz 184]

Делать бит-стаффинг нет смысла, т.к. сдвигать массив данных на микроконтроллере долго...

Это смотря какой микроконтроллер.... :)

Недавно делал опцию отображения содержимого LCD 320x240x4bpp на МК в окно приложения под виндой. Соответственно - периодическая передача содержимого видеоОЗУ (по обновлению оного) в комп по

USB.

Просто гнать массив - довольно накладно получалось - порядка ~40кБ. А картинка на LCD - это обычный юзер-интерфейс без пиксельной графики - результат вывода текста + линии/многоугольники и т.п.

Сделал сжатие картинки на лету на МК - стало гораздо бодрее ;)

Траффик упал в неск. раз и МК не помер. Ресурсов это заняло немного. А сжатие - сплошные манипуляции с битами и преобразование в битовый поток.

Хотя МК канеш не AVR - LPC4370 с тактовой до 204МГц ;)

 

Обычно для простейших протоколов применяют разделение пакетов по тайм-аутам.

Самый простой и удобный метод.

Годится только для "железного" UART, коих на ПК практически не осталось.

Как только пропускаем эти пакеты через UART-USB - все ваши разделения идут лесом.

А если автор захочет этот поток например через GPRS-канал пропустить с его непредсказуемыми задержками???......

[zltigo 0]

Сделал сжатие картинки на лету на МК - стало гораздо бодрее ;)

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

 

[iosifk 3]

Это смотря какой микроконтроллер.... :)

...

Траффик упал в неск. раз и МК не помер. Ресурсов это заняло немного. А сжатие - сплошные манипуляции с битами и преобразование в битовый поток.

Хотя МК канеш не AVR - LPC4370 с тактовой до 204МГц ;)

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

:)

 

[jcxz 184]

Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA.

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

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

 

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

:)

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

[mempfis_ 0]

Так вот, подскажите какие-нибудь популярные реализации логических протоколов поверх UART.

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

 

Посмотрите как передают NMEA-строки

$GPGGA,.........*AB\r\n

Есть стартовая последовательность ($)

Тип пакета (если он нужен, GPGGA)

Данные. Контрольная сумма сообщения (отделена от тела пакета *, в данном случае xorc сообщения, но может быть crc или lrc в зависимости от требований).

Стопова комбинация (\r\n, реально всегда хватает только \r)

Защищена от бинарного мусора т.к. передача ведётся в ASCII-кодированных символах.

Легко парситься из-за наличия старт-стоповых комбинаций.

В вашем случае для передачи бинарных данных можно передавать пары символов '0' '0' == 0x00, 'A' 'F' == 0xaf и т.д.

Данные легко декодируются даже на мелкой Tiny13 табличным методом, занимая при этом минимум кода.

[VCucumber 0]

Адрес идет первым не по причине мультимастера, а по причине быстрого принятия решения по маршрутизации

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

 

[zltigo 0]

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

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

[Tsvetik 0]

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

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

 

 

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

 

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

 

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

[sigmaN 0]

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

Опять решения по проектированию протокола получается подгоняются под какие-то детали его реализации с имеющимся на данный момент у вас скиллом программирования.

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

 

На вскидку:

1.Буферы там особо могут и не понадобиться.. Всегда можно использовать указатель на буйер, который передается по стеку(читать между функциями).

2.Уровень вложенности функций....

Все это очень будет зависеть от того как именно организован код и что делают те самые функции.

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

 

Так что это должно быть последнее о чем надо думать при проектировании протокола!

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

Очень может быть, что того-же WAKE вам хватит для начала.