[Ioann_II 0]

писали, что и без драйверов можно: https://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf

или у Keil http://www.keil.com/appnotes/files/apnt_236_v2.9.pdf

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

[yes 5]

CAN (точнее один из вариантов физического уровня, их несколько по стандарту, но речь про самый массовый, который де факто вытеснил остальные)  должен допускать соединение нескольких устройств, то есть он не может быть просто "выходом" - как подключите 3+ устройства (те же STMы) если там только вход и выход?

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

доминантным может быть только один передатчик, а остальные должны быть пассивными. и все слушают линию

-------------

на самом деле, я был не прав - одно устройство в нормальном режиме не будет работать даже с драйвером, нужно будет отключить проверку ACK (не помню, умеет это STM32)

а физический уровень (не настоящий CAN, но его эмуляцию) можно сделать если перевести CAN_TX выход в режим OPEN DRAIN и включить PULL-UP - тогда можно будет подключить туда же и CAN_RX и одним проводом соединить несколько STM-ов, сконфигуренных так же. это если лень покупать и паять драйвера. можно использовать пару транзисторов или буфер с тремя состояниями, если не получится сконфигурить выход STM, и много свободного времени :)

2 hours ago, Ioann_II said:

писали, что и без драйверов можно: https://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf

 

да, можно. но нужно ACK запретить. и некоторые контроллеры умеют свое сообщение не принимать (при отсутствии фильтрации)

у STM-а по-моему можно и ACK отключить и принимать свое сообщение, но не уверен - нужно доку на его CAN курить. такой режим никому не нужен и про него редко пишут

 

upd: AP2921 - согласен, на диоде и резисторе проще, чем на паре транзисторов или буфере. но еще проще сконфигурить выход в OPEN DRAIN

[esaulenka 5]

2 hours ago, yes said:

у STM-а по-моему можно и ACK отключить и принимать свое сообщение

Нет, нету там такого. Максимум - можно auto retransmit отключить, чтобы отправлять только одно сообщение, а не "долбить" шину без подтверждений, пока счётчик ошибок не переполнится.

Своё сообщение тоже обратно не принимается, даже если кто-то "снаружи" выставил ACK.

 

 

4 hours ago, Ioann_II said:

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

В STM'овском reference прямо указаны костыли, которые включаются в случае loopback mode. Каких-то других методов включить приём передаваемых пакетов я не знаю.

[Ioann_II 0]

Не совсем для себя ещё уяснил вот что:

Когда, например,  узел 1 проиграл арбитраж, например узлу 2 и прекратил передачу. Он сделает повторную попытку передачи только при автоматической ретрансмиссии?  Или как? И по какому биту это можно проверить (что проиграл арбитраж)?

[jcxz 184]

4 часа назад, Ioann_II сказал:

Когда, например,  узел 1 проиграл арбитраж, например узлу 2 и прекратил передачу. Он сделает повторную попытку передачи только при автоматической ретрансмиссии?  Или как? И по какому биту это можно проверить (что проиграл арбитраж)?

Вы бы хоть на википедии что-ль прочитали что такое CAN:  https://ru.wikipedia.org/wiki/Controller_Area_Network

PS: Что за стиль нынче такой - не читая никаких мануалов ни на МК ни на интерфейс, сразу быдлокодить? 

[Ioann_II 0]

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

пока что нигде этой конкретики не встречал. В т.ч. в указанном Вами источнике.

[haker_fox 60]

3 minutes ago, Ioann_II said:

"как увидеть, что арбитраж проигран?"

Я с CAN не работал, но интересовался этой темой. Полагаю, что ответ на ваш вопрос находится в описании регистров и возможностей MAC (Media Access Controller).

[PeterAwsmtek 0]

34 minutes ago, Ioann_II said:

как увидеть, что арбитраж проигран?

Установится соответствующий флаг в регистре статуса

Вся необходимая инфа по работе с CAN есть в Reference Manual по вашему процессору.

Quote

Получаю ошибки: ACK error

Ну так по стандарту полагается чтобы было хотя бы два устройства. ACK дает любое устройство на шине, кроме того, которое передает.

Не занимайтесь глупостями - купите CAN сниффер (например Marathon) - отладить фильтрацию ID без снифера будет очень сложно.

 

39 minutes ago, Ioann_II said:

сделает повторную попытку только при автоматической ретрансмиссии?

Да

[Ioann_II 0]

14 минут назад, PeterAwsmtek сказал:

Установится соответствующий флаг в регистре статуса

Вся необходимая инфа по работе с CAN есть в Reference Manual по вашему процессору.

Да вот, нашёл в регистре статуса. Проглядел, смотрел больше в регистр ошибок и прерываний. Спасибо за подсказки, буду разбираться дальше.

[esaulenka 5]

56 minutes ago, Ioann_II said:

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

1) Да. Потеря арбитража - совершенно штатное явление в сколь-нибудь нагруженной шине.

2) Прочитать документацию. 

Bit 18 ALST2: Arbitration lost for mailbox 2. This bit is set when the previous TX failed due to an arbitration lost.

Ещё там же есть биты 10 и 2.

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

[haker_fox 60]

7 minutes ago, esaulenka said:

1) Да. Потеря арбитража - совершенно штатное явление в сколь-нибудь нагруженной шине.

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

[PeterAwsmtek 0]

1 minute ago, haker_fox said:

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

Если у вас детерминированное время передачи данных, то обеспечте только один передатчик на шине, тогда никто не будет мешать и никакие данные не потеряются.

Кроме этого можно использовать 1Мбит/с - тогда кадры будут улетать очень быстро. И реже будут возникать коллизии.

В ПО можно отправлять данные повторно, автоматически и вручную, проверять наличие свободных мэйлбоксов перед отправкой и счетчик ошибок.

Буферизовать данные и тп.

[esaulenka 5]

2 minutes ago, haker_fox said:

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

Вероятно, надо было задуматься сильно заранее о пропускной способности шины :-)

А вообще, арбитраж в CAN штука очень простая и одновременно очень мощная. Арбитраж выигрывает тот узел, который передаёт dominant state (т.е. ноль). Таким образом, тот узел, который передаёт пакет с бОльшим количеством нулей в начале (т.е. с меньшим идентификатором) автоматически выигрывает арбитраж. Вам остаётся только назначить правильные идентификаторы "критичным датчикам".

[PeterAwsmtek 0]

17 minutes ago, esaulenka said:

А вообще, арбитраж в CAN штука очень простая и одновременно очень мощная. Арбитраж выигрывает тот узел, который передаёт dominant state (т.е. ноль). Таким образом, тот узел, который передаёт пакет с бОльшим количеством нулей в начале (т.е. с меньшим идентификатором) автоматически выигрывает арбитраж. Вам остаётся только назначить правильные идентификаторы "критичным датчикам".

да, очень важное замечание.

[haker_fox 60]

@esaulenka, @PeterAwsmtek, спасибо! А то сейчас используем RS-485. И многие вещи приходится делать ручками, но зато привычно и годами откатано. А за CAN браться боязно, ибо: нет опыта, пугает мультимастер и т.п.