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

1) Максимальная - 1 Мбит/сек
2) 4 слова - 8 байт
3) ? Что имеется в виду под драйвером? Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET).
4) Расстояния между процессорами на плате - меньше 10 см, расстояние от контроллера, осуществляющего передачу "вовне" (на ПК) - меньше 2 м.
5) на месте
6) нет, ошибки не контролируются в связи с тем что автор чайник и не знает как это делать)))



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


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


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


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

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




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

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

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

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

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



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

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


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

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

Если передача потерянного пакета производилась один раз, значит подтверждение на него дал не основной получатель. Значит, не то что-то с этим основным получателем, которое вроде бы на шине, а на самом деле непонятно чем занимается. Может, чтение буферов редко происходит. Скорость передачи и загрузка шины должна соотноситься с быстродействием устройства. Можно сделать 1 Мб/с, а проверять буфер(ы) раз в 10 мс, и ффсе.
Ага, так похоже и происходит :
"Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET)."
Типичная реакция у Windows - 10 мс. Один передатчик тянет, а два уже нет.
"Приплыли"?

Если не трудно подскажите, в каком месте это выставлялось у Infineon-a?
В описании CAN-контроллера своего процессора вообще такого не видел.

Нет, тут должно быть все достаточно чисто. Работает же USB и т.п. ;-)
В устройстве свои буфера должны быть достаточного размера.
Мы пользовали древний USB-CAN, все пахало на 1Мбит под виндами без потерь и напрягов.

В дивайсе (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.

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

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

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

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

Сообщение отредактировал Fledgling - Sep 30 2008, 16:45

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

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

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

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

Задача устройства - регулирование исполнительного механизма в соответствии с показаниями датчиков.
Например, обьясню на одном из регулируемых параметров:
МК1 читает данные с датчика температуры, получает значение Т1 и выставляет его на шину CAN.
МК2 читает данные со второго датчика температуры, получает значение Т2, выставляет на шину.

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