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

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

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

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

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

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

Есть) По умолчанию устройсто всегда слушает линию. Неважно, работает оно автономно, или в сети.
При включении устройства, через случайный промежуток времени, если по линии ничего не пришло, оно назначает себя мастером, и отправляет широковещательный пакет. Таким образом, мастер сам назначается в сети...

кстати о йожиках...

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


(круглый)

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

Если в устройстве есть RTC то при включении использовать его значение в качестве случ.вел.

ключевое слово.

А наличие ацп сомнению не подвергается

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

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

Вот и самое время использовать оный!

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

если нет батарейки, то после включения всегда получим одно и то же значение
И где тут случайность?

Я имел ввиду не RTC без батарейки, а то что вкючить несколько устройств одновременно не возможно.

нууу... спорно. Общий рубильник выкл/вкл, например

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

(круглый)

Всё зависит от того какой интервал времени выбрать в качестве критерия одновременности ...г,д,ч,м,c,мс,мкс,нс,пс...

ну г,д,ч,м,с можно смело фтоппко
а с остальными - это уж как может RTC выдавать
Хорошо, согласен, что с подобными временнЫми интервалами есть случайные величины - разброс емкостей питания, нарастание напряжения ядра, RTC,... есть некоторый разброс
Но, хорошо шумящий ADC, имхо, лучше

Согласен на все 100%.

А по поводу случайного интервала :
если вероятность получения несколькими устройствами одинакового интервала не нулевая (теория вероятности), то это "ОЙ" произойдёт в самый не подходящий момент (это уже закон подлости).

нет, Мерфи:

RTC - RealTimeClock?



если устройства работают в сети, то питание так и подается на все сразу


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

значит все-таки не обойтись без кнопок\перемычек...

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

Да часы или просто энергонезависимый счетчик RealTimeCounter.

Самый простой вариант это кнопка.
А чтобы сказать более точно возможно ли без оной обойтись, нужно более точно знать характеристики сети:
времянки, макс. кол-во устройств в сети, вообще предполагаемое кол-во выпущенных устройств и т.д.

А как же Ethernet? Там через случайный промежуток времени повторяется передача, если канал занят...

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

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

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

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

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

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

Это дело можно автоматизировать при помощи скрипта, который запускает прошивку МК. После прошивки номер инкрементируется. Можно отвести на номер 6 байт, не так много. Будет аналогия с MAC-адресом)))

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

слабо поставить на каждую плату какой-нибудь даллас, типа DS1990, только в подходящем корпусе?

Жизненная ситуация №1: пользователь по ошибке вклчил в сеть с существующим мастером ещё одного мастера (забыл снять джампер).
Жизненная ситуация №2: в сети мастер отвалился (завис, сгорел и т.д.). Устройства как стадо баранов стоят и ждут "рассчитанное значение фазы", т.е. ничего не делают и при этом пользователь даже не догадывается о проблеме.

Даже с аппаратным определение мастера обязательно должна быть реализована детекция коллизий на шине.

По поводу автоматизации генерации уникального номера при прошивке - поищите в сети. Для AVR, например, существует тулза AVRDude, которая может самостоятельно инкриментировать серийный номер в ПЗУ при каждой перепрошивке. Для других МК, думаю, найдутся программы с подобным функционалом.

про "жизненные ситуации" это Вы прямо в точку! за наводку по софту спасибо, буду искать.

ТС, а что за МК (или ПЛИС) вы используете? Дело в том, что некоторые МК имеют свой уникальный идентификатор, который вшит в них уже при производстве. Из известных мне, ID имеют XMEGA, STM8 и STM32.

система разрабатывается на TMS320F28069 от Texas Instruments, по даташиту внутреннего идентификатора не встречал

Есть такой древний стандарт - Profibus (часть 2) - там вся эта многомастерность подробно и аккуратно расписана.

Получится использовать. Все каналы АЦП всё равно шумят, и в том числе подключённые к земле. А значения измеряемых величин тем более можно рассматривать как случайные. Хотя объём случайности может быть и не велик - например по 1 биту с канала АЦП.
Взять значения всех каналов АЦП, составить вместе (то есть записать в последовательно расположенные элементы массива), по ним вычислить CRC или MD5 или что-то подобное чтобы смешать все каналы АЦП вместе. То что получится - случайное число. По этому числу определить время задержки до начала передачи. Начать передачу. Если коллизия - то может быть у другого блока такие же значения с АЦП - тогда ещё раз заново взять значения всех каналов АЦП и т.д.

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

Я еще и прошивку идентификатора предложил выше, 6 байт, аналогия с MAC-адресом. Вроде на весь мир хватает)))

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

По мне я бы собрал систему на CAN, которая позволяет расставить приоритеты, и считал бы сообщением от мастера (фаза или что там) сообщение с максимальным приоритетом за время, равное интервалу сеанса связи. Тогда вообще париться не нужно, все предсказуемо и дубово, не нужно передавать никакие полномочия вообще.