Разработка коммерческого электронного устройства с нуля

Приветствую!

Хочу поделиться собственным опытом разработки электронного устройства. Сначала расскажу небольшую предисторию, чтобы было понятно, зачем это собственно нужно было мне.

С чего все начиналось

Изначально мы занимались разработкой программного обеспечения для чип-тюнинга. Одна из основных задач которого — считать прошивку из ЭБУ (электронный блок управления двигателем) и записать ее обратно. Понятное дело, что для этих целей нужно каким-то образом связать компьютер и ЭБУ при помощи адаптера. Когда раньше подавляющее количество ЭБУ использовало простейший способ приема-передачи данных, достаточно было использовать простейший адаптер на транзисторах или специализированной микросхеме. Однако на сегодняшний день большинство автомобилей для «общения» своих компонентов со внешней средой используют 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. С ее помощью успешно были выполнены «лабораторные работы» для освоения процессора: мигание светодиодом, пищание звуком, отображение на LCD экране, работа с UART.

Очень понравилась IDE от CooCox. Были также пробы и с Keil, но, как говорится — «не пошло».

Рабочий процесс

Как я уже писал выше, были попытки найти исполнителей, которые сделают все «под ключ», но они не увенчались успехом. Растягивать разработку на длительное время и разбираться во всем самому также не хотелось. Поэтому было принято решение разбить задачу на независимые части, и некоторые из них поручить разработчикам, у которых был опыт в подобных вещах. Такой разработчик был найден при помощи фриланс-биржи. Собственно от фрилансера требовалось создать программу, которая управляет процессором. Остальные работы, связанные с разработкой окончательной схемы, печатной платы и заказом на производстве уже было кому поручить. Для тех, кто пойдет моим путем скажу, что фрилансер во всем этом процессе — это не панацея и после него еще придется заниматься оптимизацией кода, для того, чтобы этот код не просто работал, а был качественным и расширяемым.

Исполнитель сразу предложил мне использовать в этом проекте 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 устройство.

Заключительные этапы

По результатам тестирования было уже принято решение в создании платы, которая пойдет в серию. Окончательную схему устройства сделал мой компаньон, разводку плату поручили стороннему исполнителю. На схеме устройства изначально не экономили — все что можно было защитить и сделать максимально отказоустойчивым — делали.

Отдельной темой можно выделить корпус устройства. Это тема отдельного топика. Поэтому скажу, что в данный момент я остановился на заводском изготовлении корпуса из акрила, и этим корпусом мы на днях планируем комплектовать наши устройства.

Первоначально мы поставляли устройство в обтянутом прозрачном кембрике, а саму плату покрывали лаком.

Итоги

Приведу немного хронологии, для того, чтобы можно было понять что это стоило.

1. март 2013 — первое знакомство с STM32
2. июнь 2013 — старт работ
3. октябрь 2013 — первый тестовый образец
4. январь 2014 — официальный запуск продаж

Следует также сказать, что это не единственный проект, который делался в эти временные рамки.

Что использовалось при создании проекта:

1. RTOS ChibiOS
2. Sublime Text2
3. GCC (CodeSourcery)

Вспомагательное железо для создания проекта:

1. CAN Hacker
2. Saleae Logic Analyzers
3. USB-UART converter

В итоге получили J2534 устройство, поддерживающее следующий список протоколов:

Поддержка следующих протоколов:

1. ISO 11898 (raw CAN) до 1Mb/s
2. ISO 15765-4 (CAN)
3. ISO 14230-4 (Keyword Protocol 2000)
4. ISO 9141-2

В виду того, что ряд функций, описанных в стандарте J2534, не используется в программах, с которыми планировалось использовать устройство, их было решено исключить. В частности, это поддержка протоколов J1850 (PWM/VPW). Возможно, когда будет время, я подтяну и эти протоколы в устройство, чтобы получить 100% охват протокола J2534.