Раздача адресов i2c

Shtopor

Добрый день любимый форум. Разрабатываю хитрое модульное устройство. Решаю вопрос присвоения адресов модулям на шине I2C.

Если кратко:

Кратко

Если подробно:

Подробно

Есть большая плата с микроконтроллером, есть маленькие платы - модули, у каждого есть маленький микроконтроллер. Модули 99,9% времени должны быть в глубоком сне. Материнский МК 99,8% времени находится в глубоком сне. Модули (в основном по одиночке, но иногда и вместе, человеческий фактор) иногда просыпаются от внешнего пребывания и должны передать информацию материнскому МК. Материнский МК в основном только принимает информацию. Все устройства (и материнский и модули) 99,95% временни находятся в глубоком сне со включенным слевом.

Модули бывают разные и одновременно к материнскому контроллеру могут быть присоединены несколько одинаковых и куча разных модулей. Нужен протокол поддерживающий "Мультимаcтер" да так что любой элемент может быть и слейвом и мастером. Ситуация:
1. Модули должны подключатся на общую шину. Причем они могут быть на горячую сняты и поставлены обратно.
2. Нет никакой возможности провести к модулю отдельный проводок "Чип селект".
3. Нет возможности создать какое либо кольцо, подключая один модуль к другому.
4. Метод с перемычками тоже отпадает. На корпусе нет для них места.
5. Последовательно подключать модули и присваивать адреса тоже нет возможности.
6. Чем меньше пинов будет у этой шины тем лучше так как коннекторы очень дорогие, а устройство планируется для серийного производства.

Думая над выбором контроллера для модулей выдвинуты следующие требования:
1. Хочется аппаратный I2C, с прерыванием для глубокого сна.
2. Нужно много ног, минимум 13 I/O.
3. Минимальная цена.
4. Минимальное энергопотребление.
Из за первого и второго требования я выбрал Attiny40, несмотря на жуткие недостатки в виде:
1. Отсутствие EEPROM. - Не то что бы он нужен.
2. Нет самопрограммировоания. - Задача модулей настолько проста что нет необходимости обновлять им прошивку. И да понимаю риски разного рода 0-day уязвимостей. (И очень их боюсь) Но других соответствующих требованиям тинек я не нашел.

Тут кстати тоже не помешал бы совет. Может я не внимательно искал.

Про протокол:
На сколько я понял мне в основном подходит только I2C. Там есть и "Мультимастер" и слейв в любой момент сам может стать матером, иделаьно. Но вот незадача на шине может быть одновременно несколько одинаковых модулей, и им как то нужно присвоить разные адреса.

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

На данный момент есть лишь идеи в стиле:
1. Материнский контроллер громко вещает для всех - "сейчас буду раздавать адреса". И становится слейвом.
2. Модули запускают таймер с врменем 100*Серийный номер.
3. Затем они по очередно (по истечению таймера) просыпаются и рассказывают материнскому контроллеру свой Серийный номер, в ответ получая адрес.
4. Если модуль бы вставлен на горячую он громко всем орёт что он родился. А контроллер инициирует процедуру регистрации заново.

Звучит все это как то слишком ненадежно. Особенно при включении всех одновременно. Ищу помощи у знающих и вообще любых советов и предложений.

smoluks

В 1-wire эти проблемы давно решены, но вот мультимастера нет. Попробуйте от него избавиться, раз уж есть материнский контроллер.
Посмотрите даташит на ds2401, 18b20

яверт

Shtopor писал(а):

Нужен протокол поддерживающий "Мультимаcтер"
...
я выбрал Attiny40

Tiny40 может быть только слейвом.

ЗЫ что бы советовать по теме, неплохо бы хоть в общих чертах узнать что вы делаете...

Shtopor

яверт писал(а):

Tiny40 может быть только слейвом.

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

яверт писал(а):

ЗЫ что бы советовать по теме, неплохо бы хоть в общих чертах узнать что вы делаете...

Расписал максимально подробно на сколько могу. Если про выбор МК то нужно 99,9% времени спать, просыпаться по внешнему прерванную ножки INT0, и по обращению с шины (совпадению адреса), то есть без всяких еже секундных опросов от центрального МК. Никакой другой периферии кроме 1 таймера не нужно. Минимум Flash, минимум SRAM, пускай даже полное отсутствие EEPROM (хотя на самом деле немножко бы пригодилось, хотя бы 16 байт). И хотя бы 12 I/O ног + одна на INT0.

Вот сейчас сидел думал. А ведь если просто все модули резко начинают слать на материнского мастера по его адресу свои серийники. Все кроме самого блатного серийника (с максимальным количеством нулей) отвалятся по пути. И материнский контроллер продолжит общение только с ним. Выдаст ему адрес, и тот замолчит. Затем все повторяется снова, пока не замолчат все. Это жизнеспособно? Или я чего то не понимаю в арбитраже? Моя работа с I2C до сих пор ограничивался лишь часами реального времени и EEPROM памятью.

_noise

Цитата:

что бы при включении или "горячем" добавлении модуля, каждому модулю присваивался адрес, что бы далее они могли мирно спать в глубоком сне и просыпатся только по аппаратному прерыванию совпадения адреса

совпадению с чем адреса чего? Сколь угодно подробно описать ситуацию не равно поставить задачу, ой не еби мозга решать погнали.

Цитата:

Tiny40

Почём берём, где берём, где берём иначе, где берём срочно быстро прям щас, из каких вариантов выбрали.

Shtopor

_noise писал(а):

Цитата:

что бы при включении или "горячем" добавлении модуля, каждому модулю присваивался адрес, что бы далее они могли мирно спать в глубоком сне и просыпатся только по аппаратному прерыванию совпадения адреса

совпадению с чем адреса чего? Сколь угодно подробно описать ситуацию не равно поставить задачу, ой не еби мозга решать погнали.

Совпадении адреса I2C, не о каких других адресах в тексте речи и не шло. У МК есть "Wake-up Source" - "TWI address match interrupt" о нем и идет речь.

_noise писал(а):

Почём берём, где берём, где берём иначе, где берём срочно быстро прям щас, из каких вариантов выбрали.

Выбирал из всех 8 битных AVR отсортировав по количеству Flash и SRAM убрав из списка всю ненужную мне периферию. http://www.atmel.com/products/selector_overview.aspx + Минимальный размер корпуса в идеале QFN20. В какой то момент стал выбирать только из тинек http://en.wikipedia.org/wiki/Atmel_AVR_ ... ison_chart Так как с мегами всё более или менее понятно, и для тестов у меня их завались. Критерий выставлен довольно точно. Я лично некуда не спешу, закрываю с больших складов с помощью дистрибьютора fivel. Да и нечего еще не заказал, пока только присматриваюсь. Что вообще за вопросы?

яверт

Shtopor писал(а):

Это жизнеспособно? Или я чего то не понимаю в арбитраже?

Только если модули будут отслеживать коллизии и автоматически прекращать передачу при их обнаружении. Иначе при передаче серийных номеров 1010 и 0101 мастер примет 0000.
Есть ли это в atmel`овском TWI не знаю. В CAN есть, там арбитраж сделан подобным образом.

zat

Может будет проще использовать шину CAN ? Как бы в автомобилях работает с кучей датчиков и все гуд.
Единственное на что надо обратить внимание это длина линии. А так.. вроде должно подойти.
Подходит обычная витая пара, дальность зависит от скорости, скажем 10 Кбит на 6 км можно передать, 1 Мбит около 50м.
Обычно, 100 Кбит хватает. Если МК не поддерживает CAN, то можно поставить контроллеры, они стоят недорого вроде.

propell_ant

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

vt340

Shtopor писал(а):

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

Ну, если i2c - то и метод в стиле i2c ) Сделайте ВСЕ модули разными, т. е. те, которых на шине может быть несколько, просто выпускайте в нескольких вариантах, различающихся только адресом

Al-x

Если вариант 1-WIRE или CAN ну совсем не катит, то в I2C, по-моему, так и есть - контроль арбитража с отпаданием тех, кто его проиграл. (в megaх это было, с тиньками не работал).
Хотя я и утверждал и утверждаю, что для I2C не страшны большие расстояния, всё равно в нормальном устройстве рекомендовал бы эту шину только если всё на одном корпусе (материнской плате). Если отдельно обсуждать интерфейсы, то я бы ещё смотрел в сторону UART, при чём есть вариант полудуплекса, с одной линией связи. А если брать две линии связи, то он всё равно выигрывает у I2C, т.к. там одна линия это такт, а вторая - данные, в то время как у UART две линии можно использовать для одновременной передачи данных. Опять же - если не требуется супер скорость, то хватит и одной линии (против 2 I2C).
Теперь к алгоритму. Да, вы правы, любой выбранный интерфейс должен содержать возможность арбитража. Если это условие выполнено, то делать можно так:

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

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

PS: ничего особенного в моём алгоритме нет, так работает шина 1-Wire (в общих чертах), о которой вам уже отвечали.

Al-x

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

Не знаю, как в тиньках, но в большинстве современных МК уже зашит серийник.

Shtopor

Всем спасибо! Кажется первая версия концепции в моей голове уже готова.

Спасибо smoluks и zat. Но 1-Wire и CAN мне к сожалению не подходит так как нет аппаратного Wake-Up источника. А мне супер важно энергопотребление.

Спасибо яверт и _noise! Я при изначальном выборе кажется даже и не заметил Attiny48 с полноценным TWI, 64 байтами EEPROM, и кучей выходов, и что меня максимально радует есть самопрограммирование. Я слишком критично хотел QFN20 и не заметил этот прекрасный контроллер с QFN28 (не 32 а именно 28). Дык что смешно он еще и дешевле.

Спасибо propell_ant. Я скорее всего оптимизируют процесс до нажатия одной кнопки. Напишу программку которая будет генерировать новый HEX и сразу прошивать. А в 48-й теньке так вообще есть EEPROM.

Спасибо vt340. Но это будет дополнительный геморой для конечного пользователя, смотреть какой модуль у него и искать соответствующий. А я своего пользователя люблю. =)

Спасибо Al-x. Тот же способ я уже описал выше. Хотя здесь очевидно и отпадет 40-я тинька так как программным матером отлавливать коллизии я не хочу, не надежно это звучит. Мне к счастью никакие расстояния не нужны, максимум 20см в пределах одной ПП. Нужно прочитать про серийники в МК, я такого не слышал, если в AVR можно где нибудь считать что то подобное я буду беспредельно счастлив. Когда модуль адресуется он расскажет материнскому контроллеру чем он конкретно занимается.

Думаю еще пару дней подумаю и закажу для тестов себе 48-х тинек. А пока соберу стенд на 8-х мегах. попробую создать коллизию и разрешить её. Если у кого еще есть предложения я тут. А об экспериментах с арбитражном обязательно отпишусь, хотя так как я знатный любитель ASM у меня это затянется.

SOVA

Можно воспользоваться алгоритмом ARP: Включаемый модуль спрашивает "кто есть с таким-то адресом?" (INARP запрос). Если в другом блоке прошит запрашиваемый адрес, он отвечает "я имею такой адрес" (INARP ответ). Тогда новый блок изменяет адрес и снова спрашивает. Если за период времени нет ответа, то блок присваивает себе адрес и выдаёт сообщение в сеть "я блок такой-то с таким-то адресом" (ARP сообщение). Мастер себе прописывает таблицу адресов.
Для этого нужны три команды: INARP запрос и ответ, ARP сообщение.
Можно конфигурировать сеть каждый раз по включении, можно запоминать во флеш по нажатию кнопки конфигурации.

alexandr idushy

Al-x писал(а):

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

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

PS: ничего особенного в моём алгоритме нет, так работает шина 1-Wire (в общих чертах), о которой вам уже отвечали.

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

ILYAUL

Очень похоже на "охранку". Но там пока всем адреса не присвоишь - ... чего заработает

Горнист

Есть такая штука - smbus, по сути своей i2c, но с наворотами.
вот тут http://smbus.org/specs/SMBus_3_0_20141220.pdf начиная со страницы 48 описано как оно назначает адреса. Может это вам будет полезно.

akatenev

Вот действительно, странный вопрос. Все это давно есть в SMBus, для чего сей стандарт и придуман, собственно. Пользуйтесь на здоровье, зачем изобретать велосипеды?

alexandr idushy

Привет. Я внезапно перевел значимую часть "I2C-bus specification and user manual" Rev. 6 — 4 April 2014. Может где то тут ее пристроить, вдруг кого из модераторов заинтересует... Если это баян дайте сцыль на перевод.

Горнист

В сообществе можно опубликовать.

alexandr idushy

Горнист писал(а):

В сообществе можно опубликовать.

Как пост или в каком виде? Я не смог послать ЛС модераторам - прав маловато. Поэтому решил тут написать.

ILYAUL

! http://www.ti.com/interface/i2c/switche ... ml#p3107=8

Горнист

alexandr idushy писал(а):

Горнист писал(а):

В сообществе можно опубликовать.

Как пост или в каком виде? Я не смог послать ЛС модераторам - прав маловато. Поэтому решил тут написать.

Как пост, почему нет? Там даже раздел есть "техническая литература".

alexandr idushy

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

Горнист

alexandr idushy писал(а):

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

Можно сделать пост с описанием, а доку приаттачить.

Easyelectronics.ru

Раздача адресов i2c

Кто сейчас на конференции