i2c для своих устройств Опции

[Ромка]

Приветствую!

Делаю устройство на AVR с возможностью подключения внешних датчиков. Датчики также на AVR, сопрягать между собой думал по i2c.
Но вот нюанс - каждому датчику надо прошивать номер, а в главном устройстве придётся обеспечить возможность задание этого номера? (а в идеале ещё и задание номера на датчике, чтобы можно было два одинаковых ставить)..
В 1-wire всё проще - там есть поиск устройств, а как быть здесь?

[XVR]

У I2C устройств есть адрес. Как минимум 7 бит (максимум - 10, если не ошибаюсь). Не вдавался в подробности реализации I2C в AVR, но какой то адрес (может и не все 7/10 бит) там быть должен
Адрес зашивать в EEPROM. Можно предусмотреть 1 стартовый адрес, который будет изначально шиться во все устройства. Главное устройство при обнаружении такого датчика будет присваивать ему первый свободный адрес.
Ограничение - новые датчики должны подключаться к главному устройству строго по 1шт зараз.

[ReAl]

Ограничение - новые датчики должны подключаться к главному устройству строго по 1шт зараз.

Не обязательно.
ACCESS.bus

2.1.7. Configuration Process
...
2.1.7.2. Identification Phase
To begin address assignment, the computer sends an Identification Request message at the device default address. Every device at this address must then respond with an Identification Reply message. As each device sends its message, the ACCESS.bus physical layer arbitration mechanism automatically separates the messages based on the identification strings. The computer can then assign an address to each device by including the matching identification string in the Assign Address message. A device that receives this message and finds a complete match with the identification string moves its device address to the new assigned value. As soon as a device has a unique address, it shall change to 'on line state' in a 'disable mode'. in this state the device is waiting to receive an "Enable Application Report" control message from the host to start sending its application reports.

"Identification Reply message" включает в себя серийный номер.

protocol revision: 1 byte ("B")
module revision: 7 bytes (e.g., "V1.0 ")
vendor name: 8 bytes (e.g., "DEC ")
module name: 8 bytes (e.g., "LK501 ")
device number: 32-bit signed integer

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

Но я не меге48 обошёлся пятью перемычками (на одном входе АЦП) и так могу различить до 32 своих плат на шине.

Год-два назад этот документ ещё лежал на http://www.vesa.org/public/Access%20Bus/abusv30.pdf но почему-то пропал. Есть ещё тут http://www.mcc-us.com/abspec30.htm но в формате MSWord.

[XVR]

Не обязательно.
ACCESS.bus

"Identification Reply message" включает в себя серийный номер.
...

Очень похоже на PnP для SMBUS 2.0. Вот только одна загвоздка:

ACCESS.bus physical layer arbitration mechanism automatically separates the messages

AVR'ный I2C это поддерживает? IMHO нет. А без аппаратной поддержки не получится (причем эта поддержка отличается от поддержки multimaster'а)

[ReAl]

p.s. Сейчас под шумок заглянул наконец-то в спецификацию SMBus (SMBus ARP) - там приблизительно то же самое, только потолще идентификатор и получше расписано протокол.

AVR'ный I2C это поддерживает? IMHO нет. А без аппаратной поддержки не получится (причем эта поддержка отличается от поддержки multimaster'а)

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

upd:
Тьху, это ж надо как я прозевал этот момент, на i2c по данным арбитраж идёт только у мастеров. А только ради нумерации делать всех мастерами и чтобы устройство с неприсвоенным адресом в режиме мастера орало время от времени (например, "самому главному мастеру" или GCALL с определённым типом пакета) "ау! вот тут я с таким-то типом и серийником без адреса сижу" - как-то может быть слишком затратно.

upd2:
Лучше пусть "самый главный мастер" иногда шлёт широковещательное приглашение к разруливанию адресов, по которому все бомжи дают заявки на присвоение.
И то не один раз при включении, а периодически - только если предполагается подключение/отключение при работе (хотя просто пересброс кого-то этому эквивалентен).
Но, опять же, только для этого может и неинтересно городить мультимастер.
Хотя в определённых условиях может и захотеться мультимастера и так, то тогда нагрузить и этим уже не сложно.
Я сейчас мутю одну муть, так временами хочется отказаться от операций чтения вообще (ну кроме часов/eeprom).