протокол CAN

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

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

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

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

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

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

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

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

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

Зд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

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 в кодеварриор встроен.

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

Hello, Andrey!

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."

Я вот тут нашел немного ифы "на пальцах" по этому вопросу, вроде бы начал понимать как это обычно делается:

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

WBR, Aleksandr Lapshenkov.

Hello, Wiktor!

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

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

WBR, Aleksandr Lapshenkov.

Hello, Andrey!

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

WBR, Aleksandr Lapshenkov.