Определение мастера в многомастерной сети Опции

[Славентий]

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

Имеется некоторое устройство, считающее значение фазы и формирующее на основании данного значения управляющие импульсы. Данное устройство должно работать как индивидуально, так и в группе с несколькими аналогичными устройствами. При работе в компании, одно из устройств должно быть ведущим и раздавать остальным рассчитанное значение фазы. Для организации сети планируется использовать один из вариантов: CAN или SCI(UART). CAN поддерживает аппаратный арбитраж, но может не удовлетворить по скорости передачи. SCI же удовлетворяет по скорости, но, как мне кажется, придется придется прибегать к привлечению человека в вопросе выбора мастера (допустим ставить перемычку в разъеме соединения блоков, куда выведены линии цифрового входа устройства, или ставить на каждый блок клавишу запуска/указания мастера).

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

Заранее благодарен за внимание.



Сообщение отредактировал Славентий - Feb 21 2012, 07:29

[haker_fox]

но там нет мастера. Здесь нужно однозначно назначить мастера автоматом

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

Я знаю, что в Ethernet нет мастера Я имел в виду, что там используется передача через случайный промежуток времени, если обнаружена коллизция. И этот метода работает по всему миру. Мои знания не устарели?
Это все к тому, что случайность - не такая уж и дыра, в которую можно попасть

[Sergey_Aleksandr...]

Имеет ли каждое устройство свой уникальный серийный номер или иной идентификатор? Например, у кого больше (меньше), тот и мастер на шине.

UPD Тут подумал вот о чём. Если одно из устройств при работе в сети перезагрузится (помеха по питанию, сбой в ПО и т.п.), то оно "забудет", кто был ведомым, а кто ведущим и запустит механизм захвата шины. Произойдёт коллизия. Нужно уметь обрабатывать коллизии. Или ввести помимо механизма захвата шины механизм её удержания. Например, мастер периодически (раз в 10мс) шлёт пакет "мастер на шине есть". При отвале самого мастера пакет не генерируется и бывшие ведомые начинают по новой захватывать шину. Но при этом должна быть реализована задержка запуска механизма захвата шины, бОльшая интервала времени между пакетами мастера "шина захвачена".