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

[zap]

Посмотрел подробнее - увы, attiny25 не потянет трансивер

Причина - выходы AIN0/AIN1, которые я планировал использовать для дифф шины одновременно являются выводами DI/DO от USI, который я планировал использовать для полу-аппаратной реализации UART.

Поэтому придётся использовать tiny2313, у неё 20 ног зато есть полноценный полнодуплексный USART. Это, может, даже и к лучшему - UART совсем не будет мешать i-wire коду, всё-таки вручную дёргать биты довольно тонкая задача. Если SO20 слишком крупная, есть MLF-20 размером 4 на 4 миллиметра.

Подключение трансивера будет выглядеть как-то так:


Выводы A и B будут переключаться между Z-состоянием (в этом случае на них подтяжкой образуется "1" и "0" соответственно), это рецессивное состояние, и выводом "0" и "1" соответственно (просто переключая режим через DDRB ^= 3, регистр PORTB можно заранее загрузить соответствующим значением 2), это будет доминантное состояние. При этом можно смешивать устройства на 5В и 3.3В без проблем.

Компаратор настроим на генерацию прерываний по фронту и спаду.
UART будет гнать по запросу данные в микроконтроллер и обратно. Можно даже сделать через UART какие-нибудь настройки трансивера, например переключение между 8МГц (быстро, но неэкономно) и 1МГц (медленно, но жрёт немного). Пожалуй, также пригодится команда установки адреса устройства (чтобы трансивер сразу фильтровал "свои" пакеты от чужих и не беспокоил "материнский" микроконтроллер всякой чепухой).

Памяти тиньки хватит для буфферизации где-то 4 пакетов, это тоже хорошо.

Опенсорсность прошивки позволит, если будет необходимость, запрограмировать оставшиеся ноги на какие-нибудь несложные дополнительные функции, например можно генерировать ШИМ/меандр на одном из свободных выходов таймера и т.п.

Также можно одну ногу задействовать на сигнал BUSY - выставлять её в 1 пока трансивер ведёт передачу пакета и сбрасывать в 0 когда трансивер готов передавать новые данные.

[Андрей СШ]

Совмещение устройств 5 и 3,3 вольта - вряд ли. У tiny предел по напряжению на входе VCC+0,5 В.

Какую скорость может развить устройство с тактовой частотой 1 МГц?

Сколько повторных передач допускается?

Шина свободна если прошло 2N тау. А если устройство только что включилось и нет известного тау?

[i]

Что бы избежать переполнения таймера и не потерять точность измерения, можно использовать 16-ти разрядный таймер тактируемый тем-же клоком, что и ядро. Можно использовать 8-ми битный аппаратный таймер и программно его растянуть до 16-ти (но лучше все таки использовать честный).

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

вот тут, я извините, не понял.

Битовая скорость примерно в 200-300 раз ниже тактовой.

Повторные передачи явление нормальное из-за арбитража, если устройство имеет наименьший приоритет, то оно  может 100 раз  начинать передачу и 99 раз проигрывать в арбитражном суде. А вот если оно Х раз передевало и его ни кто не перебивал, но X раз подряд передача кончалась ошибкой, ему стоит задуматься о своем поведении.
У приемников наверное тоже нужно ввести ограничение Y, на количество пакетов подряд, которое оно само пометило ошибкой. Причем Y>X.
(Однажды наступил на грабли: из-за ошибки в коде, CRC иногда считалось неправильно, и пакет с таким CRC вызывал истерику на шине, шли постоянные повторы-отлупы...)

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

[Андрей СШ]

вот тут, я извините, не понял.

Да вроде всё понятно. Требования к передатчику по таймингам строже чем к приёмнику, это создаёт запас устойчивости.

Битовая скорость примерно в 200-300 раз ниже тактовой.

4000 бод.

Как включившееся устройство поймёт, что это интервал между пакетами, а не длинный тайм?

[i]

Ни как.
Оно либо зарубит недопереданный пакет, либо его передачу зарубят, либо два пакета дополнят друг друга и будут оба зарублены.
Короче будет небольшая драчка (0, 1 или 2 пакета), а после наступит синхронизация. Это как новый сотрудник ... есть ммм.. некоторая заминка на адаптацию. Можно заставить его некоторое время прислушиваться к шине, а уж потом вылезать с предложениями.

[zap]

Битовая скорость примерно в 200-300 раз ниже тактовой.

4000 бод.

8000000/200 = 40000.
На двух мегагерцах мы получали что-то около 9600.
Ну да, на 8МГц так и выходит в 4 раза быстрее.

[Андрей СШ]

будет небольшая драчка

Поворачиваем ключ зажигания - все устройства запитываются +/-100 мс и наблюдаем на шине трэш и угар.
Можно действительно заставить все устройства выжидать немного и опционально добавить на шину генератор стартового пита. Заодно этот генератор сообщает всем скорость обмена принятую на данном велосипеде.

На двух мегагерцах мы получали что-то около 9600.

Речь шла о Tiny в экономичном режиме 1МГц, так что - 4800.

[i]

будет небольшая драчка

...
Поворачиваем ключ зажигания - все устройства запитываются +/-100 мс и наблюдаем на шине трэш и угар.
...

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

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

[Valdior]

Я за can,т.к. это специально для автомобильных тем было разработано. При больших мощностях воростают помехи, и другие протоколы могут не справиться с ними, потери данных и все такое прочее. В моей практике было такое, что на электромобилей из-за помех и плохой работе отказались от rs-485 в пользу can, и все суперно работает. Скорость отличная.
Использую сейчас CAN в связи контроллера и панели индикации на велике, протокол писал сам, очень доволен. Пару десятков цифр успевают отправить в одну а потом и в другую сторону на частоте 20кГц, и это ещё вроде не предел.

[i]

Я тоже использую CAN-драйверы ISO1050. Они прекрасно вписались в i-wire, добавив гальвано-развязку и отличную помехоустойчивость, оставив при этом адаптивную скорость передачи, чего нет у CAN-контроллеров.

[Youyu]

Кто-нибудь знает что это за пункты протокола2 выделенные желтым?