Във връзка с темата за матрично свързване на платки се чудех дали да не го направя с CAN, на когото обаче познавам само физическия интерфейс.
Та първият ми въпрос е от много общо естество - лесно ли се подкарва, конкретно на майкрочипски контролери (dsPIC33 серията например). От доста време не съм писал нищо за микроконтролери, но преди няколко пъти съм им дописвал errata на някои техни чепове, а за това проектче не си струва да се разхождам из поляна с мотики.

Вторият ми въпрос е:
до колко е възможно синхронизирането на процеси. Примерно ако изпратя броудкаст команда за семплиране на аналогови канали, тази команда може ли да се дешифрира от хардуера на кана и директно да ме вкара в прекъсване. От там нататък латентността мога сам да си преценя дали ме устройва.

Това е въпрос на имплементация на CAN. И във всички имплементации, които са минавали през ръцете ми, отговорът е: Да.
Периферния CAN модул в почти всички имплементации може да се конфигурира да филтрира съобщенията от бъс-а по ID. И да ги праща в съответно за това ID, FIFO. Съответно можеш да конфигурираш прекъсване при получено съобщение във FIFO-то.
Синхронизирането обаче обикновено се прави по Глобален часовник, което също е въпрос на имплементация - софтуерна в този случай.
Разбира се не изключвам всякакъв друг фолклор, който просто ползва физическия слой на CAN, плюс каквото са отпуснали от Микрочеп-а.

Прецизната синхронизация не му е по силите на кан-а - ако е минала арбитрацията новото съобщение ще трябва да изчака докато се довърши предишното, дори да е с по-висок приоритет. Мисля че в CAN-FD имаше допълнение по темата, ама да не те излъжа.
Ако по друга линия има шедюлинг на времето и си гарантираш че никой не предава в тоя момент, ще стане. Смислените контролери съхраняват и таймстамп на съобщението, което би трябвало да ти даде суб-микросекундна точност, дори и да не се пънеш да реагираш безусловно бързо на прекъсването.

Ако един CAN контролер (примерно MCP2515 в normal mode) прати съобщение, което не се припознава от никой в мрежата, ще получи ли acknowledge и ако не получи, ще предава ли съобщението отново?

Нямам идея от CAN, но не ми звучи логично да получи акнолидж.
Пък дали ще предава до утре - сигурно се задава от ЗКУ-то.

И аз така разсъждавам, но от написаното в чаршафа на контролера, леко се обърквам:

Any node that has received an
error-free frame Acknowledges the correct reception of
the frame by sending back a dominant bit (regardless
of whether the node is configured to accept that
specific message or not)

Да , май грешно разсъждаваме
И аз го прочетох това след поста, и май ще предава пак...освен ако не е програмирано за One-Shot Mode (т.3.4)

One shot mode не ми върши работа, защото, ако бъде загубен арбитража, съобщението няма да бъде предадено. Това, което целя е, дадено съобщение да се предава само веднъж или краен брой пъти в случай, че няма ACK за него.

Е, явно ще усложниш обработките,
ама изглежда ще получиш АСК от някой слушател, aко шината е в ред.

Това се пресъздава лесно само с един дивайс на линията.
На осцилоскоп се забелязват данни постоянно след първоначално предаване на пакет.

Това е ясно, тествал съм го и е така, както казваш. Въпросът беше, ако освен предаващата точка има поне още една, но съобщението не я касае - дали тя ще прати ack. До този момент стана ясно, че - да.

CAN пакетът има само Source Address, няма Destination Address. Така че, всеки пакет касае всяка точка.

Къде го тоя сорс адрес в кан съобщението? Няма такива неща там.

Да, праща ако види валиден пакет, нищо че не е за него. Дали е за него или не се разбира по-навътре според настроените филтри, докато ацк-то идва от по-ниско ниво.
Ако е сам на бъса започва да праща безкрайно докато някой не му го потвърди. Има броячи за error passive режим.

Недей заблуждава хората с празни приказки.