[spf 0]

Если соотношение тактовой частоты контроллера и шины большое, возможна ситуация, когда при последовательной отправке двух и более сообщений один канал начнет передачу первого сообщения, а флаг занятости передатчика (либо канала) будет выставлен позднее, чем будет выполнена его проверка для возможности передачи второго сообщения. В итоге пойдет запись второго пакета в тот-же канал, он будет частично переписан, т.е. комбинация двух сообщений (CRC будет верна).

Если контроллер так криво работает, то как вообще тогда можно работать с ним?

[Fledgling 0]

Перегрузка легко считается.

1) Какая скорость используется?

2) Сколько байт данных в сообщении?

3) Какие драйвера применены?

4) Какие расстояния?

5) Терминаторы на месте?

6) Контролируете ошибки в контроллере CAN?

 

1) Максимальная - 1 Мбит/сек

2) 4 слова - 8 байт

3) ? Что имеется в виду под драйвером? Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET).

4) Расстояния между процессорами на плате - меньше 10 см, расстояние от контроллера, осуществляющего передачу "вовне" (на ПК) - меньше 2 м.

5) на месте

6) нет, ошибки не контролируются в связи с тем что автор чайник и не знает как это делать)))

 

 

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

Имеется в виду, выставлять один и тот же кадр на выдачу несколько раз за цикл? Но по какому алгоритму это делать?

 

Вообще причину легко будет понять, если проанализировать статусные регистры can-контроллера после каждой отправки/получения.

Какие имено поля CSR (CAN Status/Control Register) анализировать? LEC?

 

В CAN сообщение считается переданным только тогда, когда все "сказали" что все до них дошло без ошибок.

Как это можно определить?

Выставляется ли контроллером какой нибудь флаг в CSR или Message Control Register, сообщающий о том, что именно все адресаты получили сообщение?

 

!!!!!!!!!!!!!! Не _все_, а _хоть один_ кто-то !!!!

Да, мне тоже так казалось:)

Но после цати тестов моего бага я уже ни в чем не уверен))

[spf 0]

!!!!!!!!!!!!!! Не _все_, а _хоть один_ кто-то !!!!

Приплыли...

Я поставил слово в кавычки именно потому, что хоть кто-то должен сказать "ок" в нужный момент, а все остальные с этим должны согласиться или сказать что в канале ошибка. Если ошибка, то все должны это сообщение выкинуть.

 

 

 

Как это можно определить?

Выставляется ли контроллером какой нибудь флаг в CSR или Message Control Register, сообщающий о том, что именно все адресаты получили сообщение?

Почитайте стандарт, там все доходчиво сказано, даже с картинками и в переводе :)

[Vokchap 0]

Если контроллер так криво работает, то как вообще тогда можно работать с ним?

Учитывать это. Уже наступал на эти грабли.

[Andrew2000 0]

Приплыли...

Ну так и формулируйте яснее: " когда все "сказали" " - вот "все" Вас и поняли... :)

 

Под однократной передачей я имел ввиду вот что. У Infineon-a (прочитав в посте-вопросе про message objects я подумал, что CAN-контроллер тот-же) в CAN-контроллере можно задать однократный режим передачи, когда контроллер будет только один раз пытаться передать телеграмму не обращая внимание на ощибки и отсутствие подтверждения приема удаленной стороной.

Если выключить однократную передачу - будет ждать подтверждение (точнее пытаться передать "до посинения").

[spf 0]

Имеется в виду, выставлять один и тот же кадр на выдачу несколько раз за цикл? Но по какому алгоритму это делать?

Не надо ничего выставлять несколько раз.

Контроллер должен сам повторять сообщения, если на шине возникают ошибки. В некоторых контроллерах можно отключать автоматический повтор передачи сообщений (делать только одну попытку отправки). Видимо про это была речь.

 

 

Учитывать это. Уже наступал на эти грабли.

Это где такие грабли?

[Vokchap 0]

У Infineon-a (прочитав в посте-вопросе про message objects я подумал, что CAN-контроллер тот-же) в CAN-контроллере можно задать однократный режим передачи, когда контроллер будет только один раз пытаться передать телеграмму не обращая внимание на ощибки и отсутствие подтверждения приема удаленной стороной.

Тоже самое будет в любом другом, если используется TTC.

 

Это где такие грабли?

У Атмэла. На сабжевом не проверял.

[DogPawlowa 0]

Приплыли...

Я поставил слово в кавычки именно потому, что хоть кто-то должен сказать "ок" в нужный момент, а все остальные с этим должны согласиться или сказать что в канале ошибка. Если ошибка, то все должны это сообщение выкинуть.

Почитайте стандарт, там все доходчиво сказано, даже с картинками и в переводе :)

Ничего не понял, кто приплыл. Надеюсь, что проблемы с русским языком больше, чем с техникой :)

 

Если передача потерянного пакета производилась один раз, значит подтверждение на него дал не основной получатель. Значит, не то что-то с этим основным получателем, которое вроде бы на шине, а на самом деле непонятно чем занимается. Может, чтение буферов редко происходит. Скорость передачи и загрузка шины должна соотноситься с быстродействием устройства. Можно сделать 1 Мб/с, а проверять буфер(ы) раз в 10 мс, и ффсе.

Ага, так похоже и происходит :

"Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET)."

Типичная реакция у Windows - 10 мс. Один передатчик тянет, а два уже нет.

"Приплыли"?

[Fledgling 0]

Под однократной передачей я имел ввиду вот что. У Infineon-a (прочитав в посте-вопросе про message objects я подумал, что CAN-контроллер тот-же) в CAN-контроллере можно задать однократный режим передачи, когда контроллер будет только один раз пытаться передать телеграмму не обращая внимание на ощибки и отсутствие подтверждения приема удаленной стороной.

Если выключить однократную передачу - будет ждать подтверждение (точнее пытаться передать "до посинения").

 

Если не трудно подскажите, в каком месте это выставлялось у Infineon-a?

В описании CAN-контроллера своего процессора вообще такого не видел.

[spf 0]

Ага, так похоже и происходит :

"Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET)."

Типичная реакция у Windows - 10 мс. Один передатчик тянет, а два уже нет.

"Приплыли"?

Нет, тут должно быть все достаточно чисто. Работает же USB и т.п. ;-)

В устройстве свои буфера должны быть достаточного размера.

Мы пользовали древний USB-CAN, все пахало на 1Мбит под виндами без потерь и напрягов.

[Andrew2000 0]

"Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET)."

Типичная реакция у Windows - 10 мс.

В дивайсе (IXXAT CAN II) стоит Freescale MCF5235, 150 MHz + SJA1000

а если это PCI-плата, то SAB XC16x

до виндов, думаю, далеко.

 

У Infineon-a было так:

Single Transmission Try

0 Single transmission try is disabled.

1 Single transmission try is enabled. The

corresponding TXRQ bit is reset immediately

after the transmission has started.

[Fledgling 0]

Ничего не понял, кто приплыл. Надеюсь, что проблемы с русским языком больше, чем с техникой :)

 

Если передача потерянного пакета производилась один раз, значит подтверждение на него дал не основной получатель. Значит, не то что-то с этим основным получателем, которое вроде бы на шине, а на самом деле непонятно чем занимается. Может, чтение буферов редко происходит. Скорость передачи и загрузка шины должна соотноситься с быстродействием устройства. Можно сделать 1 Мб/с, а проверять буфер(ы) раз в 10 мс, и ффсе.

Ага, так похоже и происходит :

"Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET)."

Типичная реакция у Windows - 10 мс. Один передатчик тянет, а два уже нет.

"Приплыли"?

Нет, пока "плаваем"))

немного поясню.

У устройства есть внутренняя шина (для обмена данными между МК). Третий МК является своеобразным "шлюзом" - он транслирует все принятые внутренней шине кадры через контроллер CAN №2 на внешнюю шину - где приемник - ПК.

 

Но ошибки ловятся именно на внутренней шине (счетчики процессоров анализируются в 800 Гц цикле МК3, процедурка просто смотрит сколько пропусков по счетчикам МК1 и МК2, инкрементирует какой то свой внутренний счетчик ошибок ErrorCounter и выдает его на внешнюю шину, где мы его видим на ПК - в данном случае скорость работы ПК на винде не критична ИМХО).

 

Кстати драйвер IXXAT сам накапливает данные в буфер, считывать их программно можно хоть с частотой 10Гц - выдаст все накопленные сообщения программе за милую душу:)

 

Получение данных через обьект №15 в процессоре производится через прерывание на обьекте CAN.

Опять таки замечу что при снижении потока до 1 кадра каждые 100 Гц с трех процессоров ошибки не исчезли, ошибки сводятся почти к нулю при оставлении на шине 1 передатчика (МК1) и одного приемника (МК3)

Изменено 30 сентября, 2008 пользователем Fledgling

[spf 0]

У устройства есть внутренняя шина (для обмена данными между МК). Третий МК является своеобразным "шлюзом" - он транслирует все принятые внутренней шине кадры через контроллер CAN №2 на внешнюю шину - где приемник - ПК.

Такие пояснения добавляют неопределенности :)

Вы бы нарисовали что же у вас там и как, что и хотите, что получается...

А так какие-то метания.

 

1) надо бы изучить матчасть поплотнее - протокол и используемый контроллер.

2) четко и ясно описать задачи каждого устройства и системы в целом.

 

PS:

В хорошем вопросе содержится большая доля ответа. Так уже начните задавать вопрос с чувством, с толком, с расстановкой. Когда будете все по местам расставлять, ответ должен сам и найтись. :)

[DogPawlowa 0]

Кстати драйвер IXXAT сам накапливает данные в буфер, считывать их программно можно хоть с частотой 10Гц - выдаст все накопленные сообщения программе за милую душу:)

Жаль :)

Тем не менее ничего не меняется. В шлюзе то не фрискэйл?

Мы тут ничего не выясним сейчас. Все можно проверить осциллографом - нужно передавать одинаковое сообщение, синхронизироваться от него и убедиться, что шлюз выдает подтверждение. Если да, то значит данные теряются внутри. А если нет... Тогда думать.

А так это гадания.

[Fledgling 0]

Такие пояснения добавляют неопределенности :)

Вы бы нарисовали что же у вас там и как, что и хотите, что получается...

А так какие-то метания.

 

1) надо бы изучить матчасть поплотнее - протокол и используемый контроллер.

2) четко и ясно описать задачи каждого устройства и системы в целом.

 

Задача устройства - регулирование исполнительного механизма в соответствии с показаниями датчиков.

Например, обьясню на одном из регулируемых параметров:

МК1 читает данные с датчика температуры, получает значение Т1 и выставляет его на шину CAN.

МК2 читает данные со второго датчика температуры, получает значение Т2, выставляет на шину.

 

Процессор МК3 получает по шине оба значения, расчитывает результирующее Трез = (Т1+Т2)/2 с частотой 100Гц.

Каждый кадр имеет так называемый "счетчик обновляемости".

в 100Гц-м цикле счетчик обновляемости каждого кадра уменьшается на 1, если кадр пришел - устанавливается в первоначальное значение. Для Т1 и Т2 счетчик равен 10. Если счетчик кадра = 0 (значит кадр "не приходил" 10 стогерцовых циклов подряд) - устройство генерирует отказ по контролю температуры.

Так в принципе и отловили баг - периодически генерировался данный отказ (редко достаточно).

Потом уже стали процерять по инкрементирующимся счетчикам.