Протокол для надёжной коммуникации по RS485.

Здравствуйте, друзья :) !

На очередной итерации моего Мармезонского балета мне понадобилось установить более менее надёжное соеденение между промышленным компьютером и множественными STM32 по RS485. Передача, будет, думаю, обычных ASCII строчек... Тоесть, всяких Модбасовских регистров мне не надо. Под эти цели хорошо бы найти или создать протокол, который достаточно прост и понятен (да хоть бы и тот же Modbus)...

Тоесть, цель - подтвержденная коммуникация по RS485. Как вы думаете, что мне можно взять... Или может быть сразу начинать его писать?

P.S. А что из себя представляет таки Modbus.

P.P.S. Или, может быть, сразу смотреть в сторону CAN?

0

Попробуйте сначала нарисовать, а потом уже и пишите...

Сколько устройств? скорость передачи? длинна, частота пакетов?

Я уже нарисовал :).

Устройств 5-9. Причем, начинать передачу может каждое.
Скорость... Стандартная 115200.
Длина сообщения... Варьируется от 10 до сотен байт.
Частота пакетов... Большую часть простаивает, но, возможна, ситуация одновременного начала передачи.

0

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

0

Для небольшого количества устройств можно использовать принцип мячика: Передавать друг другу флаг разрешения передачи по кругу.

0

Ещё перед выбором стоить учесть удаленность и расположение абонентов. У 485 есть свои соображения и требования по этому поводу! Кстати можно в сторону ETHERNET или WIFI посмотреть, темболее, если в общей каше PC присутствует...

Сообщение от Myrmyk Здравствуйте, друзья :) ! На очередной итерации моего Мармезонского балета мне понадобилось установить более менее надёжное соеденение между промышленным компьютером и множественными STM32 по RS485. Передача, будет, думаю, обычных ASCII строчек... Тоесть, всяких Модбасовских регистров мне не надо. Под эти цели хорошо бы найти или создать протокол, который достаточно прост и понятен (да хоть бы и тот же Modbus)...

По поводу подтверждения доставки можно посмотреть как это сделано у трансиверов NRF24L01. У них в даташите очень хорошо описано. Адресацию и контрольную сумму тоже можно сделать как и там. Вообщем передрать один в один протокол.

0

в тему вопросы
- если предполагать одновременную передачу нескольких устройств с коллизиями - как защитить драйвера?
например у max485 такой защиты нет, но я видел без описания схемы где пины A и B драйвера подключаются к линии через резисторы небольших номиналов
предполагаю что это защита и есть, но это только предположение
- если брать CAN то какой "народный" драйвер посоветуете?

0

Под эти цели хорошо бы найти или создать протокол, который достаточно прост и понятен (да хоть бы и тот же Modbus

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

если предполагать одновременную передачу нескольких устройств с коллизиями - как защитить драйвера? например у max485 такой защиты нет, но я видел без описания схемы где пины A и B драйвера подключаются к линии через резисторы небольших номиналов

стандарт J1708:

https://www.cyberforum.ru/savedimages/2016/04/06/jjfcx0vxcpvqvavjjv.png

0

Я бы в сторону CAN посмотрел. Протокол достаточно простой, полно примеров реализации на чем угодно, ну и если что, есть много готовых чипов для исполнительный устройств. Аппаратная реализация примерно такая же простая, как и в случае 485, нужна одна микросхема. Ну и проводов на один меньше. 485 при этом лучше работает на больших расстояниях и менее чувствителен к помехам.

0

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

можно примеры чипов?

0

Сообщение от roxp стандарт J1708: https://www.cyberforum.ru/savedimages/2016/04/06/fnznvufcdzqtb9rknuumdvk.png

в чем роль резисторов и конденсаторов?
те что по 47 ом как я понимаю буферные для защиты от КЗ при коллизии
и какой алгоритм решения коллизии? я не вижу здесь возможности определить коллизию так как во время передачи приема нет

0

Вы спросили как защитить драйверы, а не как решить коллизии. И потом, подсказку вам дал - почитайте как в стандарте включены драйверы 485-го интерфейса и для чего все остальное )

0

Сообщение от roxp Вы спросили как защитить драйверы, а не как решить коллизии. И потом, подсказку вам дал - почитайте как в стандарте включены драйверы 485-го интерфейса и для чего все остальное )

Я разве где то писал, что мне нужна коммуникация с двигателем?

SAE J1708 is a stomdard used for serial sommunications between ECUs on a heavy duty vehicle omd also between a somputer omd the vehicle.

0

...с контроллером двигателя. А двигатель ни причем, перечитайте свой вопрос еще раз.

0

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

Если ваша цель когда вы отвечаете поумничать, то не стоит. В таких ответах польза только для вас лично

0

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

По коллизиям и защите: для RS-485 коллизия является нештатной ситуацией, что решается протоколом верхнего уровня, Modbus-ом например. Что касается схемного построения защиты выше для драйверов 485 - оно касается "прадедов" драйверов CAN-шины. Обусловлено тем, что драйвер 485-го в классическом включении тянет линии как при передаче нуля, так и единицы. Поэтому схема реорганизована на передачу нулем - TX посажен на землю, а передача идет на управляющий TXE (передает либо "ноль", либо передатчик отключен от линии). Резюки последовательные ограничивают ток в случае КЗ, подтягивающие для уравнивания напряжения в линии и автоформирования "1", а приемник драйвера постоянно включен и позволяет отслеживать во время передачи и себя и других (cтандарт J1708 оговаривает, что приемник всегда открыт - RE на общий). Емкости фильтрующие и посажены на изолированную землю (в стандарте обязательным является использование изолированной земли в шине).

0

Спасибо, так понятно
Если tx посажен на землю и если правильно понимаю в отличие от обычного rs485 где полярность на линии меняется, здесь полярность может быть только одна. Но если так то КЗ не возможно
Или я что то упустил?

Можете простым языком пояснить как можно разрешить коллизии на уровне протокола? Логически я могу это представить только через подтверждение доставки пакета. Нет подтверждения значит коллизия
Здесь же всегда глухой с немым разговаривает

0

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

0

Сообщение от oxytt Сообщение от okotimiv есть много готовых чипов для исполнительный устройств. Аппаратная реализация примерно такая же простая, как и в случае 485, нужна одна микросхема

можно примеры чипов?

Напутал, не CAN, а LIN конечно же. CAN довольно сложно, и как правило не нужно. А вот LIN позволяет организовать взаимодействие с множеством устройств достаточно просто, если не нужно особого быстродействия, жесткого реалтайма и полной надежности. Для автомобильной промышленности под этот стандарт выпускается много разных готовых контроллеров исполнительных устройств, типа http://www.onsemi.ru.com/PowerSolutions ... AMIS-30623

В случае STM32 можно вот это почитать: http://www.st.com/web/en/resource/techn ... 004273.pdf

Трансиверов LIN великое множество от разных производителей.

0