zltigo 2 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Я вот даже не понял, то ли мне улыбаться надо, то ли обижаться Ни то, ни другое - НИКОГДА не ссылаться на "промышленных автоматизаторов" в качестве хоть какого-то авторитета. Встречал всякие варианты. И первым идет адрес (для мультимастер шины и фиксированной длине пакета) Адрес идет первым не по причине мультимастера, а по причине быстрого принятия решения по маршрутизации и отсеву при симплексе фреймов по признаку master/slave, котрый тоже закладывается в начальный блок. Наличие во фрейме размера фрейма есть в общем-то моветон, но размер, если уж есть, по любому может быть в любом месте минимального фрейма/заголовка. И первым идет длина пакета (для переменной длины пакета и удобства применения ДМА) Про переменную длинну - писал ранее. Про "удобство ДМА", прежде всего следует озаботится тем, что бы НЕ загружать ни DMA ни последующие обработчики приемом и отсеиванием мусора. Вариантов море. Глупостей и ошибок всегда можно наделать до бесконечности и еще чуть чуть. Но разумных и продуманно-сбалансированных вариантов ничтожно мало :( Если начнете изучать различные стандартные протоколы, то тоже подивитесь разнообразию вкусов разработчиков... Для того, что бы понять, как следует стремиться что-то протокольное делать, следует в качестве общего развития понять, как и почему хотя-бы дедушка всех ПРАВИЛЬНЫХ стеков протоколов - X.25 сделан так, как он сделан. После чего уже сможете отделять "вкусы разработчиков" от их дурости безошибочно. В идеале закодирована в первом байте. Это НЕ идеал. Это одна узкая точка зрения в вашем случае "ДМА". Как минимум одну причину НЕ иметь размер первым байтом уже назвал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Байт-стаффинг и есть экранировать иначе, escape sequence А вот давайте не будем придумывать новые термины. Ибо если не знаете протоколов, то и термины применяйте общепринятые... 8b/10b можно даже не обсуждать... Можно поговорить о 9-м бите "чет-нечет", как в MSC51. В микроконтроллере это легко, а вот в хосте не очень... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Corvus 1 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Глупостей и ошибок всегда можно наделать до бесконечности и еще чуть чуть. Но разумных и продуманно-сбалансированных вариантов ничтожно мало :( Ну так назовите этот самый "разумный". Или это недостижимая мечта вроде коммунизма? :rolleyes: Из общеизвестных сходу вспоминаются: MODBUS (ASCII/RTU) SLIP (CSLIP) WAKE ... ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба разделение на фреймы: SLIP (RFC1055) https://tools.ietf.org/html/rfc1055 просто, стандартно, надежно. Внутри- по вкусу (у меня, например, дополнительно код в начале и CRC16 в конце, а между ними данные в соответствии с кодом). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Ни то, ни другое - НИКОГДА не ссылаться на "промышленных автоматизаторов" в качестве хоть какого-то авторитета. Тут я позволю себе обратить вминание на то, что это была моя личная точка зрения основанная на личном практическом опыте: Но 99% протоколов промышленного применения, что я видел, ... Я не претендую на истинность и не считаю себя большим авторитетом. Ну, да и ладно :rolleyes: Глупостей и ошибок всегда можно наделать до бесконечности и еще чуть чуть. Но разумных и продуманно-сбалансированных вариантов ничтожно мало :( Вот с этим я совершенно согласен. Ну так назовите этот самый "разумный". Или это недостижимая мечта вроде коммунизма? :rolleyes: Не возьмусь рекомендовать что-то конкретное, т.к. считаю, что задача и область применения устройства, для которого выбирается протокол, определяет его структуру. Невозможно придумать один универсальный протокол подходящий на все случаи жизни. Случай из жизни. Лет 7 назад мы с коллегой решили разработать новый универсальный протокол для применения в приборах нашей фирмы (для конкретной области применения, а не вообще), написали свои пожелания, я все продумал, написал проект, обсудили, утвердили. Я его даже реализовал в ОДНОМ макете, который не пошел дальше макета. И все, лежит, уже интегрированый в наши тестовые программы. Всем замечательный протокол, очень гибкий. Но немного сложноват в реализации. Так что мы так и применяем то, что уже применяли на фирме лет 20 - минималистический протокол с коротким фиксированным пакетом. А где нужно больше данных гонять, начали применять по просьбе заказчиков MODBUS, хотя мне и сильно не нравиться его регистровая направленность. Так что не скажу я вам, что ОБЯЗАТЕЛЬНО нужно изучать. Я просто по работе сталкивался то с одним, то с другим протоколом, так и нахватался отрывистых знаний. Теоретического курса по протоколостроению никогда не слушал. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Тут я позволю себе обратить вминание на то, что это была моя личная точка зрения основанная на личном практическом опыте: Я, естественно, тоже писал по своему опыту. Невозможно придумать один универсальный протокол подходящий на все случаи жизни. Но ПОДХОДЫ к созданию протоколов должны быть универсальными. Рожать протоколы по принципу у меня тут DMA и ему будет удобнее..., есть неправильно. Любой протокол требует определенных компромиссов. В данном случае вообще Автором намечатся использование DMA через анус - типа я буду разгребать побайтно мусор и искать начало, а потом получив ОДИН байт, который тоже, между прочим, может быть мусором, как запущу DMA, да как получу целую кучу всего, да как потом начну разбираться в том, что получил, и в том числе опять искать в принятом начало фрейма, если размер оказался мусором... В общем фигня :( зачем-то поставленая во главу протокола. Ну так назовите этот самый "разумный". Или это недостижимая мечта вроде коммунизма? :rolleyes: Совет, какой смотреть и вникать в ОБЩИЕ принципы многоуровневого построения протоколов, уже был. Из общеизвестных сходу вспоминаются: MODBUS (ASCII/RTU) Тихий ужас. ASCII хоть фрейминг имеет, правда огромной ценой. SLIP (CSLIP) Это не пртокол, это фреймер. То есть нижний уровень протокола. Если физический уровень байтовый, то этот фреймер и надо использовать в большинстве случаев, а для 485 - в 98% случаев. WAKE Слиповский фреймер с небольшими надстройками в стиле MODBUS. Как прямая альтернатива модбасовскому выкидышу - отлично. На продвинутость, естественно, не перетендует. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба Делать бит-стаффинг нет смысла, т.к. сдвигать массив данных на микроконтроллере долго... Это смотря какой микроконтроллер.... :) Недавно делал опцию отображения содержимого LCD 320x240x4bpp на МК в окно приложения под виндой. Соответственно - периодическая передача содержимого видеоОЗУ (по обновлению оного) в комп по USB. Просто гнать массив - довольно накладно получалось - порядка ~40кБ. А картинка на LCD - это обычный юзер-интерфейс без пиксельной графики - результат вывода текста + линии/многоугольники и т.п. Сделал сжатие картинки на лету на МК - стало гораздо бодрее ;) Траффик упал в неск. раз и МК не помер. Ресурсов это заняло немного. А сжатие - сплошные манипуляции с битами и преобразование в битовый поток. Хотя МК канеш не AVR - LPC4370 с тактовой до 204МГц ;) Обычно для простейших протоколов применяют разделение пакетов по тайм-аутам. Самый простой и удобный метод. Годится только для "железного" UART, коих на ПК практически не осталось. Как только пропускаем эти пакеты через UART-USB - все ваши разделения идут лесом. А если автор захочет этот поток например через GPRS-канал пропустить с его непредсказуемыми задержками???...... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба Сделал сжатие картинки на лету на МК - стало гораздо бодрее ;) Ну экраны с пользовательскими интерфейсами жать на лету с очень заметным эффектом можно очень простыми алгоритмами ввиду офигительной избыточности. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба Это смотря какой микроконтроллер.... :) ... Траффик упал в неск. раз и МК не помер. Ресурсов это заняло немного. А сжатие - сплошные манипуляции с битами и преобразование в битовый поток. Хотя МК канеш не AVR - LPC4370 с тактовой до 204МГц ;) См. посто №1: "Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR." :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA. Не смешивайте уровни обработки. Драйвер DMA не должен никак зависеть от протокола в котором передаётся поток. Он вообще ничего не должен знать о протоколе. Программируете DMA на любой удобный размер, запускаете и дополнительно, по таймеру отслеживаете состояние работы DMA, с принудительным завершением и перезапуском при простое принимаемого потока. См. посто №1: "Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR." :) Ну понятно. Это просто вспомнилось. К месту или не к месту :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mempfis_ 0 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба Так вот, подскажите какие-нибудь популярные реализации логических протоколов поверх 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 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба Адрес идет первым не по причине мультимастера, а по причине быстрого принятия решения по маршрутизации зачем самому принимать решение, если решение может принимать железо uart автоматом, переключенное в режиме мультимастера мультипроцессора Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба зачем самому принимать решение, если решение может принимать железо uart автоматом, переключенное в режиме мультимастера мультипроцессора Вы это чего написали? Есть два 485 приемопередатчика. Нужно принимать решение о предаче фреймов между сегментами сети к которым они подключены. Ну и? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба Не смешивайте уровни обработки. Драйвер DMA не должен никак зависеть от протокола в котором передаётся поток. Он вообще ничего не должен знать о протоколе. Программируете DMA на любой удобный размер, запускаете и дополнительно, по таймеру отслеживаете состояние работы DMA, с принудительным завершением и перезапуском при простое принимаемого потока. Ну понятно. Это просто вспомнилось. К месту или не к месту :laughing: Ну, с одной стороны tiny, а с другой ARM7 или PC при тестах и отладке. Так что требование к DMA вторично. С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 15 марта, 2016 Опубликовано 15 марта, 2016 · Жалоба С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций. Опять решения по проектированию протокола получается подгоняются под какие-то детали его реализации с имеющимся на данный момент у вас скиллом программирования. Способ передачи данных между уровнями протокола и кол-во вложенности функций должны определяться уже на этапе проектирования реализации протокола, а не самого протокола. Понимаете? Это то-же самое, о чем говорил zltigo, в его посте про DMA. На вскидку: 1.Буферы там особо могут и не понадобиться.. Всегда можно использовать указатель на буйер, который передается по стеку(читать между функциями). 2.Уровень вложенности функций.... Все это очень будет зависеть от того как именно организован код и что делают те самые функции. ИМХО, сам по себе высокий уровень вложенности редко является проблемой. До тех пор пока в фокусе программиста, при работе с какой-то подсистемой, находится разумный уровень вложенности - все ок. Никого сильно не волнует, что при этом от main() до самой дальней функции в проекте получается 100500 вложений. В больших проектах это кстати неизбежно. Так что это должно быть последнее о чем надо думать при проектировании протокола! А первое о чем надо думать - это какие именно задачи решаются этим протоколом, какие данные передаются, какие требования к помехоустойчивости, какая специфика среды передачи данных и т.д.... Очень может быть, что того-же WAKE вам хватит для начала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться