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

[zap]

Так это не просто минус, это тупо бесполезно. Микроконтроллеров с UART как грязи, а с CAN - по пальцам пересчитать, и цена негуманная абсолютно (атмеги с CAN стоят за 300р) и выбор никакой (например, тинек с CAN не бывает).

Чем больше я думаю идею с RS485, тем больше она мне нравится. Минимум внешних компонент (одна микруха за 20-30р), можно подключить на шину такую небольшую штучку с трансивером, после этого можно к шине подключаться по радиоканалу. Например, можно велокомп сделать из телефона, лишь бы был блютуз и возможность запуска апплетов (на джаве, например, или на питоне, как на моей нокии).

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

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

А тут за 20-30р получаем чумовую помехоустойчивость. Я грустно подумал про 16-килогерцовый ШИМ токами по 30-60 ампер, идущий через фазные провода, которые почти наверняка пересекутся с шиной обмена данных, и понял что никакие CRC нас не спасут. Будет тупо повтор передачи по пятьдесят раз, пока всадник не смилостивится и не отпустит газ, в этот момент может пара пакетов и проскочит, а так... 

[i]

Микросхема действительно достойная и не очень дорогая (чуть дешевле микроконтроллера). Буду иметь её в виду, для передачи сигналов на расстояния в метр и более.
В приложении статья, раскрывающая некоторые вкусности CAN в физическом плане.
По самой шине можно пускать хоть UART, хоть 1ware, но для детектирования коллизий (когда два узла начинают одновременную передачу) аппаратный UART не годится, так как не может заткнутся, пока не отбарабанит байт целиком. Тут нужен либо аппаратный CAN-контроллер, либо программная (или программно-аппаратная) реализация нечто подобного, умеющая работать в мультимастеровом режиме.

[zap]

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

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

• [b-b]CAN[/b-b], плюсы:
  
  
  
  • Аппаратное разрешение коллизий
  • Аппаратный контроль целостности
  • Отличная помехозащищённость
  • "Имидж" протокола для транспортных средств
  Минусы:
  
  
  
  • Очень ограниченный выбор микросхем с CAN
  • Дороговизна микросхем с контроллером CAN
  • Отсутствие "маленьких" микроконтроллеров с CAN (минимум ATMEGA16M1)
  • Очень чувствительна к отклонению тактовой частоты (0.5%)
  • Очень дорогие устройства для сопряжения CAN с компьютером
  • Маленький размер пакета (до 8 байт)
• [b-b]RS485/UART[/b-b], плюсы:
  
  
  
  • Два протокола в одном (компьютер можно подключать к отдельным устройствам по UART, устройства между собой могут общаться по RS485)
  • Дешевизна микросхем трансиверов
  • Очень широкое распространение микроконтроллеров с UART
  • Возможно создание простых дешёвых устройств для сопряжения шины с Bluetooth (аналог для CAN >$100)
  • Отличная помехозащищённость (по-моему, лучше CAN т.к. не использует "открытый коллектор")
  Минусы:
  
  
  
  • Отсутствие аппаратного арбитража
  • Фиксированная скорость передачи (i)
• [b-b]I²C[/b-b], плюсы:
  
  
  
  • Широкий выбор микроконтроллеров с I²C
  • Аппаратный арбитраж в режиме multi-master (аналогично CAN)
  • "Слышит" шину в режиме спячки, просыпается если на шине выставляют нужный адрес
  • Произвольная частота тактирования шины (в разумных пределах, естественно)
  Минусы:
  
  
  
  • Шина "общий коллектор", что усложняет создание дифференциальной шины
  • Дороговизна устройств для сопряжения с компьютером
• [b-b]"Самопал"[/b-b], плюсы:
  
  
  
  • Теоретически возможна реализация на любом МК
  • Возможность побитного арбитража, аналогично I²C и CAN
  Минусы:
  
  
  
  • Полноценная реализация протокола займёт много памяти
  • Программная реализация отъест от и без того скудной производительности процессора
  • Очень медленная скорость передачи

Можно добавлять в список, надеюсь наличие модераторских прав позволит мне менять этот список и через день, и через два Также принимаются аргументы за исключение любого из перечисленных выше пунктов из списка (например "да это всё чушь, микросхемы с CAN контроллером очень дешёвые и доступные! вот ссылка рраз ддва и ттри").

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

[zap]

Подкину идей разной степени бредовости:

• Раз и CAN, и I²C используют шину с общим коллектором, может каким-то образом возможно сопряжение выходов I²C с CAN трансивером? Это бы нам дало дифференциальный помехозащищённый I²C. Правда, не очень понятно что делать с шиной тактирования, как я понимаю, CAN трансиверы содержат только один канал. Короче, надо смотреть документацию на CAN трансиверы.
  
• Для "самопала" можно попытаться использовать протокол SPI. Плюс SPI в том, что это тупой бит-сдвиговый протокол, что положишь в регистр, то он и выдвигает под бой барабана (шину тактирования). Шину MOSI можно подключить к MISO через резистор (и далее на общую шину, возможно через RS485 трансивер), получим полудуплекс аналогично тому, что я выше предлагал для UART - посланный байт тут же окажется в приёмнике. Сличив посланный и принятый байт, можно узнать, есть ли кто на шине кроме нас или нет.

[i]

Протоколы были разработаны для разных целей:
UART - для телетайпов;
RS485 - улучшение помехозащищённости  UART (ввод дифференциальной шины);
I²C - для разговора микросхем внутри одного устройства (телевизор например);
CAN - для автомобилей;
SPI - для программирования микроконтроллеров.

Ясно, что в чистом виде ни один нам не подходит, либо дорог, либо туп, либо беззащитен.
Мне больше нравится "самопал", так как теоретически в него могут войти плюсы от любого протокола, а их минусы либо нивелированы, либо отсутствуют. Можно от одних взять физику, от других логику. Можно гибко подходить к использованию протоколов, т.е. использовать несколько их, каждый там где он наиболее удобен.
Для этого нужно прикинуть скелет ЭТС и посмотреть, что/где/куда должен сообщить/выполнить/узнать/отобразить, какие объёмы данных куда идут, как часто и кому они требуются и пр. и пр...

[i]

Ресурсы микроконтроллеров можно наращивать количеством самих микроконтроллеров. Если не ставить перед собой задачу всё упихать в одно устройство, то вполне возможно решить проблему с нехваткой ресурсов.
В случае BMS, нужно контролировать только напряжение на каждом элементе (можно ещё и температуру) и ток на всей батарее. Это можно сделать с помощью множества компараторов, оптронов, супервизоров, мультиплексоров и одним мегаконтроллером, который ещё и мотор будет крутить и на экране картинки рисовать. А можно насадить на каждый элемент свой микроконтроллер, на батарею свой, на мотор свой, на экран свой. Использовать микроконтроллеры как универсальные кирпичики. И общаться они могут по разному, например внутри батареи они могу говорить на своём языке, а вся батарея в целом - на общем.

[zap]

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

Наращивать ресурсы количеством можно только если нет более дешёвого способа обойтись без этого. Геммороиться с кучей микроконтроллеров тоже не сахар - чего стоит одно прошивание 17ти микроконтроллеров. К тому же микроконтроллеры ощутимо подорожали за последний год. В общем, Ваш подход неоптимален с точки зрения ресурсов: фактически Вы предлагаете выделить отдельный микроконтроллер в качестве драйвера шины. Но это неоптимально, так как кроме МК придётся ещё ставить трансивер. И суммарная стоимость всей этой катавасии приблизится к стоимости МК со встроенным CAN.

Хм, хотя если выделить отдельный МК... он мог бы устроить "дифференциальную шину" самостоятельно, дёргая двумя ножками в противофазе, например. Тогда внешний трансивер не нужен. Интересная мысль, как Вам? Можно разработать такой публичный "драйвер шины" - готовую прошивку для какого-то мелкого микроконтроллера. Общение между ним и микроконтроллером - по UART, например. Тогда можно будет подцепиться и компьютером к этой шине.

P.S. В случае BMS кроме напряжения и тока Вам обязательно надо считать ампер*часы и, желательно, ватт*часы, потому что это моментальные значения и в случае вынесения этих функций в велокомп погрешность подсчётов существенно вырастет за счёт задержки передачи. И гора компараторов, оптронов, супервизоров и мультиплексоров в BMS не нужна, я Вас уверяю, точно так же, как можно обойтись без микроконтроллера в каждом канале.

[detoxic]

с таким подходом вспотеете писать кучу ляпушек и заплаток.
чтобы надежно и дешево - это rs485 физика и modbus rtu сверху. но в этом случае обработка сообщений в некоторых приложениях может вызвать остановку основной программы (смотря как написать конечно)
а чем LIN не устраивает в AVR? все бесплатно

[av-master]

а чем LIN не устраивает в AVR? все бесплатно

идеологически LIN в AVR должен плохо работать. так как продвигается microchip-ом

[i]

RS485 передает 0 и 1 сменой полярности диф. пары, т.е. диф напряжение присутствует всегда, в той или иной полярности. Если два мастера на шине одновременно выдадут разные значения, то возможно КЗ по питанию.
CAN либо выдаёт диф.напряжение одной полярности (dominant), либо нет (recessive). КЗ возможно только при неверном соединении шины.
Процу можно дёргать только одной ногой, вот только второй провод дифпары будет привязан к земле или Vcc. Чтобы отвязать дифпару от питания и нужна интерфейсная микруха.

modbus rtu сеть с одним главным и кучей подчинённых.
"Обычно в сети есть только один клиент, так называемое, «главное» (англ. master) устройство, и несколько серверов — «подчиненных» (slaves) устройств. Главное устройство инициирует транзакции (передаёт запросы). Подчиненные устройства передают запрашиваемые главным устройством данные, или производят запрашиваемые действия. Главный может адресоваться индивидуально к подчиненному или инициировать передачу широковещательного сообщения для всех подчиненных устройств. Подчиненное устройство формирует сообщение и возвращает его в ответ на запрос, адресованный именно ему. При получении широковещательного запроса ответное сообщение не формируется." Из википедии.
Таким образом, что бы мастер узнал о каком либо событии, он должен напрямую спросить об этом, значит он должен знать всех участников сети и кто за что отвечает и регулярно их опрашивать.
Не подходит ИМХО.

[zap]

Прочитал про LIN - то же самое:

    * В основу LIN положена концепция "single-master/multi-slave"

Что же до КЗ по диффпаре, это легко лечится резистором последовательно со всеми выходами. Трансивер RS485, как мне кажется, должен быть на это расчитан изначально. В отличие от RS422 он изначально придуман для создания сети из равноправных устройств.

And now the most important question, how does RS485 function in practice? Default, all the senders on the RS485 bus are in tri-state with high impedance. In most higher level protocols, one of the nodes is defined as a master which sends queries or commands over the RS485 bus. All other nodes receive these data. Depending of the information in the sent data, zero or more nodes on the line respond to the master. In this situation, bandwidth can be used for almost 100%. There are other implementations of RS485 networks where every node can start a data session on its own. This is comparable with the way ethernet networks function. Because there is a chance of data collosion with this implementation, theory tells us that in this case only 37% of the bandwidth will be effectively used. With such an implementation of a RS485 network it is necessary that there is error detection implemented in the higher level protocol to detect the data corruption and resend the information at a later time.

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

[detoxic]

лин продвигается консорциумом LIN http://www.lin-subbus.org/
производителям мк лишь остается соответствовать спецификациям, не взирая на бренды
в мультимастерных сетях должен быть механизм раздачи прав между мастерами самому главному, вообщем те же вилы

[zap]

Забавный протокол LIN. Буду вникать, вдруг он нам и в самом деле подойдёт.

Спецификацию выкачал с сайта, если кому-то не хочется там регистрироваться, вот она: http://cs.ozerki.net/zap/lin_spec.zip

[i]

...Что же до КЗ по диффпаре, это легко лечится резистором последовательно со всеми выходами. Трансивер RS485, как мне кажется, должен быть на это расчитан изначально. ...

Это все так. Под КЗ шины я подразумевал, что шина попадает в запрещённое положение, когда на обоих проводах 0 или 1 или нечто третье, зависящее от построения. Испорченную передачу, в лучшем случае придётся начинать заново, в худшем - мк могут встать в ступор.

[zap]

В общем, посмотрел я LIN - тот же CAN, только похуже. И очень сложный в реализации. Подразумевается что на шине есть некий "мегамозг" (что-нибудь не меньше атмеги 16й, по моим прикидкам), который бьёт в барабан и подтирает сопли всем дочерним устройствам, и следит чтобы они не подрались. И тоже открытый коллектор, и никакого диффсигнала.

Не годится, увы. У I²C перед LIN одни преимущества и никаких недостатков.

Теперь буду смотреть Modbus RTU.

[i]

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

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

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

[zap]

Зачем перебираем - надо посмотреть, может всё уже придумали до нас, и мы зря только очередной раз придумываем велосипед. Недаром любая научная работа начинается (во всяком случае, должна) с раздела "обзор предыдущих работ по данной теме".

Что мне конкретно хочется от него:

- Скорость передачи достаточную для динамического отображения параметров ТС на экране компьютера (предположим, экран большой (лаптоп), влезает много данных, ведётся регистрация всех параметров по маршруту). То есть, например, амперы/вольты/ампер*часы/ватт*часы/напряжения ячеек (предположим, 32 штуки), обновляться данные на экране (по максимуму) где-то 4 раза в секунду. При этом пропускная способность шины должна быть занята не более чем на 10%, чтобы МК успевали заниматься ещё и другими делами кроме передачи данных. Итак, порядка 100 байт в посылке, 4 раза в секунду, и это 10%, значит общая пропускная способность должна быть 4000 байт в секунду, или 40 килобит. Довольно сурово.

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

- Помехоустойчивость. Ну это как водится.

- Равноправие всех учаснегов шины. Никаких "мастеров" и "рабов". Ну, тут у нас потребности сходятся.

- Абсолютно минималистичный базовый протокол, для того, чтобы его реализация влезала даже в МК с 1-2 килобайтами памяти. По этому параметру мне не понравился ни LIN, ни Modbus, слишком много фигни они тащат за собой из прошлого.

- Малое потребление, желательно без дополнительных телодвижений (типа посылки микросхемы в "спячку"). Например, упоминавшийся ранее CAN трансивер SN65HVD1050 всем хорош, но потребление аж 10 миллиампер это слишком уж дофига - такая BMS посадит аккумулятор велика за месяц простоя. Трансивер MAX487, например, потребляет всего 130мкА - вот это мой размерчик.

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

[av-master]

Всем требованиям озвученым выше соответствует CAN. аппаратно как представлен в огромном количестве контроллеров. у микрочипа например
dsPIC33FJ256GP506-I/PT   16бит, 256K FLASH, (10x10, шаг 0.50), 0K EEPROM, 16К ОЗУ, 40 MIPS, CAN   TQFP-64 - 5.3 у.е.
PIC32MX795F512L-80I/PT   32 битный микроконтроллер, 100pin, 512kB Flash, 128kB RAM, USB OTG, Ethernet, CAN   TQFP - 9.5 у.е. можно и графику и линукс поднять.
PIC18LF2480-I/SO   8 битный микроконтроллер, CAN, аналог 258 / 28 Pin, 16 KB EnhFlash, 768 RAM, 25 I/O, Pb Free   SOIC - 4,5 у.е.
MCP2510-I/SO   Формирователь CAN протокола / Stand-alone CAN Controller, I temp   SOIC-18  CAN-для любого контроллера - 3,2 у.е
MCP2551-I/SN   Трансивер / High Speed CAN Transceiver   SOIC-8 - 1у.е.