Добрый день!

У меня CAN-шиной соединены 4 устройства STM32F4. Каждое из них подсоединено к компьютеру по USART для возможности вывода на экран входящих и исходящих сообщений. При отправке данных от одного устройства к конкретному другому, сообщение всё равно отображают все 4 устройства. Объясните, пожалуйста, каким образом правильно настроить адресацию и фильтрацию сообщений на STM32F4.

Если не ошибаюсь, то в стандарте Can нет такого понятия, как адрес устройства. Есть понятие - идентификатор посылки.
В системе, где несколько устройств, и каждое из устройств может отправить посылку любому другому, целесообразно, чтобы в идентификаторе содержалась след информация:
Идентификатор получателя, идентификатор отправителя, тип посылки.
Соответственно фильтры настраиваются на идентификаторы посылок.
Например так:

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

Хорошо. Я вас понял.

Главный вопрос в инициализации у меня относительно строк CAN_FilterIdHigh, CAN_FilterIdLow, CAN_FilterMaskIdHigh, CAN_FilterMaskIdLow. Я не очень понимаю, что конкретно в них писать. В них нужно писать диапазон Id? Если да, то зачем нужны какие-то скобки?

Термины, которые Вы используете, видимо из кода HAL от CMSIS или CubeM. Тут я Вам не советчик. Единственное, что могу добавить, фильтр можно настроить на полное совпадение с конкретным идентификатором, так и установить маску, когда под один фильтр может попадать целая группа идентификаторов.

Не скажу конкретно про ваш STM, но в CAN-модуле с которым я работал для фильтрации сообщений было правило
если ((CAN_ID & FILTR_MASK) == FILTR_ID) сообщение принимается, иначе игнорируется.
Поэтому UserManual в руки и читать мат.часть.

Вы начните с чтения мануала на процессор. Там довольно подробно расписана фильтрация, какие режимы есть и что надо писать в регистры. Дальше если вы хотите использовать Cube / HAL, то уже смотрите, что их функции пишут в эти регистры и таким образом понимаете, что вам надо в них передавать

Я честно говоря с HAL еще не сталкивался, но из опыта работы с CMSIS - его дока очень слабая, без мануала на проц не обойтись. Может быть в HAL это поправили.

И опять же из опыта работы с CMSIS - для CAN от него толку ноль. Он слишком уж тонкая обертка над железом и вообще нет никаких плюшек по сравнению с прямой работой с регистрами CAN-модуля процессора.

Тем более что там пять строчек кода.
Вам надо тупо настроить 1 раз регистры (зачем вызывать для этого какие-то левые п/п, один бог знает) и всё. Далее вы просто обрабатываете сообщения поступающие в ваш ящик в прерывании.

Как настроить регистры, более или менее понятно. Я бы задал вопрос под другим углом: Каким образом сделать так, что бы каждый из нескольких идентичных каналов, с процессором прошитым одинаковой прошивкой определил для себя заданный диапазон идентификаторов, несовпадающий с другими каналами (топология один мастер - четыре слейва. Ранее это делалось на SPI и оно естественным образом рулилось сигналами NSS но захотелось лишнего геморроя - решил попробовать CAN... ) Вводить в схему перемычки или дип переключатели категорически не хочется, иметь различную версию прошивки для каждого канала - тем более...

Ну если Вы раньше каким-то образом определяли кто будет мастером на SPI, то в чём проблема так же назначить мастера и теперь?

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

А мастер почему простаивает, пусть он распределит. Не?

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

О, это в чём-то похоже на IrLAP (IrDA): мастер выдаёт запрос и ведомые, услышавшие и не заригистрированные, во временных слотах, естественно с коллизиями, откликаются; ну и потом, естественно разрешение коллизий.

Естественно - не реагировать одинаково. Назначить каждому слэйву уникальный ID. На этапе производства (сер.номер) или динамически после вкл. Ну или использовать уникальный номер уже имеющийся в МК или каком-либо чипе схемы.

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

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

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

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

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

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

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

У каждого 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 бит должно хватить) - то все это будет арбитрироваться/разрешаться железкой автоматически
вроде как все...