Контроллер AT90CAN128, cреда программирования CvAVR.
CAN инициализировал, мобы на отправку тоже. Сообщения отправляются.

Уперся в прием кадра:
В сеть другим устройством кидается кадр с id 401 и длиной 1 байт, мне нужно его принять.
Пытаюсь сконфигурировать моб7 на прием конкретного кадра с id 401. Что то не получается принять данные... Я правильно конфигурирую сам моб?
Пожалуйста прочтите каменты после строк кода и ответьте если в курсе...


CANPAGE = 0x78; //выбор моб7 автоинкремент буфера данных отключен
// вопрос. если автоинкремент отключен, то как читать/писать canmsg с индексом байта, так? canmsg[0]... canmsg[7]

CANCDMOB = 0;
//вводим моб в неопределенное состояние (прием/передача не определены) -думаю это не обязательно

CANIDT1 = 0x32; //задаем TAG: id "401"
CANIDT2 = 0x20; //...
//сдесь задаем именно этот id -401

CANIDM1 = 0xFF; //задаем mask "111 1111 1111" прием/передача только одного id
CANIDM2 = 0xE0; //...
//тут по-идее маска, что прием будет конкретного id, а зачем??? если мы уже указали в TAGe, что ждем id 401 и другие будут отсеиваться...

CANSTMOB=0; // очистим ош-ки и прерывания данного моба
CANCDMOB = 0b10000001; //Разрешаем прием кадров в этот моб, без ответа, CAN2.0A, ожидаемая длина сообщения 1байт

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

даже с такой инициализацией в CANSTMOB нет флага успешного приема. Вообще как будто нет моба на прием:

CANPAGE = 0x70;
CANCDMOB = 0;
CANSTMOB=0;

CANIDT1 = 0;
CANIDT2 = 0;
CANIDT3 = 0;
CANIDT4 = 0;

CANIDM1 = 0;
CANIDM2 = 0;
CANIDM3 = 0;
CANIDM4 = 0;

CANCDMOB = 0x80;

с такой инициализацией моб должен хватать первое же сообщение на прием, неважно какой id и т.п. а флага успешного приема нет. и ошибок приема нет никаких.

совсем я что то запутался, в чем может быть дело...

здесь среди файлов я выкладывал "фирменную" библиотечку для работы с CAN непосредственно от Atmel - в соответствующем разделе форума есть ссылка. так вот, скачайте эту либу (она для WinAVR) и посмотрите, как делают там, ну и сделайте так же. или вообще всю либу портируйте на свой CVAVR, особых сложностей не должно возникнуть.

У меня такое ощущение, что я делаю то правильно, просто не на то настраиваю прием!

В автомобиле (вижу сеть при помощи ноута и адаптера can) по нажатии кнопки в кадре с id 401 изменяется значение (кадр всего один байт).
Похоже что не простой прием, а типа удаленного запроса или еще чего-то, с этим я пока не разбирался. Как видно в моих предыдущих постак биты RTRTAG и RTRMSK (в CANIDT4 и CANIDM4) у меня по нулям, возможно нужно заполнить биты, и соответственно прием кадра в CANCDMOB настроен 0х80 Rx data frame, а возможно нужно на Remote Frame.

Я эту библиотеку уже давно скачал, но там еще сложнее для понимания...

Я с отключенным автоинкрементом не работал, но подозреваю, что индекс считываемого байта надо запихивать в три младших бита CANPAGE:
"INDX2:0: FIFO CAN Data Buffer Index Byte location of the CAN data byte into the FIFO for the defined MOb".


Маска определяет, какие биты ID будут приниматься во внимание при фильтрации. Если маска=0, приниматься будет всё подряд, невзирая на значение в IDT.

И еще:
Присвоение CANSTMOB=0, то есть сброс статуса лучше делать сразу после указания моба в CANPAGE.

Remote Frame - вобще не из этой оперы.

А как у вас выглядит инициализация всего CAN ? Включены ли принимающие мобы в CANEN1,CANEN2 ?
Вы уверены, что настроенная скорость совпадает со скоростью сети? (Принимают ли остальные то, что вы передаете)

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

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

для обеих кнопок один can-кадр c id 401, судя по программе CANHACKER, он содержит 1 байт, в котором изменяются разные биты в реакцию на нажатие одной или другой кнопки.

Исходя из этих данных, я так понял, что это похоже на удаленный запрос, а ловил я кадр с id 401 как простой кадр приема- может поэтому он и не проходил процедуру сравнения и в статусе этого "моба на прием" не было RxOK, там вообще ничего, он в "0".


Может мне кто нибудь разъяснить как принять удаленный запрос? В даташите атмела (и в русской версии) очень скудно написано, "при удаленном запросе нужно выставить бит RTRTAG". Ну понятно что если ждем удаленный запрос, то нужно выставить бит RTRTAG в CANIDT4, но для чего там же RB0TAG, как его выставить? и для чего в CANIDM4 биты RTRMSK и IDEMSK- их как выставлять в этом случае?

В Remote Frame вообще нет поля данных, после DLC сразу CRC идет.
(Это из бошевской спецификации CAN, версия Sep. 1991; Part A - page 15, 3.1.2; Part B - page 49, 3.2.2)
Так что если есть хоть один байт данных - то имеется явно Data Frame.

Если RTRMSK обнулить - то фильтр не будет различать Data Frame и Remote Frame с одинаковым ID, примет и то и другое.
Если выставить в 1 - будет приниматься то, что задаёт RTRTAG.
Про IDEMSK я сам плохо понимаю. По идее, его обнуление приведет к приему сообщений как стандартного так и расширенного формата. А вот если 1 - я не нашёл где задаётся, какой формат принимать (бит IDE в CANCDMOB - "IDE bit of the remote or data frame to send").
В атмеловском CAN Tutorial написано:
Для CAN2.0A: IDEMSK : Identifier extension mask value : 0 comparison true forced 1 comparison enable (detect CAN2.0b reception while CAN2.0a expected)
Для CAN2.0B: IDEMSK : Identifier extension mask value : 0 comparison true forced 1 comparison enable (detect CAN2.0A reception while CAN2.0B expected)

RB0TAG служит для задания значения резервного бита R0, который следует за битом IDE (в стандартном формате CAN2.0B с 11-битным ID) или за R1 (в расширенном формате CAN2.0B с 29-битным ID и в CAN2.0A).
Этот бит "reserved for future expansion", то есть в нынешних протоколах можно на него забить, и писать 0.
Что интересно, он входит в Control Field, а не в Arbitration Field, и в фильтрации не должен учитываться, по идее. Но в даташите в разделе Acceptance Filter указывается критерий фильтрации: ID + RTR + RBn + IDE


Все-таки попробуйте CANSTMOB=0 прописать сразу после задания CANPAGE, и только потом CANCDMOB=0 .
А еще на всякий случай при настройке принимающего моба в DLC задать 1.

черт! я попутал с переводом id бинарника в хекс. 401 будет по другому записываться.

Вот так все пашет! CANSTMOB я действительно перенес в начало, но сомнительно, по-моему его и в конце можно ставить.
Спасибо тебе Juray, а то что то маловато тем по этому мк, подсмотреть реальные примеры негде... (

void Rx_mob(void)
{

CANPAGE = 0x70; //выбор моб7
CANSTMOB=0; // очистим ош-ки и прерывания данного моба

CANIDT1 = 0x80; //задаем TAG: id "401"
CANIDT2 = 0x20; //...
CANIDT3 = 0;
CANIDT4 = 0;

CANIDM1 = 0xFF; //задаем mask "111 1111 1111" прием/передача только одного id
CANIDM2 = 0xE0; //...
CANIDM3 = 0;
CANIDM4 = 0;

temp2=CANMSG;
CANCDMOB = 0x81; //Разрешаем прием кадров в этот моб, без ответа, CAN2.0A, ожидаемая длина сообщения 1байт
}

Читал что в ней есть ошибка переполнения и проглатывания пакетов, это правда?