Здравейте! Трансфера на данни върви без проблем, но искам да добавя и адрес на получател. В документацията се говори за 2 маски и 6 филтъра. Като библиотека използвам CAN-MCP251x на CCS(имам я и преведена за XC8).
Изпробвах всякакви комбинации на маски и филтри - без резултат.
Контролерите продължават да получават данни от всички адреси, а връщаният адрес от can_getd() функцията винаги е 0(тя фукнцията не връща адрес, а се подава указател към адрес..).
Ето библиотеката за тези, които я нямат:
Как става тази работа? Или трябва аз да добавя някакъв байт в изпращаните данни, които да играе ролята на адрес?
Благодаря!

Реализирах варианта с допълнителен байт служещ като адрес. Добре работи!
Все пак ако някой знае как става работата с тези маски и филтри ще съм благодарен ако сподели!

Някой играл ли си е да подкара софтуерен can контролер на обикновен pic?
Да речем, че трябва да се пращат само 3-4 фрейма..... и няма RX данни. Демек - да разбира, кога шината е свободна, да разбира от арбитраж, да чете ack бит.....

Пробвах с pic12f1840 с вътрешен осцилатор на 16 Mhz. Слухти за свободна шина и прави арбитраж. На 50 Kb/s шина работи прилично. Ако трябва да се прави и RX частта, нещата стават тегави и не си струва мазохизма.

Да го правиш софтуерно е безсмислено.
Какво те мъчи с филтрите и маските? Операцията е логическа - идва число (идентификатора от полученото съобщение), то се подава на филтъра. В този филтър първо се прилага "маската" като логическо И - на този етап целта ти е да махнеш определени битове, които не те интересуват - например ако искаш да хванеш група от идентификатори можеш да махнеш определени битове (примерно най-младшите 3) и така ще "минават" през филтъра 8 поредни идентификатори.
Та след като определени битове се махнат от числото, отива на следващата стъпка - сравнение (цифров компаратор) - ако съвпадне минава навътре и влиза в мейлбокса, ако не съвпадне изчезва и не влиза.
Това се прави, защото имаш ограничено количество "меилбокси", а те са там за да класифицираш групите съобщения според някаква приоритетност - в логически "канали". Това ти е нужно и полезно, ако искаш да закачиш обработката на различни прекъсвания поради това че определен идентификатор в протокола е с по-висок приоритет и трябва да се обслужи по-бързо.
Затова и протоколите за КАН се мислят за лесно групиране по идентификаторите - бавните, асинхронни данни се предават в една зона от идентификатори, бързите - в друга. Ако има идея за адресация (например canopen) се ползват примерно най-младшите битове за да се сложи адреса - например там SDO заявките се пращат като 0x600+адреса - т.е. заявката към нод на адрес 5 мастъра я праща като съобщение с идентификатор 0х605, а за адрес 43 се праща на 0х643.
В слейва имаш възможност за два подхода - да не ползва филтрите на хардуерно ниво и всички съобщения да влизат към софтуера - тогава софтуера ще се занимава с всичко по бъса, дори да е ясно че не е за него. Т.е. филтрите ще са софтуерни. Понякога и това се прави - ако примерно искаш да следиш трафика и да пращаш по усб примерно.
Но ако говорим за ембедед устройство, се прави друго - филтъра се слага така, че устройството с адрес 43 си настройва филтъра да влизат само идентификатори, завършващи на 43. Така съобщенията, предназначени за други адреси, не го безпокоят.
Маските позволяват да "махнеш" примерно старшите битове и филтърът ти да пропуска не само точно 0х643, а всичко завършващо на 43 - 0х043, 0х143, 0х243, .. 0х743 и т.н. За този пример маската ти трябва да има 0-ли в старшите битове и 1-ци в младшите - т.е. казваш старшите са "don't care", младшите трябва точно да съвпадат.

Цялата тая концепция идва от идеята на КАН бъса да има адресиране по съдържание, а не само по слейв адрес. В смисъл че предназначението на дадено съобщение се описва в идентификатора - няма друго поле за адрес, и, на твоя въпрос, не бива да слагаш адрес в данните. Ако имаш нужда да адресираш към физически конкретно устройство правиш обратното - къде в идентификатора стои адреса. На по-смислените протоколи това се ползва, но не за всичко - има "области" от идентификатори, за които тая логика е така (както описаната за SDO - тя е валидна за зона от 0х600-0х6FF за заявки, и от 0х500-0х5FF за отговори). Но извън тая зона има други зони - примерно от 0х180, в която няма адреси, т.е. 0х185 не значи че е нещо за адрес 5.
Така се комбинират различни услуги (протоколи) с различни нужди - SDO-то е за асинхронни request-response, другата зона на 0х180 е за процесни данни (PDO) - там механизма вече е producer-consumer и може да се прави предаване на данни от един източник към много получатели.