[nanorobot 3]

Линии NSS от мастера остались в системе? Если да, то кто мешает по их состоянию в программе задавать шаблон идентификаторов. Ногодрыг мастером GPIO NSS и вот каждый Слейв знает свой шаблон, анализируя свою GPIO NSS.

 

 

:rolleyes: в таком случае вопросоа бы не возникло в принципе. одна из причин стреммления к КАНу - снижение числа гальванически развязанных линий.

[AlanDrakes 1]

У Вас есть кристалл с уникальным ID, прошитым на производстве. Напишите что-то совместимое с CAN шиной, что будет использовать какой-нибудь специфический канал для настройки именно ведомых.

Допустим, при запуске все кристаллы одновременно ломятся в шину с сообщением и посылают свой номер в какое-то поле. Происходит коллизия. Коллизия решается, выигравший забирает первый диапазон адресов.

Повторить до окончания коллизий.

Допустим, адреса 0x00 ~ 0xFF, каналы по 16 адресов (0x10)

Посылка -> Коллизия -> Разрешение -> Выигравший забирает адреса 0x00 ~ 0x0F и замолкает.

Посылка -> Коллизия -> Разрешение -> Второй выигравший забирает 0x10 ~ 0x1F и тоже замолкает.

И так далее.

 

UPD: Я тут подумал. Эту же процедуру можно проводить только в случае возникновения коллизии при ответе контроллера. То есть, сеть может организовываться полностью сама. Разве что мастер не будет знать кто где.

Настройка можно хранить в выделеной странице (двух) Flash-памяти, либо на врешней EEPROM микросхеме, а перенастраиваться только при обнаружении ошибки.

 

Я сейчас мыслю, абстрагировавшись от работы шины данных.

Есть знатоки работы CAN протокола? Как можно реализовать подобное, используя стандартные методы?

 

Хотя, в моём случае, при построении сети, работа ведётся исключительно между мастером и ведомыми. И он же выдаёт им сетевые адреса. Да, слизано с больших сетей с DHCP сервером. При этом работает по двухпроводной схеме (нет, не RS-485).

Изменено 31 июля, 2018 пользователем AlanDrakes

[nanorobot 3]

Разве что мастер не будет знать кто где.

 

В самую точку....

Изменено 31 июля, 2018 пользователем nanorobot

[dimka76 42]

Все слейвы изначально неотличимы один от другого. На любое сообщение от мастера либо все среагируют одинаково, либо все проигнорируют, в зависимости от изначально установленных фильтров. Как в такой ситуации мастер что либо может распределить?

 

У каждого STM есть уже зашитый на заводе уникальный серийный номер. Вот его и используйте. Или его часть.

Device electronic signature

Unique device ID register (96 bits)

[jcxz 184]

В самую точку....

Это уже совсем другой вопрос. Чтобы на него ответить нужно знать ответ на "А как различаются "кто есть кто" в вашей системе"? И тогда сами себе и ответите "как".

И к назначению уникальных ID слэйвам это уже не имеет никакого отношения.

[yes 5]

если невнимательно читал - извиняйте

 

есть стандарты (протоколы) обмена по CAN-у в которых используются адреса источника и приемника - SAE J1939 он же iso 11783, по-моему

 

там есть процедура Address Claim Procedure в тырнете написано как оно устроено

 

но вроде как и без стандартов в среде, где допустимы/разрешаются конфликты сделать что-то подобное не сложно:

только что подключенный контролер сообщает (особый тип сообщения - в старших битах, например) что-то типа "я контролер такой-то (свой тип и какой-то серийный номер или что-то такое, чтобы прошло решение конфликта - если все вдруг одновременно включились) хочу себе такой-то (например, инкремент с 0) адрес" - ему либо отвечают "шалишь, такой адрес уже занят", либо остальные контроллеры у себя в табличку дописывают что этот контроллер получил этот адрес. после 0-N итераций этот контроллер получает адрес, а потом другим сообщением говорит "дайте мне табличку адресов" - причем табличку обновляют все, а передавать, например, может каждый то же самое сообщение "я контролер такой-то хочу/имею адрес такой-то" - если все это в extended CAN ID засунуть (28 бит должно хватить) - то все это будет арбитрироваться/разрешаться железкой автоматически

вроде как все...