ST
На осцилографе выглядит вот так, до и после выключения NART на анализаторе
Size: a a a
2021 September 21
2021 September 22
TK
Нарт глючная хрень, тоже ловил с ней какие то баги
TK
Но тут на скрине осцилл просто не может засинхрониться, попробуй усложнить условие синхронизации
ST
Усложнить? У меня триггер по спаду на can-low стоит.
TK
Резюк 120 ом есть?
ST
Да, на плате стоит. На анализаторе подключаемый, одинаково себя ведёт и с ним и без него.
TK
Да, усложнить, например добавить условие захвата если ширина паузы больше чем определённое число
КЯ
Подтверждение приема происходит внутри bxCan внутри stm32
ST
А как оно происходит? Если скажем на шине все устройства в silent режиме или в sleep?
КЯ
то шлется бесконечно, пока кто-то не подтвердит получение сообщения
КЯ
по-моему, можно настроить чтобы передатчик STM32 слал однократно, без ожидания подтверждения. Но это плохой путь
ST
Это как раз опция NART (no automatic retransmission) и про нее в RM написано, что должно быть отключено.
TK
Это отход от стандарта, да
ST
У меня на f7 это отключено, т.е. он будет слать до победного. При этом перепосылок нет, на f1 (анализатор) принимается корректно. А вот от f1 к f7 идут перепосылки постоянные. Я в прерывании на f7 вижу один и тот же пакет бесконечно.
КЯ
может вы прерывание обрабатываете неправильно, подтверждение осциллографом есть непрерывной передачи?
TK
Ну знач ф7 не дает ответ в отведённое время
TK
Чем то занят нехорошим
ST
Думаю что правильно. Если на f1 включить nart, т.е. отправил 1 раз и забыл, то все работает. Там выше картинка есть, но видимо некорректная, мне уже объяснили.
ST
Он вообще 98% времени в idle :)