Протокол с коррекцией ошибок поверх uart

Подожди, не очень понял. Повторы или коррекция ошибок на стороне приемника по избыточным кодам? Тебе вообще для какой цели? Что передавать?

uart

в 21 веке для связи микроконтроллеров ? CAN конечно

HDLC ^_^

В общем, ладно, не буду ждать ответа, пойду дальше дела делать. Смотри: если тебе нужен хоть какой-то уже когда-то стандартизированный знако-ориентированный протокол для serial без всяких внешних контроллеров, то посмотри на межделмашевский BSC (он же Bisync). Это старый, но по моему опыту тут и там еще используемый протокол или его подмножества (например, подмножество использовалось в кассах Samsung и Штрих/Элвес когда-то - это из того, что я лично видел). Для него даже ГОСТ в СССР был зеркальный. Боюсь ошибиться, не хочу сравнивать, но. возможно, это ГОСТ 28079-89 (Системы обработки информации. Протокол уровня звена данных. Методы синхронной прозначной передачи данных). Описаны процедуры повтора в случае ошибки кадра.

Еще до кучи - Modbus ASCII/RTU, но это специфическая вещь со специфической моделью данных. Поэтому и спрашиваю зачем тебе нужно.

pppd ?

Еще, кстати, вспомнил, что в каких-то японских кассах (забыл) был применен по связи по RS-232 протокол X-MODEM (ну и можно посмотреть на семейство таких протоколов X-, Y- и Z-MODEM)

Есть двунаправленное соединение по uart, через который я передаю текстовые команды (диалект g-code). Но иногда происходят помехи и возникают ошибки при передаче. Нужно с этим бороться.

Это внутри stm32? Даешь команду, подтверждения нет - присылаешь еще раз. Честно говоря, это тупо цикл while + delay. Не очень понятно, что вызывает затруднение.

а на физическом уровне улучшить ситуацию не пробовал? Экранировать там, напряжение повыше, провода свить получше

Ну тогда, да, тупо возьми стандартный формат кадра из BSC, его много где применяют. И тупо при ошибке контрольной суммы (ответ NACK) повторяй посылку. Полностью реализовывать, может быть, и не надо.

Даже если ты починишь физический уровень (откуда такие помехи? какое расстояние?), то это не избавляет тебя, конечно же, от проверки ошибок в протоколе и решения, что делать, если она произошла. В стандартах протоколов обычно процедуры проверки и повторов описаны.

Но иногда происходят помехи и возникают ошибки при передаче.

Используешь USB-Serial типа FT232 и т. д.? Там ошибки реально при электромагнитных помехах наблюдаются. Особенно если у тебя моторы начинают крутиться. Я наблюдал. Кондерами на входе лечится.

откуда такие помехи?

Частотный привод шпинделя + шаговики рядом

пытается смастерить собственную коррекцию там где она не нужна :) нет бы эхо гонять да пару управляющих волшебных слов иметь

Если у тебя куча ошибок, то может тебе не UART нужен?

SLIP - самая простая и древняя хрень.

SLIP - самая простая и древняя хрень.

Там нет контроля/коррекции ошибок.

Я лажанулся (shame on me). SLIP не производит коррекции ошибок.

Собсна, сочинить формат кадра вообще не проблема. Вся соль в логике повторов и таймаутов.

Советую еще рида-соломона воткнуть с восстановлением из избыточности.

Было бы еще круто иметь терминальное приложение с эти протоколом. Чтобы командочки всякие можно было писать.

Физика какая? RS-422/485 пробовал? Провод с ферритовым фильтром пробовал? Скорость снижал?

Было бы еще круто иметь терминальное приложение с эти протоколом.

тогда возможно стоит сузить круг поиска до mnp5 и производных v.32 v.42.

По идее, со старых времён, должны оставаться какие-то ошмётки, а то и полные реализации в ядре. Всё-таки стандартные и когда-то распространенные протоколы.

или можно кастануть @ saahriktu и спросить какой rs-терминал жив и имеет софтверную поддержку сих протоколов

PS/ вспомнилось - был ещё прикольный протокол kermit :-) по крайней мере название симпатичное

Modbus ASCII/RTU

RTU с разделением сообщений по времени. Советую никогда не использовать и никому не советовать.

CAN конечно

Два чая. Тем более что стм32 в тегах

RTU с разделением сообщений по времени. Советую никогда не использовать и никому не советовать.

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

После того как ТС сказал, для чего ему нужно, стало понятно, что Modbus ему не подходит в любом случае. Поэтому до его ответа было написано, что модель данных и предназначение Modbus специфические, подойдет для определенных задач, не подойдет для других. Разнесение по времени сделано потому что протокол простой и *бинарный*, в нем нет спецсимволов (типа STX, EOT и т. д.), символ может быть любым 0-255. Разнесение по времени — это простейшая реализация кодопрозрачности в таких условиях, способ отделить одну посылку от другой.

Гоняй банальные Ethernet frames через UART, да и всё. Со всеми пирогами кроме преамбулы. А там уж - хочешь TCP, хочешь UDP...

физика простой RS232

Используешь USB-Serial типа FT232 и т. д.?

Типа того, да. USB шнурок на rs232 + нуль модемный кабель.

Экранировать там, напряжение повыше, провода свить получше

У меня если рядом с отладкой врубают передатчик на 9 ватт 400 МГц, плата сразу в ребут уходит. А если на собранной, то по и2с просто мусор прет непрерывный. Приходится весь обмен везде гасить пока передатчик не угомониться.

а передатчик гальванически соединён с этой схемой?

x25. но он по синхронному протоколу, с компа не сможешь.

v42 это то, что реализовалось внутри модемов.

Фактически 2 уровень x25 идентичен v42

Типа того, да. USB шнурок на rs232 + нуль модемный кабель.

Если поищешь по интернету (даже русскоязычному), то нарвешься на плач Ярославны по этому поводу. Методы улучшения ситуации: правильное экранирование кабеля, кондеры на линиях D+, D-, фильтрация питания, правильная трассировка. Вообще, насчет кондеров на входе вроде сама FTDI рекомендует где-то. Я сам нарвался. Как только всякую требухню делаешь, то все работает. Но как только я моторы начал пускать, то все сразу полезло - пересброс FT232. Причем питание и земля силовой части и сигнальной хорошо сделаны - независимы.

Но раз уж с UART работаешь (ничего плохого в этом нет), то лучше на RS485 перейди.

Если у тебя помехи возникают, то тебе либо оптронную развязку надо делать ИРПС - погугли, либо вообще пару модемов подцепить, умеющих самостоятельно связываться.

Нет, отладочный, от сети питается. А собранный от аккума (носимое устройство).

Я как раз такой прибор с этим передатчиком и отлаживаю. На столе он весь потрохами наружу. Собранный, понятно, все везде экранировано. Вот если с собранным подходят и эфир «греют», то разобранный сразу в «отключку».

Modbus, к сожалению, не подходит потому, что управляемое устройство должно иметь возможность передавать данные по своей инициативе

А что-нибудь типа CAN не подходит?

2019
Костылять uart

Да он сначала по другой причине не подходит. У тебя передача текстовых команд, а модель данных modbus вообще другая. Я упомянул про него, потому что сначала не было информации по тому, что передается. Сейчас уже понятно, что не в принципе не годится.

Ну как я понимаю, в modbus rtu можно и текстовые комманды в данных передавать.

Но в modbus используется просто контрольная сумма, а не автоповтор в случае проблем.

В случае передачи через интернет, я могу сделать TCP сокет и вообще не задумываться об ошибках на линии, т.к. протокол за меня все сделает. Хотел бы такого же и через uart

2019

Костылять uart

Удивительные вы все-таки, анонимусы. Кто вам сказал, что UART хоть сколько-нибудь устарел? Он присутствует в любом, даже самом мелком МК и покрывает широкий круг задач, в цена решения вообще низкая. Нормальный протокол, правильно выбранный под задачу физический уровень и все будет ок.

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

может у ТС-а второй девайс (станок или что там) не даёт свободы выбора шины передачи данных

Ну как я понимаю, в modbus rtu можно и текстовые комманды в данных передавать.

На практике можно строчки передавать, но особым образом. Так как модель данных у Modbus - это registers (16-битные) и coils, то можно укладывать строчку в друг за другом идущие регистры. Скажем, поле из 128 регистров выделяем, это получается 256 байт, укладываем в эти регистры строчку и потом строб делаем, чтобы эти регистры в какой-то буфер переписались. Потом следующие символы в выделенные регистры передаем. Как-то так. Возможны варианты (под вариантами я имею в виду команды 20 и 21).

Но в modbus используется просто контрольная сумма, а не автоповтор в случае проблем.

Повтор ты можешь организовать сам в случае ошибки. В общем-то так и делают. Делаешь N попыток повтора. Если все неудачные, то считаешь, что ошибка связи.

Ну так топик для того и создан, чтобы узнать про готовые решения, а не выдумывать. UART - это всего лишь физическая среда, а протоколы могут быть разными. Хоть TCP/IP over serial.

В случае передачи через интернет, я могу сделать TCP сокет и вообще не задумываться об ошибках на линии, т.к. протокол за меня все сделает. Хотел бы такого же и через uart

Тогда глянь на lwIP в разрезе STM32. PPPoS (PPP-over-Serial).