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

У Вас есть кристалл с уникальным ID, прошитым на производстве. Напишите что-то совместимое с CAN шиной, что будет использовать какой-нибудь специфический канал для настройки именно ведомых.
Допустим, при запуске все кристаллы одновременно ломятся в шину с сообщением и посылают свой номер в какое-то поле. Происходит коллизия. Коллизия решается, выигравший забирает первый диапазон адресов.
Повторить до окончания коллизий.
Допустим, адреса 0x00 ~ 0xFF, каналы по 16 адресов (0x10)
Посылка -> Коллизия -> Разрешение -> Выигравший забирает адреса 0x00 ~ 0x0F и замолкает.
Посылка -> Коллизия -> Разрешение -> Второй выигравший забирает 0x10 ~ 0x1F и тоже замолкает.
И так далее.

UPD: Я тут подумал. Эту же процедуру можно проводить только в случае возникновения коллизии при ответе контроллера. То есть, сеть может организовываться полностью сама. Разве что мастер не будет знать кто где.
Настройка можно хранить в выделеной странице (двух) Flash-памяти, либо на врешней EEPROM микросхеме, а перенастраиваться только при обнаружении ошибки.

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

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

Сообщение отредактировал AlanDrakes - Jul 31 2018, 13:58

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

Сообщение отредактировал nanorobot - Jul 31 2018, 17:01

У каждого STM есть уже зашитый на заводе уникальный серийный номер. Вот его и используйте. Или его часть.
Device electronic signature
Unique device ID register (96 bits)

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

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

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

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

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