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

[Fledgling]

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

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

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

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

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

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

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

[Vokchap]

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

[Fledgling]

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

Практически не проверялось.
При срабатывании в основном канале функции (моей) SendFrame кадр ставится в очередь (стек FIFO).
Очередь орбрабатывается при каждом вызове SendFrame, процедура обработки циклически проверяет CAN обьекты 0-7, являются ли они свободными, если да - кадр из очереди ставится на передачу в этот обьект.
Теоретически вероятна ситуация когда в очереди всегда 1 кадр (при малой нагрузке) и для передачи используется только обьект 0. В данном случае он просто справляется со всем потоком.
Однако даже в таком случае упомянутые в первом сообщении ошибки остаются.

P.S.: Нагрузка на контроллер CAN может менятся в процессе разработки ПО устройства, поэтому количество CAN обьектов-передатчиков возможно взято "с запасом". Чтобы люди, занимающиеся разработкой функциональных алгоритмов, не заморачивали себя вопросами обмена по CAN.

[Vokchap]

Очередь орбрабатывается при каждом вызове SendFrame, процедура обработки циклически проверяет CAN обьекты 0-7, являются ли они свободными, если да - кадр из очереди ставится на передачу в этот обьект.

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

[Andrew2000]

...а флаг занятости передатчика (либо канала) будет выставлен позднее, ...

Здесь говорилось про "проверяет CAN обьекты 0-7" - до передатчика еще далеко, не то.

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

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

[spf]

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

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

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

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

[Dog Pawlowa]

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

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

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

[Fledgling]

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

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

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

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

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

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

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

[Dog Pawlowa]

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

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

[Fledgling]

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

Данные теряются именно внутри
Отказы считают сами процессора, через шлюз выдают при тесте ТОЛЬКО счетчик ошибок (то есть сколько сам процессор насчитал пропусков). при передаче данных через шлюз эффект ошибок "удваивается" - так как в итоге две шины. Но на ошибки на шлюзе плевать - критичными являются ошибки на внутренней шине

Вы меня не поняли, я прошу отделить "мух от котлет". Вы же продолжаете все сваливать в кучу.
У меня подозрения что трудности не в CAN, а в общих алгоритмах.
Отделите CAN, у него простая функция - передать то, что ему положили в регистры.(ему же все равно что в него положили, температуру или давление, не про это речь)
Обязательно надо выполнять проверки всевозможных ошибок и регистров состояний.
Диагностику CAN надо отделить от диагностики остальной программы. Иначе ошибку можно искать без конца, потому что сложно выяснить что же все таки работает так, как должно. Надо постепенно отсекать те вещи из рассмотрения, которые полностью проверены и в которых вы полностью уверены.

Прошу прощения. Попробую конкретизировать на CAN'e.
Мы пришли к выводу, что ошибка при передаче через CAN (неизвестно в каком месте, при передаче, при приеме или ошибка на шине) следующим образом - выключили все остальные функции процессоров, оставив одну - передавать с частотой 100Гц инкрементирующийся счетчик с МК1 и МК2 и принимать их в МК3.
МК3 регистрирует пропуски по счетчикам.

Проверили алгоритм приема и передачи, логически они верны (в своей программе конечно можно искать ошибки год и не найти явную).
Теперь теряемся в догадках. Что это - не успевает выдать передатчик или приемник (на 1 раз за 100Гц можно успеть я думаю), коллизии на шине вроде бы исключены. На этом и завязли - какие еще причины могут быть? Конечно, просить на форуме "в каком месте в коде исправить" было бы глупо, поэтому здесь я хочу найти только направления, по которым нужно дальше двигаться в поисках причины