Я занимаюсь разработкой электроники. Шесть лет назад я написал свою первую статью начинавшуюся этими же словами и увидел неподдельное внимание. Все эти годы я продолжал оттачивать свое мастерство и на текущий момент я хочу перефразировать вступление:
Я занимаюсь разработкой электроники и мне этого мало.
Чтобы немного понять, что я имею ввиду, предлагаю заглянуть под кат.</cut>
Да, я фотографирую себя с помощью встраиваемого компьютера, который я разработал и для которого я собрал софт, на камеру, которую мне пришлось поднимать вручную (хехе, какая двусмысленность). Да, я покрыл полный стек разработки: от идеи до воплощения, включая отладку железа и софта.
А теперь небольшое отступление, как я вообще докатился до жизни такой. Около двух лет назад наш коллектив влился в разработку электроники и софта для одной международной компании. Проект оказался несколько нервным: заказчики меняли архитектуру железа на лету (например, мы меняли систему питания два раза, с выпуском прототипов в железе, меняли контроллер, с разрабкой софта и для старого и для нового, разумеется с отладкой в железе, а под конец, когда железка уже работала с DDR3L памятью нас попросили переделать под DDR4). Тем не менее, железка вышла в свет, и вы можете не только посмотреть непредвзятый обзор онлайн: тыц, но и купить ее по всему миру. К слову, как разработка схемы, так и трассировка печатной платы были выполнены лично мной. В этой истории есть масса интересных моментов, но не будем отвлекаться: в процессе работы над этим и другими проектами я получил серьезный опыт и у меня сформировалось понимание, как процесс разработки аппаратуры можно ускорить и улучшить. В двух словах: человек, который умеет как в железо, так и в софт, может ускорить этот процесс в разы. Например, отладка новой железки для программистов это кошмар: непонятные схемы, неизвестность, как изменения в софте отражаются в железе, соответственно, сложность с проверкой своего кода и полная потерянность. Отладка железки для железячника этот тот же кошмар, только в профиль: тонны кода, сложности навигации в нем и уж тем более сложности модификации этого кода, и как результат – потерянность. Сотрудничество двух команд это потерянность в большинстве случаев.
Второй важный навык, который я вынес из этого, и многих других проектов это навык оперативной разработки железа. Возможность выкатить первую версию железа через месяц после утверждения ТЗ это здорово. (Изменения в ТЗ это не здорово, но об этом в другой раз). Например, в проекте выше для первых прототипов мы взяли готовый процессорный модуль от NXP, а все остальные фичи реализовали в простой четырех-слойной плате. Да, на плате немного срач, но для медленных интерфейсов это абсолютно не важно. Важно то, что такую плату могут изготовить за неделю, а собрать и отлаживать такую комбинацию в разы проще: можно декомпозировать и отлаживать по частям:
В результате, эта стратегия позволила мне многие разработки переиспользовать и начать вести собственные проекты в аналогичном оперативном и гибком темпе. Один такой пилотный проект вышел в свет и полностью доступен здесь: https://nxp.gitbook.io/8mmnavq/
Этот проект оказался коммерчески жизнеспособным, хоть и не таким масштабным. Тем не менее идея показалсь интересной, и мы продолжили работу. Отсюда и начинается главное повествование.
Итак, в ходе работы мы установили множество трудовых отношений, в том числе и с компанией NXP (как вы уже увидели по ссылке на гитбук), и когда эти ребята выпустили новый процессор IMX8M Plus (ниже), мы решили что стоит взяться за него посерьезнее, и переиспользовать все наработки, которые были получены как в пилотном проекте NavQ, так и опыт разработки в целом.
Железо
Собственно, в первой ревизии железа (на КДПВ) было реализовано следующее:
-
Процессор IMX8M Plus (его блок-схема выше)
-
До 8Гбайт LPDDR4 памяти (32бит, до 4266MTs), до 1ТБ eMMC (8бит, до 3200Mbps)
-
Два USB-C порта (до 5Gbps на порт), с поддержкой Power Delivery
-
Два MIPI CSI (Camera Serial Interface), 4 канала данных на каждый порт
-
Два LVDS порта для вывода видео, 4 канала данных на каждый порт
-
Один MIPI DSI (Display Serial Interface), 4 канала данных на порт
-
Один PCIe Gen 3, (1 канал данных, до 8GTs)
-
Один 1000BASE-T Ethernet, с поддержкой IEEE 1588v2
-
Один WiFi модуль, 2.4/5GHz, c Bluetooth Low Energy
-
Масса низкоскортных интерфейсов (UART, SPI, I2C, JTAG)
-
Питание от USB или от 5-20В внешнего источника питания
Практически все, что есть в процессоре. И это все в сборке размером с кредитку. Разводка всего этого в 6 слоях было тем еще приключением. Собственно, все это отражено на КДПВ. Но на этом решили не останавливаться, и решили еще немного добавить в новой ревизии:
-
Двухпроводой автомобильный Ethernet (до 100 Mbps)
-
Два CAN интерфейса, каждый с индивидуальным с PHY
-
NFC и Trusted Platform модуль (криптография и все такое)
-
RTC с твердотельным суперконденсатором
Кстати, о разводке: вот лицевая и тыльная сторона платы в том как это вижу я во время проектирования: в таких случаях начитается оптимизация на новых уровнях: например у USB-3.0 высокоскоростные диффпары можно переподключать с «неправильной» полярностью: линк в процессе тренировки подстроится. И это определено в стандарте USB. Такие знания позволяют творить с USB хорошие трюки: например разводка всего USB в одной плоскости. А это хорошо с точки зрения целостности сигналов: меньше переходов на другие слои – меньше искажений полезного сигнала. Да и разводка получается элегантнее и компактнее. И таких трюков десятки.
Еще один приятный момент: навыки работы в нескольких САПР. Разумеется у каждой САПР есть свои плюсы и минусы. Например, мне нравится Orcad Allegro за его абсолютно серьезный подход к правилам и проверкам дизайна. Система от британцев, а уж они то ребята дисциплинированные. Но еще мне нравится Altium Designer. Разработчики стараются сделать софт приятным в использовании и со всеми современными графическими фичами: вот где еще я могу собрать всю свою поделку, включая хитро выгнутые шлейфы, да так, чтобы выглядело реалистично?
Сильным подспорьем оказываются и навыки в 3D моделировании: спроектированный корпус для модуля становится как и защитой этого модуля от внешних воздействий: его уже не повредишь случайным касанием, так и придает законченный вид изделию:
Но это все покрывает только половину задачи. Следующий шаг – поднять все это в софте.
Софт
Очевидно, что такое обилие новых интерфейсов требует серьезной работы и на стороне софта. Итак, я понял, что я хочу с этим справится. Сборка ядра Linux это уже мелочи на сегодняшний день, никого этим не удивить, сборка Yocto тоже решаема парой пинков в нужных местах (если потребуется), модификация Device Tree Structure, собственно структуры которая сообщает ядру какая периферия для него доступна это тоже не страшно. Всяческие низкоскоростные интерфейсы просто «включаются» в ядре и заводятся в железе сразу. Но вот работа с видеоподсистемой, и особенно с камерами это был серьезный вызов. И я решил себя в этом попробовать. Я догадывался, что это кошмар, но глубину этой «кроличьей норы» оценить не мог. А оценить оказалось что.
Этот новый IMX8M Plus немного отличается от всех своих предшественников в организации всей своей медиа-подсистемы. NXP добавила в процессор так называемые ISI, Image Sensing Interfaces и ISP, Image Signal Processors, оба для обработки видео-потоков с камер. Помимо того, что все это новые модули, они еще сильно связаны с V4L2 (Video For Linux) подсистемой в Linux. И еще над всем этим ведется работа, и каждый релиз BSP от NXP отличается от предыдущего. И люди это пытаются использовать и разумеется это невероятно сложно. Быстрый взгляд в коммьюнити хаб разработчиков открыл страшную картину: я сходу столкнулся с дюжиной тем где люди обращались за помощью к NXP:
-
https://community.nxp.com/t5/i-MX-Processors/iMX8M-MIPI-CSI-4-lane-configuration/m-p/875755
-
https://community.nxp.com/t5/i-MX-Processors/IMX8-MIPI-CSI2-video-capture-not-working/m-p/1222637
-
https://community.nxp.com/t5/i-MX-Processors/IMX8MP-MIPI-CSI2-Problems-in-custom-camera/m-p/1234225
-
https://community.nxp.com/t5/i-MX-Processors/imx477-sensor-driver-for-i-MX8M-Plus/m-p/1271067
-
https://community.nxp.com/t5/i-MX-Processors/Unable-to-record-a-video-using-MINISASTOCSI/m-p/1293651
-
https://community.nxp.com/t5/i-MX-Processors/8MPLUSLPD4-EVK-with-MINISASTOCSI-usage/td-p/1259724
-
https://community.nxp.com/t5/i-MX-Processors/i-MX8-ov5640-mipi-v3-driver-problem-SOLVED/m-p/1022521
-
https://community.nxp.com/t5/i-MX-Processors/IMX8MM-Gerneric-MIPI-CSI-driver-available/m-p/1085966
-
https://community.nxp.com/t5/i-MX-Solutions/Post-TP2850-driver-on-i-MX8M-Plus/m-p/1241606
И это не праздный интерес «а что это вы тут сделали?», это конкретные вопросы «у нас не работают ваши изобретения на вашем-же железе». В общем, проблема становилась все масштабнее.
Небольшое отступление: разработка железа с моей точки зрения несколько проще: да, разумеется нужно обладать знаниями в области, понимать пути решения задачи и обладать опытом, но в случае когда железо проектируется с нуля присутствует полная свобода выбора: здесь я поставлю процессор, а тут разъемы (немного утрирую, конечно). В софте, особенно в Linux, есть 30 лет истории развития проекта, и в нем всё со всем тесно связано. «Нельзя просто так взять и добавить драйвер» © с нуля, нужно понимать все пути взаимодействия этого драйвера с системой, и систему соответственно. Особенно в таких случаях, когда это массивные штуки вроде медиа-подсистемы.
Невозможно передать всю гамму эмоций в одной статье, но в результате мне потребовалась неделя, чтобы заставить камеру работать. В процессе отладки рушилось все: ядро целиком, видео-подсистема, драйвер, вера в человечество и даже части собственной машины (был в глубокой задумчивости, а не пойти-ли мне в проститутки). Когда я в результате увидел картинку с камеры, я немного испугался: вид у меня был явно помятый:
В процессе отладки я полагался на свои знания в железе на все сто процентов: проверки того, что изменения в софте реально применяются к железу, и применяются правильно категорически важны: один неправильный бит и камера находится в состоянии сброса, неверный источник тактового сигнала в коде и камера не стартует: нет тактовой частоты.
В результате я доказал себе отладка как железа, так и софта одним человеком, особенно на таком уровне сложности ВОЗМОЖНА. Это для меня выглядит как level-up, и вот почему. Есть предположение, что это знание масштабируемо: работая меж двух команд (SW и HW) можно как разрешать многие ошибки на начальных этапах проектирования, так и в последующем значительно ускорять процесс разработки (понимая что и где нужно каждой из команд).
На этом работа над камерой была завершена. Но помимо этого есть еще и вывод видео. И это было второй частью приключения. Вывести картинку не сложно, но вот вывести на монтитор GUI целой операционной системы уже посложнее. Небольшой флэш-бэк из прошлой статьи: “В качестве собственно операционной системы я выбираю Debian. По-моему, отличный дистрибутив — простой и надежный, как деревянная палка. Беру готовую сборку, распаковываю на раздел карточки, и указываю при загрузке ядра, где искать его законную корневую.”
Так вот, с графикой такое не проходит. Графическая подсистема (скажем, оконный менеджер) тесно завязана на десятки библиотек, а эти библиотеки в свою очередь завязаны на ядро Linux, которое в свою очередь обращается к драйверу графического ускорителя. Драйвера собираются под конкретное железо, и могу предлагать только часть возможностей необходимых оконному менеджеру, соответственно, не любая комбинация возможна.
В моем случае мне несказанно повезло: NXP дружит с Wayland, а Ubuntu (прямой потомок Debian) совсем недавно начала поддерживать Wayland со своей стороны.
То есть, пара дней гуглинга и медитаций дали желаемое: я завел Ubuntu на новом процессоре. А это уже открывает окно в целый мир: я сходу поcтавил ROS (Robot Operating System), подключил уже проверенный PCIe модуль с любимыми видео (а потом и аппаратный Neural Network Accelerator) и поставил соответствующий софт. Даже YouTube посмотрел, чего я не мог сделать на своем предыдущем одноплатнике:
Таким образом, получилась целая платформа, немного напоминающая Raspberry PI. То есть: подключил клавиатуру, мышь, дисплей и вот у тебя полноценный компьютер. Еще один level-up: я с детства мечтал спроектировать и собрать собственный компьютер, с теми интерфейсами какие я хочу, с той геометрией и тем софтом которым я привык пользоваться. Получилось здорово, мне нравится.
Aftermath
Разумеется, многие интерфейсы еще не проверены, работы непочатый край, разумеется, есть идеи как систему можно расширить благодаря ее модульности. Есть вещи, которые просто обязаны, случится, например Time Of Flight камеры лежат и ждут когда за них возьмутся.
Над проектом ведется работа, и не одним лишь мной. Будет вкусный софт и вся поддержка, и не только со стороны NXP. Всю эту систему с полным набором интерфейсов можно будет получить даже бесплатно, вот как это происходило с предыдущим поколением.
При первой-же возможности доступ к файлам проекта будет открыт (как для https://nxp.gitbook.io/8mmnavq/), и мне будет крайне интересно услышать мнение от ребят с опытом. Реально интересно кто сможет найти проблемы в дизайне и буду рад за тех у кого вообще возникнет такое желание.
В целом, я рассматриваю это как хороший старт, и надеюсь что я немного раскрыл свою мысль из введения: «я занимаюсь разработкой электроники и мне этого мало». Stay tuned!
Автор: Бушуев Андрей