Универсальный протокол обмена между микроконтроллерными устройствами

[av-master]

Что вы уцепились за Физику. каждый ее решит как ему хочется. а через переходник все будет цепляться.
все равно никаких устройств кроме одного (для себя) никто делать не будет Open-Harware тут не прокатит. масса далека от критической ))
Всеравно исходить из наличия нужно . а основную роль отыграет стоимость. и большинство плюнет и поставит обычный Уарт через обычный max3232  или вообще без него 

Вот протокол придумайте хороший , информативный мало ресурсный и нормально. потом уже физика пойдет хоть черех WiFI хоть через GPRS.

Я в своих девайсах юзаю примерно:
B1B3xxxxyyyyzzvvDDDDDDDDDDDDDDCRCB2B3
где все данные в HEX виде
B1B3...B2B3 начало и конец пакета
xxxx - адрес приемника
yyyy - адрес передатчика
zz - тип пакета
vv - версия пакета (или номер параметра)
DDDDDDDDDDDDDD данные ( не более 1024 )
CRC - контрольная сумма (XOR по модулю)
и все это работает на тысяче устройств через кучу интерфейсов от ИК порта минуя радио и проводные модемы, заканчивая WIFi и GPRS (уже и 3G пробуем)

[zap]

[b-b]av-master[/b-b], Вы, вероятно, правы, и тем не менее хочется разработать нечто, несколько выходящее за рамки "на коленке гвоздь согнул".

По сути разработка протокола прикладного (7го по модели OSI) уровня является одной из целей данного проекта (с него, собственно, вся ветка и начиналась). Тем не менее, для того чтобы такой протокол привёл к настоящей совместимости разных устройств имеет смысл разработать хотя бы "основной рекомендуемый" канальный протокол (2го уровня), основываясь на одном из существующих физических протоколов (1го уровня, в нашем случае RS-485). Таким образом, разработав какое-то устройство (возможно даже мелкосерийное) и опубликовав его протокол Вы даёте возможность другим мелкосерийным производителям, при необходимости, встраивать поддержку данного устройства. Возможно, я несколько оптимистичен, но такие вещи лучше разрабатывать, обкатывать и шлифовать заранее - тогда в момент, когда критическая масса всё-таки наступит, можно будет взять его за основу, вместо того чтобы каждый производитель ушёл в свою степь (как обычно, к сожалению, и происходит).

Со своей стороны хочу сказать, что работа с моей стороны идёт, правда, несколько медленнее чем хотелось бы (попали в аварию, жена в больнице с переломом, появилось много новых интересных дел и забот). Тем не менее, кое-какие результаты есть.

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

Во-вторых, я работаю над программой симуляции RS-485, а также протокола e-Bus поверх него. На текущий момент симуляция UART работает в полный рост, теперь пробую разные вещи и смотрю как оно себя поведёт в симуляции. Много думаю Предварительный скриншот для развлечения присутствующих прилагается

[NiceParty]

...Так как шина у нас полудуплексная, то приёмник любого устройства (в том числе передающего) постоянно "слышит" шину, в том числе во время собственной передачи. Таким образом, посланный байт неизбежно оказывается в буффере приёмника того же устройства. По окончании передачи путём сравнения отосланного и принятого байта можно сделать вывод о вмешательстве в передачу другого устройства...

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

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

Поэтому я все-таки сторонник полного дуплекса, если дополнительные два провода не помешают. А провод удобно тянуть витой парой FTP: одна пара на прием, вторая на передачу, оставшиеся две пары - питание. (Либо тогда опять CAN )

[zap]

...Так как шина у нас полудуплексная, то приёмник любого устройства (в том числе передающего) постоянно "слышит" шину, в том числе во время собственной передачи. Таким образом, посланный байт неизбежно оказывается в буффере приёмника того же устройства. По окончании передачи путём сравнения отосланного и принятого байта можно сделать вывод о вмешательстве в передачу другого устройства...

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

Безусловно такое может возникнуть, просто этот механизм предлагается как дополнительный для быстрого определения коллизий. От контрольных сумм и перезапросов ошибочных пакетов, к сожалению, нас никто не освобождает, впрочем как и в i2c и CAN.

Мне тоже приходилось размышлять над бесконфликтным полудуплексом по одной паре 485. Я пока пришел к такому решению:
В режиме ожидания на шине зафиксирован стабильный уровень с помощью подтягивающих резисторов. А разрешение конфликтов на начало передачи решается с помощью старт-битов разной длительности и последующего снятия активного уровня и возврата в режим прослушки для анализа состояния линии. На основании этого анализируется наличие попыток одновременного захвата шины и вступает в силу алгоритм определения приоритетного устройства. После того как порядок передачи определен, начинается передача уже самих данных с использованием обеих полярностей сигнала.

Идея вроде бы рабочая, и даже подтягивать ничего не надо (RS485 трансиверы автоматом выдают на выходе "1" если вход TX в Z-состоянии), но минус в том, что придётся нестандартным образом использовать UART. Хотелось бы обойтись только техниками, которые "пролезут" хотя бы через USB-UART переходник, а ещё лучше чтобы оно "пролезало" через Bluetooth UART. То есть "вручную" дёргать шину можно только на микроконтроллерах (которые имеют возможность непосредственного управления сигналом TX, а также "ручного" чтения сигнала RX), ни одно другое стандартное UART устройство общаться по такой шине не сможет.

Поэтому я все-таки сторонник полного дуплекса, если дополнительные два провода не помешают. А провод удобно тянуть витой парой FTP: одна пара на прием, вторая на передачу, оставшиеся две пары - питание. (Либо тогда опять CAN )

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

Я ещё думал над тем, чтобы к UART интерфейсу подключить CAN трансивер (там те же самые RX/TX), в этом случае коллизии будут определяться практически гарантировано. Но не нашёл подходящих с низким энергопотреблением, те которые видел просто ЖРУТ электричество, да и цены в разы больше.

Из того, что смотрел, больше всего понравился CAN трансивер MCP2551, но он жрёт 10 миллиампер когда выход в рецессивном состоянии, и 75 в доминантном. Правда, у него имеется режим энергосбережения, в нём он жрёт около 400 мка...

[NiceParty]

...Хотелось бы обойтись только техниками, которые "пролезут" хотя бы через USB-UART переходник, а ещё лучше чтобы оно "пролезало" через Bluetooth UART. То есть "вручную" дёргать шину можно только на микроконтроллерах (которые имеют возможность непосредственного управления сигналом TX), ни одно другое стандартное UART устройство общаться по такой шине не сможет...

Ну в УАРТе как бы две раздельные линии на прием и передачу и не предусмотрено множество вещающих одновременно (только один говорит), поэтому коллизий с одновременным вещанием в общую шину и не возникает. Формат пакета УАРТа и не предусматривал такое издевательство, какое мы тут придумать пытаемся

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

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

[zap]

Ну в УАРТе как бы две раздельные линии на прием и передачу и не предусмотрено множество вещающих одновременно (только один говорит), поэтому коллизий с одновременным вещанием в общую шину и не возникает. Формат пакета УАРТа и не предусматривал такое издевательство, какое мы тут придумать пытаемся

Однако в RS485 это предусмотрено прямо в стандарте. Правда, там расчёт на схему один ведущий - много ведомых.

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

Таким образом, прямо от рождения, работает SPI, но это тормозно - и чем больше устройств, тем больше тормоза. К тому же, если конечное устройство - на багажнике (к примеру, задняя фара) а первое - на руле, то замыкать кольцо придётся длиннющим проводом через весь лисапед

Куплю пачку трансиверов RS485 и пачку CAN, поиграю с ними.

[NiceParty]

Таким образом, прямо от рождения, работает SPI, но это тормозно - и чем больше устройств, тем больше тормоза. К тому же, если конечное устройство - на багажнике (к примеру, задняя фара) а первое - на руле, то замыкать кольцо придётся длиннющим проводом через весь лисапед

Не известно, что лучше: быстро, но с коллизиями или чуть медленнее, но с гарантированной скоростью доставки. В конечном итоге нам большая скорострельность и не нужна, несколько десятков миллисекунд - этого вполне достаточно, имхо.
А длиннющий провод - не страшен, он у нас и так будет длинным, соединяющим все устройства. Просто вместо 4-х проводов (двух сигнальных, земля и питание) потребуется 6 (+2 сигнальных обратной ветви). Что, в общем-то, не сильно меняет суть дела. Да и недорогие многожильные FTP - на каждом углу.

[amd9800]

так чем закончилось все?

[zap]

Переключился на протокол i-wire от [user]i[/user].
В варианте с RS485 слишком много тонких мест. Режим мультимастер практически нереализуем из-за непредсказуемости поведения в момент одновременного включения нескольких мастеров.
В логической части протокола (формат команд) использовал некоторые наработки из того, о чём я говорил на этой ветке.

i-wire достаточно успешно используется в как минимум двух устройствах - "энергоблоке" [user]i[/user], и ещё одном промышленном, которое скоро будет производиться массово. Во втором случае он используется с гальванической развязкой и дифференциальной передачей сигнала (через относительно дешёвую микросхему трансивера CAN) между кучей устройств (где-то от 10 до 40 устройств) в режиме мультимастер.

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

К сожалению, развитие протокол получил в рамках оплачиваемой работы.
Поэтому эта работа принадлежит фирме, в которой мы оба работаем.
Если кому интересно, могу поговорить с начальством об открытии спецификации, она у нас есть.

[zap]

Дык, диалектика же. Развитие по спирали.
Мы не повторяемся, мы возвращаемся к нерешённому вопросу находясь на новом уровне!

Добавлено 29 Нояб. 2014 в 17:53

Думаю [user]clawham[/user] может Ваш протокол воткнуть, но надо у него спрашивать. Единый стандарт протоколов однозначно на пользу

Эм... а прошивка там не опенсорс? Тогда обсуждать в данной теме нет смысла.

[i]

Не имею ничего против спирали.
Но пока не пройден порочный круг с единым протоколом обмена... до спирали далековато.
Обычно:
   одному нравится RS232  (он проще)
   другому - RS485  (он длиньше)
   третьему - I2C  (просто хочет разобраться)
   четвертому - CAN  (он круче)
   пятому ...
и так далее.

P.S.
Эх...если этот КРУГ удастся разорвать, то каждый желающий сможет сделать своё устройство (дисплей, контроллер, фару, тормоз, моргалку, бибикалку, флагоподымалку...), причем  необязательно "открытое", главное, что они будут совместимы и любой желающий сможет поставить (или не поставить) на свой транспорт, понравившийся вариант...

[zap]

Да не будет такого никогда. Реализация протокола требует мозгов и усилий, гораздо проще впердолить резистор последовательно с мощным светодиодом и готова фара. Протоколы? Нет, не слышал.

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

[Андрей СШ]

... CAN  (он круче)

Фи, примитив какой.
МЭК-61850 - вот выбор тех, кто не ищет лёгких путей.

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

Что бы в одной системе могли работать быстродействующие устройства и всякая мелочь придёться делать более одной физической реализации шины. Следовательно среди устройств появляется шлюз. А чтобы это всё работало вместе нужен верхний уровень протокола, независимый от физического. Постепенно приходим к семиуровневой модели OSI.

[Андрей СШ]

Готов добавить поддержку общего протокола в свой контролёлер солнечной батареи для тех кто хочет СБ на крышу или возит с собой рюкзак фотоэлементов на велосипеде.

[zap]

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

Вот исходя из универсальности я давно уже утвердился в мысли, что базой должен быть UART. Он очень простой и аппаратная реализация есть почти везде. В 13й тиньке его, правда, нету, но в 25й уже есть. А вручную дёргать биты... мне не понравилось, слишком много проблем, и нагрузка серьёзная.

Если кому интересно, вот протокол который я буду использовать в своём iWattnick'е. Собственно, всё уже написано и работает (для STM32), а также либу для ПК и простенькая утилита для общения с устройством с командной строки.

[_claw]

Что бы в одной системе могли работать быстродействующие устройства и всякая мелочь придёться делать более одной физической реализации шины. Следовательно среди устройств появляется шлюз. А чтобы это всё работало вместе нужен верхний уровень протокола, независимый от физического. Постепенно приходим к семиуровневой модели OSI.

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

[i]

Вот исходя из универсальности...
А вручную дёргать биты...
...
Если кому интересно, вот протокол который я буду использовать в своём iWattnick'е. ...

UART порождает больше проблем чем решает. Взятие его за основу упрощает реализацию физического уровня, но отягощает логический уровень.
Причин тому много: нечувствительность к ошибкам передачи (я прокукарекал, а там хоть не рассветай), отсутствие квитирования приема (передать-то я передал, а вот принял ли кто-либо мне по-барабану, сижу и жду ответа). Невозможность разрешать коллизии на физическом уровне навязывает требование наличия только одного ведущего, а это приводит к тому, что ведущий должен "знать" все устройства на шине, как говориться "в лицо", следовательно введение в шину нового устройства, потребует вносить его поддержку в программу ведущего, что совсем не просто для пользователя. Скорость передачи строго фиксирована, значит нужно применять кварцы для тактирования (RC-генераторы и "керамика" не прокатят из-за температурного дрейфа) да и кварцы в диапазоне -20+50 могут "уплывать".
Разумеется все эти недостатки можно обойти программно на логическом уровне....только от "простоты UART" и следа не останется.

MUDBUS этим не занимается, он будет хорошо работать только в хорошей среде передачи, где помехи редки или вовсе исключены (CRC защищает только часть пакета, а заголовок ни как не контролируется на валидность, то есть может придти пакет "на деревню дедушке от ваньки"). Ну и iWattnick должен знать всех с кем собирается работать (скорее всего это будет только комп), ну или иной ведущий должен знать как общаться с iWattnick, то есть эти устройства становятся зависимыми друг от друга, изменения в КАП одного потребует изменений в обработчике другого.
Все это уже обсуждалось.

CAN например, лишен большинства этих недостатков (кроме требования к фиксированной и точной скорости). У него свои "тараканы", но помельче.
Есть еще протокол ZACwire, который применяется в датчике температуры (-50+150) и у которого просто нет ног для кварца, поэтому хоть частота передачи и "плавает" это не мешает верно принимать данные о температуре.

[inel]

Мое мнение - RS485-UART оптимальное решение, поясню почему.
Аппаратный UART имеется практически во всех современных и главное дешевых контроллерах.
К примеру, STM8 стоит всего 26р. AVR по параметрам и цене курит в сторонке.
Так-же, на примере STM8, по UART можно разбудить контроллер. Экономия энергии, это то-же важно.

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

Отправил команду - жди ответа. Нет ответа, повтори. Нет ответа, значит с 'рабом' что-то не так.
Да, мастер должен быть только один. и знать о 'рабах' Не вижу в этом проблемы.
В любом случае новый девайс кто-то должен знать в 'лицо'. Если мастер не знает, значит необходимо обновить прошивку, что можно сделать одним нажатием кнопки на смартфоне.
Мастер должен заниматься не критичными задачами, в основном сбором информации. В роли мастера идеально подходит бортовой комп.
Слэйвы должны быть самодостаточными. Ничего юзеру добавлять не надо. Мастер сам найдет 'раба' (например сканирование при включении).
На экране бортового компа не должно быть ничего лишнего. Только важная информация(скорость, одометр, заряд ..), остальное на смартфон. Нефиг юзеру знать о напряжениях на ячейках. Он вообще не должен знать о существовании БМС. Кому надо, посмотрят графики на смартфоне. Кстати, память на 4МБайт стоит всего 50р. Считаем - 2байт на ячейку. 16ть ячеек. Сбор данных - каждые 10-ть сек.Получается около 347 часов статистики - больше двух недель.

Скорость передачи строго фиксирована, значит нужно применять кварцы для тактирования (RC-генераторы и "керамика" не прокатят из-за температурного дрейфа) да и кварцы в диапазоне -20+50 могут "уплывать".

Ну не строго. Допускается довольно таки жирный разбег.