[Phantom_ 0]

Привет

Есть у меня МК Freescale DSP56F805.

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

 

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

Среда программирования Metrowerks CodeWarrior 5.6

 

Мне нужно обеспечить хотя бы 3 режима работы:

1) Из этого МК будут читаться данные для отображения на панельки;

2) Возможность отдавать команды для МК;

3) Обмен данными с соседними МК.

 

Не могу разобраться, как назначить МК ID. Как послать значение другому МК или панельке.

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

[aschas 0]

Здравствуйте !

Зайдите к нам на сайт 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-битные идентификаторы (без сильной необходимости)

[DogPawlowa 0]

- не используйте RTR бит (никогда)

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

[galjoen 0]

Сразу хочу Вас предупредить :

- не используйте 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?

[DogPawlowa 0]

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

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

 

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

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

[galjoen 0]

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

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

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

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

[DogPawlowa 0]

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

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

 

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

Ну да ну да

[Phantom_ 0]

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

[galjoen 0]

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

1. Для этого необязательно использовать RTR.

2. При использовании RTR подразумеваетя, что использующий его, знает о том, что отвечающий находится в сети. А откуда взять эту информацию? Вот вы откуда знаете что вам ответят?

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

 

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

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

[Палыч 6]

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

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

[galjoen 0]

Наверное, приимущество одно: стандартный фрейм (не содержащий дополнительных 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 не хватает приоритетов и из-за этого приходится изощрятся, что приводит к ещё большему росту накладных расходов и ЗАМЕДЛЕНИЮ доставки приоритетных сообщений.

[Палыч 6]

Почему от 0 до 64?

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

От 0 до 21 или уж от 0 до 24...

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

[DogPawlowa 0]

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

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

 

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

[galjoen 0]

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

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

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

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

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

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

А насчёт бита RTR, я посмотрел, что он в арбитраже участвует и понял, что напрасно его не использую. Не обязательно для запросов - лишний уровень приоритета всегда полезен.

[Phantom_ 0]

Мужики, пока вы здесь, объясните мне, непонятливому:

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

Объясните на пальцах, в чём разница ? Они, кажется, подобны.

Думаю, что из них использовать для фильтрации. Склоняюсь к маске.

Изменено 8 мая, 2009 пользователем Phantom_