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

[i]

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

Идея iwire проста "как карандаш за 2 копейки" : бит информации определяется не длительностью тайма (time - время) или пита (pit - ямка), а их отношением (больше-меньше).
Это снимает требование других протоколов к точности измерения времени, позволяет замедлять или ускорять передачу даже в пределах одного байта (не важно в каких попугаях измеряется удав).

Не хочу сказать, что так же просто написать программную реализацию физического уровня, но точно знаю, что это возможно. "Не боги горшки обжигают."

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

[Torvald]

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

Да, в общем-то, основная идея и так понятна. Но можете продолжить.

UPD: На 13а тиньке реализовать можно, но с программным UARTом не хочется связываться. На 2313 значительно проще, но у него 20 ног. Может быть проще сишную библиотечку создать? Подцеплять её хоть к AVR, хоть к ARM - кому что больше по душе. И лишний корпус (пусть даже восьминогий) не потребуется - для малогабаритных устройств может быть важно.

[xek]

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

Я не очень понимаю, чем плох вариант взять CAN и иметь радость не решать целый ворох проблем, ведь есть микроконтроллеры со встроенным CAN интерфейсом. Ну да, плюс наверняка нужна развязка(которую может быть можно наколхозить), но вряд ли в сумме вся рассыпуха + мк будет дороже 3-4$ в сумме.

Электровелосипед — это и так недешевое удовольствие. В чем проблема, что универсальный модуль блока поворотников будет на 200р дороже? Да, нельзя будет сделать BMS где поячеечно будет свой контроллер. Но как бы и зачем? Покажите хоть одну продаваемую BMS с такой модульностью? Я лично знаю одного-единственного производителя специализированных микросхем под такого рода решения.

Ресурсы человеческие наши здесь весьма ограничены, шанс сделать вторую Arduino (в плане массово популярности) — мал. Может быть лучше сильно ограничить условия ТЗ и сделать какое-то минимально осязаемое решение для проблем 95% людей здесь?..

Ну просто проектирование велосипеда с проектирования протокола — это «проектирование велосипеда»...
Предлагаю максимально точно описать с начала, как будет устроен велосипед на уровне блоков (контроллер - модуль дисплея - bms) и т. д., описать требования и хотя бы составить план работы. Иначе нас ждет «блеск и нищета опенсорса».

Обсуждение большого и сложного хардварного проекта свелось к обсуждению софтового протокола...

[Андрей СШ]

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

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

Когнитивный диссонанс.

Фичу с лишней единицей на конце пакета так никто и не пояснил.

[user]xek[/user], в общем комиссии по стандартам работают так:
1. Кто нибудь (кому сильно надо или много заплатили) в одиночку готовит черновик.
2. Остальные выссказывают своё "фи".
3. "Кто нибудь" дорабатывает по замечаниям.
{повторить 2,3 N раз}
3+N*2+1. Все голосуют за принятие/против принятия стандарта.

Осталось найти человека, который захочет нарисовать блок-схему велосипеда. Иначе дело не сдвинется.

[i]

...
Фичу с лишней единицей на конце пакета так никто и не пояснил.
...

А разве был вопрос?
Значит я его либо не понял, либо не видел.

[Андрей СШ]

Это был неявный вопрос.

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

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

Или я чего то недопонял.

[i]

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

[Андрей СШ]

Тогда всё намного проще.

Я как раз только что реализовал приём/передачу байта по этому протоколу.

Можно попросить [user]zap[/user]a продолжить рассказ. Буду добавлять верхние уровни.

[i]

Хочу предупредить о подводных камнях.
1) Приемник и передатчик должны работать одновременно, а не по очереди - это позволит решать коллизии без порчи пакетов и переключений режимов.
2) Приняв стартовый пит, устройство, которое имеет пакет для передачи, должно начать передачу - это позволит пакетам сортироваться прямо на шине, первым пройдет ответ "А", потом "B" и последним "Z". Также это позволит побитно-одинаковым пакетам сливаться в один.
3) Между пакетами нужно ввести паузу, что бы пакет был обработан. Для этого я беру удвоенное число принятых бит и отсчитываю столько же тау последнего пита.

[Steel RAT]

Я тоже вставлю полушку.
В качестве основного контроллера желательно использовать готовую "коробку".
К примеру, дешевые контроллеры производства GreenTime.
Чтобы каждому не надо было травить плату, паять детали, изобретать корпус...
Переделка методом перепрошивки имеющегося чипа. Либо его заменой.
На дополнительно используемые выводы (интерфейс связи) паяется простая схема согласования под избранную шину.
Многим может она вообще не потребуется. 

Я предлагаю:
1. Определится с таким аппаратным решением.
2. Выбрать интерфейс связи/программирования.
3. Закрепить протокол. Если надо, масштабируемый.

[i]

Не надо выбирать один контроллер "на все времена", времена меняются (как и смартфоны).

[Андрей СШ]

Мне до этих камней ещё плыть и плыть. У меня пока связь точка-точка причём в одну сторону. Хотелось бы пока определиться с:
1. Форматом пакета (включая ограничения на размер).
2. Таймингами.
Предлагаемые +/-25% мне кажутся неоптимальными. Поскольку разница в длинне time-ов не может быть меньше чем один квант времени, то пит получается минимум четыре кванта. Если принять +/-50% (как на исходной диаграмме), то пит будет два кванта. Выйгрыш в скорости или помехоустройчивости.


Можно использовать изменяемую скорость передачи i-wire в электротранспортной шине:
1. Устанавливаем две стандартные скорости обмена на шине.
2. Быстрое устройство на маленькой скорости сообщает всем, что на следующие 100 мс занимает шину.
3. Медленные устройства отключаются на 100 мс.
4. Быстрое устройство передаёт HDTV на высокой скорости другим быстрым устройствам.
5. Все возвращаются на низкую скорость.

[Андрей СШ]

По моему два пита, для определения конца пакета мало. Может получиться, что устройство чуть побыстрее отсчитает 1,9 пита и начнёт передачу, а устройство помедленнее досчитав до 2,1 наткнётся на пит первого.

[i]

Формат. Размер пакета ограничивает CRC8, если перейти на CRC10 или CRC16 выбор размера становится намного шире.

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

Скорости. Можно и так, а можно шибко скоростные устройства посадить на отдельную шину и не обязательно iwire или CAN (шина мультимастер всегда будет медленнее сингл-мастера).


Длительность тайма после последнего пита:
2 тау - конец пакета (шина занята)
3 тау - проверь CRC (шина занята)
4 тау - пакет передан верно (шина занята)
2N тау - шина свободна можно начинать передачу следующего пакета.

[zap]

По моему два пита, для определения конца пакета мало. Может получиться, что устройство чуть побыстрее отсчитает 1,9 пита и начнёт передачу, а устройство помедленнее досчитав до 2,1 наткнётся на пит первого.

Оно не может начать передачу через 1.9 "пита" (на самом деле пит - это доминантное состояние, а здесь мы имеем рецессивное состояние длительностью два пита, [user]i[/user] использует термин тау для обозначения длины пита) т.к. после рецессивного состояния длиной 2 тау надо выждать ещё один тау (он даётся на проверку CRC8) после чего на шине может появиться флаг ошибки (если кто-то на шине неверно принял пакет), а может и не появиться... так что следующий пакет может начаться не менее чем через 4 тау после последнего пита... а если вводить дополнительные требования по времени обработки полученного пакета устройствами, то и больше. Через 4 тау (плюс какая-то дельта на разогрев) может начаться лишь повторная передача в случае если на шине был выставлен флаг ошибки (кто-то криво принял пакет).

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

Касательно 25% длины. Я предложил 25% как нижний предел, 50% даже лучше. Просто при разнице длины тайма в 1 такт от тау очень легко упасть в яму округления отсчётов таймера, и получить длительность пита = тау -- что делать в таком случае? В наших реализациях сейчас принято, что если тайм <= тау, то это 0, но это такое пограничное решение...

Касательно CAN. Дело хорошее, но сильно ограничивает выбор микроконтроллера. CAN имеют далеко не все микроконтроллеры, и это объясняется очень просто: за каждый экземпляр проивзодитель башляет разработчику протокола. Соответственно, "копейка малая" накидывается к цене всех микроконтроллеров с CAN контроллером. Плюс к тому, сопряжение CAN с обычным компьютером или смартфоном - та ещё задачка.

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

[Андрей СШ]

С длительностью межпакетного интервала более или менее понятно.

Что касается "не слушать повторную передачу", то есть проблема: вдруг это не повторная передача, а кто то с более высоким приоритетом влез и передаёт другое сообщение?

Стандарт на длину интервалов должен быть разным для приёмника и передатчика.
передатчик должен давать +/-50%
приёмник определяет по тайм<тау.

[Андрей СШ]

Ещё два плюса трансивера на Tiny
1. Устройства с лишним процессорным временем могут обойтись без трансивера.
2. Устройства вообще без мозгов могут быть подключены через трансивер, генерирующий стандартные пакеты по дискретным сигналам.

Идея устройства на шину:
Красная лампочка, которая подсчитывает количество ошибок передачи в единицу времени и загорается при превышении порога.

[zap]

Что касается "не слушать повторную передачу", то есть проблема: вдруг это не повторная передача, а кто то с более высоким приоритетом влез и передаёт другое сообщение?

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

Кстати, меня тоже зовут Андрей, и [user]i[/user] - тоже Андрей. Я брякнул не подумав .

Стандарт на длину интервалов должен быть разным для приёмника и передатчика.
передатчик должен давать +/-50%
приёмник определяет по тайм<тау.

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

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

Впрочем, если трансивер будет аппаратный, такой проблемы не будет - он всегда будет работать на 8Мгц от встроенного RC генератора. Впрочем, не исключено что для экономии энергии можно реализовать режим 1МГц от встроенного RC, вот тогда и встанет проблема общения медленных с быстрыми.