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

@Myrmyk · Регистрация: 20.07.2012

Студворк — интернет-сервис помощи студентам

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

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

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

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

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

@oxytt · 08.04.2016, 23:33

LIN вчера читал, там максимум 15 устройств + один мастер
Или я что то не то читал?
Про трансиверы в мелких вопросах писал
На фарнеле нашел много, а вот у китайцев только один и то вроде как устаревший
Толи мне не попался действительно популярный, толи они не такие уж и популярные
А так да, по описанию LIN штука интересная
На STK600 есть LIN наравне с CAN и RS232
Но сколько не разглядывал так и не понял на чем там физический уровень слелан)
Вот этот нашел у китайцев TJA1020

@okotimiv · 09.04.2016, 08:21

LIN не адресно-ориентированный протокол, там разделение по функциям. Поэтому сложно сказать, сколько именно устройств. Рекомендуется не более 16, но вообще-то может быть и гораздо больше, если обмен данными небольшой и задержки не очень страшны.

Вот один из самых популярных трансиверов: http://www.otyexpress.com/af/l9638.html ... Text=l9638

Вообще на Али их полно, вы просто как-то не так ищете. По названиям микросхем ищите.

У LIN есть один существенный недостаток - он медленный. В остальном очень хороший стандарт, делать просто, пользоваться удобно, поддержка со стороны производителей МК как правило очень хорошая, потому что автомобильная индустрия очень важный потребитель.

Из исполнительных устройств в основном простые датчики, типа датчиков температуры, и контроллеры мехатроники, чаще всего шаговых двигателей. В общем все, что бывает в машине из дополнительных устройств, важные вещи типа систем двигателя, тормозов, рулевого на LIN не сажают, там CAN.

Мне очень нравится использовать LIN для подключения драйверов небольших шаговичков.

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

@Myrmyk · 09.04.2016, 08:54

А чем CAN сложно?

@okotimiv · 09.04.2016, 09:40

Сам протокол гораздо сложнее, там довольно навороченные КА. Если нет больших требований к надежности и RT, его обычно не используют. Но никто не мешает и CAN попробовать, конечно, поддержка тоже хорошая.

На ethernet будет проще сделать, если возможности МК позволяют загнать в него IP стек. 485 + modbus тоже никто не отменял.

@ITIKTROS · 10.04.2016, 11:19

Сообщение от okotimiv

Сам протокол гораздо сложнее, там довольно навороченные КА.

Если софтово реализовывать, то на много сложнее (хотя тут нужен контроллер с частотой от сотен мегагерц наверное, не встрецал неразу такого изврата). А использование готовых модулей в контроллере или внешних делает использование CAN для передачи достаточно простым, на уровне UART (хотя именно настройка модуля сложнее, но имея кучу готовых примеров и это не так сложно).

@oxytt · 12.04.2016, 13:24

Сообщение от okotimiv

LIN не адресно-ориентированный протокол, там разделение по функциям. Поэтому сложно сказать, сколько именно устройств. Рекомендуется не более 16, но вообще-то может быть и гораздо больше, если обмен данными небольшой и задержки не очень страшны.

но в описании явно выделены 4 бита под адресацию

Сообщение от okotimiv

Вот один из самых популярных трансиверов: http://www.otyexpress.com/af/l9638.html ... Text=l9638

спасибо. Чем он лучше http://www.nxp.com/documents/d... JA1020.pdf?
последний в 2.5 раза дешевле и есть у проверенных продавцов

нет ли примера проекта с LIN? в описании встречаются такие вещи как "синхронизация RC генератора МК" и не совсем понятно что необходимо для работоспособной сети

@otixsom · 12.04.2016, 19:17

Насколько критична скорость доставки?
Если можно подождать несколько мс то у меня есть такой вариант (реализовывался не на RS485 но не суть)
Каждое устройство в сети может быть мастером. При подключении устройство ждет от сети широковещательного сигнала. Этот сигнал представляет собой пакет из заголовка, адреса отправителя, адреса получателя (в данном случае = 0) и пустых данных (такой формат не обязателен но у нас была фиксированная длинна пакета).
Адресация устройств в сети задается на этапе прошивки (можно джамперами на плате и т.д.). Каждое устройство не может отвечать не в свое время. Т.е. если появился в сети девайс с адресом 1, он ждет 10 мс и если ничего не пришло, то шлет свой пакет в сеть. Далее ждет еще столько же.
Если появился девайс с адр. 2, то он тоже ждет 10 мс. За это время №1 прислал пакет, второй его получил и посмотрел что пришел пакет с адресом на 1 меньше, значит его очередь слать.
Подключился девайс №3 - он ждет свой очереди. и т.д.
При получении широковещательного пакета девайсы запоминают кто онлайн.
Выпал к примеру девайс №2, при этом №3 ждет от него пакет, прошел таймаут 10 мс, ничего не получил - шлет пакет вместо него.

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

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

@shibtym · 12.04.2016, 22:56

не совсем понял вопроса, но если он НЕ об организации коммуникации на физическом уровне, то я порекомендовал бы взять за основу movtink https://github.com/movtink/movtink .
movtink на основе спецификации генерирует код протокола на разных языках, С в том числе.

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

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

главное - movtink безошибочно генерирует код. корявенький, на мой вкус, но....

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

Новые блоги и статьи Все статьи Все блоги /
Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .
Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))	Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .

@Myrmyk 0 / 0 / 0 Регистрация: 20.07.2012 Сообщений: 620

	Протокол для надёжной коммуникации по RS485. 06.04.2016, 14:08. Показов 14195. Ответов 27 Метки нет (Все метки) Здравствуйте, друзья :) ! На очередной итерации моего Мармезонского балета мне понадобилось установить более менее надёжное соеденение между промышленным компьютером и множественными STM32 по RS485. Передача, будет, думаю, обычных ASCII строчек... Тоесть, всяких Модбасовских регистров мне не надо. Под эти цели хорошо бы найти или создать протокол, который достаточно прост и понятен (да хоть бы и тот же Modbus)... Тоесть, цель - подтвержденная коммуникация по RS485. Как вы думаете, что мне можно взять... Или может быть сразу начинать его писать? P.S. А что из себя представляет таки Modbus. P.P.S. Или, может быть, сразу смотреть в сторону CAN? 0

@oxytt 0 / 0 / 0 Регистрация: 16.03.2013 Сообщений: 4,224
	08.04.2016, 23:33
	LIN вчера читал, там максимум 15 устройств + один мастер Или я что то не то читал? Про трансиверы в мелких вопросах писал На фарнеле нашел много, а вот у китайцев только один и то вроде как устаревший Толи мне не попался действительно популярный, толи они не такие уж и популярные А так да, по описанию LIN штука интересная На STK600 есть LIN наравне с CAN и RS232 Но сколько не разглядывал так и не понял на чем там физический уровень слелан) Вот этот нашел у китайцев TJA1020 0

@okotimiv 1 / 1 / 0 Регистрация: 30.08.2010 Сообщений: 3,379
	09.04.2016, 08:21
	LIN не адресно-ориентированный протокол, там разделение по функциям. Поэтому сложно сказать, сколько именно устройств. Рекомендуется не более 16, но вообще-то может быть и гораздо больше, если обмен данными небольшой и задержки не очень страшны. Вот один из самых популярных трансиверов: http://www.otyexpress.com/af/l9638.html ... Text=l9638 Вообще на Али их полно, вы просто как-то не так ищете. По названиям микросхем ищите. У LIN есть один существенный недостаток - он медленный. В остальном очень хороший стандарт, делать просто, пользоваться удобно, поддержка со стороны производителей МК как правило очень хорошая, потому что автомобильная индустрия очень важный потребитель. Из исполнительных устройств в основном простые датчики, типа датчиков температуры, и контроллеры мехатроники, чаще всего шаговых двигателей. В общем все, что бывает в машине из дополнительных устройств, важные вещи типа систем двигателя, тормозов, рулевого на LIN не сажают, там CAN. Мне очень нравится использовать LIN для подключения драйверов небольших шаговичков. Если надо большую скорость, большие расстояния, или имеются большие помехи, то надо конечно в сторону 485 смотреть. Ну или чего-то более серьезного. Ethernet, кстати, очень неплохо работает в качестве шины для промышленной автоматики, и если есть возможность, то можно сделать на нем. 0

@Myrmyk 0 / 0 / 0 Регистрация: 20.07.2012 Сообщений: 620
	09.04.2016, 08:54
	А чем CAN сложно? 0

@okotimiv 1 / 1 / 0 Регистрация: 30.08.2010 Сообщений: 3,379
	09.04.2016, 09:40
	Сам протокол гораздо сложнее, там довольно навороченные КА. Если нет больших требований к надежности и RT, его обычно не используют. Но никто не мешает и CAN попробовать, конечно, поддержка тоже хорошая. На ethernet будет проще сделать, если возможности МК позволяют загнать в него IP стек. 485 + modbus тоже никто не отменял. 0

@otixsom 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 1,183
	12.04.2016, 19:17
	Насколько критична скорость доставки? Если можно подождать несколько мс то у меня есть такой вариант (реализовывался не на RS485 но не суть) Каждое устройство в сети может быть мастером. При подключении устройство ждет от сети широковещательного сигнала. Этот сигнал представляет собой пакет из заголовка, адреса отправителя, адреса получателя (в данном случае = 0) и пустых данных (такой формат не обязателен но у нас была фиксированная длинна пакета). Адресация устройств в сети задается на этапе прошивки (можно джамперами на плате и т.д.). Каждое устройство не может отвечать не в свое время. Т.е. если появился в сети девайс с адресом 1, он ждет 10 мс и если ничего не пришло, то шлет свой пакет в сеть. Далее ждет еще столько же. Если появился девайс с адр. 2, то он тоже ждет 10 мс. За это время №1 прислал пакет, второй его получил и посмотрел что пришел пакет с адресом на 1 меньше, значит его очередь слать. Подключился девайс №3 - он ждет свой очереди. и т.д. При получении широковещательного пакета девайсы запоминают кто онлайн. Выпал к примеру девайс №2, при этом №3 ждет от него пакет, прошел таймаут 10 мс, ничего не получил - шлет пакет вместо него. Далее, если нужно кому-то отправить - то он не отправляет сразу а ждет своей очереди. В хедере указывается что это данные для кого-то конкретного. Если нужно отправить несколько пакетов за раз, то так же в хедере выставляется флаг и следующий девайс не будет пытаться ничего слать пока не завершиться передача или не пройдет таймаут. Плюсы - нет главного, все могут слать кому угодно. - нет коллизий Минусы - данные отсылаются только по времени и в строгой очереди. - нужно не провтыкать с раздачей адресов. 0

@shibtym 0 / 0 / 0 Регистрация: 07.04.2016 Сообщений: 268
	12.04.2016, 22:56
	не совсем понял вопроса, но если он НЕ об организации коммуникации на физическом уровне, то я порекомендовал бы взять за основу movtink https://github.com/movtink/movtink . movtink на основе спецификации генерирует код протокола на разных языках, С в том числе. активно используется для создания протоколов управления различных дистанционно управляемых аппаратов. предусмотренно разделение каналов, можно попробовать использовать это для мульти точечного обмена. как разруливать конфликты, организовавать доступ к среде передачи придется самому придумывать. решаемо - не бином ньютона. главное - movtink безошибочно генерирует код. корявенький, на мой вкус, но.... ах да, без ложки дёгтя не обойтись, для генерации, питон ставить придётся, гадость конечно... 0