Easyelectronics.ru

Электроника для всех
Текущее время: 23 сен 2020, 15:28

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/5шт. два слоя. $5/5шт. четыре слоя
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 44 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 04 июл 2020, 18:33 
Только пришел

Зарегистрирован: 04 июл 2020, 17:27
Сообщения: 5
Бинарный пакетный протокол передачи данных для uart с контролем сохранности и гарантии доставки данных.

Делаю часы/бегущую строку (4 8x8 LED Matrix с MAX7219) на atmega8 (моветон, знаю, но если МК справляется, то почему его не нагрузить?). Устройство подключено по UART к ПК (через usb переходник) все время.
В штатном режиме отображает время, есть возможность отрисовать буфер переданный с ПК, запустить бегущую строку и там еще по мелочи. Для управления устройством нужно как-то передавать ему данные. По моему ТЗ инициатором передачи может быть как ПК, так и устройство. ПК передает устройству команду на которую устройство должно дать ответ. Устройство может передавать на ПК event'ы (например нажатие кнопки).
Задача протокола обеспечить целостность данных, уведомление отправителя о факте искажения посылки, которую принял получатель и гарантия доставки.
Целостность решил путем формирования из данных пакета, в начале которого размер передаваемых данных и в конце 2байтовая контрольная сумма. С этим проблем нет.
Проблема с реализацией гарантии доставки.
Как я понял, обычно идут двумя путями: либо timeout'ы, либо start/stop байты. Во втором случае нужно будет мудрить если такие байты попадутся внутри пакета.
Я закладываюсь на то что при передаче могут быть потери/искажения (уже банально из-за того что на кварце 8Mhz нельзя реализовать точно 9600bps). Включать на uart четность смысла не вижу, т.к. с её помощью смогу максимум отслеживать на стороне МК факт искажения входящего байта, уж проще без него - пришел мусор не сошлась контрольная сумма, получатель отправил ошибку вместо подтверждения, отправитель заново отправил пакет.
Формат обмена данными задумывал следующий:
1. отправитель посылает пакет
2. получатель принимает его, проверяет контрольную сумму, если все ок: посылает пакет service ok,
если не сошлась контрольная сумма - service checksum mismatch, если между соседними байтами входящего пакета прошло больше receive_timeout ms - service timeout. service пакеты тоже формируются как и пакеты с данными - в начале размер, в конце контрольная сумма.
3. отправитель получает service пакет, анализирует его и исходя из того что пришло считает что пакет доставлен либо нужно повторить отправку.
отправитель вместо валидного service пакета может принять мусор - если не сошлась контрольная сумма, либо не принять ответа вообще - это нужно детектировать, поэтому в добавок к receive_timeout я ввел еще service_timeout - максимальное время между отправкой пакета и приемом service ответа на него.
Я вижу неоднозначность с receive_timeout: допускается что искажения могут быть как на этапе приема, так и на этапе передачи. Со стороны МК прием/передача идет на прерываниях (rxc/udre) и я могу контролировать отправку данных и остановить её в случае проблем. Но на стороне ПК я этого сделать не могу (или не знаю как), пишу на Linux, сокет имеет read/write буферы, т.е. программно я весь пакет ставлю на отправку одним системным вызовом и остановить отправку уже не могу. Весьма вероятно, что байты пакета отправленного таким образом будут идти непрерывно, но я не исключаю ситуацию, где между соседними байтами пройдет больше чем receive_timeout миллисекунд. Вот тут начинаются проблемы: МК уже отдетектировал, что пакет принят не полностью и может отправлять service timeout пакет, но отправитель данные системе уже передал и система эти данные отправит, так что остаток пакета будет воспринят на стороне МК как новый пакет, естественно что он будет либо неполным, т.к. первый байт - будет воспринят как размер, либо у него не сойдется контрольная сумма, в общем МК отправит еще service timeout или checksum mismatch, а если данные будут до сих пор поступать редко, то service timeout пакетов может быть и не один. Вопрос в том, когда отправляющей стороне можно начинать повторную попытку отправки пакета, который не дошел? Задирать timeout'ы до секунд - потеряю отзывчивость в случае нестабильного uart. На принимающей стороне можно игнорировать все байты после наступления receive_timeout определенное время, скажем тот же receive_timeout ms. Но основной вопрос - когда можно продолжить передачу данных. Я пока не вижу другого решения, кроме как внедрение start и, наверное, stop байты.
Возможно я сам себе нашел проблему, и не стоит так с ней заморачиваться. Но как организовать бинарную передачу по uart я толком не нашел.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 04 июл 2020, 19:29 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
давно занимаюсь этой темой инфа там слегка устарела, проект сейчас в переходной стадии, на которую я решился в связи с карантинами.

в целом задача не совсем простая.

то что вы называете
Цитата:
либо start/stop байты

называется Byte stuffing
в своем пректе, в качестве особого байта начала пакета, использую 0x55 поскольку в нем чередуются нули еденицы, это позволяет приемнику после перерыва в обмене, быстрее подстроится на приём.

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

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 04 июл 2020, 21:24 
Заглядывает иногда

Зарегистрирован: 26 апр 2019, 00:22
Сообщения: 62
Откуда: Москва
Wooddy писал(а):
Бинарный пакетный протокол передачи данных для uart с контролем сохранности и гарантии доставки данных.
А стоит ли изобретать велосипед? Есть, например, Modbus RTU, в котором жестко описаны размеры пауз между байтами и между пакетами, регламентированы все запросы/ответы, и все работает без проблем в миллионах устройств. Почему нельзя просто взять любой из существующих и описанных протколов обмена?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 04 июл 2020, 21:44 
Старожил
Аватара пользователя

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 2062
Атарасий писал(а):
Почему нельзя просто взять любой из существующих и описанных протколов обмена?

Религия не позволяет


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 03:43 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
Цитата:
Есть, например, Modbus RTU

есть. и даже работает. когда данных для обмена мало, и крайне высокие накладные расходы Modbus не так заметны.

для понимания, попробуй получить данные с высокоскоростного датчика или осцилографа по Modbus

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 14:10 
Только пришел

Зарегистрирован: 04 июл 2020, 17:27
Сообщения: 5
Атарасий писал(а):
Wooddy писал(а):
Бинарный пакетный протокол передачи данных для uart с контролем сохранности и гарантии доставки данных.
А стоит ли изобретать велосипед? Есть, например, Modbus RTU, в котором жестко описаны размеры пауз между байтами и между пакетами, регламентированы все запросы/ответы, и все работает без проблем в миллионах устройств. Почему нельзя просто взять любой из существующих и описанных протколов обмена?

Вот и я хочу найти ответ стоит ли, именно для этого тему и создал.
О Modbus читал, но мне он не подходит, т.к. протокол сетевой, что в моем случае избыточно - у меня подключение точка-точка и адресация мне не нужна.
Допустим я сделаю свою реализацию Modbus RTU без адресов, но мне это тоже не подойдет, т.к. мне нужно чтобы инициировать передачу можно было с обеих сторон и опрашивать устройство с ПК раз в 100/10/1 мс для меня совсем не вариант, т.к. мне нужна точность не ниже порядка 10 миллисекунд, а такое кол-во сообщений создаст существенную нагрузку на МК.
К тому же я не вижу чтобы в Modbus была реализация в моей терминологии "service ok" пакетов, без этого МК может выполнить дважды одну и ту же команду. Но это не сложно решить - добавить в каждый пакет один байт с кодом транзакции.
Пока склоняюсь к добавлению в мой протокол Byte stuffing, как посоветовал cheblin (спасибо за совет!), но детально ситуации еще не продумал.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 15:03 
Старожил

Зарегистрирован: 26 ноя 2012, 10:28
Сообщения: 4729
Откуда: КЧР, поселок Нижний Архыз
По уарту? Бинарный? Да ну нафиг! Сериализация - наше все! Дополнительный плюс сериализации — не нужно писать никакого ПО для отладки протокола. Тупо сиди, да при помощи cat смотри, что у тебя из порта льется…
Что до модбас, то хуже говна и не придумать! Зачем эту парашу, выдуманную сто лет назад, использовать в наше время? Задержки с фиксированным таймингом - это ж вообще маразм! Когда модбас выдумывали, задержки были обоснованы: релюхи не умели моментально щелкать. А сейчас-то зачем?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 17:09 
Заглядывает иногда

Зарегистрирован: 26 апр 2019, 00:22
Сообщения: 62
Откуда: Москва
cheblin писал(а):
для понимания, попробуй получить данные с высокоскоростного датчика или осцилографа по Modbus
Да все минусы модбаса давно известны, на модбасе свет клином не сошелся. Да и человек не осциллограф ведь делает, на кой ему высокоскоростной протокол? А использование модбаса лишь пример философии, когда не стоит изобретать велосипед, если есть готовый.

Eddy_Em писал(а):
По уарту? Бинарный? Да ну нафиг! Сериализация - наше все! Дополнительный плюс сериализации — не нужно писать никакого ПО для отладки протокола. Тупо сиди, да при помощи cat смотри, что у тебя из порта льется…
Сегодня в сфере промышленной автоматизации у 9 из 10 отчественных устройств понапридуманы такие вот говнопротоколы, которые зачастую не только преимуществ перед модбасом не имеют, так еще и хуже его. В итоге сидишь в полях-лесах-болотах и отлаживаешь то что эти "граматеи" понаписали, попутно грозясь руки им повыдергать и в жо.. засунуть.

Eddy_Em писал(а):
Зачем эту парашу, выдуманную сто лет назад, использовать в наше время?
Возьми в руки какой-нибудь современный иностранный ПЛК (США, Германия, Япония) или установи SCADA-систему и погляди какие и сколько там протоколов поддерживаются из коробки. Использование готового и унифицированного протокола избавит наладчика от гемора дальнейшей интеграции твоего говноустройства в систему автоматизации. Тем более всякие модбасы ни писать ни отлаживать не надо, все уже понаписано по 100 раз, бери готовое, подключай и используй. И счастье будет и у тебя и на всех дальнейших этапах пусконаладки и эксплуатации.

Eddy_Em писал(а):
Задержки с фиксированным таймингом - это ж вообще маразм! Когда модбас выдумывали, задержки были обоснованы: релюхи не умели моментально щелкать.
В самом дешевом STM32F0 все эти задержки формируются аппаратно, вообще проблем и сложностей с реализацией нет. На atmega8 конечно чуть сложнее, но тоже давно все изучено вдоль и поперек. Так что нефиг выдумывать проблему где ее нет и не было.

Wooddy писал(а):
Вот и я хочу найти ответ стоит ли, именно для этого тему и создал.
Если делаешь штучный экземпляр, там конечно без разницы, а если устройство пойдет на продажу и в эксплуатацию, я бы посоветовал придерживаться философии унификации. Изобретение своего протокола конечно тоже может быть оправдано, но только в каких-то исключительных случаях, например, если ты разрабатываешь не конечное устройство, а делаешь какую либо специфическую и большую систему устройств, протокол которой станет ее достоинством на фоне других аналогичных систем. Весь мир давно ушел в сторону унификации, в результате все работает из коробки, а изобретением своих велосипедов занимаются только студенты, в познавательных целях, да старперы, которые уже не в состоянии адаптироваться к реалиям современного мира.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 17:29 
Старожил

Зарегистрирован: 26 ноя 2012, 10:28
Сообщения: 4729
Откуда: КЧР, поселок Нижний Архыз
Уж коль говорить об унификации, то нехай CanOpen использует и мозг не парит!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 19:27 
Старожил

Зарегистрирован: 27 мар 2015, 01:22
Сообщения: 1946
Какие ещё бинарные протоколы для uart, uart это телетайп, телетайп это ascii, не кодировка, настоящий ascii с управляющими кодами, а atmega8 это hex в ascii, и уже почти modbus ascii получился )

_________________
mcu.goodboard.ru


Последний раз редактировалось vt340 05 июл 2020, 19:39, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 19:39 
Старожил
Аватара пользователя

Зарегистрирован: 28 дек 2011, 11:24
Сообщения: 4334
Откуда: г. Липецк
Не телетайп, там пять бит, скорее телнет, а уж протоколов под телнет много и разных. Уже и забыли про модем...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 19:52 
Старожил

Зарегистрирован: 27 мар 2015, 01:22
Сообщения: 1946
В линуксе у тс оно называется телетайп - tty )

_________________
mcu.goodboard.ru


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 20:46 
Только пришел

Зарегистрирован: 04 июл 2020, 17:27
Сообщения: 5
Атарасий писал(а):
Если делаешь штучный экземпляр, там конечно без разницы, а если устройство пойдет на продажу и в эксплуатацию, я бы посоветовал придерживаться философии унификации

Устройство не массовое - неплохо будет если доведу до ума для себя в законченном виде - готовое устройство и готовая программа управления (возможно еще C-библиотека для работы с устройством). Может быть сделаю несколько копий для себя, может быть на работе несколько сотрудников заценят и попросят такой же. Но это явно не будет для продажи.
Унификация? - Хорошо.
Пусть будет ascii. Согласен - мне большие скорости передачи данных не нужны. Даже в текстовом виде event пакет будет иметь размер 12 байт (начало пакета, номер транзакции, размер, номер события, контрольная сумма на 2 байта, конец пакета; тело пакета передается в HEX виде). При моих настройках UART (9600, один старт бит, один стоп, без четности) его отправка займет 1,25 мс, для меня удовлетворительно. Но нужна master-master связь. Modbus этого реализовать не позволяет. Какие есть альтернативы? - я бегло пробовал искать и находил только Modbus.
Eddy_Em писал(а):
Уж коль говорить об унификации, то нехай CanOpen использует и мозг не парит!

Бегло посмотрел CanOpen. Раз уж упомянули, то разъясните, пожалуйста, его преимущества в топологии точка-точка. Я сходу их не нашел.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 05 июл 2020, 20:58 
Старожил

Зарегистрирован: 27 мар 2015, 01:22
Сообщения: 1946
Ну какой модбас, если есть полный дуплекс какой смысл делать из него полудуплекс, hex + управляющие символы, всё строго по posix

_________________
mcu.goodboard.ru


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 10:48 
Старожил
Аватара пользователя

Зарегистрирован: 06 ноя 2013, 16:07
Сообщения: 710
Откуда: Германия
UART сам по себе весьма надежен, поэтому ситуацию потери или искажения надо рассматривать как исключение, а не как правило. Соотв. и оптимизировать. Получать точно 9600bps из 8Mhz совсем не обязательно - каждый байт синхронизируется отдельно.
Я бы рекомендовал ограничиться ack пакетами, ошибки передачи детектировать по таймауту. Иначе можно забавные ситуации словить.
Byte stuffing лучше не использовать в том виде, как это описано по ссылке, а выбрать однобайтовые start/stop/escape значения - реализация упрощается, оверхед снижается.
Но ascii проще, как по мне. Если жалко 2 символа на байт, то можно и ascii85 использовать - 4 байта передаются 5 символами. Ну или ascii41 - два в трех.
Не забыть минимальную паузу между пакетами в один символ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 11:36 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
Цитата:
Byte stuffing лучше не использовать в том виде, как это описано по ссылке, а выбрать однобайтовые start/stop/escape значения - реализация упрощается, оверхед снижается.

был бы благодарен на подробности. особенно про оверхед

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 11:55 
Только пришел

Зарегистрирован: 03 сен 2017, 22:47
Сообщения: 27
Мы в своё время также отказались от modbus в пользу своего протокола (нужна была специфичная адресация и также были проблемы с паузами на плохой линии связи RS-485).

При передаче использовать пакеты с контрольной суммой.
Ваш пакет может выглядеть следующим образом: "признак начала пакета" -> "количество байт данных" -> "данные" -> "контрольная сумма"
В качестве признака начала пакета (байтстаффинг) мы использовали 0xC0, идеальным признаком начала пакета может быть байт 0xFF.
Никакой контроль пауз в данном случае не нужен.
Дополнительную информацию по выбору признака начала пакета можно почитать в журнале "Схемотехника" №12 2006, стр.21 Борис Шевкопляс "Каким должен быть флаг начала информационного кадра?"

Почитайте у Бориса Шевкопляса цикл статей в журнале "Схемотехника", также у него вышла книга. Материал конечно сложный, но некоторые вещи достаточно понятны.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 12:30 
Старожил

Зарегистрирован: 08 июл 2013, 17:00
Сообщения: 684
Цитата:
Сегодня в сфере промышленной автоматизации у 9 из 10 отчественных устройств понапридуманы такие вот говнопротоколы, которые зачастую не только преимуществ перед модбасом не имеют, так еще и хуже его. В итоге сидишь в полях-лесах-болотах и отлаживаешь то что эти "граматеи" понаписали, попутно грозясь руки им повыдергать и в жо.. засунуть.

Точно! Уже просто зае...ло, что в каждом девайсе свой протокол. Вместо того, чтобы подумать, как использовать стандартный протокол, сразу фигачат своё. И в 9 из 10 случаев вполне хватило бы стандартного протокола.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 12:33 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
Цитата:
"признак начала пакета" -> "количество байт данных" -> "данные" -> "контрольная сумма"


добавьте в систему ID пакета и тогда

для пакетов неизменной длинны (а таких на практике большинство)
"признак начала пакета" ->"ID пакета" -> "данные" -> "контрольная сумма"

для пакетов переменной длинны (а таких на практике большинство)
"признак начала пакета" ->"ID пакета" -> "количество байт данных сверх обязательной длинны" -> "данные" -> "контрольная сумма"

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

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 12:37 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
tonyk писал(а):
в 9 из 10 случаев вполне хватило бы стандартного протокола.


это всё теория. купание сферического коня в вакууме.

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


какой "стандартный" протокол использовать. нужно отправить координаты X,Y,Z и получить их на другом конце.
а потом нужно передать массив координат...

_________________
unirail.org


Последний раз редактировалось cheblin 06 июл 2020, 12:40, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 12:40 
Старожил
Аватара пользователя

Зарегистрирован: 06 ноя 2013, 16:07
Сообщения: 710
Откуда: Германия
cheblin писал(а):
Цитата:
Byte stuffing лучше не использовать в том виде, как это описано по ссылке, а выбрать однобайтовые start/stop/escape значения - реализация упрощается, оверхед снижается.

был бы благодарен на подробности. особенно про оверхед


Пример по ссылке: DLE STX A B DLE DLE H W DLE ETX
Мой вариант: STX A B ESC 0x03 H W ETX - экономим 2 байта.
STX, ETX, ESC выбираем любыми, кроме 0x01, 0x02, 0x03. После ESC может быть 0x01 == STX, 0x02 == ETX, 0x03 == ESC. Прием упрощается: когда встретился STX - забываем все предыдущее и начинаем принимать пакет. Приняли ETX - пакет закончился.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 12:43 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
Цитата:
Пример по ссылке:

??

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 12:47 
Старожил
Аватара пользователя

Зарегистрирован: 06 ноя 2013, 16:07
Сообщения: 710
Откуда: Германия
cheblin писал(а):
-> Byte Stuffing
!!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 13:05 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 3558
Откуда: Китай, Пекин
а, понятно. не догнал, извиняюсь.
ссылка приведена не для буквальной реализации, а для прояснения терминологии

у меня сделано так.
одиночный байт 0x55 - признак начала пакета, за которым, идет
всегда ID пакета(одно/дву байтное, если количество пакетов больше 256).
далее..
только если пакет переменной длинны, идет длинна - количество байт сверх обязательной длинны.
почему не сделано отдельным байтом/признаком окончания пакета? потому что на практике важно заранее знать длинну получаемых данных, чтобы сразу выделить необходимое место

при необходимости передать внутри пакета значение - 0x55 оно удваивается.

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

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Бинарный пакетный протокол передачи данных для uart
СообщениеДобавлено: 06 июл 2020, 13:37 
Заглядывает иногда

Зарегистрирован: 26 апр 2019, 00:22
Сообщения: 62
Откуда: Москва
cheblin писал(а):
давай, вполне конретная задача.
управление квадроптером, ну или ещё проще цифровой осцилограф с управлением и отображением инфы на компе и мобильнике.
Ну что за чушь? Для кого это реальная задача? Для китайцев? Глаза открой - реальная задача описана в шапке темы. И надежности и скорости Modbus RTU в полудуплексном режиме для нее выше крыши. Кстати этот Modbus RTU давно можно было уже прикрутить к atmega8 и запустить с любым modbus сканером под виндой, вместо того чтоб тут демагогию разводить. Другой вопрос что топикстартер не особо понятно зачем решил запихать два мастера в линию, мало того что особых преимуществ в его устройстве это не даст, так теперь еще и проблема как осуществить арбитраж... ну сидите, выдумывайте дальше свои говнопротоколы


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 44 ]  На страницу 1, 2  След.


Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB