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

[i]

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

[zap]

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

В общем я имел ввиду, что надо сначала посчитать устройства, которые могут быть подключены к шине. Ограничение в 256 устройств выглядит тесноватым. У некоторых одних балансиров 200 штук.

Да даже если 200 55 оставшихся адресов вполне хватит.
При таком количестве можно устроить уже несколько раздельных шин, возможно с шлюзом.
Но электропаравоз не входит в список приоритетных целей, моя цель - электровелосипед, максимум электромотоцикл.
Нормальный электроавтомобиль потребует электроники на порядок сложнее, для автомобилей есть CAN.

19200 бод

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

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

Доставка сообщений за определённое время не гарантируется

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

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

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

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

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

Никакого питания.

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

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

Да и при необходимости питание - это всего один доп провод в шину, какие проблемы? Надо 12 вольт - добавьте ещё один провод. Надо 24 - ещё один. К протоколу это не имеет никакого отношения.

Добавлено 02 Дек 2014 в 20:18:00

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

iWire цены бы не было если бы он был реализован аппаратно.
А так - увы...
Хотя... гм... можно реализовать на какой-нибудь 13й (пусть даже на 25й) тиньке чистый трансивер i-wire как отдельное устройство.
С обратной стороны от него можно вывести на тот же UART/SPI/i2c.
Вот тебе и дешёвая аппаратная реализация в 8-ногом таракане.
Да ещё и с дифференциальным выходом сразу (открытый коллектор с подтяжкой)...
Через этот таракан хоть к блютузу, хоть к ПК подключай...
Интересная идея.

[Андрей СШ]

640 кбайт хватит всем.

Допустим 256 адресов достаточно (я всё таки считаю, что у балансиров должна быть своя шина до БМС, а на общей шине сидит только БМС), но тогда встаёт вопрос как эти адреса назначать. Сидеть с программатором и прошивать каждому в EEPROM или восемь джамперов на каждом устройстве?

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

Гарантия времени доставки очевидно не подразумевает борьбу с обрывом проводов или замыканием. Она подразумевает, что пропускная способность шины заведомо больше чем генерируется данных.
Как пример: стандарт устанавливает предел в 256 устройств на шине, максимальный размер пакета  32 байта, каждое устройство должно выдерживать паузу между передачами в (время передачи пакета)*512, при скорости 19600 гарантируется появление окна для передачи в течение 7-и секунд.

К протоколу передачи данных питание действительно отношения не имеет, но речь вроде идёт об обеспечении совместимости устройств разных производителей, будет некрасиво если левый поворотник питается от пяти вольт, а правый от 17,5.

Если кому интересно, могу поговорить с начальством об открытии спецификации, ...

?

[PeaceHaver]

У меня такой вопрос, чисто теоретический: а можно сделать две шины? Одна, подороже и качественней будет как ЦНС, а другая, полегше, подешевле и менее ответственная - как переферическая? Соответственно, первая будет, как в коробках, отвечать за двигатель/кпп и все остальное, что должно приводить в движение а/м. А вторая - за свет, индикацию, обогрев и что-то еще. Между ними сделать ретранслятор как-то. Ну, это чисто общая идея, я не особо шарю в специфике офк.

[zap]

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

[zap]

но тогда встаёт вопрос как эти адреса назначать. Сидеть с программатором и прошивать каждому в EEPROM или восемь джамперов на каждом устройстве?

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

К протоколу передачи данных питание действительно отношения не имеет, но речь вроде идёт об обеспечении совместимости устройств разных производителей, будет некрасиво если левый поворотник питается от пяти вольт, а правый от 17,5.

Об этом пусть голова болит у сборщика, уж если он возьмёт такие разные поворотники значит ему это зачем-то надо.

Если кому интересно, могу поговорить с начальством об открытии спецификации, ...

?

Дак никому не интересно было, вот и не спрашивал.
А так-то да, если сделать аппаратный трансивер на дешёвой 8-ногой тиньке по-моему получится отличная штука.
С дифф передачей, компаратор у тиньки встроенный, жаль только порт нельзя настроить в режим pull-down, придётся внешний резистор для этого пользовать (тогда уж два для симметрии - один на VCC на линию A, второй на GND на линию B). Ну и UART там сделан через задницу, но извернуться можно.

[Андрей СШ]

все адреса назначаются вручную

Об этом пусть голова болит у сборщика

Очень юзер-френдли.

Интересно как можно с компьютера по шине назначить адреса если шина без них не работает.

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

Описание протокола интересно для общего развития, маловероятно, что дойдёт до его использования.

[i]

..Интересно как можно с компьютера по шине назначить адреса если шина без них не работает...

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

А так-то да, если сделать аппаратный трансивер на дешёвой 8-ногой тиньке по-моему получится отличная штука.

Отличная идея... и авторских прав не нарушит(код закрыт) и попользоваться можно.

P.S. Начальство проявило интерес к идеи открытости протокола. Во всяком случае, категорического отторжения не было.

[Андрей СШ]

Отличная идея... (код закрыт)...

В теме под названием "Open source & open hardware", Столмана на Вас нет.

Все решаемо.

MAC - это уже адрес, если он есть то можно не заморачиваться с назначением адресов. Остальные способы требуют спец оборудования и умения собирать ядро линукс под БЭСМ-6.

[i]

В open source применяются микросхемы у которых то же есть source, как минимум описание аппаратной части на спец языке, еще они могут содержать firmware (все "аппаратные" микрухи CAN, USB, Wi-Fi, Bluetooth и прочее по-сути микроконтроллеры, с масочной программой и аппаратной обвязкой). Вам обязательно нужно знать, что у них конкретно внутри, и без этого их использование религия не позволяет?
МАС конечно адрес, но его нельзя использовать для маршрутизации, поэтому помимо MAC используют IP-адрес.
Я не умею собирать ядро линукса под БЭСМ-6, поэтому подключаюсь к устройству (или куче устройств) через мост USB-iwire(самодельное "спецоборудование") или USB-UART(покупное).

[TRO]

MAC - это уже адрес, если он есть то можно не заморачиваться с назначением адресов. ....

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

[Андрей СШ]

Ну допустим мы выбрали вариант с MAC адресом, как диапазоны между производителями распределять? Можно конечно продавать их за 1000$ в поддержку форума.

В open source применяются микросхемы ...

И это печалит Столмана, Аптона, как и многих других людей.

религия не позволяет?

Нет, предусмотрительность. Вот куплю я у вас два трансивера, сделаю прототип, а вы завтра вместо ATtiny13 в SOIC-8 закажете в китае ASIC в BGA или просто решите, что это нерентабельное занятие.

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

И вообще о чём мы с Вами спорим? Я полностью согласен, что не надо делать никакой адресации а просто составить список команд, которые будут исполняться каждым устройством по возможности.

[i]

"Спецоборудование" это atxmega32a4u - просто это AVR с USB на борту.

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

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

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

[Андрей СШ]

Если можно не учитывать MAC, то зачем он вообще нужен. Если нарвались на одинаковый MAC, то его нельзя изменить, потому что для этого надо дать команду изменения MAC по шине, а на неё отреагируют оба устройства с одинаковым MAC или городить вероятностный алгоритм.
Замена МАС вручную - это опять программатор или джамперы.

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

просто это AVR с USB на борту.

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

Что касается адресации ячеек:
1. Согласен, что внятно их пронумеровать можно только вручную (программатор/джамперы/контрольные лампочки).
2. Желательно сделать протокол, в котором нумерация не обязательна. Это позволит быстро ввести всё в работу за счёт времени, которое будет потрачено потом на поиск того кто жалуется.
Для облегчения ситуации ввести уточняющие коды жалоб "перегрев.двигатель" и "перегрев.батарея" отдельно.


А ещё я из картинки в прошлой теме не понял как обнаруживается начало передачи в i-Wire. А нет уже понял.

[Torvald]

А где можно почитать про уже неоднократно упомянутый здесь "i-wire"? Яндекс про такой протокол почему-то не знает. Вот далласовский 1-Wire мы с ним оба знаем, а "i-wire" - нет.

[Андрей СШ]

Где то там:
https://electrotransport.ru/index.php?topic=7914.0

Посмотрел на диаграммы i-Wire - увидел, что если последний бит в передаче 0, то к концу добавляется паразитная единица, а если 1 - то не добавляется. Если начать чтение не с начала, то можно вместо 10101010 получить 01010101.

[zap]

P.S. Начальство проявило интерес к идеи открытости протокола. Во всяком случае, категорического отторжения не было.

Ага, попробую тоже прозондировать со своей стороны. В принципе, по сути нужна только спецификация... имплементацию я готов сделать с нуля под тиньку на асме самостоятельно. И с авторскими правами проблем не будет, да там всё равно код придётся дописывать, UART часть там не проще iWire получится, разве что ногами придётся вручную дёргать не каждый бит, а каждые 8.

[zap]

В базовых чертах физический уровень протокола iWire расписан в этом сообщении.
Для простой (не-дифференциальной) шины нужен всего один сигнальный провод, помимо земли.
Для дифференциальной шины - соответственно, два.
Для дифференциальной шины мы используем трансивер CAN, правда для нашей задачи используем дорогой ISO10500 с гальванической развязкой. Устойчивость к помехам выше всяких похвал, шина продолжает работать практически без ошибок в условиях мощнейшей помехи от соседних проводов (меандр 50-100 килогерц, ток в несколько ампер).

Шина имеет "доминантное" и "рецессивное" состояния, как многие другие протоколы.
Условно говоря, все передатчики подключены открытым коллектором к шине. Шина подтягивается к плюсу питания резистором.
Открытие любого количества выходных транзисторов передатчиков "прибивает" шину к земле.
"Камень" (доминантное состояние) всегда бьёт "бумагу" (рецессивное состояние).

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

После пита следует тайм. Тайм есть свободное состояние шины до начала следующего пита.

Ноль или единица определяется длительностью тайма. Если хотим передать логическую 1, тайм должен быть длиннее пита. Если хотим передать логический 0 - тайм должен быть короче пита. Насколько короче - вопрос спорный, я бы сказал достаточно 25% длительности тайма туда или сюда.

Конец пакета определяется таймом длиной два пита. То есть, если после пита следует тайм в два раза длиннее, в этот момент определяется конец пакета.

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

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

На этом пока прекращаю грузить моск если интересно, могу продолжить.