Стоит следующая задача: посылать определенный пакет (протокол j1939) через определенные промежутки времени. На другом конце линии находиться устройство в режиме listen only.
Если слать пакеты из обычного режима, can-контроллер вываливается в bus-off и нечего не передает. Если перевести контроллер в режим self-test и слать из него, то в пакете отсутствует crc, ack и прочая ерунда, и пакет не распознается.
Как все-таки выслать эти пакеты?

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

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

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

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

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


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

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


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

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

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


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

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

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

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

Сообщение отредактировал kuken - Aug 23 2011, 17:32

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





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

self test mode - выключен?
TX ABORT команда не подается?

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



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

Так проблема-то как раз в том, что в шине нет никого, кто бы мог выставить ACK.
Один вещает, все остальные слушают. Конфликтовать не с кем.

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