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

[zap]

Я не хотел провоцировать очередной протокольный срач.
Просто показал, к какому выводу пришёл в итоге.
UART хорош тем, что легко заводится в компьютер (USB-UART), легко передаётся по воздуху (UART-Bluetooth), легко делается помехозащищённым (RS485 трансивер стоит копейки), прост и удобен в использовании.
Если мне захочется завести CAN или ZAGwire в мобильник или компьютер, у меня возникнут определённые трудности.
Ограничения UART мне понятны, но я готов с ними мириться ради его плюсов. Кстати, CRC8 у меня защищает весь пакет, а не часть. Если заголовок побьётся, ничего страшного - как только на шине наступит затишье (на время 1 символа), всё сбросится.

Кстати, существует автомобильный протокол SAE J1708 (собственно, это предшественник CAN) на базе UART со скоростью 9600 бод, 8N1, который реализует мульти-мастер на шине RS-485 с открытым коллектором. Есть ещё возможность вместо RS-485 трансивера воткнуть CAN трансивер (на выходы UART), можно легко ловить коллизии а дальше уже дело техники.

[Андрей СШ]

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

1. Количество устройств на шине.
2. Скорость передачи (ширина канала).
3. Гарантированное время доставки сообщений.
4. Автоматическая адресация?
5. "Горячее" подключение?
6. Рабочий диапазон температур.
7. Питание переферийных устройств от шины?
8. Напряжение на шине для питания устройств.
9. ...

[i]

В любом случае новый девайс кто-то должен знать в 'лицо'.

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

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

[i]

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

Ошибка частоты приемника +-7% относительно частоты передатчика дает гарантированную ошибку передачи (и это не смотря на прямоугольность сигнала и без учета джиттера).
Реально, при погрешности 2% UART уже может "подвирать", причем с честными глазами.

Везде, где применяется это безобразие под названием NRZ (CAN, USB и пр.) производится аппаратная подстройка фазы генератора по каждому перепаду сигнала, а что бы этих перепадов было больше вводят stuff биты, для разжижения последовательности нулей и единиц... и да же после этого оговаривают максимально допустимую погрешность 1.7%.
У UARTA нет ничего подобного, это просто сдвиговый регистр, который дергает проц при приеме каждого байта и выдает ему нечто, стыдливо прикрытое битом паритета (в лучшем случае).

[Torvald]

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

В некотором устройстве, одним из разработчиков которого я являюсь, стоят две атмеги, которые общаются друг с другом по UART'у 38400 бод. Одна атмега тактирована от кварца, вторая - от встроенного RC-генератора. Испытания в диапазоне температур -30...+50С в термокамере показали, что связь пропадает лишь при -30С, да и то не на всех изделиях. Может не так страшен температурный дрейф, как его малюют?

[zap]

[user]i[/user], в моём протоколе есть широковещательные сообщения, поэтому нет никаких проблем с рассылкой общих команд, которые воспримут сразу все устройства и исполнят все, кто его понимают.

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

Для мультимастера даже внешний трансивер CAN не нужен, достаточно перевести выход TX из режима push-pull в режим pull-up (на stm32 это делается штатно конфигурацией портов В/В, на МК где такого режима нет достаточно внешнего транзистора с резистором). Тогда '0' станет доминантным состоянием на шине и мы сможем ловить коллизии.

[i]

Рад за Вас, а у меня тинька26А теряла связь с RF-модулем, хотя тинька26 работала (и продолжает работать на автобетононасосе) стабильно, пришлось перезакупать всю партию.
Частоту RC генератора можно и подстраивать, даже апнот есть на эту тему... тогда и мороз и жара станут не так страшны. Ведь это так просто.

P.S.
С UART-ом знаком давно, еще когда в армии настраивал обороты двигателя телетайпа по камертону 440Гц (нота Ля). Если сектор на валу двигателя хотя-бы чуть двигался, при просмотре через камертон, телетайп печатал полную пургу. А было это устройство ввода-вывода чуда советской военной техники топографической ЭВМ "ТЭМ-1" на феррит-транзисторных модулях. Возили ее на КРАЗе и разворачивали в полевых условиях.
30 лет прошло, а протокол телетайпа до сих пор жив и живее всех живых.

[zap]

1. Количество устройств на шине.

Логически - до 255 адресов. Физически - как получится, но десяток уж точно хотелось бы иметь возможность.

2. Скорость передачи (ширина канала).

Небольшая. Предназначение шины - координация действий устройств, чтение и настройка параметров, исполнение команд.
Пока планирую 19200 бод, посмотрим насколько оно будет устойчиво к помехам. В SAE J1708 вообще используется 9600.

3. Гарантированное время доставки сообщений.

Доставка сообщений за определённое время не гарантируется. Целостность гарантируется CRC8, макс длина пакета 19 байт (без CRC8).

4. Автоматическая адресация?

Это что? Есть широковещательный адрес 0, который все устройства определяют как "свой".

5. "Горячее" подключение?

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

6. Рабочий диапазон температур.

Это уж как получится. Обычные микросхемы расчитаны на 0-70 градусов, понятно что на морозе они тоже работают, но уж до какого предела - как получится.

7. Питание переферийных устройств от шины?
8. Напряжение на шине для питания устройств.
9. ...

Никакого питания. Если нужно - тяните доп. провод, какие проблемы.

[i]

[user]i[/user], в моём протоколе есть широковещательные сообщения, поэтому нет никаких проблем с рассылкой общих команд, которые воспримут сразу все устройства и исполнят все, кто его понимают.
...

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

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

[i]

... Целостность гарантируется CRC8, макс длина пакета 19 байт (без CRC8)...

Если верить
"Программные реализации вычисления CRC"
  Name  : CRC-8
  Poly  : 0x31    x^8 + x^5 + x^4 + 1
  Init  : 0xFF
  Revert: false
  XorOut: 0x00
  Check : 0xF7 ("123456789")
MaxLen: 15 байт (127 бит) - обнаружение одинарных, двойных, тройных и всех нечетных ошибок

[TRO]

Вставлю и я свои пять копеек.

В контроллере нет нормальной аппаратной части для полноценной работы RS485, по уму надо дергать ногой направления передачи данных самостоятельно и заблаговременно, т.е. програмно. Те аппаратные бюджетные микросхемы UART(TTL) to RS485 имеют вход направления передачи который надо правильно дергать. Готовые платы преобразователей  которых валом на ебей и прочих (вырисовывал схему когдато) просто сразу переводят в режим передачи по приходу фронта с UART и переключаются на прием выдерживая паузу RC цепочкой. В итоге, из за того что невыдерживается пауза между переходом на передачу и началом потока данных первый байт зачастую может оказатся битым и появляются проблемы со стандартным оборудованием, длиной линии и чувствительности к помехам. А по причине формирования фиксированной задержки в конце пакета получаем проблемы на скоростях передачи для которых эта задержка не будет оптимальной (задержки должны быть пропорциональны скорости передачи).
Знаю что существуют правильные микросхемы с буферами внутри, которые определяют скорость передачи и выставляют все таймауты правильно, но в живую не видел и доступность и цену незнаю.

Темерь по модбасу. Его контрольная сумма еще тот геморой, прийдется серьезно нагружатся програмно.

[PeaceHaver]

Тема огонь, но толком как автоинженер ничего, окромя родной кан-шины, не вкуриваю. Буду следить за прениями. Из темы понял, что УАПП - дешево и сердито. Настолько же дешево, насколько и сердито.

[zap]

MaxLen: 15 байт (127 бит) - обнаружение одинарных, двойных, тройных и всех нечетных ошибок

Я в курсе. На длинах длинее 15 байт не всегда будут обнаруживаться тройные ошибки, переживём.

[i]

Тема огонь, но толком как автоинженер ничего, окромя родной кан-шины, не вкуриваю....

Так подкиньте дровишек. Раз CAN для Вас родной, откройте секрет, почему несмотря на его очевидные недостатки (дорог, непривычен, непонятен), его все таки пихают в автомобили?

[inel]

Я согласен, что CAN намного стабильнее и лучше, НО использовать stm32 или CAN контроллер в поворотниках или термодатчике, да еще и драйвер нужен - это слишком.

RS-485, в принципе, можно так и спалить (даже от такой простой вещи как одновременно "заговорившие" два устройства). Поэтому склоняюсь к трансиверу CAN, по сути это тот же RS-485 только с доминантным состоянием на шине.

То-же к этому пришел. Например tja1050.

[VVK]

И я пару слов добавлю.

По CAN'у.
Шина хорошая (даже очень), но с ней получается дороже, т.к. он имеется только в более дорогих контроллерах. Плюс к нему драйвер нужен. В целом поднимает цену рублей на 150 на один узел. Я в своем контроллере тоже изначально CAN закладывал, т.к. у меня большой опыт работы с ним на пром. оборудовании. Но потом отказался от него, слишком он дорогой получается. В новой версии контроллера я его из схемы убрал.

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

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

В максе вопрос интерфейса стоять не должен, т.к. на линии всего два устройства: индикатор и контроллер.

[PeaceHaver]

Тема огонь, но толком как автоинженер ничего, окромя родной кан-шины, не вкуриваю....

Так подкиньте дровишек. Раз CAN для Вас родной, откройте секрет, почему несмотря на его очевидные недостатки (дорог, непривычен, непонятен), его все таки пихают в автомобили?

Ну, я хоть и заканчивал по специальности телематика, почему именно кан был выбран вопрос никогда не ставился. Вопрос всегда стоял вида "что теперь с этим делать?".

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

Но, собственно, что в 80-х подходило для быстрого и надежного широковещательного обмена данными небольшого кол-ва ЭБУ и исполнителей, перестало удовлетворять требованиям уж лет 10 назад точно, когда к общей шине подключили еще сверху системы комфорта и развлечения.

Крайний раз, когда я сталкивался с этим геморроем, это когда был учеником механика, а диагносту попался Туарег, в котором... Блин, как же описать. Короче, у него есть 3 ветки блоков управления: ветка силового агрегата (движок, коробка передач), системная (все необходимые приборы) и ветка инфортейнмент (кондей, обогрев, стеклоподъемники и прочее).

Так вот, через пару часов засыпания системы блок из одной ветки начинал кидать сигнал, блок из другой ветки почему-то (?) начинал поддерживать обмен, из-за чего просыпались все где-то 60 ЭБУ, и система просто высасывала АКБ. И никакой изоляции - все эти блоки подключены тупо к одной мешанине, и если будет реально плотный обмен данных, кто-то вообще не сможет транслировать.

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

В целом, он, конечно дорог. Но не требует затрат при эксплуатации (в отличие от сервера, к примеру). Крайний случай, если перебило эту кишку, то кузов и так ушел в утиль. Широкое вещание в реальном времени малыми объемами данных, при этом несколько способов контроля передачи данных. И, самое главное, за эти 20+ лет он отработан, на него выпускается продукция множеством поставщиков.

В целом, ситуация с описанным УАРТом схожая, только в промышленности - выпускается давно, долго и всеми. Уперлись в его пределы, ищутся пути выхода, но кто будет сруливать с наезженной колеи? Собственно, как обычно, все опыты пойдут в илитных марках за счет богатеньких буратин. Будем посмотреть-с.
Добавлено 01 Дек. 2014 в 23:40

Я согласен, что CAN намного стабильнее и лучше, НО использовать stm32 или CAN контроллер в поворотниках или термодатчике, да еще и драйвер нужен - это слишком.

Думаю, для народного байка это будет избыточно. У нас к примеру, жгут от Фабии поставляется только целиком (от бампера до бампера). Стоимость этого жгута - почти половина автомобиля. И я не утрирую: зачастую причиной списания авто является то, что кусок жгута, процентов 10, перемололо в труху о передний лонжерон. Этак, железо почти живое, можно все починить. Но этот жгутик в сборе ставит крест на авто.

[agat50]

Даже в 3х баксовом STM32F103 уже вижу "USB 2.0 full speed". Почему не его? Экономить один бакс на девайсе имхо смысла мало - проект как я понял на долгую перспективу, МК дешеветь и дешеветь будут.