[kuken 0]

Стоит следующая задача: посылать определенный пакет (протокол j1939) через определенные промежутки времени. На другом конце линии находиться устройство в режиме listen only.

Если слать пакеты из обычного режима, can-контроллер вываливается в bus-off и нечего не передает. Если перевести контроллер в режим self-test и слать из него, то в пакете отсутствует crc, ack и прочая ерунда, и пакет не распознается.

Как все-таки выслать эти пакеты?

[HARMHARM 0]

Была подобная проблема. Без подтверждения пакеты, как ошибочные, не распознаются listen-only устройством. Для тестирования Listen-only отключали. Вариант решения - еще один простейший CAN-контроллер, выдающий подтверждение.

[KRS 0]

Была подобная проблема. Без подтверждения пакеты, как ошибочные, не распознаются listen-only устройством.

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

 

[sysel 0]

Можно попробовать TX PHY подключить к MOSI (SSP) и формировать сообщения шины CAN программно (как поток бит).

Кривовато, потребует изучение кодирования сообщений, но реально.

[Andy_Mozzhevilov 0]

Можно попробовать TX PHY подключить к MOSI (SSP) и формировать сообщения шины CAN программно (как поток бит).

Кривовато, потребует изучение кодирования сообщений, но реально.

Чушь полная. Если только на низких скоростях (и то не при помощи SSP), и то неясно, зачем такое извращение.

 

PS: Автору топика. Если у вас именно в bus-off вываливается, то ищите где. Подключенный в listen only узел не должен никак влиять на шину. То есть можете вообще нагрузить кабель терминаторами, и передавать пакеты, эффект с точки зрения передатчика должен быть таким же, как и при наличии на другом конце узла с listen only.

При всем этом, как вам выше сказали, в bus off передающий контроллер не будет падать, только в error passive.

Сам Listen only узел CAN будет принимать сообщения только в том случае, если на шине существует нормальный обмен, т.е. CAN пакеты подтверждаются принимающими узлами, находящимися в активном режиме.

 

 

ЗЫ: Почему прием нужно осуществлять именно в listen only? Какой в этом глубокий смысл? Почему нельзя перевести принимающий узел в активный режим?

[kuken 0]

Извиняюсь, контроллер конечно в режиме error passive.

Сегодня проверил: с другим аналогичным девайсом общается без проблем и без ошибок.

На принимающей стороне pic2480 в виде расходомера fms.

 

ЗЫ: Почему прием нужно осуществлять именно в listen only? Какой в этом глубокий смысл? Почему нельзя перевести принимающий узел в активный режим?

Расходомеры делались давно и много, тут ничего не поменяешь.

 

Вся штука в том, что тот же pic2480 шлет пакеты без подтверждения без проблем, а lpc при отсутствии подтверждения замолкает на передаче первого же пакета.

[KRS 0]

Вся штука в том, что тот же pic2480 шлет пакеты без подтверждения без проблем

Это как это? полное нарушение стандарта!

 

, а lpc при отсутствии подтверждения замолкает на передаче первого же пакета.

он не замолкает, а продолжает отправлять пакет, пока не дождется подтверждения!

в любом случае вы можете подать команду Abort Transmission (можно например еще смотреть код ошибки в CANxICR регистре)

 

 

[sysel 0]

Чушь полная. Если только на низких скоростях (и то не при помощи SSP), и то неясно, зачем такое извращение.

Делал софтовый SPDIF трансмиттер с помощью этого SSP, программно формируя поток бит. Так что насчет скорости - это Вы зря.

А извращение - передать в шину сообщение с уже выставленным ACK-ом.

[kuken 0]

он не замолкает, а продолжает отправлять пакет, пока не дождется подтверждения!

 

Я не создавал бы топик, если бы он слал

 

А pic походу и шлет пока не получит подтверждение.

Изменено 23 августа, 2011 пользователем kuken

[KRS 0]

А pic походу и шлет пока не получит подтверждение.

Вы уж определитесь! А то

 

can-контроллер вываливается в bus-off и нечего не передает.

 

 

Вся штука в том, что тот же pic2480 шлет пакеты без подтверждения без проблем

пакет считается отосланным если статус есть TX OK

 

self test mode - выключен?

TX ABORT команда не подается?

[Andy_Mozzhevilov 0]

Делал софтовый SPDIF трансмиттер с помощью этого SSP, программно формируя поток бит. Так что насчет скорости - это Вы зря.

А извращение - передать в шину сообщение с уже выставленным ACK-ом.

Для чего? Оно же не сможет участвовать в арбитраже и поэтому не будет соответствовать стандарту CAN. То есть потенциально оно может вклиниться в шину и разрушить все, что там происходит в данный момент.

 

Я не создавал бы топик, если бы он слал

 

А pic походу и шлет пока не получит подтверждение.

 

Сдается мне, что вы сильно "плаваете" в мат.части, оттого вопросы ваши непонятны, терминология сумбурна и не соответствует стандартной. Отчего помочь вам в решении вашей проблемы сильно затруднительно.

[sysel 0]

Для чего? Оно же не сможет участвовать в арбитраже и поэтому не будет соответствовать стандарту CAN. То есть потенциально оно может вклиниться в шину и разрушить все, что там происходит в данный момент.

 

Так проблема-то как раз в том, что в шине нет никого, кто бы мог выставить ACK.

Один вещает, все остальные слушают. Конфликтовать не с кем.

[Andy_Mozzhevilov 0]

Так проблема-то как раз в том, что в шине нет никого, кто бы мог выставить ACK.

Один вещает, все остальные слушают. Конфликтовать не с кем.

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