Привет! Хочу поделиться собственным опытом разработки электронного устройства.
Для начала расскажу немного предыстории, чтобы было понятно, зачем мне это вообще-то понадобилось.
Где все началось
Изначально мы занимались разработкой программного обеспечения для чип-тюнинга.Одна из основных задач которого – прочитать прошивку из ЭБУ (электронного блока управления двигателем) и записать ее обратно.
Понятно, что для этих целей нужно как-то соединить компьютер и блок управления с помощью переходника.
Когда раньше в подавляющем большинстве компьютеров использовался простейший способ приема и передачи данных, достаточно было использовать простой адаптер с транзисторами или специализированную микросхему.
Однако сегодня большинство автомобилей используют CAN-шину для «связи» своих компонентов с внешней средой.
Адаптер для CAN-шины на транзисторах не собрать, и обязательно нужен процессор, который будет всем управлять по конкретной программе.
Вот так и возникла первая проблема - как побороть CAN шину.
Чтобы не изобретать велосипед, был выбран готовый адаптер, работающий по стандарту J2534. Для тех, кто не в курсе, стандарт J2534 — это стандарт, описывающий аппаратное и программное обеспечение устройства, которое можно использовать для подключения к блоку управления через компьютер.
Его разработали американцы.
Основной причиной его разработки стало законодательное обеспечение возможности обновления прошивки БУ не специализированным дилерским сервисом, а кем угодно.
Собственно, если каждый может обновить прошивку на своем телефоне, то почему он не может сделать это на своем автомобиле.
Самый доступный импортный аналог стоит около 200 долларов.
Как выяснилось позже, два одинаковых устройства, соответствующие стандарту J2534, могут по-разному работать с одним и тем же программным обеспечением.
Поэтому изначально нам пришлось привязаться к конкретному производителю и его устройству.
Ээксперименты
Нужные нам в железе функции присутствовали в обычном диагностическом адаптере ELM327. Остается только написать драйвер J2534 (по сути, это DLL, служащая прослойкой между программой на компьютере и самим устройством).Я сначала связался с разработчиками ELM327, но они сказали, что не планируют писать такой драйвер, но готовы предоставить бесплатно прошитые чипы для ELM327. Ранее я написал драйвер, который поддерживал только протокол ISO 11898 (raw CAN).
Однако здесь меня разочаровало.
При скорости CAN 1 Мбит/с ELM327 просто не успевает принять такое большое количество пакетов, постоянно выдавая ошибку при переполнении внутреннего буфера сообщений.
Кроме того, протокол обмена между компьютером и ELM327 организован в виде обмена сообщениями ASCII (чтобы было удобно работать в терминале).
Соответственно, вместо передачи одного байта данных передаются три (два байта — отображение символов плюс разделительный пробел).
Оказалось, что большая часть USB-трафика была потрачена впустую.
А учитывая, что максимальная скорость работы с ELM327 по USB составляет 3 Мбит/с, то принять 1 Мбит/с по CAN-шине при такой организации обмена не представляется возможным.
Я никогда не любил ни от кого зависеть, поэтому мысль о создании собственного адаптера J2534 меня не покидала.
Первые шаги
Здесь должен сказать, что до разработки своего адаптера J2534 у меня не было никакого опыта разработки с использованием процессора, но опыт программирования у меня был большой.Первоначально были попытки найти исполнителей, которые могли бы создать такое устройство «под ключ», но они не увенчались успехом.
Поэтому было принято решение начать заниматься этим самостоятельно.
Прежде всего нужно было определиться с процессором.
Выбор пал на процессор ARM от ST — STM32F105. Критериями выбора процессора были его распространенность, цена и наличие сторонних специалистов, которые могли бы помочь решить проблемы в кратчайшие сроки.
В качестве макетной платы была куплена макетная плата от Olimex. С его помощью была успешно проведена «лабораторная работа» по освоению процессора: мигание светодиодов, звуковые сигналы, отображение на ЖК-экране, работа с UART. 
Мне очень понравилась IDE от CooCox. Были еще испытания с Кейлом, но, как говорится, «не получилось».
Рабочий процесс
Как я писал выше, были попытки найти исполнителей, которые сделают всё «под ключ», но они не увенчались успехом.Растягивать разработку на долгое время и во всем разбираться самому тоже не хотелось.
Поэтому было решено разбить задачу на самостоятельные части, а часть из них поручить разработчикам, имеющим опыт в подобных вещах.
Такого разработчика нашли с помощью биржи фрилансеров.
Собственно, от фрилансера требовалось создать программу, управляющую процессором.
Остальную работу, связанную с разработкой конечной схемы, печатной платы и заказа на производство, уже было кому поручить.
Для тех, кто пойдет по моему пути, скажу, что фрилансер во всем этом процессе — не панацея, и после этого вам все равно придется оптимизировать код, чтобы этот код не только работал, но был качественным и расширяемым.
Подрядчик сразу предложил мне использовать в этом проекте RTOS вместо стандартной библиотеки из STM32. Честно говоря, я был озадачен.
Я никогда не имел дела с RTOS, и мой партнер был категорически против использования RTOS для этого проекта.
В конце концов я наконец согласился использовать RTOS и потом не пожалел.
Поначалу особых проблем не было и были успешно изготовлены отдельные «строительные блоки», отвечающие за обмен между адаптером и компьютером по USB, работу с UART, разработку собственного загрузчика, с помощью которого можно обновить прошивку устройства.
через USB. Проблемы начались с CAN. Стандартные драйвера для работы с CAN ChibiOS (я выбрал именно эту RTOS) используют аппаратные слоты процессора для хранения полученных сообщений.
Их всего три, поэтому если вы не успеете выбрать оттуда сообщения, они просто потеряются.
Так и произошло.
Пока сообщения шли «медленно», их благополучно принимали, но как только количество CAN-сообщений в секунду перевалило за тысячи, начались проблемы.
«Разогнать» или оптимизировать прием с помощью штатного драйвера не удалось, поэтому было принято решение полностью его переписать.
Те.
сделать программный буфер сообщений CAN вместо аппаратного.
Размер такого программного буфера составил 256 CAN-сообщений и этого оказалось вполне достаточно.
Пришлось самому придумывать, как написать этот драйвер, потому что.
у исполнителя не было технической возможности генерировать лавинообразный поток из CAN-пакетов, а искать нового исполнителя и возвращать его обратно не было желания до скорости.
Но все, что не сделано, сделано к лучшему, и благодаря самостоятельной разработке драйвера для ChibiOS мне удалось погрузиться в его изучение.
После этого ряд частей проекта было решено сделать самостоятельно, без привлечения третьих лиц.
Часть времени была потрачена на изучение протоколов ISO 15765-4 (CAN), ISO 9141-2. Надо сказать, что настоящие БУ помогали быстро с ними расправиться – достаточно было «послушать» обмен БУ.
Первый образец
Первый образец устройства существовал в виде макетной платы с STM32F105 и макетной платы с интерфейсами L9637D и TJA1050. Вот как выглядел первый лабораторный образец.
И вот так с другой стороны: 
В лабораторных условиях с использованием указанных тестовых программ все работало прекрасно.
Однако прежде чем создавать плату для серийного производства, было решено изготовить тестовые некоммерческие образцы, которые будут раздаваться людям, готовым принять участие в тестировании.
Изначально хотели делать платы с использованием ЛУТ, но позже заказали с завода 10 плат. Такое тестирование, конечно, принесло свои плоды.
В самой прошивке устройства обнаружено не так много ошибок, но нам пришлось адаптировать устройство к программам различных производителей, использующих устройство J2534 в качестве адаптера.
Заключительные этапы
По результатам испытаний уже принято решение о создании платы, которая пойдет в серию.Окончательную принципиальную схему устройства сделал мой напарник, разводку платы доверили третьей стороне.
Изначально на конструкции устройства не экономили — было сделано все, что можно было защитить и сделать максимально отказоустойчивым.
Корпус устройства можно выделить в отдельную тему.
Это тема для отдельной темы.
Поэтому скажу, что на данный момент я остановился на акриловом корпусе заводского изготовления, и мы планируем на днях оснастить этим корпусом наши устройства.
Изначально мы поставляли устройство в закрытом прозрачном кембрике, а сама плата была покрыта лаком.
Полученные результаты
Приведу небольшую хронологию, чтобы вы поняли, чего это стоило.
- Март 2013 г.
— первое знакомство с STM32.
- Июнь 2013 г.
– начало работы.
- Октябрь 2013 г.
– первый тестовый образец.
- Январь 2014 г.
– официальный старт продаж.
Что использовалось при создании проекта:
- ОСРВ ЧибиОС
- Возвышенный текст2
- GCC (Источник кода)
- CAN Хакер
- Логические анализаторы Saleae
- USB-UART преобразователь
- ISO 11898 (raw CAN) до 1 Мбит/с
- ISO 15765-4 (Канада)
- ISO 14230-4 (Протокол ключевых слов 2000)
- ИСО 9141-2
В связи с тем, что ряд функций, описанных в стандарте J2534, не используются в программах, с которыми планировалось использовать устройство, было решено их исключить.
В частности, он поддерживает протоколы J1850 (PWM/VPW).
Возможно, когда будет время, добавлю эти протоколы в устройство, чтобы получить 100% покрытие протокола J2534. Теги: #RTOS #arm #stm32 #микроэлектроника #can #OBD2 #Программирование микроконтроллера
-
Есть Ли Доступ В Интернет В Самолетах?
19 Oct, 24 -
Сканирование Документов По Сети
19 Oct, 24 -
Невидимая Мышь
19 Oct, 24 -
Почему Мы Перешли На Marionette.js
19 Oct, 24
