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

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

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

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


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

Подробнее
Реклама

Комментарии 44

    0
    Стоимость экземпляра и как с окупаемостью (если не забыть посчитать зарплату специалистов на разработку)?
      +3
      Стоимость экземпляра — в районе 100 долл. США. На оплату услуг сторонних специалистов потрачено порядка 1000 долл. Но львиную долю проекта я делал самостоятельно.
        +1
        А в эту $1000 входит разработка модели корпуса и пресс формы для него? И расскажите, пожалуйста, немного детальней про заводское изготовление корпуса из акрила. Хотя бы, какая технология используется, стоимость подготовки производства и минимальный заказ?
          +2
          Нет, разработка корпуса сюда не входит. 3D модель корпуса мне сделали за 15 долл, и я его отпечатал на 3D принтере. Однако, от идеи 3D печати я отказался — во-первых — дорого (около 20 долл), во-вторых — медленно (один корпус печатался 5 часов). В итоге, один из клиентов мне сам предложил помощь с корпусом из акрила. Суть простая — берется толстый лист акрила и на станке с ЧПУ убирается все лишние внутренности. Это технология быстрая (за день можно сотню корпусов сделать) и относительно доступная (9 долл. за корпус при заказе от 150 шт.). На последнем фото поста именно корпус из акрила, а не пластик из пресс-формы.
          Возможно про корпуса я расскажу в отдельном посте, т.к. много чего пришлось перепробовать, в том числе литье в силиконовые формы.
            +2
            Не откладывайте в долгий ящик — очень интересно узнать подробности про корпус!
              0
              а можно про корпуса подробнее, в смысле контактов?

              плюс, $9/корпус — это для вашей платы, оно ведь видимо от объемов зависит и так далее?
                0
                Контакты у меня в Украине. Думаю Вы и у себя найдете подобную фирму. Мне делала это фирма, которая рекламой занимается. Они много чего из акрила делают. От объемов конечно же зависит. Более-менее адекватная цена начинается, когда корпуса полностью используют заводской лист акрила. Как мне сказал, человек, который делал, можно было взять акрил менее качественный, и цена будет значительно ниже, но я не стал экспериментировать с качеством.
                0
                А не проще ли было не фрезеровать из толстого листа, а собрать «бутерброд» из нарезанных лазером рамочек из дешёвого листового акрила, стянув их потом винтами?
                  0
                  Тонкие листы не такие прочные, могут и лопнуть при стяжке болтами.

                  Да и не факт что от этого сильно дешевле получится.
                    0
                    Думал и над таким вариантом. Элементы очень компактно расположены на плате. Если делать бутерброд, то нужно отступы по краям делать, а это дополнительная площадь платы, увеличение размеров устройства, увеличение веса (при доставке конечным потребителям играет роль). И таки, да, не факт, что бутерброд будет дешевле цельного куска.
                    0
                    Ясно, спасибо. Я тоже к фрезеровке в итоге пришел для небольших партий. Думал, вдруг это еще какой-то новый способ изготовления. Правда, единичные корпуса сравнимы по цене с напечатанными, но качество лучше.
                      0
                      Подскажите, а рассматривался ли вариант резки фанеры лазером и проклейка/сборка на винты слоев?

                      Я не специалист в этом, просто это первое что пришло в голову, при мыслях о корпусе для своей поделки.
                        0
                        Рассматривался, но минусы в сообщении выше написал. Я бы еще для поделок рассмотрел бы использование алюминиевого профиля в качестве корпуса — дешево и стильно.
                    0
                    А купить уже можно?
                    0
                    Ага, видел ваш адаптер :) народ пробовал, через него успешно обновляются ЭБУ хюндаев.
                    Вы молодцы :)
                    Я, несмотря на наличие stm под руками, только в качестве spy им пользовался, убедиться что mangoose китайский не тянет тупо по скорости…
                  0
                  А как RTOS выбирали и почему вообще решили её выбрать? Может посоветуете RTOS для Arduino? :)
                    +2
                    RTOS выбирал и предлагал мне исполнитель, к которому я обращался. До этого с RTOS вообще опыта никакого не было. Оглядываясь назад, скажу, что не жалею, что остановился на ней. Если бы проект писался на чистой библиотеке от STM, времени ушло бы значительно больше. По Arduino вообще не в курсе. Свое знакомство с электроникой начал с готовой макетной платы от Olimex.
                      0
                      Попробуй FreeRTOS она портирована практически на все что угодно. Ну и после кастрации лишнего вполне влезает на AVR, только нужна мега пожирней, от мега128 и толще. Иначе смысла нет. Да, только возможно придется выкинуть нафиг ардуино среду. Но это мелочи :)
                      0
                      Что использовалось при создании проекта:

                      RTOS ChibiOS
                      Sublime Text2
                      GCC (CodeSourcery)


                      Подскажите как отлаживали устройство в Sublime Text2?

                        +1
                        Отлаживали в командной строке через gdb. Математические алгоритмы, которые никак не связаны с железом отлаживались в IDE CodeBlock.
                          0
                          Понял, мне просто очень понравился редактор саблайм, но без отладки понял что это не альтернатива IDE.

                          Если нравится Code::Blocks то посмотрите в сторону Em::Blocks.

                            0
                            Ок, посмотрю. Спасибо.
                        0
                        Вопросы по чиби:
                        1. Хватило ли вам возможностей HAL, или где-то все-таки пришлось залезать на уровень непосредственной работы с периферией?
                        2. Были ли нарекания к работе мультипроцессного ядра и синхронизационных примитивов?
                        3. Работает ли проект с включенным контролем режима вызова системных функций?
                        4. Были ли подозрения или явные признаки временных лагов из-за использования системных вызовов?
                          0
                          1. Переписывал только то, что к CAN относится, остальное не трогал.
                          2. Проблем замечено не было
                          3. Как в оригинале называется этот режим?
                          4. Поначалу думал, что использование RTOS скажется на быстродействии, но ничего подобного не заметил. Максимальная нагрузка, с которой я пробовал работу адаптера (на реальном автомобиле) — 2000 CAN пакетов в секунду при скорости 500000 бит в секунду. Устройство успевало ловить эти данные и передавать по USB.
                            0
                            3. этот режим включается дефайном CH_DBG_SYSTEM_STATE_CHECK (определен в chconf.h). Если флаг определен, чиби будет проверять правильность класса вызова API (http://chibios.org/dokuwiki/doku.php?id=chibios:guides:debug_guide&s[]=ch&s[]=dbg&s[]=system&s[]=state&s[]=check) и останавливать систему через port_halt(), если класс вызова нарушен. См. раздел Сommon Errors -> Use of S-class or I-class APIs outside a proper lock state по ссылке
                              0
                              У меня дефайн CH_DBG_SYSTEM_STATE_CHECK в FALSE установлен
                                0
                                Тогда попробуйте его установить в TRUE, и посмотреть, не уйдет ли система в останов. Если уйдет — значит, где-то у Вас нарушены соглашения о классах вызовов внутри обработчиков прерываний и/или коллбэков — вот например одна из особенностей: http://forum.chibios.org/phpbb/viewtopic.php?f=2&t=1718&p=14588&hilit=gleb_l#p14588
                                  0
                                  Ок, спасибо, попробую.
                              +1
                              Наработки по CAN (те, что пришлось сделать для ChibiOS) планируете выкладывать?
                                0
                                Пока не было такого в планах. Судя по моим вопросам на форуме ChibiOS с проблемой потери CAN пакетов никто не сталкивался, и всем с головой хватало трех аппаратных слотов процессора для хранения сообщений.
                            0
                            Давай дружить — а то я делаю DIY ЭБУ на stm32 на чиби :)
                            google rusefi
                              0
                              Давай :) Видел посты о DIY ЭБУ — довольно интересная тема
                                0
                                Кстати, не могли бы вы осветить тему тестирования при разработке под ChibiOS?
                                  0
                                  А в чём именно вопрос?

                                  Chibi это по сути библиотека, gdb не знает о ней ничего — поэтому отладка абсолютно так же, как будто ChibiOS и нет.
                                    0
                                    Отладка через GDB, там всё просто.

                                    Я видел у вас тесты на код есть. Интересно, как они вызываются и прочее. Хочу освоить тестирование в C/C++.

                                      0
                                      У нас тесты в лоб сделаны
                                      пачка номер 1, юнит текстики: код, который про чиби не знает вообще — этот код компилируется в win/unix бинарник и запускается, отдельный main.c который руками вызывает методы и проверяет возвращаемые результаты. в лоб, без mock. Работает за счёт pure C, который всё равно где компилировать.

                                      пачка номер 2: у chibi есть win32 HAL — так что прошивка опять же компилируется в .exe и к ней тестирующая система подключается по TCP/IP. Это уже не unit test, это уже автоматизированное функциональное тестирование.
                                        0
                                        Понял. Надо посмотреть, а что там есть для Linux. Надо осваивать тестирование прошивок.
                                          0
                                          Posix HAL там тоже есть — так что можно аналогично поднять unix бинарник, у которого будет один или два виртуальных serial через tcp/ip
                                0
                                Здорово! А что вы потом делаете с прошивкой? Дизассемблируете и реверсите? Или там в понятном виде константы какие-то обозначены, которые можно подкрутить?
                                  +1
                                  Непосредственно чип-тюнингом автомобилей мы не занимаемся, а занимаемся только программным обеспечением и оборудованием для этого. В идеале — да, прошивку нужно дизассемблировать, чтобы найти необходимые карты калибровок. Но большинство пользуется готовыми редакторами, в которых уже после дизассемблирования все найдено. Однако это — частный случай, т.к. не для всех прошивок ЭБУ существуют такие редакторы. В некоторых случаях, карты калибровок можно найти и без дизассемблирования. Вот тут пример, как это делается: www.youtube.com/watch?v=MdK2HqHVrIU
                                  0
                                  Интересно увидеть чертежи корпуса (минимальную толщину стенок в том числе) + более крупные фото в корпусе (их можно и в эту статью разместить наверно, не дожидаться написания новой). Спасибо )
                                    0
                                    Так, я не самый острый карандаш в пенале. ELM327 вы же в итоге не используете? Значит протоколы типа 14230-4 вы писали сами, поверх транспортного CAN? Тогда вопрос — нет ли у вас желания эти исходники опубликовать отдельно? :)
                                      0
                                      Протоколы типа 14230-4 CAN не используют. Поверх транспортного CAN идет протокол ISO 15765-4. Исходники публиковать не буду, чтобы конкурентам не упрощать жизнь :). Но тех, кто хочет разобраться в с ISO 15765-4 могу проконсультировать и помочь разобраться — ничего сложного там нет. Если взять в крупную клетку, то длинное сообщение попросту разбивается на CAN пакеты по 7 байт данных в каждом, плюс служебная информация.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое