Как реализовать обмен данными по 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 следует считать, что ноль больше еденицы

Ну да ну да

[galjoen]

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

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

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

[Dog Pawlowa]

Кстати, вообще не понимаю какие преимущества у 11 бит ID?

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

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

[galjoen]

От этого места и дальше мы - "говорим на разных языках"...

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

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

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

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

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