В блоге:

2019-01-09

ELM327: бредовый режим Flow Control Mode 2

Забавную багофичу ELM327 обнаружил, экспериментируя с SZ Viewer.

Если говорить упрощенно, то CAN-шина рассчитана на передачу коротких пакетов с полезным содержимым до 8 байтов включительно. Если нужно передать более длинные данные (одним куском), то для OBD2 предлагается использовать ISO 15765-2. Это представление данных в нескольких фреймах. Поскольку получатель должен адекватно успеть принять все фреймы ответа, то есть механизм управления потоком фреймов (Flow Control).

Адаптер ELM327 предназначен в том числе для работы с CAN-шиной, потому там есть какая-никакая поддержка ISO 15765. Для более тонкой работы есть возможность управления Flow Control переключением режимов (команда ATFCSMx - поддерживается с v1.1).

Простой пример чтения VIN-номера через CAN-шину стандартным OBD2 запросом 09 02 (не все машины поддерживают). Для отправки запросов использую ELM327Chat, так просто удобнее.




В данном случае используется режим Flow Control Mode 0 (по умолчанию). ATH1 включает показ заголовков. На этом автомобиле (не Suzuki) 09 02 отрабатывает адекватно - приходит ответ из трех фреймов, в которых содержится VIN (размыл его из соображений приватности). Фреймы приходят с идентификатором 7E8 - это стандартный ответ от блока управления двигателем.

Но кроме режима 0 есть еще режимы 1 и 2. Их отличия показаны в таблице из документации к ELM327:



По этой таблице ожидаешь, что в режиме 2 можно предоставить только данные фрейма Flow Control, а ELM327 остальное возьмет на себя.

Проверяю:




ATFCSD выставляет данные, ATFCSM2 переключает ELM327 во второй режим Flow Control. Только это не работает! Ответ на 09 02 состоит только из одного фрейма, остальные два не приходят вообще.

А теперь полностью ручное управление (режим 1):




ATFCSH ставит идентификатор (7E0 в данном случае для запроса к блоку управления двигателем), ATFCSD уже установлен в предыдущем примере, режим переключается в ATFCSM1. И в этот раз все работает хорошо, как и в примере с режимом 0.

Причина поведения режима 2 раскрывается простым мониторингом CAN-шины. В этом режиме ELM327 отправляет фрейм Flow Control не с идентификатором 7E0 (как в режимах 0 и 1), а с идентификатором 7E8. Но это же бред! Зачем ставить идентификатор ответа, а не запроса?

Сперва я подумал, что это ошибка китайской версии ELM327 v1.5, но проверка на реальном v2.2 показала, что там поведение полностью идентично. Более того, такое поведение описано в документации:



Т.е. идентификатор для Flow Control фрейма выставляет такой, что указан в ответе First Frame. Крайне странное решение. Возможно есть какой-то параллельный мир, где это оправдано, но для нашего реального мира диагностики в этом нет никакой пользы. И ведь режим 0 так себя не ведет!


Резюме: если хочется ручного управления, то не используйте ATFCSM2, лучше принудительно выставлять идентификатор и переходить на ATFCSM1. Ну или использовать обычное поведение в режиме ATFCSM0 - он сравнительно адекватно работает.

0 comments:

Post a Comment

Blog Archive