Привет
Есть у меня МК Freescale DSP56F805.
На борту имеется модуль CAN. Я могу его программно включить, и пр.

Однако, не могу себе представить, как написать программу, т.е. принцип обмена данными.
Среда программирования Metrowerks CodeWarrior 5.6

Мне нужно обеспечить хотя бы 3 режима работы:
1) Из этого МК будут читаться данные для отображения на панельки;
2) Возможность отдавать команды для МК;
3) Обмен данными с соседними МК.

Не могу разобраться, как назначить МК ID. Как послать значение другому МК или панельке.
Помогите, тыкните носом куда смотреть, что прочесть. Рад буду увидеть огрызок функции/алгоритма послать/принять.

Здравствуйте !
Зайдите к нам на сайт can.marathon.ru в раздел "Литература" там есть некоторые статьи на русском и в раздел "Протколы СAN" - там есть некоторые описания на русском. Для понимания описаний на английском есть очень хороший толковый словарь англо-русский http://www.can-cia.org/fileadmin/cia/pdfs/...onary-v2_ru.pdf
Если Вы имеете опыт программирования, то Вы можете скачать у нас в разделе "Программы" универсальный CHAI-драйвер для работы с CAN в исходных кодах с GNU-лицензией под Linux и использовать его как пример того как надо правильно программировать CAN-контроллеры и организовывать обмен. Почитайте внимательно описания. В принципе, это очень хорошо проработанный методологически и правктически проверенный на многих платформах подход для организации обменв по шине CAN.
Но, следует заметить, что CAN на уровне стандарта CAN2.0B НЕ РЕГЛАМЕНТИРУЕТ использование поля ID и поля DATA.
Т.е. Вам надо использовать или стандартизованнын протоколы (CANopen, J1939, CANaerospace, MILCan (DeviceNet не предлагаю, но тоже можно)) или придумать свой протокол. Т.е. придумать как данные и/или команды будут упаковываться в поля ID и DATA и как Вы будете идентифицировать узлы в Вашей CAN-сети.
Сразу хочу Вас предупредить :
- не используйте RTR бит (никогда)
- не используйте 29-битные идентификаторы (без сильной необходимости)

Мотивируйте, пожалуйста.

Насчёт RTR бита (в стандартном понимании) пожалуй соглашусь т.к. CAN подразумевает мультимастерность (у кого случилось событие, тот и передаёт). Но для передачи данных этот бит использовать можно (для любителей поизвращатся).
Но вот насчёт 29 битных индентификаторов я имею прямо противоположное мнение т.к.:
1. Никто не запрещает передавать данные через ID. При упаковке туда 2-х байтов общее кол-во данных в пакете будет 10 байт, а не 8. Т.е. например адрес(2 байта)+данные(8 байт).
2. Данные, пересылаемые через ID, будут учавствовать в арбитраже. Т.е. если сделать правильно (в данных 0 важнее 1), то более важные данные передадуться быстрее.
3. Увеличивается кол-во приоритетов у сообщений. Т.е. одно и тоже сообщение (несколько бит в поле ID его тип) может иметь разные приоритеты (доп. биты в ID).
4. Никто не запрещает в одной сети использовать и 11 и 29 бит ID. И если нужны короткие сверхприоритетные сообщения, то можно послать их в формате с 11 бит ID.

А какие недостатки вы видите у 29 бит ID?

И что мультимастерность? Пусть она остается. RTR обеспечивает возможность одного устройства запросить конктретные данные у другого устройства, не гоняя напрасно потоки данных по шине.


А что важнее - ноль или единица?!

CAN предполагает/позволяет, что устойства по СВОЕЙ инициативе будут передавать данные. Случилось к.л. событие у устойства - оно и шлёт сообщение об этом. Как вариант - данные изменились. Как вариант - по таймеру. Как вариант - сообщение "я ещё живой". А использование RTR предполагает протокол типа запрос/ответ. Т.е. фактически это уже не мультимастерность т.к. имеются ведущий (спрашивающий) и ведомый (отвечающий). И шина при этом загружается, наоборот, больше. Что-то типа RS485/модбас получается.

При использовании CAN следует считать, что ноль больше еденицы

Философский вопрос. Я, например, старый маразматик, и люблю, когда устройство само знает названия переменных, доступных для изменения снаружи. Это текстовая строка до 80 байт. Подключив к шине компьютер, я могу универсальной программой прочитать и записать переменные, сопоставляя значения с информацией на человеческом языке, выводимой на экране, а не лазить по шпаргалкам или исходникам. Для этого компьютер спрашивает названия этих переменный у устройства. Без этой фичи шина была бы просто забита.


Ну да ну да

Очень интересно, вы продолжайте, а я поучусь уму-разуму.

1. Для этого необязательно использовать RTR.
2. При использовании RTR подразумеваетя, что использующий его, знает о том, что отвечающий находится в сети. А откуда взять эту информацию? Вот вы откуда знаете что вам ответят?
3. Я ввёл у себя такой режим "всем послать свои описатели" (они посылают их с низким приоритетом, конечно, и шина для высокоприоритетных сообщений свободна). При этом запрос только 1 (ко всем девайсам) т.е. шина (этим самым запросом) загружается меньше. И однов-но узнаю кто сейчас есть в сети (без ожидания сообщений "я жив").

Одновременно тут (п.3) вылезают преимущества 29 бит ID. Т.к. N девайса удаётся разместить в ID (у меня до 64 девайсов в сети одновр-нно) и он соотв-но участвует в арбитраже, то фактически данные приходят от всех устройств поочерёдно и "по старшинству". А был бы 11 бит ID - пришлось бы извращатся. Видимо тогда действительно RTR было бы лучше использовать. Не помню участвует RTR в арбитраже или нет.
Кстати, вообще не понимаю какие преимущества у 11 бит ID?

Наверное, приимущество одно: стандартный фрейм (не содержащий дополнительных 18 бит ID) короче на 21 бит, что при от 0 до 64 бита на данные даёт ощутимое уменьшение "накладных расходов" при передаче...

Почему от 0 до 64? От 0 до 21 или уж от 0 до 24. Кстати никто не запрещает в одной сети использовать и 11 и 29 бит ID. Нормальное железо это позволяет. А если рассматривать накладные расходы в процентах, то ситуация противоположная: 11 бит ID (реально 12 т.к. RTR участвует в арбитраже, оказывается, и может считаться данными) - 47 бит (при отсутствии битстаффинга) т.е. 11/47=23% всего!. 29 бит ID - 67 бит (при отсутствии битстаффинга) т.е. 29/67=43% лучше почти в 2 раза. А при наличии вставки бит результаты ещё лучше у 29 бит ID.
А в реальности при 11 битах ID не хватает приоритетов и из-за этого приходится изощрятся, что приводит к ещё большему росту накладных расходов и ЗАМЕДЛЕНИЮ доставки приоритетных сообщений.

Фрейм содержит поле данных (собственно, эти данные и передаются; я не рассматриваю слачай, когда в ID "заталкивают" данные). Это поле длинною от 0 до 8 байт, т.е. от 0 до 64 бита. Это поле данных "обвязано" служебной информацией (поле арбитража, служебное, контрольное...), которая (ну, за исключением ID) - не информативна. Имхо, чем меньше служебной информации - тем лучше для пропускной способности канала.
От этого места и дальше мы - "говорим на разных языках"...

Я столкнулся с одним - библиотека под WinCE /С# написана только для 11 бит. Поэтому мне пришлось съехать до 11, чтобы облегчить жизнь программисту на C#.

Что касается бита RTR и определения наличия устройств... В большинстве систем так или иначе просматривается структура мастер-слэйв. Быть может, в моем она более выражена. Нечего включать насосы, если каретка не стала в нужное положение, а всем рулит один контроллер. Поэтому в моем случае все достаточно логично. Хотя по прежнему не вижу никаких недостатков в использовании RTR и при равноценных контроллерах. При более-менее завязанных друг на друга действиях разных контроллерах в системе все так же логично.

Я имел ввиду как раз "заталкивание" данных в ID. Отсюда 18 бит, а не 21 конечно (предполагаемых затолкнутых в ID данных), ну или 24=3 байта. А заталкивание происходит вольно или невольно. Но когда вольно - результат лучше получается. У меня (при 29 бит ID) 90% сообщений вообще без данных.

Я един в 2х лицах. Поэтому решил одному себе за счёт другого себя жизнь не облегчать, а сделал самодельный переходник USB-CAN.

Мастер-слейв конечно просматривается, но CAN предполагает/позволяет наличие достаточно "умных" слейвов. Таких, что по своей инициативе будут работать. И о том что они имеются говорить, и при изменении дискретных данных сами без опроса об этом скажут, и будут знать уставки контролируемых параметров и по своей инициативе говорить о превышении, и об авариях, и с заданной частотой данные передавать смогут, и т.п.
А насчёт бита RTR, я посмотрел, что он в арбитраже участвует и понял, что напрасно его не использую. Не обязательно для запросов - лишний уровень приоритета всегда полезен.

Мужики, пока вы здесь, объясните мне, непонятливому:
В микроконтроллере есть SetAcceptanceCode ( Задаёт ID сообщения, данного буфера сообщения. Буфер сообщения исполльзуется для фильтрации сообщений входящих кадров) и SetAcceptanceMask (Задаёт регистры маски подтверждения, кажется так. Этот метод пишет подтверждающую маску напрямую в регистры маски подтверждения).
Объясните на пальцах, в чём разница ? Они, кажется, подобны.
Думаю, что из них использовать для фильтрации. Склоняюсь к маске.

Наверное, есть не в микроконтроллере, а в используемой Вами библиотеке для работы с CAN?
Для приёма пакетов задают идентификатор (назовем его IDR) и маску (MSKR). Если пришел пакет с идентификатором ID, и выполняется условие ID & MASKR равно IDR, то такой пакет принимается для дальнейшей обработки. Наверное, указанные Вами процедуры и задают IDR и MSKR. Это - моё предположение, следует найти описание этих процедур...

Можно об этом подробнее? Или есть уже, где посмотреть, что получилось?