Ошибки при обмене по протоколу CAN 2.0B в многопроцессорной системе Опции

[Fledgling]

Здравствуйте!
На этом форуме я новичок, поэтому прошу прощения, если разместил вопрос не в том топике.

Ситуация следующая - есть многопроцессорная система (на базе процессоров семейства ST10), обмен данными между ними ведется по протоколу CAN 2.0B.

Каждый процессор выдает через КАН информаци, необходимую для расчетов другому. Выдача настроена на частоту 100Гц (выставление данных на шину КАН производится по прерыванию от таймера).

Другие процессора сравнивают принятые значения с измеренными ими самими и производят вычисления.

Проблема в том, что наблюдается потеря кадров при выдаче по шине при работе нескольких микропроцессоров одновременно. Второй процессор ведет счетчик обновления данных от первого (к примеру) и наблюдает потери (для теста МК1 выдает инкрементирующийся каждые 100Гц счетчик циклов, второй обрабатывает его прием с частотой 800Гц - второй процессор наблюдает в итоге "разрывы" по пришедшему счетчику - приходят значения 1000, 1001, 1002, 1003, 1005, 1006 - пропущено 1004).

Если включен только один передатчик(передача вдется только с одного из МК - потерь фактически не наблюдается). Если на шину выдает два передатчика - идут потери.

Обьясните пожалуйста чайнику, вследствие чего могут возникать потери при приеме\передаче по CAN 2.0B?

[Fledgling]

UP!

[spf]

UP!

можно долго апать, но это дело не сдвинет с места.
Ваш вариант описания ситуации мало что говорит.
По всей видимости дело в программе или в протоколе, который вы пытаетесь огранизовать.
Каким образом распределены ID CAN-сообщений по устройствам?

[Fledgling]

можно долго апать, но это дело не сдвинет с места.
Ваш вариант описания ситуации мало что говорит.
По всей видимости дело в программе или в протоколе, который вы пытаетесь огранизовать.
Каким образом распределены ID CAN-сообщений по устройствам?

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

Описывать весь алгоритм слишком долго, возможно кто либо еще сталкивался с ошибками в CAN'e иил есть причины для наиболее часто встречаемых багов (в этой теме я новичок - но тема то как раз для новичков).

Используется расширенный формат кадров (29 бит). В ОЗУ каждого процесора содержатся одинаковые таблицы с описанием кадров (номер кадра, что заполняется в поля данных кадра и прочее).
11 бит идентификатора определяют номер строки в этой таблице (определяют уникальность идентификатора кадра), распределение по процессорам ведется по этому номеру - т.е. МК1 выдает кадры например от 0 до 50, МК2 - от 51 до 100 и тп.
Остальные биты могут быть не уникальными, но в целом ситуация, когда 2 процессора пытаются выдать кадр с одним идентификаторам невозможна (проверял, хотя учитывая, что я чайник может быть что то прозевал)

Процедуры чтения/записи написаны по алгоритму, указанному в документации на процессор (блок схема), так что логически в этом ошибки быть не должно.
Из 15 обьектов CAN контроллера CAN процессора обьект №15 используется для приема (он буферизированный), обьекты 0-7 - для передачи.

Процессоры могут стартовать асинхронно, выдачу кадров осуществляют (всех, которые предназначены к выдаче с этого МК) с частотой 100 Гц. Тесты показали, что контроллер успевает выставить все данные на шину до наступления следующего цикла.

Перегрузки на шине тоже не наблюдается, сокращали поток выдачи до 1 кадра с частотой 100Гц - количество пропусков снизилось, но осталось на высоком и неприемлимом уровне.

С удовольствием отвечу на любые интересующие вопросы по алгоритму и специфике обмена, но к сожалению описать его весь не вижу возможности.

Сообщение отредактировал Fledgling - Sep 29 2008, 18:27

[spf]

Перегрузки на шине тоже не наблюдается, сокращали поток выдачи до 1 кадра с частотой 100Гц - количество пропусков снизилось, но осталось на высоком и неприемлимом уровне.

Перегрузка легко считается.
Какая скорость используется?
Сколько байт данных в сообщении?
Какие драйвера применены?
Какие расстояния?
Терминаторы на месте?
Контролируете ошибки в контроллере CAN?

[Fledgling]

Перегрузка легко считается.
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]

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

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

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

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