ну я видел только такое (точнее, сам реализовывал): мастер шлет get info запрос на броадкастный адрес слейвы отвечают с простеньким алгоритмом избежания коллизий (тупо перед отправкой своего пакета смотрим нет ли болтовни на шине, если есть - ждем рандомное время, пытаемся снова) мастер собирает все ответы которые ему пришли (если 2 секунды ничего не приходит - значит все) в ответах содержится адрес слейва и его тип мастер "знает" некоторые типы устройств и исходя из этого самоконфигуряется это нифига не стандарт, но работает неплохо
Комментарии: 8
Dmitry
Хм, не, не подходит, подводных камней много
Lexszero
например? ну можно не броадкастить, а тупо продолбать все адреса, 255 всего ж.
Dmitry
Во-первых, по стандарту на широковещательный адрес ответа быть не должно 248. С 1 по 247 же Там от 248 до 255 зарезервированы
Lexszero
ну тем более вообще у меня на этом броадкасте был построен еще хитрый протокол автоконфигурирования шины
Anonim
Реализация "рандомного времени" это как?
Dmitry
Так что, для надёжной работы я бы придумал свой формат и прицепил бы его к придуманному(из диапазона пользовательских) коду функции Левое устройство просто вернёт 0x01 ошибку
Lexszero
то есть если кинуть броадкаст - в report slave id приходит еще уникальный cpuid стмки и была кастомная команда "назначить девайсу вот с таким cpuid вот такой модбас адрес", которая слалась на броадкаст с завода все железки шли с нулевым адресом а железки вот эти: http://btune.ru/index.jsp?id=36
Dmitry
А, вот это уже неплохо. Команду принимают гарантированно все, но адрес меняет нужная железка. Но с броадкастом всё равно не нравится мне реализация