Как реализовать обмен данными по CAN ?, новичёк я Опции

[Phantom_]

Привет
Есть у меня МК 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-битные идентификаторы (без сильной необходимости)

[galjoen]

Сразу хочу Вас предупредить :
- не используйте 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?

[Dog Pawlowa]

Насчёт RTR бита (в стандартном понимании) пожалуй соглашусь т.к. CAN подразумевает мультимастерность (у кого случилось событие, тот и передаёт).

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

2. Данные, пересылаемые через ID, будут учавствовать в арбитраже. Т.е. если сделать правильно (в данных 0 важнее 1), то более важные данные передадуться быстрее.

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

[galjoen]

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

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

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

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

[Dog Pawlowa]

... И шина при этом загружается, наоборот, больше.

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

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

Ну да ну да