Подскжите какой лучше протокол использовать для объединения нескольких устройств в сеть через интерфейс RS-485 ??
Всего будет порядка 5 устройств на базе Atmega16, все устройства в сети равноценны.

Для RS-485 лучше всего подходят пакетные протоколы. Т.е. передача происходит по принципу запрос-ответ в пакетном режиме. Посмотрите протоколы типа Wake, Modbus, PiNet.
А вот мультимастер для RS-485 реализуется весьма плохо. Не предназначен он для "равноправного" доступа к линии, т.к. нет простого по реализации механизма обнаружения и устранения коллизий. Потому подумайте как сделать какой-нибудь из ваших МК ведущим, а остальные ведомыми.

очень рекомендую Modbus, прост в реализации, и удобен

Согласен что модбас вещь стоящая но важно не планируется ли в данной сети использовать еще покупные устройства с RS-485 интерфейсом.Если например могут понадобится девайсы типа Adam,ICPCON или Nudam возможно что логичнее быдет реализовать протокол ADAM4000 кстати тоже весьма несложный.
Опять же надо знать какие данные необходимо пересылать,в к примеру модбасе неочень удобно передавать большие или структуированные данные и иногда гораздо проще в таких специфических применениях замутить свой кустарный протокол.

А почему мультимастер для RS-485 реализуется весьма плохо?



И что за ADAM4000? Ссылочку подскажите, пожалуйста.

Мультимастер обеспечивается плохо потому что у RS-485 в один момент времени может быть только один передающий модуль и единственный способ сделать мультимастерность это мудрить с временным разделением передачи(обмениватся токеном или еще как).В том же CANе например два передатчика могут начать передавать одновременно но получится это у того у кого приоритет сообщения выше остальные попробуют передать позже(неразрушающий арбитраж).

А ADAM4000 это название серии модулей фирмы адвантек и их протокол был принят дефакто остальными производителями аналогичных модулей.Что то посмотреть на эту тему можно тут

Не знаю как правильно назвать такой протокол, но счетчики электроэнергии Меркурий, модули IPCON 7017 по протоколу RS-485 и им подобные разговаривают следующим образом:

Запрос: ~АдресУстройстваКомандаЗапроса
Ответ: #АдресУстройстваДанныеОтвета

Все адреса и данные пишутся в ASCII коде, соответственно отлаживать обмен можно из программы терминала.

Это и есть ADAM4000.И RS-485 не протокол а интерфейс.

А если у меня все совсем просто: один мастер.
Можно так:
Запрос: АдресУстройства
Ответ: ДанныеОтвета
?

Можно и так только лучше всетаки передавать какойто префикс в начале чтобы знать что данные идут без разрывов.

Если вы делаете проект одноразовый для одного заказчика
то при наличии времени и желания можно придумать свой
простенький протокол особенно если в линии только один мастер
Если проект будет клонироваться для разных заказчиков
то рекомендую использовать какой нибудь распространненный
протокол (например MODBUS)
Опыт показывает что со своим протоколом жить можно но
со временем это становится сдерживающим фактором для
проталкивания своей продукции на рынок.

Удивительно точно подмечено!
Мы уже 15 лет на рынке. Продали десятки тысяч приборов нескольких десятков типов. Реальные пользователи довольны. И всё равно сейчас прихдится городить встроенные преобразователи в стандартные протоколы исключительно в рекламных целях. Нынче рынком управляют менеджеры со своими красочными картинками и пафосными фразами, а не здравый смысл.

Делайте выводы!

Какой выбрать из двух:
1) Wake
2) Modbus

Для задачи:
Master = WinXP/virtualCOM(CP210x+xx485)/C++

Slave (max10)=UART C8051Fxxx :
"текущий" передает данные с АЦП 10-20кБ/сек
"резервные" передают данные вместе до 1кБ/сек

Думаю без вариантов это должен быть Wake(или его собственная реализация).Модбас предназначен для других целей и через него крайне неудобно передавать большие или структуированные данные.

Сейчас делаю аналогичный девайс только с FTDI и уже без труда сделана собственная реализация wake.

Уважаемый IPC, почему "Модбас предназначен для других целей", а для каких тогда?

И подумайте о поляризации шины,
нужна она Вам или нет.
(Если преамбул нет то нужна)

Можно я попробую, если не возражете.
Дело в том, что MODBUS MODBUSу рознь.
Базовым, согласно стандарту считается MODBUS/RTU. Это протокол бинарный без разделительного заголовка и с временнЫм разделением телеграмм. В связи с этим, просто так организовать буферированный ввод/вывод в ПК не выйдет. По документу "MODBUS over Serial Line" именно MODBUS/RTU является обязательным протоколом, а MODBUS/ASCII, телеграмма которого состоит из ASCII символов с разделительным символом в начале и с символами окончания - всего лишь рекомендуемым. Кроме этого длина телеграммы ограничена 247 байтами, хотя в наборе имеются команды передачи данных, разбитых по телеграммам.

Прохожий, вы подстрочным переводчиком при чтении стандарта пользуетесь что ли? А то слово "телеграмма" заменили бы на более привычное "пакет", "пакет данных" все же, а?

Ничем я не пользуюсь. Просто, я так привык. Еще с того момента, когда ПЛК S5 только появились в СССР. Хотя можно и пакет. А у Вас откуда привычка к пакетам?

Модбас удобен при стандартизированной передаче отдельных параметров(слов,бит итд).Его применение оправдано при сравнительно небольшом количестве передаваемых данных и наличии нескольких slave устройств в сети.Опять же он является промышленным стандартом и при совместном использовании покупных и кустарных устройств можно задействовать широкий спектр OPC серверов и SCADA систем.Если же требуется передавать поточные данные то более целесообразно использовать что то на подобии wake.имхо.
Как уже было написано выше большие или что важно структуированные данные плохо совмещаются с модбасом в силу его ориентированности на отдельные параметры такие как слова или биты.

Итого: Wake

Не критики ради а замечания для ....

ModBus если посмотреть на него через призму OSI представляет транспортный уровень, а уж как структурированы данные за это отвечает уже уровень выше. И вот тут все зависит от головы и рук. В свое время работали с файлами и передавали их через ModBus. Как для протокола транспортного уровня у него есть недостатки: Одни мастер, сравнительно небольшая скорость передачи(ограниченная длинна кадра).

Здравствуйте! У меня возник вопрос по поводу modbus...судя по информации в инете, протокол этот открыт и как будто стандартизирован IEC, имеет статус PAS - общедоступные спецификации...я хотел бы узнать, если я реализую протокол в своих слейв-устройствах то для их продажи, я должен буду получить какой-нибудь сертификат соответствия, или иной подобный документ? Если да, то обязательно ли это? На www.modbus.org есть информация что сертификат получить можно...но нигде я его не видел, если на HART например можно найти, то на modbus нет (. Перерыл весь инет,единственные кто вменяемо пишут про это www.trianglemicroworks.com но этой информации не достаточно...помогите! Вообщем главный вопрос - это легальность modbus, и обязательность сертификации....

Ребятки незнаю как вам, а я тут сижу
и разглядываю протоколы передачи
модбас мэки ваки итд
сам занимаюсь интеграцией в системы верхнего уровня всех протоколов
могу сказать след:
мод бас вещь доступная но эти 7 (3,5+3,5) байт (в рту) ожидания для тайм аутов - жесть
(коту под хвост) но вещь действительно стандартизованая и можно приянять как дефакто..
и много отладночного софта

ваке всем хорош прекрасный канальный уровень - многих беспокоит стаффинг (хотя криминала нет)
и я б добавил к нему тайм аут по символу. Но несособо распростанен по сравнению с мод басом
тест софта кот наплакал..

протколы МЭК тоже неплохой канальный уровень но в реализации жесть - хотя и стандарт!!!
тест софта раз 2 и обчелся и все комерческое..

наверное все таки WAKE

Kovrov, странно что занимаясь разработками на основе ModBus вы знаете только про ModBus RTU, но не в курсе про ModBus ASCII. Иначе к чему эта реплика?
А вообще тип протокола связи зависит от области применения, как уже выше заметили. Если в проект только "свои" приборы входят это один случай, а когда требуется стыковать с "чужими" приборами, то нужно внимательно изучать все аспекты связи во всем проекте. У нас в приборах, например, используется свой собственный протокол, этакая компиляция PiNet и Modbus, но для совместимости стандартный ModBus тоже поддерживается.

какая реплика?
С чего вы взяли что я не вкурсе модбас ASCII?
Я к чему сказал- к тому что как то всегда ёжусь когда уарт простаивает...
Всегда ближе к телу синхронизация по старт байтам...
и потом это все имхо..
И у нас в приборах реализован тоже собственный протокол нечто среднее между ваке и IEC870
Речь идет и выборе и доступности протокола...
Выложите описание вашей разработки протокола, а также вспомогательный софт...
И будем иметь ввиду....

Вы подскажите мне пожалуйста...реализовывая в своих устройствах протокол modbus вы не сталкивались с вопросами о правомерности его использования...я понимаю что стандарт открыт, и спецификация более чем подробна...но начальство от меня хочет услышать однозначный ответ могут писать они что устройство поддерживает modbus 100%. и за это точно ничего не будет...такая вот вообщем проблема...самое странное что про сертификацию на оф. сайте написано, что мол можно пройти...но обязательно-ли? И скрин или копию сертификата этого вообще найти не могу...кому дают то они его, и зачем? если нигде нельзя посмотреть как он выглядит хоть...на HART нашел сразу же, загуглил - на тебе 2-3 ссылка...

А где раздобыть исходники на какой-нибудь протокол?
Желательно Modbus. Обязательно для AVR. Желательно на CodeVision.
Подскажете, товарищи?

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

Прошу прощения, сейчас изучу. Поиском пользуюсь, но то, что хотелось бы не нахожу. А вообще я что, не в ту тему написал?

исходников на Code vision нету, но алгоритм рассказать могу.
Если ктото где то поправит - в сторону улучшения буду признателен...
Итак канал MODBUS RTU (со стороны приема кадра- режим слейв)
1) Задействую таймер прерывание на время в 1,5 символа (например OCx CTC mode)
2) UART RX работает всегда, при возникновению прерывания по UARTв любом случае обнуляем таймер.
3) Проверяем принятый байт на четность или 2й стоп, если ок помещаем в буфер но неболее N байт в буфере (256).
4) При появлении прерывания по таймеру (считаем что прошло 1,5 символа) начинаем разбор кадра...
смотрим адрес в первом байте буфера если сходится с адресом слейва разбираем кадр далее - считаем CRC, если не совпал адрес слейв или CRC16 -- вектор буфера на начало и ждем след перрывания по таймеру.
Вроде все!!
Насчет 1,5 символа - возможно нада подрихтовать!!!
Как уважаемые коллеги этот вариант?

Неверно! Если пауза между символами больше 1,5-кратного интервала, но меньше 3,5-кратного, то данный фрейм нужно "фтопку". Об этом в стандарте явно прописано. Разбор фрейма нужно проводить, только если пауза тишины превысит 3,5-кратный интервал.
Начало фрейма тоже по 3,5-кратной паузе тишины ловится. А прием в буфер имеет смысл начинать, только если сетевой ID совпал с собственным (для slave) или с тем, что был в запросе (для master). Зачем нужно "чужие" пакеты принимать/разбирать-то? Исключение составляет только broadcast ID, который всеми slave должен приниматься.
Кстати, постоянный прием с линии можно оставлять, только если локальное "эхо" отсутствует.

Да это все верно.. Именно поэтому и был выбран интервал 1,5
1) 1,5 символа взято из соображений ускорения синхронизации, выставив паузу в 3,5 нужно дополнительно стаховаться что я не попаду (например в момент включения) в середину передачи символа на уарт.. Можно поставить больше 1,5 - например даже лучше 1,75 тогда проблем в реализации 3,5 интервала для передатчика вообще не будет..
Далее...
Почему разбирать чужие пакеты?
после детекта IDLE я по прерыванию смотрю только на совпадение адреса ВСЁ!!!
CRC считаю только если адрес совпал - вы просто несовсем внимательно прочитали...
Вся перелесть - в том что алгоритм весит всего нескольо строк на АSМ

Помашу после драки кулаками:

Протокол серии ADAM-4000 - это страшный сон разработчика!!! Для каждой команды - свой формат. В том числе, разный символ-заголовок пакета!!! Очень много команд, у которых все различие подвариантов "на чтение" и "на запись" - только по длине! Форматы ответов тоже разные на разные команды! В отличие от MODBUS ASCII, сплошь и рядом всякие "левые" - не шестнадцатеричные - символы внутри пакета, так что скормить его целиком в процедурку типа "HEX2BIN" не выйдет!

А уж "контрольная сумма", представляющая собой просто сумму размером в 1 байт - это просто прелес-с-сть!

Уж простите, что я вот так вот "криком" - наболело...

Рекомендую ознакомиться с дискуссией, где обсуждается связь между подтяжками, протоколом обмена и помехоустойчивостью. Modbus ASCII для RS-485 непригоден из-за низкой помехоустойчивости, oн предназначен для RS-232.