Работа с шиной CAN

cast yax123, Iron_Bug, DarthVadimius, Eddy_Em

Тебе таблица 4-2 нужна, так как айдишник у тебя 11 бит.

Младшие биты айдишника определяют что ты читать хочешь, остальные задаються регистрами ?XIDNSIDH, ?XIDNSIDL и для айдишников в 29 бит еще ?XIDNEID8. Вместо знаков вопроса R/T.

Из On Bus message видно что айди пробит 7FF.

* If OPTREG2.MTYPE = 1, then SID3 is forced to zero.

Важное и так видно кстате :D

Значит для чтения A/D Regs нужно запросить 7F0 ( три младших 0b000, четвертый неважно значит 0.)

cansend slcan0 7F0#R

Read User Mem (bank 2) нужно запросить 7F6 ( три младших 0b110, четвертый неважно значит 0.)

cansend slcan0 7F6#R

Для записи (Write Register из таблицы) младшие опять нули.

cansend slcan0 7F0#addr.mask.value

Поставить GPIO все на выход (GPDDR 1f адрес)

cansend slcan0 7F0#1F.7F.7F

Поставить GPIO в 1010101 (GPLAT 02h адрес + сдвиг 1Ch = 1E)

cansend slcan0 7F0#1E.7F.35

Мне не нравиться только то, что в даташите для RTR пишется еще и длина сообщения (DTC). Здается cansend'ом нельзя отправить RTR с сообщением, тоесть DTC будет ноль. До понедельника проверить я не могу.

Возможно прийдется non-RTR (OPTREG2.MTYPE=1) запросы юзать, в них нужно 4-й бит айдишника в 1 ставить для запроса. Тоесть для запроса A/D Regs нужно отправить пустое сообщение с айдишником 7F8 (четвертый 1,три младших 0b000.)

cansend slcan0 7F8

Запись не изметится.

Здравствуйте. Попробовал:

cansend slcan0 7F0#R
cansend slcan0 7F0#1F.7F.7F

И похоже, что не получил никак результатов, т.к. в соседнем терминале запущен candump:

candump slcan0 | uniq
  slcan0  7FF   [0] 
  slcan0  7F0   [0]  remote request
  slcan0  7FF   [0] 
  slcan0  7F0   [3]  1F 7F 7F
  slcan0  7FF   [0] 

slcan0  7FF   [0]

А вообще, из-за того что отключен Command Acknowledge (CAEN=0) нет возможности понять принял ли он данные (даже не RTR, а просто Input Message)

Есть еще небольшой нюанс, который хотелось бы уточнить... После включения в сеть mcp25050 на CANUSB сразу же загарается (и без прерыва горит) крассная лампочка (что означает «ошибка»).

Сейчас тестовая сеть у меня сделана в лучших традициях.

Мое предположение, что это происходит по причине, описанной в Controller Area Network Physical Layer Requirements (Раздел 3, страница 3-4)

Note that a minimum of two nodes must be used to initialize communication on a CAN bus. Since a
transmitted message must be acknowledged in the ACK bit by a receiver, the transmitting controller will
send out an error flag if the message is not properly ACKed.

Note that if the ACK bit is missing, the transmitting controller will generate its own error flag. If a message
is not ACKed, an error is generated with each occurrence until the controller reaches an error limit that is
internally set by the CAN protocol. The controller places itself in a bus-off state when this internal limit is
reached. This is a protocol controller function that prevents a single node from blocking all communication
on a bus.

Собственно может ли быть такое, что мой CANUSB переходит в режил «listening only» и вообще ничего не шлет в сеть?

Собственно может ли быть такое, что мой CANUSB переходит в режил «listening only» и вообще ничего не шлет в сеть?

Сомнительно. Да и кандамп же выводит твои посылки.

Попробуй через

cansend slcan0 7F0#1F.7F.7F # все  gpio на выход

cansend slcan0 7F0#1E.7F.7F # все в 1
cansend slcan0 7F0#1E.7F.00 # все в 0

Поставь OPTREG2.MTYPE=1 и зделай запрос.

cansend slcan0 7F8

запорол 3 контроллера

А как? О_о

Этиж контроллеры одноразового программирования. Если неправильно прошил - труп.

А так как это домашние поделки- разумеется бюджет не велик и доступка к чему-нибудь энтерпрайзному у меня нет...

Для генерации прошивки я использую «MCP2505x Programmer application»... Это очень древнее, сильно-сильно багнутое ПО, кое-как заведенное на «семерочке». Я молучу про то, что для запуска оно хочет иметь физический LPT порт, молчу про то, что десяток виндовых библиотек мне пришлось качать из всяких файлшар и ручками вкручивать в винду...

Но есть некоторые вещи, о которых молчать сложно! Например эта «программа» не генерит чексумму (её нужно ручками вписывать в .hex файл). А еще, в рандомный момент в .hex файле в некоторых строках не хватает последнего символа, которые, наверное по задумке авторов, ты должен угадать. Если ты не правильно угадал- во время прошивки программатор (а про него отдельно расскажу) всю строку заменяет на 3FF и контроллер становится мертвый.

Доступа к нормальному программатору для mcp2502X/5X разумеется у меня нет, зато у меня есть оригинальный PicKit3, который не предназначен программировать эти контроллеры. Но некоторые неизвестные умельцы из интернетов написали прошивку для третьего кита, и немножко хакнули PICKit3 Programmer, и теперь оно вроде бы шьет. К слову схемы подключения контроллера к программатору тоже нет, поэтому подключать пришлось «на угад», опираясь на фантазии, домыслы и обрывки информации из интернетов.

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

car tool? or hard embedded?

Я с MCU работаю, ничего посоветовать не могу.

Кинь кандамп с

cansend slcan0 7F0#2D.8.8 
cansend slcan0 7F8

#cansend slcan0 7F0#2D.8.8 

Wrong CAN-frame format! Try:

    <can_id>#{R|data}          for CAN 2.0 frames
    <can_id>##<flags>{data}    for CAN FD frames

<can_id> can have 3 (SFF) or 8 (EFF) hex chars
{data} has 0..8 (0..64 CAN FD) ASCII hex-values (optionally separated by '.')
<flags> a single ASCII Hex value (0 .. F) which defines canfd_frame.flags

e.g. 5A1#11.2233.44556677.88 / 123#DEADBEEF / 5AA# / 123##1 / 213##311
     1F334455#1122334455667788 / 123#R for remote transmission request.

:~# cansend slcan0 7F0#2D.08.08 
:~# cansend slcan0 7F8

Wrong CAN-frame format! Try:
.... (такая же ошибка как и выше)

:~# cansend slcan0 7F8#
:~# cansend slcan0 7F0#2D88 
:~# cansend slcan0 7F8#
:~# cansend slcan0 7F0#2D.80.80 
:~# cansend slcan0 7F8#

В это же время в соседнем терминале:

candump slcan0 | uniq
  slcan0  7FF   [0] 
  slcan0  7F0   [3]  2D 08 08
  slcan0  7FF   [0] 
  slcan0  7F8   [0] 
  slcan0  7FF   [0] 
  slcan0  7F0   [2]  2D 88
  slcan0  7FF   [0] 
  slcan0  7F8   [0] 
  slcan0  7FF   [0] 
  slcan0  7F0   [3]  2D 80 80
  slcan0  7FF   [0] 
  slcan0  7F8   [0] 
  slcan0  7FF   [0] 

Игры с GPIO к сожалению тоже не дали никаких результатов. Интересно что

GP0/AN0 - всегда низко
GP1/AN1 - всегда низко
GP2/An3/PWM1 - всегда высоко
GP3/AN3/PWM2 - всегда высоко
GP4/Vref- - всегда высоко
GP5/Vref+ - всегда высоко
GP6/CLKOUT - всегда наполовину (2.5)
GP7/RST_/Vpp - всегда низко

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

Полагаю, что команда переключить все GPIO в выводы не сработала

Может и нет, но они же выставлены на вывод.

GP6/CLKOUT - всегда наполовину (2.5)

Значит там меандр, он работает как выход для клока.

OPTREG1 bit 6 CLKEN:
1 = Clock Out Function disabled
0 = Clock Out Function enabled

Ты же его нулем оставил? Остальные я не проверял по даташиту.

У меня появилась идейка как еще проверить передачу. Смени TXID0SIDH

cansend slcan0 7F0#3C.7F.0f 

slcan0  0FF   [0]

Ошибочка, маска на 8 бит.

cansend slcan0 7F0#3C.FF.0f 

Не кастуй меня. Я под логином Eddy_Em больше сюда никогда не приду. Только из-под анонизмуса.

С кэн-шиной работал давно. И это были какие-то дикие контроллеры, которым пришлось перелопачивать модули ядра, чтобы их завести. И работало оно не через canopen, а через сисвызовы.

В canusb есть способ узнать какая именно ошибка?

проверь провода самого CAN'а и что терминаторы у тебя стоят на концах линии, особенно если провод короткий. без них в CAN обычно мусора дофига и вообще хаос.

Не сработало...

Похоже действительно canusb не хочет вещать...

В canusb есть способ узнать какая именно ошибка?

Похоже можно, сейчас начал разбираться с драйвером D2XX но пока результата нет

От шины с двух сторон стоят резистеры на 120ом. Шина действительно очень короткая (менее 20 см) и CAN_H и CAN_L не переплетены; если уж совсем честно, то шина и нода находятся на брэдборде (пруф оф концепт как-никак) и питаются от ноутбука к которому же и подключен CANUSB.

Похоже действительно canusb не хочет вещать...

Но candump же видит пакеты.

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

Нет. Я так понимаю вольтметр у тебя есть, можешь им проверить напряжения между canL и canH canusb при отправке пакетов.

Спамь в цикле 000#00.00.00. Ноль в кане это 5 вольт между выводами. Если покажет на приборе что-то отличное от нуля, то значит шлет.

Здравствуйте. Провел следующие испытания:

• Отключил все питание, отключил mcp2551 от CAN шины
• подключил Pickit3 порты 4,5 на CANH,CANL, перевел в режим осциллографа
• Подключил canusb
• Включил питание на шину
• задеплоил модули ядра, поднял slcan (как описано выше) // лампочки не горят (нет ни ошибки, ни разумеется приёма, поскольку нода отключена
• осциллограф на частоту 500Кгц (как и шина)
• Включил rising edge detection // В шине абсолютная тишина. Ни единого срабатывания
• Отправляю 000#00.00.00 // результат Обратите внимание Ch2 (CANL) постоянно на нуле (не знаю нормально это или нет).
• далее интереснее. После отправки, даже если я не запускаю cansend, а просто включаю осциллограф я вижу очень похожу активность: Раз,Два
• подключаю Node'у
• запускаю осциллограф: Результат
• Выключаю Node'у
• Замер - в шине тишина. Нет ничего
• Отправляю что-нибудь cansend'ом - круг замыкается. Начинается такая же картина, как в начальных пунктах

Iron_Bug , может у вас есть какие-нибудь соображения по поводу поста выше?

Внес некоторые изменения в схему подключения:
1) запитал шину от другого ноута (не от того же, на котором canusb)
2) подключил vdd (+5) второго ноутбука к canusb (в мануале canusb сказано что это «optional»)

Итого получилось, что: нода питается от другого ноутбука и gnd и Vdd от другого ноутбука подключены к canusb.

Осциллографом, при подключенной ноде, получил картику, ближе похожу на правду

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

Вот пример сигналов https://www.interworldna.com/images/pico/canbus_waveform_1.jpg заметь что они зеркальны, дифпара же.

Передача ведется разницей напряжений. Когда обе по 2.5v, разница 0(логическая 1). Если canL 0v и canH 5v, разница в 5v(логический ноль).

У тебя там даже близко на кан не похоже, так еще и есть моменты когда оба сигнала в высоком состоянии.

Частота осцилографа должна минимум в 2 раза превышать частоту сигнала, теорема Котельникова в гугле. Но там и так видно что все не так.

А ты землю пиккита подсоединил к земле шины когда мерял?

Пока единственное объяснение моему результату вижу то, что по какой-то причине и canusb и mcp2551со старта работают в режиме canbus one wire (не путать с 1-wire), когда вся инфа летает по одному проводу. Два эти устройства поддерживают такую передачу, хотя мне не ясно почему. Сегодня вечером попробую замерять сигнал только от mcp2551 без canusb ну и разумеется ещё раз перепроверю все подключения.

Искал в интернетах но так и не нашёл ответ на нетипичный вопрос: есть ли у can шины ограничения по минимальной длине шины?

Может мне стоит попробоватьиспользовать более длинную шину?

Землю к земле подключил. К слову на выводе canusb есть два контакта для земли и два контакта для Vdd но в манула никаких указаний по их подключению нет клик

выводы canusb

Ну Vdd в шине не обязателен, достаточно общей земли на всех нодах. А про 1 wire can я только вот от тебя узнал. : D

Про этот девайс не знаю но постоянно работал с адаптером Меркурий 221 http://www.incotexcom.ru/m221.htm. Проблем с CAN интерфейсом не было ни каких. Правда подключались только к электросчетчикам. Еще CAN интерфейсом балуются адаптеры для диагностики авто.

стоят резистеры на 120ом. Шина действительно очень короткая

Резисторы можно и выкинуть.

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

я тут редко бываю в последнее время.
график странный. идёт сигнал арбитража шины и он обламывается, судя по всему.
если проблема ещё не решена, то проверь ногу Rs на чипе. она регулирует режимы работы чипов mcp2551 (см. даташит). чипы должны быть в одном режиме, соответственно.