протокол CAN

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Здpавствуй, All!

Возникла проблема в осознании принципа формирования идентификаторов ID
сообщений при передаче информации через CAN. Рылся в инете, нашел несколько
статей, но так и не понял в соответствии с каким принципом формируются ID,
маски...
        Я пишу для моторолы mpc565. Так вот тут в мане есть пример программы:
(У контроллера 3 модуля CAN; у каждого модуля 14 буферов сообщений, регистр
глабальной маски для регистров 0..13, и 2 специальных для 14го и 15го буферов
сообщений. Два разных режима работы для буферов сообщений: стандартный и
расширенный.(standard ID message buffer structure(11 бит) и extended ID message
buffer structure(29 бит) ) )...

Тут на англицком, я попытаюсь перевести:
"
Приложение использует MB14 (MB - message muffer)для прослушивания фреймов со
стандартным ID 0x11. маска Rx14Mask установлена в 0x0FF. folowing IDs will fit:
0x111, 0x211,..,0x711. Когда какой нибудь фрейм будет найдет (я так понял в
канале связи) ответ (echo frame) отсылается с MB1. Echo frame frame is assigned
ext ID 0x1111. (здесь уже расширенный ID, зачем не понимаю :) )

MB13 слушает фреймы с ID 0x22 RXGlobalMask установлена в 0x7FE. folowing IDs
will fit:0x22, 0x23. Когда пришел фрейм ответ посылается из MB0. Ответный фрейм
имеет расширенный ID 0x23(Echo frame is assigned ext ID 0x23)

В главном цикле MB5 периодически шлет данные с ID 0x333333

там еще есть, но это уже потом может сам осознаю на основе выше изложенного )
"
Так вот, собственно, мне не понятно как эти все ID формируются. Может у
когонить есть мануал для "для даунов" по этому поводу? или объясните как это
работает?

С уважением - Aleksandr

Re: протокол CAN
AL> Так вот, собственно, мне не понятно как эти все ID формируются. Может у
когонить есть мануал для "для даунов" по этому поводу? или объясните как это
работает?


идентификаторы раздаешь своим устройствам сам.
меньший номер соответствует большему приоритету и наоборот.


то есть например у тебя есть термометр, сигнал аварии, кнопка.

назначаешь им идентификаторы

термометр - 100
авария    - 10
кнопка    - 20

получается что от термометра сообщения будут ожидать освобождения шины
если одновременно с термометром начала передавать кнопка, а от кнопки
сообщения будут ожидать освобождения шины если одновременно с ней
начался передаваться сигнал аварии.

назначать идентификаторы проще всего руками положив их в один .h-файл,
который используется во всех девайсах на шине. В этом случае трудно
получить "пересекающиеся" идентификаторы.

ну а еще есть куча протоколов которые позволяют автоназначать
идентификаторы по типу как это делает DHCP, но там что-то столько
наворотов что мне как-то не представляется проект в котором это
оправдано... почитай CANopen например на эту тему

... Я в оптический прицел президента разглядел!

Re: протокол CAN
Здpавствуй, Dmitry!

Понедельник 11 Октября 2010 22:26, ты писал(а) мне, в сообщении по ссылке

 AL>> Так вот, собственно, мне не понятно как эти все ID формируются.
 AL>> Может у когонить есть мануал для "для даунов" по этому поводу? или
 AL>> объясните как это работает?

 DO> идентификаторы раздаешь своим устройствам сам.
 DO> меньший номер соответствует большему приоритету и наоборот.

<----->

 DO> ну а еще есть куча протоколов которые позволяют автоназначать
 DO> идентификаторы по типу как это делает DHCP, но там что-то столько
 DO> наворотов что мне как-то не представляется проект в котором это
 DO> оправдано... почитай CANopen например на эту тему

Ага, это понял, спасибо.
Еще по поводу ID: У меня 2 контроллера "общаются" по кану. Так вот, не
используя каких-то отдельных протоколов, на уппаратном уровне, принимающий
мудуль CAN каким то образом сам фильтрует поступающие посылки, монипулируя ID и
масками.(это я понял из примера в мане)
Т.е. В отличие от RSа, здесь сам модуль определяет ему ли пришло сообщение и в
какой буфер сообщений оно адресовано. В RSе то программно задаются адреса, и
посылки приходят всем участникам сети. Программист портом сам программно
фильтрует посылки.

 Вот эти монипуляции я никак не могу понять. Т.е. если посмотреть с моей
стороны (программиста), то видна следующая картина: когда по шине приходит
сообщение, то приемник(это опять же из примера) сам, на аппаратном уровне,
проеверяет ID посылки в соответствии с ID принимающих буферов. Если посылка
предназначается одному из этих буферов, то кладет данные в эти буфера.
Проверяет время, потраченное посылкой на достижение одресата. Выставляет флаг
прерывания соответствующего буфера. !-> И посылает Acknowledg обратно
передатчику (Так ли это, насчет Acknowledg?).

Так вот у меня передатчик передает, пакеты на осциллографе я вижу, даже могу
пальцем на экране асцила показать в каком месте посылки сами данные передаются,
но приемник молчит как мертвый. А передатчик при этом ругается, что не получает
подтверждения. К сажалению, не могу быть уверенным в отсутствии косяков в
настройке приемника...

Извиняюсь за непоследовательность, но еще кое что касаемо выше упомянутого
примера: Для приема и передачи используется один и тот же модуль CAN, но
некоторые из его буферов передают, а некоторые принимают... Hу раз в мане так
есть, значит оно должно работать ? 0_о. Попробовал так же написать программу.
Что получилось: сам модуль CAN тяжело настроить неправильно. Ведь получается,
что здесь и приемник и передатчик настраиваются одновременно, и эдентично,
разница лишь в ID буферов. Hо вот у меня это не работает, передатчик передает,
а приемник не принимает.

П.С. Freescale + QuickStart = это что-то. Предложенная квикстартом
инициализация не работает, пришлось ручками инитить все регистры ((

С уважением - Aleksandr

протокол CAN
Hello, Aleksandr !

Once (Wednesday October 13 2010) at 12:32 someone named Aleksandr Lapshenkov
wrote to Dmitry E. Oboukhov. So, look here:


 AL> П.С. Freescale + QuickStart = это что-то. Предложенная квикстартом
 AL> инициализация не работает, пришлось ручками инитить все регистры ((

   А не пробовал использовать Processor Expert? Я чтоб не парится с регистрами,
просто создал проект на PE и вытащил потом из асемблерных файлов, сгенерённых
им, уже готовые процедуры инициализации. Правда там синтаксис асма не совпадал,
но это уже мелочи.
   Правда не знаю, есть ли PE под mpc, я для дсп писал, там PE в кодеварриор
встроен.

--
Best regards,
 Wiktor Martyshenko

протокол CAN
Hello, Wiktor!

 AL>> П.С. Freescale + QuickStart = это что-то. Предложенная квикстартом
 AL>> инициализация не работает, пришлось ручками инитить все регистры ((

 > А не пробовал использовать Processor Expert? Я чтоб не парится с регистрами,
 > просто создал проект на PE и вытащил потом из асемблерных файлов,
 > сгенерённых им, уже готовые процедуры инициализации. Правда там синтаксис
 > асма не совпадал, но это уже мелочи.
 > Правда не знаю, есть ли PE под mpc, я для дсп писал, там PE в кодеварриор
 > встроен.

Залез на сайт фрискейла, похоже действительно нет PE для mpc.
А жаль, было бы здорово :(

WBR, Aleksandr Lapshenkov.


протокол CAN
Aleksandr,

You wrote to Dmitry E. Oboukhov:

 AL>>> Так вот, собственно, мне не понятно как эти все ID формируются.
 AL>>> Может у когонить есть мануал для "для даунов" по этому поводу?
 AL>>> или объясните как это работает?
 AL>
 DO>> идентификаторы раздаешь своим устройствам сам.
 DO>> меньший номер соответствует большему приоритету и наоборот.
 AL>
 AL> <----->
 AL>
 DO>> ну а еще есть куча протоколов которые позволяют автоназначать
 DO>> идентификаторы по типу как это делает DHCP, но там что-то столько
 DO>> наворотов что мне как-то не представляется проект в котором это
 DO>> оправдано... почитай CANopen например на эту тему
 AL>
 AL> Ага, это понял, спасибо.
 AL> Еще по поводу ID: У меня 2 контроллера "общаются" по кану. Так вот, не
 AL> используя каких-то отдельных протоколов, на уппаратном уровне,
 AL> принимающий мудуль CAN каким то образом сам фильтрует поступающие
 AL> посылки, монипулируя ID и масками.(это я понял из примера в мане) Т.е.
 AL> В отличие от RSа, здесь сам модуль определяет ему ли пришло сообщение
 AL> и в какой буфер сообщений оно адресовано. В RSе то программно задаются
 AL> адреса, и посылки приходят всем участникам сети. Программист портом
 AL> сам программно фильтрует посылки.
 AL>
 AL>  Вот эти монипуляции я никак не могу понять. Т.е. если посмотреть с
 AL> моей стороны (программиста), то видна следующая картина: когда по шине
 AL> приходит сообщение, то приемник(это опять же из примера) сам, на
 AL> аппаратном уровне,
 AL> проеверяет ID посылки в соответствии с ID принимающих буферов. Если
 AL> посылка
 AL> предназначается одному из этих буферов, то кладет данные в эти буфера.
 AL> Проверяет время, потраченное посылкой на достижение одресата.
 AL> Выставляет флаг прерывания соответствующего буфера. !-> И посылает
 AL> Acknowledg обратно передатчику (Так ли это, насчет Acknowledg?).

Об этом почему-то и я в своё время нигде не нашёл даже намёка...
на самом деле подтверждение формируется и отправляется аппаратно!!!
А вот формат подтверждения везде расписан.

 AL> Так вот у меня передатчик передает, пакеты на осциллографе я вижу,
 AL> даже могу пальцем на экране асцила показать в каком месте посылки
 AL> сами данные передаются, но приемник молчит как мертвый. А передатчик
 AL> при этом ругается, что не получает подтверждения. К сажалению, не
 AL> могу быть уверенным в отсутствии косяков в настройке приемника...

У приёмника настраиваются две маски - накладываются на адрес-айди -
одна - по которой мессага пропускается на приём, вторая - определяет биты,
которые при приёме не обрабатываются, в смысле контроля АйДи на предмет
пропусканя для приёма.

 AL> Извиняюсь за непоследовательность, но еще кое что касаемо выше
 AL> упомянутого примера: Для приема и передачи используется один и тот же
 AL> модуль CAN, но некоторые из его буферов передают, а некоторые
 AL> принимают... Hу раз в мане так есть, значит оно должно работать ? 0_о.
 AL> Попробовал так же написать программу. Что получилось: сам модуль CAN
 AL> тяжело настроить неправильно. Ведь получается, что здесь и приемник и
 AL> передатчик настраиваются одновременно, и эдентично, разница лишь в ID
 AL> буферов. Hо вот у меня это не работает, передатчик передает, а
 AL> приемник не принимает.

Про то, как настроены маски, я так и не понял...


Andrey


протокол CAN
Hello, Andrey!

 > Aleksandr,

 > You wrote to Dmitry E. Oboukhov:

 AL>>>> Так вот, собственно, мне не понятно как эти все ID формируются.
 AL>>>> Может у когонить есть мануал для "для даунов" по этому поводу?
 AL>>>> или объясните как это работает?
 AL>>
 DO>>> идентификаторы раздаешь своим устройствам сам.
 DO>>> меньший номер соответствует большему приоритету и наоборот.
 AL>>
 AL>> <----->
 AL>>
 DO>>> ну а еще есть куча протоколов которые позволяют автоназначать
 DO>>> идентификаторы по типу как это делает DHCP, но там что-то столько
 DO>>> наворотов что мне как-то не представляется проект в котором это
 DO>>> оправдано... почитай CANopen например на эту тему


 AL>> Выставляет флаг прерывания соответствующего буфера. !-> И посылает
 AL>> Acknowledg обратно передатчику (Так ли это, насчет Acknowledg?).

 > Об этом почему-то и я в своё время нигде не нашёл даже намёка...
 > на самом деле подтверждение формируется и отправляется аппаратно!!!
 > А вот формат подтверждения везде расписан.

По поводу формата подтверждения - поищу..

Единственное, что нашел на данные момент это вот:
"ACKnowledgement Check - каждый узел получив правильное сообщение по сети
посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий
узел регистрирует ошибку Acknowledgement Error."

<------>

 > У приёмника настраиваются две маски - накладываются на адрес-айди -
 > одна - по которой мессага пропускается на приём, вторая - определяет биты,
 > которые при приёме не обрабатываются, в смысле контроля АйДи на предмет
 > пропусканя для приёма.

Я вот тут нашел немного ифы "на пальцах" по этому вопросу, вроде бы начал
понимать как это обычно делается:
http://electronix.ru/forum/index.php?showtopic14%157&st=0&p97%827&#entry97827

<----->

 > Про то, как настроены маски, я так и не понял...

Решил не замарачиваться с примером, а пытаться писать свое )

WBR, Aleksandr Lapshenkov.


протокол CAN
Hello, Andrey!

В общем с протоколом более менее рзобрался. Даже сеть CAN заработала. А не
работала она тупо по причине непропая ((

WBR, Aleksandr Lapshenkov.


Site Timeline