Ошибки при обмене по протоколу 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]

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

А частота у генераторов достаточно одинаковая ?

Частота по идее абсолютно одинаковая

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

МК3 регистрирует пропуски по счетчикам.

И снова не договариваете
Сколько пропусков на каком количестве посылок, стабильно ли это возникает?
Как регистрирует, N1 != N2 или анализируется линейность изменения каждого счётчика по-отдельности?

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

Может оказаться что вся бяда именно в том, что все синхронно только "по идее", а на деле все плывет.

[Fledgling]

И снова не договариваете
Сколько пропусков на каком количестве посылок, стабильно ли это возникает?
Как регистрирует, N1 != N2 или анализируется линейность изменения каждого счётчика по-отдельности?

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

Может оказаться что вся бяда именно в том, что все синхронно только "по идее", а на деле все плывет.

Третий процессор проверяет так:

if (cnt1 - cnt1_old > 1) {errorMK1++;}
if (cnt2 - cnt2_old > 1) {errorMK2++;}

cnt1_old = cnt1;
cnt2_old = cnt2;

cnt1 и cnt2 - счетчики, принимаемые от МК1 и МК2.
И все это проверяется в 800 Гц (для верности воткнули на макс. частоту) цикле (в 8 раз чаще чем выдается).
Если новое значение счетчика еще не пришло - errorMK не изменится.

errorMK1 и errorMK2 даже приблизительно не равны друг другу. на значение счетчика 10000 (т.е. выдалось от 0 до 10000) errorMK1 может насчитать 10, а errorMK2 - 500. И наоборот.
Тенденция - счетчики растут лавинообразно - то есть могут не изменятся достаточно долго, потом резко растут, и снова "затыкаются".

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

[spf]

Третий процессор проверяет так:

if (cnt1 - cnt1_old > 1) {errorMK1++;}
if (cnt2 - cnt2_old > 1) {errorMK2++;}

cnt1_old = cnt1;
cnt2_old = cnt2;

cnt1 и cnt2 - счетчики, принимаемые от МК1 и МК2.

Хм, это странно, что счетчики изменяются нелинейно.

Надо проверять успешно ли завершается отправка из МК1 и МК2.

Но скорее всего ошибка в другом:

И все это проверяется в 800 Гц (для верности воткнули на макс. частоту) цикле (в 8 раз чаще чем выдается).
Если новое значение счетчика еще не пришло - errorMK не изменится.

Если ваш контроллер не использует режим FIFO то следует работать по прерыванию.
Все сообщения принимается в один приемный слот?
Фильтры каким-то образом используются?

Если вы работаете через один приемный слот, то данные у вас будут теряться.
Теряться они будут когда два контроллера синхронно выдадут ответы друг за другом. Придет один пакет, придет второй, второй затрет первый, считать получиться только последний.

Нельзя полингом работать при таких скоростях, даже если вы сделаете 1600 или 3200 Гц опроса.

[Dog Pawlowa]

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

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

[Fledgling]

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

На приеме только один слот, который буферизированный (обьект №15).
Чтение из него производится по прерыванию (у обоих контроллеров есть по прерыванию в таблице векторов).

Есть мнение что когда мы производим чтение из обьекта, приходит второй кадр - а обьект №15 в это время "заблокирован".
Может ли увеличение числа обьектов-приемников помочь или не стоит даже пытаться?
Или нужно менять весь алгоритм в целом и вводить синхронизацию?

Кстати пакеты все равно будут висеть на шине последовательно, даже при максимальной скорости передача одного пакета (CAN кадра) будет около 100 мкс, процессор вроде бы должен успевать обработать и считать в свой буфер содержимое кан-обьекта до поступления следующего кадра.

Сообщение отредактировал Fledgling - Oct 2 2008, 04:32

[Dog Pawlowa]

Чтение из него производится по прерыванию (у обоих контроллеров есть по прерыванию в таблице векторов).

Какому прерыванию? Сколько времени занимает обработка?

Или нужно менять весь алгоритм в целом и вводить синхронизацию?

Вы же молчите как партизан - не говорите ни сколько буферов в приемнике задействовано, ни про фильтрацию. Синхронизация абсолютно не нужна.
Получается, мы должны рассказывать, что у Вас происходит.
Буфер у Вас один. Из-за несинхронности наступает момент, когда кадры идут один за другим. Первый принимается, а второй нет, потому как буфер занят. А на второй кадр подтверждение дает то устройство, что передало первый кадр, поэтому второе устройство считает, что оно успешно приняло. А шлюз и не подозревает, что был еще кадр.
Даже в старом MCP2515 три буфера приема. И обрабатываются они примерно так:

Код

//запись принятого фрейма(ов) в циклический буфер
void CanSpyReceiveService(void)
{    if (msg_head>=CAN_ARR_SIZE)  msg_head=0;
    if (!can_readMessage(&can_msg_array[msg_head])) return;
    else  msg_head++;
}
// чтение фрейма
uchar can_readMessage(CanMessage *msg)
{    uchar stat, res;
    
    stat = mcp2515_readStatus();
    if ( stat & MCP_STAT_RX0IF )
  {        // Msg in Buffer 0
        mcp2515_read_canMsg( _MCP_RXBUF_0, msg);
        mcp2515_modifyRegister(MCP_CANINTF, MCP_RX0IF, 0);
        res = 1;  //CAN_OK;
    }
    else if ( stat & MCP_STAT_RX1IF )
  {    // Msg in Buffer 1
        mcp2515_read_canMsg( _MCP_RXBUF_1, msg);
        mcp2515_modifyRegister(MCP_CANINTF, MCP_RX1IF, 0);
        res = 1;  //CAN_OK;
    }
    else
  {    res = 0;//CAN_NOMSG;
    }    
    return res;
}

Успехов

[Fledgling]

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

Как такое возможно? Кадр передается по шине со скоростью 1МБит/сек порядка 100 мкс (примерно), а ассемблерная процедура приема успевает считать гораздо быстрее (просто посчитали количество инструкций, посмотрели сколько времени выолняется каждая, например MOV выполняется за 2 такта - 50 наносекунд). Значит до прихода следующего кадра уже точно слот №15 (приемник) освободится? или я ошибаюсь?

Сообщение отредактировал Fledgling - Oct 2 2008, 11:19