Тут, для меня проблем работы с МАРАФОНОМ вплоть до создания своих программулин, например, нет. Дело больше в самом CAN – для самого начала неплохо бы изучить структуру КАН-кадра (или «сообщения», или «фрейма» – в разной документации возможно различное название). Для этого, опять же, надо представлять для чего вообще была создана эта технология и, если хотите, её «философия» - то есть, чем принципиально она отличается от других (того же, например RS485). Тут важно понимать, что за «простоту» принципа обмена информацией «расплачиваются» повышением общих накладных за счет обязательности у каждого прибора в сети наличия КАН-контроллера. Далее, - естесственно, это все стандартизировано, и ещё на аппаратном уровне имеются и проверки целостности, и защита от ошибок, и аппаратные фильтры и ещё много чего нужного, но делаемого автоматически и, таким образом, освобождающего программиста от заботы об этом всем.. Для программера остается только сам формат кадра – идентификатор сообщения и восемь байт с данными. И ВСЕ – больше он ни о чем может не волноваться. Протокол обмена устроен так: например, там написано, что некий датчик общается с основными «мозгами» авто в следующем порядке: на скорости 500 кБит/с, форма – «запрос – ответ», формат данных – «в первом байте – каждый бит (из 8-ми) говорит о его состоянии, - 1-ый, допустим, исправен-неисправен (да-нет – булева переменная, 2-ой – есть связь-нет связи, третий - ещё какие-то булевы параметры.)» То есть первый байт, по протоколу ответственен за булевы переменные (да-нет). Второй байт может быть уже какой-то аналоговой величиной (допустим, напряжение). Тогда весь байт отдан под него (может быть под аналоговые переменные отдано и больше – один байт максимум обеспечивает 255 – и то, если беззнаковая переменная, если знаковая – то до 127). Ну, и так далее – все зависит от того, как заранее ДОГОВОРИЛИСЬ это все дело передавать. Если для передачи данных не хватает восьми байт, то в протоколе прописывают ещё один кадр со своим идентификатором и восемью байтами данных. И т.д. Далее – контроллер датчика постоянно слушает сеть (как, впрочем, и все остальные контроллеры остальных приборов). «Слышит» он все сообщения, которые в ней «гуляют». Как только он услышал в сети кадр с идентификатором, который прописан у него программно (или в фильтре), только на него он реагирует – шлет свой пакет из предписанных ему по протоколу сообщений (о своем состоянии, величинах которые он контролирует и проч.) Кстати, очень часто, в одном из байт, как правило, передается так называемый «счетчик» - в каждом новом сообщении величина счетчика увеличивается на 1 и так до 255, потом – по-новой. Для «принимающей» стороны это, хоть и косвенно, говорит о том, что прибор исправен. Да и при необходимости, можно точно восстановить последовательность кадров. Формат общения не обязательно может быть «запрос-ответ», зачастую такие приборы, как датчики сами с некоторой «договоренной» периодичностью шлют свои сообщения. Или наоборот, - шлют только по запросу, если же превышен некоторый критичный порог, - начинают слать постоянно с некоторой периодичностью.. И т.д. – все это и есть описание протокола информационного обмена… Ну, как, нужен такой «ликбез»?...
