Вот тут спецификация J1939 которую удалось найти и преобразовать в JSON файл. Этот файл используется для декодирования сообщений. При первом запуске на новом устройстве нужно подгрузить этот файл в браузер и он будет храниться в браузере. Всегда можно отредактировать файл в любом текстовом редакторе и загрузить в веб приложение - это позволит переименовывать параметры как угодно, и изменять карту параметров, если обнаружили в нем ошибку.
Вот тут также найденные описания ошибок - тоже файл с теми же свойствами.
Обзор устройства начну с конца, постепенно раскрывая детали:
Онлайн демо веб интерфейса с генерацией фейковых параметров.
Комплектующие:
Корпус
Кабель
Контроллер
Преобразователь напряжения
Приемопередатчик CAN
Схема:
Прошивка:
Проект
Программа для прошивки
Железо и backend:
Код тут
По схеме тут все просто - используются готовые компоненты. Задача понижающего преобразователя напряжения - получить 5v из бортовой сети двигателя (24-28v). На плате Devkit ESP32 имеется свой преобразователь и он из 5v делает 3.3v, что и используется непосредственно ESP32. На входе преобразователя я еще дополнительно припаял диод как элементарную защиту от переполюсовки, хотя по идее можно поставить диодный мост и тогда по поводу перепутать плюс и минус можно не заморачиваться. А переполюсовка тут актуальная тема т.к. у разных производителей на одном и том же разъеме плюсы и минусы на тех же пинах, но поменяны местами. CAN трансивер необходим для преобразования физического уровня CAN шины для работы с обычными цифровыми пинами микроконтроллера.
Для создания программы для микроконтроллера использовался VS Code с установленным официальным расширением от Espressif - Espressif IDF. Может быть используя Arduino платформу какие то вещи можно было бы сделать удобнее, но был интерес въехать и потрогать немного FreeRTOS как бы непосредственно. Немного непривычно поначалу, но если разобраться, то все хорошо. Могу сказать, что система сборки у Espressif норм.
Микроконтроллер при старте инициализирует SPIFFS хранилище (аналог файлового хранилища, где хранятся файлы веб приложения), поднимает точку доступа (SSID: J1939_AP пароль:12345678), файловый сервер, websocket сервер, инициализирует CAN драйвер, начинает слушать CAN шину и при получении сообщений рассылать их всем websocket клиентам подключенным к серверу. Кстати CAN драйвер в ESP32 называется TWAI , что , как я понял , связано с какими-то лицензионными заморочками.
Особенностью файлового сервера является то, что при запросе клиентом файла он пытается отдать этот файл , а если его нет, то пытается отдать заархивированный файл {имяфайла}.{расширение}.gz и только если нет ни того ни другого отвечает ошибкой. Что касается протокола J1939, то на микроконтроллере реализовано только чтение обычных сообщений , широковещательных сообщений переданных по транспортному протоколу (более 8 байт) и отправка простых (8 байт) сообщений в шину. По задумке устройство может отправлять в шину только сообщения об очистке сохраненных ошибок, но тот же самый механизм используется при отправке сообщений для управления желаемой скоростью вращения двигателя и желаемой передачи АКПП. Расшифровка же сообщений происходит в браузере клиента.
Фото:
Frontend (веб приложение):
Код тут
Для веб интерфейса использовал современные инструменты веб разработки последних ревизий.
Проект веб приложения имеет 3 сценария сборки:
build_preview - собирает проект для предпросмотра на локальном сервере (preview)
build_embedded - собирает проект непосредственно для микроконтроллера. Генерируются только архивированные файлы gz. Разделение на части не производится т.к. опытным путем установлено, что файловый сервер ESP32 быстрее отдает один файл побольше чем несколько разделенных файлов. Весь проект в архивированном виде имеет размер 498kB и отлично помещается в памяти ESP.
build_deploy - этот сценарий добавлен недавно и создает файлы для публикации приложения на github pages. Пример настройки альтернативного именования файлов, поскольку сборка по умолчанию (preview) генерирует файл с символом “_” в начале, что в результате порождает ошибку при скачивании файла браузером.
Помню в начале знакомства с веб разработкой у меня было непонимание - где конкретно находятся файлы веб приложения и как они исполняются. И если у кого-то возникает такой вопрос, то работает это все так: При обращении из браузера (клиента) к какой-либо странице, сервер отвечает файлом index.html. В этом файле есть список файлов веб приложения и браузер запрашивает эти файлы с сервера, разархивирует и далее действует по инструкциям из этих файлов. Таким образом файлы веб приложения изначально находятся на сервере, скачиваются и выполняются браузером.
На веб приложение ушло больше всего времени. Изначально я сделал все с использованием замечательной библиотеки element-plus, но почему-то выловил жесткую утечку памяти и месяц бился с этим явлением. Постепенно заменяя компоненты из element-plus самописными.
Общий алгоритм работы приложения такой- приложение получает массив байт от микроконтроллера, далее этот массив декодируется с помощью данных из JSON файла. (Как я искал и парсил доступную инфу по J1939 - тема для отдельной статьи.)
Поскольку вся спецификация протокола довольно объемна, то хранить ее на мк не выйдет , по крайней мере в стандартной комплектации ESP32 Devkit с 4 Mb флеш памяти. В связи с чем решено было хранить данные для декодирования параметров и передаваемых ошибок на стороне клиента в браузере. При первой загрузке веб приложения эти файлы создаются автоматически, но имеют немного данных для декодирования, можно изменить данные в этом файле в текстовом редакторе или загрузить по указанным в приложении ссылкам.
При загрузке файлов правильность их структуры проверяется с помощью отличного AJV по схеме файла. Данные хранятся в памяти браузера и при использовании из другого браузера или с другого устройства надо опять подгружать файлы.
Поиск по параметрам осуществляется с помощью FuseJS через интеграцию VueUse. Вообще библиотека VueUse должна быть дефолтной частью проекта на Vue3 поскольку содержит огромное количество очень полезных функций, которые намного облегчают код и работают напрямую с реактивными объектами Vue.
В приложении есть возможность строить графики изменения параметров. Добавление параметра на график осуществляется включением соответствующего переключателя в меню параметра. Графики строятся используя гениальный Echarts и в коде в частности есть пример переключения темы графика “на лету”.
И все это дело собирается в 498Kb! По моему не плохо. Собранные файлы помещаются в папку spiffs_images проекта для микроконтроллера и сохраняются в его памяти при прошивке. Из этой области памяти файловый сервер ESP32 отдает файлы по запросу браузера.
Среди вопросов по работе остался момент периодической “заморозке” вебсокет сообщений, которые были замечены из браузеров на линуксе и на андройде, причем периодичность их появления не зависит ни от чего. Из браузеров виндовса подобная проблема ни разу не проявила себя, что наталкивает на мысль о какой-то глубокой малозаметной ошибке в реализации протокола либо на стороне ESP либо на клиентской стороне.
Вообще в целом реализация проекта подарила интересный опыт и полезные наработки, что, думаю, может пригодиться в будущем (если оно будет)).
Фото в “полях”:
Сканер подключен к диагностическому разъему двигателя C-15 Caterpillar
Графики параметров с работающего двигателя
