Несколько лет я искал такой проект, в котором мог бы сполна реализовать свою креативность. Собственный проект, который бы стал испытанием моих навыков и принёс внутреннее удовлетворение.

Карманные ПК всегда занимали в моём сердце особое место. Первым был Palm III, а чуть позже я стал обладателем Sharp HC-4500. Меня заинтересовали проекты Yarh.io, и в начале этого года я задумал купить uConsole. Предполагалось, что этот девайс будет отправлен в марте, но заказ всё ещё находится на стадии подготовки. Так что, вооружившись множеством идей и сильной мотивацией, я приступил к реализации собственного проекта по сборке карманного ПК: Decktility.

▍ Основные критерии проекта

Я хотел испытать свои силы и расширить границы возможностей самодельных решений. Модель Micro 2 от проекта Yarn.io лично мне показалась грубоватой. На момент разработки она была явно ограничена аппаратными возможностями.

Почитав документацию Yarn.io, я понял, к чему хочу прийти. Мне хотелось собрать устройство, которое бы выглядело более тщательно проработанным. Я также хотел, чтобы оно оказалось достаточно лёгким и держало батарею хотя бы пару часов.

На тот момент я уже рассматривал в качестве основы BigTreeTech Pad 5, поскольку он представлял самую тонкую комбинацию сенсорного экрана и Pi, какую мне удалось найти. Также вполне логичным выглядело решение отказаться от сборки складного устройства, поскольку такой вариант предполагал ряд сложностей:

• Если отталкиваться от Pad 5, то одна половина будет иметь толщину около 15 мм, а толщина половины с клавиатурой, если учесть 18 мм батареи 18650 и корпус, окажется не менее 20 мм. Общие 35 мм – это уже слишком. Я подумал об использовании стандартного плоского LiPo-аккумулятора, но мне не нравится их опасность в случае короткого замыкания.
• Трудно собрать качественные петли. Элемент корпуса с экраном будет довольно увесистый, а нам не нужно, чтобы в процессе печати он шатался.

Так что решение было принято: форма корпуса моего устройства будет аналогична Micro 2 от Yarn.io и uConsole от ClockworkPi.

▍ Прототипирование

Прежде, чем приступать к 3D-проектированию, я купил в сети некоторые базовые компоненты. Когда они прибыли, я эти компоненты измерил, чтобы понимать, сколько каждый из них займёт места. Это также позволило мне начать собирать прототип:



Следуя руководству подключения компонентов, я начал со сборки схемы питания, а именно USB-системы управления батареей (BMS, Battery Management System), способной заряжать два литиевых аккумулятора 18650, в паре с понижающим преобразователем 5 В, поскольку Pi, клавиатура и кулер требовали именно 5 В. Для проверки подачи питания во время зарядки я использовал тестер USB-C PD (Power Delivery).

Когда всё заработало, я с помощью соединительных проводов подключил Pi:



В итоге я обнаружил, что BMS при зарядке прилично греется. Эта система повышала получаемые от USB 5 В до примерно 8,4 В, необходимых батареям. Повышение напряжения происходит значительно менее эффективно, чем его понижение, поэтому здесь нагрев больше. Это говорило о необходимости добавления системы охлаждения. В открытом виде нагрев платы до 45° – это ещё не так плохо, но в корпусе, где Pi будет генерировать дополнительное тепло, такая температура уже нежелательна.



В теории из батареи, переключателя и Pi должен получиться рабочий продукт, но что, если батарея окажется близка к разряду? Если переключатель питания останется активен, он будет высасывать батарею и в итоге повредит её.

Для решения этой проблемы, я добавил Arduino Nano. Этот микроконтроллер будет решать много задач, но для начала я реализовал с его помощью считывание напряжения батареи. Для этого я добавил два резистора с высоким сопротивлением, поскольку они всегда будут подключены к батарее, а значит будут забирать энергию. В случае резисторов MR на 2,2 МОм и 3,9 МОм утечка составит всего 0,82 мкA (5/(2200000 + 3900000)). Это где-то 4,1 мкВт – иными словами, для высасывания батареи на 20 Вт/ч потребуется 203252 дня. В таком случае это уже не проблема.



Теперь, понимая, когда можно безопасно включать оборудование, нужно было реализовать возможность фактического включения. Для этого я использовал особый вид транзистора – силовой MOSFET (или «силовой FET»). Цепь этого FET находится на зелёной печатной плате, виднеющейся за кучей проводов:



Примерно в это же время я начал проектировать прототипы CAD в OnShape. Немало часов пришлось провести за измерением и зарисовкой различных компонентов для Decktility. Мне требовалось их 3D-изображение, чтобы можно было подогнать размер и форму корпуса.



На раннем этапе мне пришлось решать дилемму с расположением батарей. Изначально предполагалось, что они будут выступать противовесом экрану. Важно, чтобы в руках устройство ощущалось сбалансированным – экран и батареи являются довольно тяжёлыми элементами, поэтому их нельзя располагать на одной стороне.

Я рассматривал два варианта расположения батарей: по сторонам, чтобы создать своеобразные выступы для удержания устройства, либо в нижней части корпуса по центру. Размещение их по сторонам потребовало бы два отдельных держателя, и минимальная длина нижней половины устройства оказалась бы 7,5 см. Мне реально понравилась эта идея с выступами, но её недостатки подтолкнули к альтернативному варианту.

▍ Сборка

После проработки базового дизайна корпуса настало время печатать его первую версию. Первую из многих…



Массивная плата с FET быстро привлекает взгляд. Фото с ней я показал просто, чтобы продемонстрировать, насколько она выбивается из общей схемы. В итоге я заменил её на более компактную и уже потом продолжил.

Поменять эту плату оказалось труднее, чем я предполагал. Есть много доступных готовых модулей, но большинство из них собраны на N-FET, а не P-FET. Платы с N-FET дешевле и проще в сборке, в результате чего мы получаем переключение питания на линии GND. Позднее я выяснил, что мне нужен именно вариант с P-FET ввиду потребности в постоянно подключенной общей земле, необходимой для совместной работы логики Arduino и Pi (для коммуникации по I2C).

В итоге я не смог найти достаточно компактную плату с FET, поэтому прибёг к реверс-инжинирингу уже имеющейся в своём первом проекте KiCad:



После чего пересобрал её на экспериментальной плате:



Возможно, я соберу кастомную плату в будущем. Это позволит мне добавить разъёмы для различных компонентов, упростив тем самым сборку.

В отсутствии кастомной платы с FET мне удалось заставить работать большинство базовых компонентов до этапа добавления Pi. Тогда я быстро выяснил, что взял для основного питания провод неподходящей толщины. У меня под рукой был 20 AWG, который я обычно использую для дронов, потребляющих намного бо́льшую мощность. Позднее я заменил этот провод на 24 AWG.



Работая над прошивкой для Arduino, я столкнулся с проблемой: при каждой загрузке её новой версии микроконтроллер перезапускался. Это приводило к отключению электронного выключателя и, как следствие, перезапуску Pi. Чтобы решить эту проблему, я вместо использования Arduino внутри устройства подключил его второй экземпляр к I2C. На более позднем этапе я также добавил разъём JST-SH, чтобы легко отключать внутренний Arduino.



Неплохим дополнением стали бы светодиоды, отражающие состояние зарядки, но добавление 1 или 2 таких в корпус потребовало бы приличных усилий. И тут меня осенило: можно же использовать оптоволокно! Проволока для протягивания кабелей (или гибкая проволока для браслетов) может проводить свет от светодиодов BMS до края корпуса. Для этого лишь потребуется проложить и приклеить такой провод. Заказав срочную доставку и проведя простой эксперимент, я подтвердил эту идею:



После множества опробованных вариантов аппаратная часть была закончена:



На тот момент кастомная реализация устройства с I2C позволяла Pi и Arduino взаимодействовать. Pi мог спросить у Arduino состояние заряда или напряжение батарей, и тот эти данные исправно сообщал. Я начал изучать возможность вывести эту информацию на рабочий стол Linux, в ходе чего прочитал о dbus и upower. Поначалу, я хотел написать собственный драйвер ядра, но затем до меня дошло: «Что, если изменить прошивку Arduino так, чтобы он действовал как уже поддерживаемое в Linux устройство?» Поизучав различные варианты, я остановился на реализации «индикатора расхода батареи» LTC294x. Это оказался один из немногих связанных с питанием драйверов ядра Linux, которые были доступны в Raspberry Pi OS.

Теперь Arduino действует так, будто является устройством Linux, поэтому полностью в этой системе поддерживается.

Я испытал восторг, когда впервые увидел на экране значок батареи:

▍ Полученные уроки

Ниже я привёл краткую сводку некоторых полезных уроков, которые выше не затронуты:

• Как уже говорилось, важной частью стало воздушное охлаждение. Мне пришлось охлаждать плату BMS, а также Pi. Нескольких отверстий для потока воздуха будет недостаточно. В итоге я расположил компоненты под прямым обдувом со стороны кулера. Это также несколько ограничило возможности расположения остальной электроники, поскольку я уже не мог свободно перемещать плату BMS.
• Минимум крепёжных деталей: самый лучший крепёж – это тот, без которого можно обойтись. Если вы придумаете механизм с пазом и защёлкой, чтобы сэкономить детали, то такое решение вполне может себя оправдать. Для меня соответствующие затраты вылились в дополнительное усложнение дизайна.
• Проектиррвание для … 3D-принтеров? Или ЧПУ-станков? Изначально я планировал сделать 3D-печатный корпус, а позднее попробовал изготовить его алюминиевую версию с помощью ЧПУ-станка. Проектирование для 3D-принтеров сильно отличается, так что для обработки на 3-осевом фрезерном станке потребовалось вносить изменения.
• Размещать электронику трудно: помимо продумывания воздушного охлаждения, вам также нужно учитывать объём проводов, необходимых для подключения всех компонентов. Я также стремился сделать девайс максимально компактным, и поиск оптимальных компромиссов оказался нелёгкой задачей. Кроме того, есть проблемы с юзабилити: ваша SD-карта может входить в слот, но будет ли она легко извлекаться? Сможете подцепить её ногтем?
• 3D-печать – фаски: я делал фаски на выступах, чтобы исключить необходимость использовать поддержку при их 3D-печати. Помимо этого, я делал фаски по краям в области разъёмов (например Ethernet и линий ввода-вывода), чтобы облегчить подключение штекеров.
• 3D печать – указание поддержек вручную с помощью закрашивания (painted-on supports): этот инструмент очень удобен, если у ваших деталей множество выступов, но поддержка требуется лишь некоторым (присутствует в SuperSlicer/PrusaSlicer).
• 3D печать – детали могут деформироваться: при сборке батарейной кассеты нужно учитывать, что создаваемое батареями давление может выдавливать её стенки наружу, в результате чего кассета не будет входить в корпус при вставленных батареях. Здесь важно измерить деформацию и оценить, не слишком ли выгибаются стенки наружу, так как вы явно не захотите столкнуться с критическим сбоем литиевых батарей.
• Активное использование SSH: я расширил свой цикл разработки за счёт удалённых команд. Я мог выполнять локальный код Python удалённо с помощью ssh me@cyberdeck 'python' < powermanager.py
• В Raspberry Pi 4 есть более двух шин I2C: если вы спалите свою шину CM4 I2C, то можете использовать другие контакты ввода-вывода для создания дополнительных портов I2C.
• Название проекта важно: несмотря на то, что «Decktility» является, пожалуй, не лучшим названием, оно хорошо своей запоминаемостью, а также уникальностью, благодаря которой онлайн-поиск с лёгкостью выдаст нужные результаты. С выбором хорошего названия вам может посодействовать ChatGPT.

▍ Напоследок

Все детали проекта освещены в репозитории Decktility.