Представляет собой идеальную платформу для ознакомления с микроконтроллерами серии F3 и разработки прототипов устройств.
Она оснащена мощным 32-битным ARM Cortex-M4 процессором (STM32F303VCT6), поддерживающим DSP функции, что обеспечивает высокую производительность и возможность работы с сигналами с плавающей точкой.
Плата интегрирует в себя гироскоп, акселерометр и компас (L3GD20 и LSM303DLHC), что позволяет точно отслеживать движения и ориентацию устройства. Кроме того, на плате присутствуют кнопки, светодиоды, USB-порт и встроенный отладчик ST-LINK, что делает взаимодействие с платой удобным и эффективным.
STM32F3 Discovery идеально подходит для разработки прототипов в различных областях, включая создание устройств для автономного управления, таких как коптеры или системы умного дома. Функциональность и возможности делают её незаменимым инструментом для стартапов, инженеров-разработчиков и студентов, желающих глубже погрузиться в мир встраиваемых систем и IoT.
STM32F4 DISCOVERY от STMicroelectronics представляет собой идеальную платформу для изучения и разработки приложений на микроконтроллерах STM32F407 и STM32F417. Она оснащена мощным 32-битным процессором ARM Cortex-M4 с встроенным FPU, что обеспечивает высокую производительность и возможность работы с числами с плавающей точкой.
На плате имеется встроенный отладчик ST-LINK/V2, который упрощает программирование и отладку приложений. Кроме того, STM32F4 DISCOVERY включает в себя цифровой 3-осевой акселерометр, цифровой микрофон и аудио ЦАП с интегрированным драйвером класса D. Эти компоненты позволяют разработчикам создавать приложения с звуковым вводом-выводом и мультимедийными возможностями.
Для удобства и наглядности на плате также расположены светодиоды различных цветов и кнопки, что делает процесс разработки интерактивным и интуитивно понятным. Плата питается от USB или внешнего 5V источника, что упрощает её интеграцию в различные проекты.
STM32F4 DISCOVERY от STMicroelectronics представляет собой идеальную платформу для изучения и разработки приложений на микроконтроллерах STM32F407 и STM32F417.
Она оснащена мощным 32-битным процессором ARM Cortex-M4 с встроенным FPU, что обеспечивает высокую производительность и возможность работы с числами с плавающей точкой.
На плате имеется встроенный отладчик ST-LINK/V2, который упрощает программирование и отладку приложений. Кроме того, STM32F4 DISCOVERY включает в себя цифровой 3-осевой акселерометр, цифровой микрофон и аудио ЦАП с интегрированным драйвером класса D. Эти компоненты позволяют разработчикам создавать приложения с звуковым вводом-выводом и мультимедийными возможностями.
Для удобства и наглядности на плате также расположены светодиоды различных цветов и кнопки, что делает процесс разработки интерактивным и интуитивно понятным. Плата питается от USB или внешнего 5V источника, что упрощает её интеграцию в различные проекты.
STM32F4 DISCOVERY идеально подходит для стартапов, инженеров-разработчиков и студентов, желающих быстро и эффективно начать работу с микроконтроллерами STM32F4 и использовать их мощные возможности для создания разнообразных приложений, от звуковых устройств до систем управления и автоматизации.
3. Плата разработки STM32F7-Discovery от STMicroelectronics
Представляет собой мощное решение для создания встроенных систем и приложений реального времени, обладающее расширенными мультимедийными возможностями.
Оснащенная микроконтроллером STM32F746NGH6 с ядром ARM Cortex-M7, плата обеспечивает высокую производительность благодаря частоте до 216 МГц и полному набору DSP инструкций.
STM32F7-Discovery поддерживает разнообразные интерфейсы, что делает её идеальным выбором для интеграции в промышленные системы. Основные характеристики включают 1 Мб программной памяти контроллера, 128 Мб Quad-SPI флэш-памяти и 128 Мб SDRAM. Наличие ART Accelerator™ и кэш первого уровня обеспечивает быстрый доступ к данным и инструкциям.
Плата также оснащена 4.3-дюймовым дисплеем с емкостным сенсором, что расширяет возможности для разработки интерактивных пользовательских интерфейсов. Для ввода и вывода аудио используются 3×12-битные АЦП и 2×12-битных ЦАП. Разнообразие интерфейсов включает разъемы для камеры, микрофона, наушников, microSD, RF-EEPROM, а также USB OTG HS, USB OTG FS и вход SPDIF RCA.
С двумя кнопками для управления питанием и перезагрузкой, плата STM32F7-Discovery обеспечивает простоту в использовании и интеграции, делая её идеальным выбором для разработчиков, работающих в области встроенных систем, мультимедиа и систем реального времени.
Представляет собой компактное и удобное решение для создания прототипов и разработки IoT устройств.
Она обеспечивает простоту использования благодаря встроенным возможностям, таким как автоматическая загрузка программ, отладка через USB-UART мост CH340G от Silicon Labs и удобная интеграция с Arduino и другими IDE.
Основные особенности платы включают хорошо оптимизированную разметку печатной платы в последней версии 4.0, где все вводы/выводы были рационализированы. Встроенный LDO на 3.3В обеспечивает стабильное питание, что важно для надежной работы устройств. Плата также оснащена двумя программируемыми кнопками и двумя светодиодами для удобства отладки и индикации состояний.
ESP32 HW-608 NODEMCU идеально подходит для быстрой разработки и тестирования IoT приложений благодаря своей компактности, простоте интеграции и широким функциональным возможностям.
Разработанная NXP в сотрудничестве с mbed, предназначена для прототипирования различных устройств, особенно подходящих для робототехники.
Эта плата выделяется компактными размерами, значительно меньшими по сравнению с большинством аналогов на рынке. Она оптимальна для конфигураций с ультранизким потреблением энергии благодаря энергоэффективной аппаратной платформе.
Плата оснащена микроконтроллером Kinetis MKL43Z256VLH4 на базе процессора ARM Cortex-M0+ с тактовой частотой 48 МГц.
Устройство имеет 256 КБ флеш-памяти, 32 КБ оперативной памяти и 16 КБ ROM. Оно поддерживает несколько режимов малой мощности и оснащено блоком пробуждения с малой утечкой, а также четырехканальным DMA контроллером.
Семейство MCU Kinetis KL43 полностью совместимо с программным обеспечением, оборудованием и средствами разработки Kinetis MCU и Freedom.
Мощная плата расширения, созданная для упрощения работы с микроконтроллером Seeeduino XIAO. Она значительно улучшает функциональность устройства благодаря нескольким важным особенностям.
Встроенная микросхема управления батареей и крепление для аккумулятора позволяют легко подключать и заряжать литиевую батарею, обеспечивая бесперебойное питание.
Разъемы Grove на плате, включая два порта IIC и один UART, обеспечивают легкость подключения различных модулей и сенсоров, что делает процесс разработки более интуитивным и удобным.
Grove Shield также оснащен пластиной для соединения Flash SPI, что позволяет добавлять дополнительную память к Seeeduino XIAO и расширять его возможности.
Эта плата помогает избежать сложностей с проводами и пайкой, предоставляя более чистое и упрощенное решение для соединений.
Seeeduino XIAO поставляется с парой неспаянных 7-контактных разъемов, которые необходимо припаять перед подключением к плате расширения, что дает пользователю возможность более гибко настроить свое устройство.
Инновационная плата разработки, основанная на OpenWrt Linux и микроконтроллерах MT7688 и ATmega32u4. Она предназначена для создания приложений Rich IoT, идеально подходящих для умных домов и офисных решений.
Совместимость с Arduino Yún позволяет использовать широкий спектр функций и преимуществ обеих платформ, что значительно упрощает создание сложных и многофункциональных программ.
Эта плата обеспечивает надежную обработку видео благодаря достаточной памяти и пространству для хранения данных. Разработчики могут писать программное обеспечение на языках Python, Node.js и C, что предоставляет гибкость и множество возможностей для разработки приложений.
Созданная совместно Seeed Studio и MediaTek, LinkIt Smart 7688 Duo объединяет их экспертные знания в области открытых аппаратных решений и современных IoT технологий.
На платформе MediaTek Labs доступны ресурсы для полной поддержки работы с LinkIt Smart 7688 Duo, включая SDK и активные форумы для обмена знаниями и опытом. Важно строго следовать инструкциям по эксплуатации, чтобы предотвратить неправильное использование и сохранить работоспособность устройства.
Представляет собой компактный шилд для GSM/GPRS связи, разработанный на базе популярного модуля SIM800L. Он предоставляет возможность отправки SMS, осуществления голосовых звонков и обмена данными через GPRS, что делает его идеальным выбором для проектов, требующих мобильной связи в условиях IoT.
Модуль поставляется с встроенной антенной, а также поддерживает возможность подключения дополнительных антенн для улучшения качества связи. Управление модулем можно осуществлять через USB-UART или напрямую через UART микроконтроллера, что обеспечивает гибкость интеграции с различными устройствами и системами.
Светодиод на плате предоставляет визуальную обратную связь о состоянии модуля: он быстро мигает при включении, уменьшая частоту мигания при установлении стабильного соединения с сетью оператора. Потеря связи с оператором снова активирует быстрое мигание, указывая на процесс поиска сигнала.
Этот модуль идеально подходит для разработки приложений, требующих надежной и компактной GSM/GPRS связи, включая мониторинг, управление и другие IoT решения.
Модуль для микроконтроллера MSP430FR5994, идеально подходящий для разработки на основе платформы FRAM MSP430FRxx. Этот модуль включает интегрированный инструментарий для программирования, отладки и измерения энергопотребления, что делает его идеальным выбором для быстрого старта проектов.
На плате установлены кнопки и светодиоды для простого взаимодействия с внешним миром, а также держатель карты памяти и ионист (суперконденсатор), позволяющий работать без внешнего источника питания. Микроконтроллер оснащен 256 КБ встроенной памяти FRAM с высокой отказоустойчивостью и быстрой скоростью записи, а также 8 КБ SRAM.
В его арсенале - интегрированная коммуникационная периферия, таймеры, АЦП, блок шифрования AES, низкоэнергетический ускоритель и аппаратный модуль для векторной математики. С тактовой частотой 16 МГц, микроконтроллер обеспечивает достаточную производительность благодаря аппаратным математическим блокам, что делает его эффективным для разнообразных проектов, требующих высокой энергоэффективности.
Для прототипирования доступен разъем BoosterPack на 40 контактов, идеально подходящий для подключения различных модулей расширения, включая беспроводную связь, графические дисплеи и датчики. Вы также можете разработать собственные модули или выбрать из уже существующих продуктов от различных производителей.
Для разработки доступны две бесплатные среды разработки, поддерживающие технологию EnergyTrace++ для реального времени профилирования и отладки на LaunchPad. Эти инструменты позволяют анализировать и оптимизировать энергопотребление, отслеживать состояние ядра, тактовые импульсы и другие ключевые параметры работы устройства.
Плата разработки на основе микросхемы N76E616 от компании Nuvoton представляет собой инновационное решение в сфере микроконтроллеров. Этот 8-разрядный микроконтроллер на базе 1T 8051 обладает высокой производительностью и включает в себя встроенную флеш-память.
N76E616 поддерживает до 18 кБ основной флеш-памяти (APROM) для хранения пользовательского кода. Важной особенностью является функция внутреннего программного программирования (ИАР), которая позволяет настраивать части массива пользовательского кода в качестве энергонезависимого хранилища данных. Эти данные можно считывать с помощью инструкции IAP или MOVC.
Дополнительно предусмотрено хранилище Flash – LDROM, где обычно размещается загрузочный код для внутреннего системного программирования (ISP). Это обеспечивает гибкость и удобство при разработке и обновлении программного обеспечения.
Микросхема N76E616 обладает полной совместимостью с инструкциями семейства микроконтроллеров 80C51, что упрощает перенос и адаптацию программного обеспечения. Её высокая производительность и возможности программирования делают этот чип идеальным выбором для широкого спектра приложений, требующих надежной и эффективной работы в условиях ограниченных ресурсов.
Обычно Android-устройства принято считать "бесполезными" через 5-10 лет после выхода. Особенно, это касается бюджетных моделей, которые "не тянут" современные сервисы или те девайсы, которые по каким-то причинам физически пострадали в процессе своей жизни. Но пока одни выкидывают смартфоны и планшеты, считая их электронным хламом и засоряя мир, другие стараются найти применение всему подряд и оказывается, что Android-устройства ещё вполне себе могут оказаться полезными. Однако порой необходимо реализовать автоматическое включение устройства при подключения к зарядке и вот здесь многие впадают в ступор - ведь замкнуть кнопку включения зачастую недостаточно! В сегодняшнем материале я расскажу свои кейсы запитывания устройств от блоков питания, а также реализацию автовключения на разных чипсетах. Интересно? Тогда добро пожаловать под кат!
❯ Как и зачем?
Вероятно, читатель спросит мол "зачем 10-летние Android устройства могут быть нужны?". И если немного призадуматься, то можно прийти к выводу, что действительно гаджеты прошлых лет могут быть достаточно полезными во многих сферах, причём не только планшеты, но и Android-смартфоны. И помимо реализации чего-то "стандартного" на манер красивых Android-часов с будильником или, например, мультимедиа станции а-ля iPod, есть ещё множество интереснейших кейсов, в которых можно использовать такие устройства. Я лично собрал для себя несколько:
HMI-панель: это умные программируемые дисплейные модули, которые могут выводить ту или иную информацию с микроконтроллеров или любых других устройств на экран. Благодаря 10-дюймовому планшету можно сделать очень удобное переключение режимов работы каких-то устройств, либо сделать показ информации с различных датчиков в помещении в реальном времени. Никто не мешает и в машину такой планшет поставить для сбора информации о двигателе.
У Android-устройств перед классическими HMI-дисплеями есть огромное преимущество: наличие 3D-ускорителя и возможность выводить красивые визуалиации и графики, а также анимацию. В будущем проекте со своей машиной - "ВАЗ 2110", я покажу как использовать планшет в таких целях на практике.
Сбор данных: у микроконтроллеров слишком маленький объем встроенной Flash-памяти, чтобы хранить какие-то большие датасеты и строить из них статистику. Конечно можно подключить MicroSD... но ведь ко всем сразу не будешь по отдельной флэшке подключать, да и MicroSD отнюдь невечные при постоянной перезаписи данных - и здесь приходит на помощь такой планшет. eMMC обычно значительно более выносливая через MicroSD, с неё можно достать данные (при отсутствии шифрования), а мощный процессор планшета вполне может ещё и обрабатывать приходимые данные и куда-то отправлять. Вполне полезно!
Использование как одноплатника: я писал об этом недавно статью. Во многих бюджетных планшетах разведен UART на плате, к которому есть доступ из пользовательского окружения и даже Java-приложений! Таким образом, можно общаться с микроконтроллерами по проводному интерфейсу, или напрямую дергать ножками микроконтроллера реализовав прошивку-прослойку для МК.
Нестандартные применения: ну, тут я просто хотел похвастаться своим проектом с превращением планшета в игровую консоль с помощью внешнего микроконтроллера :)
Так что, как мы с вами видим, устройства прошлых лет отнюдь не бесполезны и при определенной смекалке мы можем им дать вторую жизнь и приспособить для работы на каком-нибудь объекте. Понятное дело что что-то серьёзное на них никто вешать не будет, но например панель заказа нямки в чебуречной или что-то на манер ГУ в машине - почему бы и нет?
Однако порой возникает задача реализовать авто-старт устройства при подключении смартфона к зарядке или вообще реализация автономной схемы питания. Автономная схема питания реализуется относительно легко: порой можно кинуть 5В от блока питания на VBat (плюсовой и минусовой контакт АКБ) напрямую. КП у MediaTek, имеют пороговое напряжение на аккумуляторе до 5.5-5.6В и не выгорают. Но это рискованно, если БП плохой и произойдет скачок - есть шанс того, что окажется пробитой обвязка/КП/ключи (вход со стороны USB обычно защищен от такого). Лучше всего использовать DC-DC преоразователь на ~4.2В с током от 1.5-2А.
А вот с авто-стартом вопрос интереснее. Всё зависит от реализации этой самой кнопки включения и от чипсета: например, на смартфонах Sony с чипами Qualcomm иногда достаточно лишь сдуть кнопку включения и замкнуть её контакты перемычкой: всё будет работать без каких-либо проблем. Но на некоторых смартфонах, зажатая кнопка включения будет уводить устройство в циклический ребут каждые 10 секунд, что может быть неприемлемо.
Несколько месяцев назад, читатель под ником @A1f подогнал мне китайский iPhone 7 Plus на Android - всё как я и люблю :) Девайс был рабочий, однако после того, как читатель отдал его в сервис, у него по каким-то причинам потерялось пару винтов, оказалась сломана кнопка включения на шлейфе, а смартфон не заряжался...
Ну, с зарядкой вопрос я решил быстро: китайские айфоны иногда используют свои "Lighting'и", несовместимые с оригиналом и которые не могут заряжатьоригинальный айфон. Благо в комплекте был пожухлый оригинальный кабель, который я разобрал и припаял всё обратно. Теперь и USB, и зарядка работают нормально!
С кнопкой вопрос был интереснее: хотя найти такую на шлейфе и кинуть с неё перемычки - дело 5 минут, я лёгких путей не искал и решил сделать автостарт при подключении к зарядке - как и на оригинальном айфоне :)
И, как вы уже поняли, просто так поставить перемычку на контакте Power и массу не получится - смартфон будет постоянно уходить в ребут. Поэтому я сдампил загрузчик с помощью SP Flash Tool и начал ковырять его в IDA Pro, благо устройство не требует разблокировки этого самого загручзика. Способ рабочий для многих устройств на MediaTek, в том числе и некоторых 67xx (возможно придется разблокировать загрузчик), а на устройствах с другими чипсетами алгоритм может быть +- похожим, но если нет возможности напрямую вмешаться в загрузчик, можно сделать авто-загрузку патчем boot.img.
❯ Реверсим и патчим
Для реализации автозагрузки, необходимо пропатчить загрузчик. В устройствах на чипсетах MediaTek их два - первый Preloader, который занимается первичной инициализацией периферии и ОЗУ, а второй - lk, который инициализирует дисплей, грузит ядро Linux и передаёт ему управление. В сети уже давно лежат слитый исходный код и Preloader, и lk, так что с их изучением проблем не возникнет, идея общая у всех устройств.
Итак, что-же происходит при включении смартфона? lk определяет так называемый режим загрузки, в зависимости от которого меняется раздел, с которого грузится ядро (boot или recovery), а также параметры передаются ядру (atags). В процессе работы lk и перед загрузкой ядра, перед тем как показать анимацию зарядки, загрузчик проверяет нажата ли кнопка включения - и если да, то быстренько перезагружает устройство в обычный режим.
Да, всё так легко! Таким образом, нам остаётся лишь пропатчить условие с проверкой кнопки включения, дабы смартфон считал что кнопка нажата тогда, когда она по факту не нажата. В IDA Pro, lk загружается с смещением памяти в 0x0, а найти нужную инструкцию нам поможет зацепка в виде отладочной строки. IDA Pro сразу строит все xref'ы и обращения к строкам, так что найти нужные данные не составит труда. Ищем "[%s] PowerKey Pressed in Kernel Charging Mode Before Jumping to Kernel, Reboot Os" и смотрим все обращения к адресу памяти, с которого начинается строка.
Чуть выше метода вызова printf, можно найти наше условие, которое начинается с инструкции CMP R0, #0. Сразу после него идёт инструкция BNE, которая бранчит код и продолжает загрузку системы в режиме "зарядки". Нам остаётся лишь заменить её на NOP в hex-редакторе в той-же IDA Pro и система сразу после попытки включится в режиме зарядки уйдет в ребут и перезагрузится в обычном режиме, будто мы просто включили смартфон с кнопки!
Прошиваем наш новый lk:
И видим, что всё работает! :)
❯ Второй способ
Если возможности пропатчить загрузчик нет, в дело вступает второй способ, заключающийся в патче boot.img - раздела с ядром устройства и ramdisk'ом, в котором содержаться скрипты для инициализации устройства (*.rc). Всё дело в том, что даже при зарядке смартфон загружает ядро Linux, первоначальный рамдиск и в зависимости от режима загрузки запускает либо app_process (главныйй процесс в Android), стартуя загрузку системы, либо специальную программу, которая часто называется charger и находится в /system/bin/ (иногда в самом boot.img).
На смартфонах с разными чипсетами реализация этого способа может сильно отличаться, однако приведу пример с смартфонами Sony Erisson из 2011 года (у меня есть Xperia Play с сломанной кнопкой включения). Там устройство начинает выполнение скрипта init.rc, тот в свою очередь запускает init.semc.rc и на этапе инициализации запускает программу chargemon, которая выводит анимацию зарядки, отключает смартфон, если кабель вытащили и слушает нажатие кнопки включения, продолжая процесс загрузки, если пользвоатель зажал кнопку включения. Соответственно, весь фикс - закомментировать эту строку :)
#exec /system/bin/chargemon
В случае MTK, можно попробовать ещё пропатчить init.rc, дабы он продолжал загрузку системы даже в случае подключения кабеля в режиме зарядки. Способов много, главное проявить смекалку и не бояться разбираться в чём-то непонтяном :)
❯ Заключение
Как видите, ничего сложного в реализации автоматического старта устройства нет. Где-то можно обойтись перемычкой на кнопку включения, где-то патчем boot.img, а где-то и патчем загрузчика. Но тем не менее, это вполне возможно на практике и позволяет делать такие приколюхи, как я со своим китайским айфоном :)
Надеюсь, материал вам был интересен и полезен! Пишите, нужно ли вам было реализовать что-то подобное и как это делали в комментариях!
Друзья, если у вас есть подобные китайчики и вы не разделяете желания пытаться вдохнуть в них жизнь, но выбрасывать их жалко — можете задонатить их мне :) Как сами видите — девайсы попадают в хорошие руки. Из недавнего — я взял нерабочую, утопленную китайскую копию 14 Pro Max из под СЦ в качестве основного смартфона. Также у меня есть канал в Telegram, куда я выкладываю бэкстейджи статей, различные заметки о ремонте, моддинге, программировании и реверс-инжиниринге и свои мысли, а также ссылки на свои новые статьи и видео. Кому интересно — залетайте!
Интересный материал?
Если вы постоянный читатель, смотрите ли вы мой YouTube-канал?
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
Пожалуй, немалая часть моих читателей так или иначе интересуется DIY-тематикой. И в различных самодельных девайсах порой есть необходимость вывести какую-либо информацию на дисплей, будь это текст, графики или даже какая-то анимация! Для разных задач существуют самые разные дисплеи и в сегодняшнем материале я хотел бы систематизировать и собрать подробнейший гайд об использовании дисплеев с нерабочих мобильных телефонов: какие бывают протоколы и шины данных, как читать схемы устройств и определять контроллеры дисплеев, какие дисплеи стандартизированы, а какие придётся реверсить самому и как быть с подсветкой. В практической части статьи мы подключим дисплей используя протокол MIPI DBI к RP2040 с использованием DMA. Интересно? Тогда добро пожаловать в статью!
❯ Виды дисплеев и их протоколы
Пожалуй, ЖК-дисплеи с самого момента их появления стали основным инструментом для вывода информации и взаимодействия с пользователями. Первые ЖК-панели были монохромными и требовали отдельный драйвер, который занимался выводом изображения на экран и формированием необходимых для его работы напряжений.
Сейчас же всё гораздо проще и каждый любитель DIY-электроники может и сам подключить дисплейчик к своему проекту и использовать в необходимых ему целях. Ведь не зря написаны десятки библиотек по типу AdaFruit LCD, которые упрощают задачу программисту и дают ему возможность оперировать готовыми и простыми операциями по типу «вывести линию» или «отрисовать изображение». Однако, готовые библиотеки — это, конечно, здорово, но они не всегда дают понимание о том, как работают такие дисплеи на программном и аппаратном уровне. И первая часть статьи как раз и будет посвящена этому.
Всего в мире дисплейных матриц существует несколько общепринятых аппаратных протоколов. Некоторые из них можно легко использовать в собственных проектов с микроконтроллерами, с другими придется повозиться:
Параллельная шина 8080 — одна из самых простых и понятных шин данных, как в теории, так и на практике. Суть её очень простая: на каждый бит отводится по одной сигнальной линии, плюс две дополнительные линии для сообщения статуса передачи: RD означает запрос чтения, а WR — запрос на запись. Большинство дисплеев использует девятый, неявный бит D/C, который сообщает контроллеру, задаём ли мы номер команды, или уже пишем аргументы для этой команды. Что самое приятное — шина по сути стандартизирована и во многих дисплеях команды на старт записи в видеопамять, а также получение ID-контроллера идентичны. Шина бывает 8-битной и 16-битной (её состояние задаётся битами IM0..IM2 и используется не только для подключения дисплеев, но и микросхем параллельной флэш-памяти, ОЗУ и т. д. Такие шины используются в дисплеях с разрешением до 480x320.
SPI — шина, которая наверняка знакома большинству моих читателей. Достаточно простая — у нас есть две сигнальные линии с входным (MISO) и выходным (MOSI) битом, плюс сигнал тактирования, который согласовывает передачу данных. Таким образом, шина получается полнодуплексной. Фактически, каждый байт передаётся по одному биту через одну сигнальную линию, что, по сравнению с 8080, заставляет повышать тактовую частоту контроллера SPI, но при этом занимает гораздо меньше пинов самого МК или процессора. В программном плане, большинство дисплеев представленных в различных интернет-магазинах полностью совместимы с дисплеями 8080, ведь SPI — просто один из режимов работы. Единственный нюанс — из SPI дисплея не всегда можно вычитать ID-контроллера и вообще что-либо читать из регистров дисплея.
I2C — относительно редко используемая шина для дисплеев из-за её невысокой производительности, однако, тем не менее, очень подходящая для МК (благодаря использованию только двух сигнальных линий — SDA для данных и SCL для тактирования. Даже чипселект здесь программный благодаря тому, что каждое устройство имеет собственный адрес!), однако её можно найти в дисплеях некоторых телефонов из самого начала 2000-х годов.
TTL/параллельный RGB — тут, в общем-то, меня упрекали пару раз из-за того, что я продолжаю называть её TTL, но так сложилось исторически — даже в даташитах эту шину называют именно так. С логической точки зрения она очень простая: у нас есть 16/24 сигнальные линии, где 5 (или 8) бит используются для красного и синего канала и 6 (или опять же 8) бит используются для зеленого цвета (т. е. в 16-битном цвете у нас RGB565, а в 24-битном — RGB888). К ним идут сигналы HSYNC для горизонтальной синхронизации и VSYNC для вертикальной. Вообще, необязательно использовать все сигнальные линии предоставляемые дисплеем — можно использовать, например, RGB332 и использовать всего 8 сигнальных линий. Однако для отображения картинки, необходимо строго соблюдать тайминги синхронизации, иначе дисплей будет просто показывать белый цвет. Помимо цифрового варианта, бывает также аналоговый, очень похожий на телевизионный RGB или VGA. Такие дисплеи обычно используются для матриц до 1024x768 включительно.
MIPI DSI — протокол, используемый для дисплеев высокого разрешения — от 480x800 и выше, его можно встретить в большинстве современных смартфонов и планшетов. Кроме того, такие дисплеи используют относительно мало пинов — по два на каждый канал LVDS (обычно в смартфоне около двух-четырех каналов) + две сигнальные линии на тактирование. Звучит всё хорошо? Как-бы не так: протокол дифференциальный и на каждый канал (т. е. логический бит) приходится по две сигнальные линии — одна с положительная, а вторая отрицательная. Затем одна вычитается из другой и получается окончательный сигнал, а сделано это для уменьшения помех от передачи данных по нескольким линиям с очень высокой тактовой частотой без увеличения битности шины.
LVDS/eDP — Протоколы, используемые в матрицах ноутбуков, телевизоров и иногда планшетов. На физическом уровне близки к DSI, на программном — если честно, не знаю, но наслышан о некой стандартизации и высоком уровне совместимости. Даже «неродные» ноутбучные матрицы вполне «заводятся», максимум после перепрошивки родной EEPROM, даже если дисплей другого разрешения!
В списке выше, мы рассмотрели несколько популярных аппаратных шин для дисплеев. В данной статье, мы разберемся в программных особенностях таких дисплеев и узнаем, где взять по дисплею одного из следующих типов: SPI, I2C, а также 8080.
❯ Виды дисплеев и их протоколы
Пожалуй, писать статью, где были бы только готовые примеры без объяснения принципов работы «под капотом» было бы плохим тоном. Поэтому предлагаю немного разобраться в системе команд для самых распространенных контроллеров дисплеев в наше время.
У рассматриваемых нами дисплеев есть собственная видеопамять, благодаря чему нет необходимости соблюдать тайминги, а также общий набор команд (или аппаратных регистров), которые мы можем записывать и тем самым менять поведение дисплея. Если мы просто подадим питание на дисплей и попытаемся что-то вывести — у нас ничего не выйдет, поскольку при каждом аппаратном RESET'е, состояние большинства регистров, кроме SleepOn и PowerOn не определено и может содержать в себе любой «мусор». Для корректной работы дисплея, нам необходимо послать определенный набор команд, называемый инициализацией, который установит настройки драйвера дисплея, такие как контраст, параметры цветности, направление развертки изображения из VRAM и т. д. Пожалуй, стоит сразу отметить, что некоторые люди называют регистры дисплея командами — это означает одно и тоже!
Пример инициализации. На самом деле, не все люди делают такую простыню из вывозов функций чтения/записи регистров дисплея, поскольку это кушает драгоценный ROM. На AVR, например, команды инициализации можно хранить в ROM и читать из PROGMEM.
Если дисплей инициализирован неправильно, то мы можем наблюдать некорректную развертку, артефакты на дисплее и полосы: если вы когда-нибудь прошивали смартфоны прошивками других ревизий, то могли замечать подобный эффект сами.
Набор команд для контроллеров дисплеев частично стандартизирован спецификацией MIPI DBI, которая описывает и закрепляет некоторые конкретные адреса регистров, общие для всех контроллеров дисплея. К ним относится, например, установка «окна» для записи (0x2B и 0x2A), sleepout (0x11) и некоторые другие. Проприетарными командами остаются настройки питания, развертки, контраста и самого драйвера дисплея. Ну и всяческие LUT, а также палитровые режимы (если они есть) тоже проприетарные.
Пример одной из таких стандартизированных команд:
Почти во всех дисплеях есть разделение отправляемых байтов на команду (или выборка номера регистра для чтения/записи) и на данные. Как обработать текущий байт определяет отдельный пин (или бит, в зависимости от конфигурации дисплея), называемый D/C (Data/Command), иногда также можно встретить названиеRS. Обычно, при записи команды, D/C должен быть на низком уровне, при записи данных, соответственно, на высоком. Суть простая: записываем номер команды (или регистра) при низком D/C, а затем дописываем необходимые аргументы (или конфигурацию регистра) при высоком уровне D/C. Примерно так:
Касательно сброса, то в дисплеях обычно существуют два вида этого процесса: аппаратный сброс через соответствующий пин и программный с помощью специальной команды. Пин RESET никогда нельзя оставлять в «воздухе» (т. е. не подключенным) в надежде что «да состояние пинов МК после ресета известно, мусора на шине явно не будет». Мусора может и не будет, а вот дисплей упадет в вечный ресет, поскольку ожидает перехода сигнала RESET в высокий уровень. Тоже самое касается и пина CS, отвечающий за выбор устройства на шине. Если вам не нужен CS и у вас висит только одно устройство на шине — просто притяните его к массе. Некоторые контроллеры (например, ILI9325) адекватно реагируют на CS «в воздухе», некоторые — нет. Только после того, как RESET оказался на высоком уровне, дисплей начнёт принимать команды:
Переходим конкретно в выводу данных. Для начала вывода изображения на дисплей, нам необходимо выполнить команду 0x2C, которая переведет контроллер дисплея в режим записи данных в видеопамять. После этого, нам остаётся лишь установить высокий уровень на пине D/C и просто слать непрерывный поток пикселей. Контроллер дисплея сам инкрементирует координаты на дисплее и после того, как координаты выйдут за границы нужной области, дисплей сам их переведет в изначальные. Таким образом, достаточно лишь один раз проинициализировать дисплей и просто гонять в него данные, например, с помощью DMA.
Всё просто и понятно :)
❯ Дисплеи с шиной 8080
Пожалуй, подобные дисплеи найти проще всего, поскольку они использовались в большинстве кнопочных телефонов из нулевых. Такие экранчики можно встретить во многих моделях Nokia, Samsung, LG, Fly, Sony Ericsson и большинстве китайских телефонов. С поиском распиновки и разводкой таких дисплеев всё относительно просто и одновременно сложно: на некоторые модели телефонов (например, почти на все Nokia) можно свободно найти схему в гугле и узнать распиновку коннектора дисплея… однако этот коннектор сначала надо сдуть и развести на breakout-плате, или под микроскопом вывести перемычки. В некоторых случаях (например, Siemens S-серии), дисплей просто прижимался к контактам на плате, а сами контакты имели более чем паябельный шаг.
Из схемы на Nokia N70. Этот дисплей применялся во многих Symbian-смартфонах Nokia тех лет: N-Gage/N-Gage QD, N70, N72, 6600 и некоторых других.
Но особо удобными можно считать дисплеи с паябельными шлейфами с большим шагом пинов — такие можно встретить в некоторых телефонах Samsung и большинстве китайских телефонов. Пытливый читатель спросит «так это ж китаец, где ты на него схему будешь искать?». И вот тут, китайские производители нас приятно порадуют, поскольку за редким исключением, такие дисплеи имеют стандартизированную распиновку: лично мне известны матрицы 37 Pin, 39 Pin и 44 Pin. Как найти для них распиновку? Пишем на «алике» или «таобао» 37 pin lcd tft и смотрим: в описании продавец частенько прилагает распиновку (правда учтите, что 37 pin не имеет пинов IM для настройки ширины шины, а 16-битный интерфейс может быть слишком прожорилвый по числу пинов):
В случае с китайцами, иногда можно найти и схему (нажимайте на зеленую стрелку) на устройство: например, почти на все модели Fly схемы лежат в свободном доступе, где почти всегда можно найти распиновку дисплея. Иногда производитель даже выводит тестпоинты на все сигнальные линии и дисплей с тачскрином можно использовать, не выпаивая его с платы!
Распиновка на Fly IQ239. На нижней части изображения, вы можете увидеть, что такие, безусловно, здоровенные дисплеи можно купить за копейки и сейчас :)
Но задумывались ли вы когда-нибудь, откуда на тачскринах в дисплеях с «али» взялись кнопки «домой», «сообщения», «телефон»? Это ведь те самые дисплеи, которые использовались в «ноклах», просто припаянные к удобной плате! :) Кроме того, на китайские дисплеи без проблем можно найти даташит: обычно они используют контроллеры от ST или ILI, в зависимости от разрешения дисплея.
Концептуально, аппаратная реализация протокола одновременно простая и понятна любому: программа устанавливает состояние каждого бита передаваемого байта на сигнальных линиях D0..D7 (либо D00..D15, если шина у нас 16-битная), а затем просто «дёргает» линию RD (Read или чтение), либо WR (Write или запись) по переходу из низкого уровня в высокий, благодаря чему контроллер дисплея понимает, что байт (или слово в случае 16-битного интерфейса) можно «забирать» с шины. По переходу из высокого уровня в низкий, контроллер снова переходит в режим ожидания следующего байта с шины.
Где взять такие дисплейчики? Да почти везде! Но лучше всего брать дисплеи с китайчиков, которые можно развести на вот таких breakout-платах, которые можно заказать на алике за пару сотен рублей.
Обратите внимание на то, как по свински припаивают подсветку на некоторых дисплеях. И это завод! Лучше сразу прозвоните прежде чем подавать питание. Я, вот, забыл, понадеялся на производителя и по итогу сжёг подсветку :(
Другой вопрос, где искать на них информацию? Помимо схем, можно просто поискать на алике «37 pin lcd tft», «39 pin tft lcd», «24 pin tft lcd» и т. п. Обычно продавцы сами выкладывают распиновку и даже прикладывают ID контроллера дисплея. Поскольку иногда различия в распиновках всё же попадаются, обращайте внимание на то, куда у вас идут дорожки от подсветки и от резистивного тачскрина (если есть), а также вызванивайте все пины с массой — это поможет подобрать правильную распиновку без логического анализатора. Вот, например, дисплейчик из китайской нерабочей реплики Nokia 130 с здоровым 2.4" дисплеем… казалось бы, вообще не понятно что за дисплей, однако воспользовавшись смекалкой, мы находим его распиновку!
❯ SPI-дисплеи
SPI-дисплеи в телефонах встречались относительно редко. В основном, подобные дисплейчики можно было найти в моделях начала 2000х годов: сименсах, моторолах, ранних сонериках T-серии и Nokia на S40. Иногда SPI-дисплеи можно встретить в современных кнопочных телефонах — обычно они имеют шлейф с менее чем 15 пинами, как некоторые модели Fly. Обычно контроллер дисплея поддерживал сразу несколько аппаратных шин, а производитель телефона ещё на этапе установки шлейфа к контроллеру дисплея замыкал необходимые IM-пины выбирая необходимую шину, поэтому программный протокол фактически идентичен дисплеям с шиной 8080.
Несомненным плюсом SPI-дисплеев можно назвать малое число пинов для работы с матрицей: достаточно всего два (плюс сигнал D/C, если дисплей не 9-битный), если повесить RESET на VIO, либо три (четыре), если хотите управлять аппаратным RESET вручную. Но есть и, в некоторой степени, минусы: например, не все микроконтроллеры умеют работать в 9-битном режиме и возможно последний бит придётся досылать «ногодрыгом» (что ломает любую возможность реализации DMA).
Многие дисплеи с этим интерфейсом задокументированы ещё в начале 2000х годов на известных форумах и сайтах, таких как VRTP, Радиокот и easyelectronics, поэтому проблем с их подключением не возникнет даже у новичка. Даже такой крутой и уважаемый дядька, как @DIHALT, когда-то писал полезный материал об использовании FSMC в STM32.
Достать их новыми можно и сейчас: различные магазины запчастей для телефонов бывают продают их по 20-30-40 рублей… Я недавно себе целую коробочку накупил, в том числе и просто для ремонта смартфонов для будущих статей :)
❯ I2C-дисплеи
Дисплеи с такой шиной — настоящая редкость и обычно попадались в телефонах самого начала нулевых годов с низким разрешением дисплея. Из известных мне — Ericsson'ы и ранние Sony Ericsson T-серии, ODM Motorola (головастики например) и… пожалуй всё. Казалось бы, разве I2C может быть полезен для работы с дисплеями, где требуется активный вывод графики? Ведь он совсем медленный! Однако, даже он может пригодится для некоторых проектов, а в большинстве МК частенько попадается аппаратный TWI.
Кроме того, I2C дисплейчики удобно отлаживать: благодаря тому, что периферийное устройство должно отрапортовать ACK (состояние успешности получения байта) мастер-устройству, можно сразу определить обрыв линий до дисплея. Но какой-то конкретной информации по ним я не смогу написать — они все совсем разные :( Правда, полезным линком поделюсь, ребята с форума VRTP собрали хорошую таблицу с различными контроллерами дисплеев, где бывают и i2c!
❯ Подсветка
Отдельного радела стоит тема подсветки дисплеев. По первой может показаться, что тут всё просто: современным дисплеями достаточно 5В, а на старых можно замерить напряжение бустера на живом девайсе и смастерить свой DC-DC повышающий преобразователь, или взять, например, уже готовый драйвер, как известный в определенных кругах LTYN. На самом деле и тут есть свои нюансы.
Итак, каким образом реализована подсветка в том или ином устройстве? Обычно её реализация заключается в последовательном соединении двух и более светодиодов, которые формируют небольшую ленту под рассеивающей плёнкой. На современных китайских дисплейчиках, для работы в полную яркость достаточно всего лишь 5В источника питания + токоограничивающего резистора. Но что самое приятное, подсветка в таких дисплеях способна работать и при 3.3В, пусть менее ярко, но всё равно вполне читабельно.
Если вы делаете портативное маломощное устройство, работающее от одного Li-Ion аккумулятора, то достаточно лишь пустить 3.3В с линейного стабилизатора, который формирует напряжение VSYS для микроконтроллера. Таким образом, у вас будет стабильная подсветка среднего уровня яркости. В качестве альтернативного «бомж» варианта, когда нет возможности собрать нормальный драйвер подсветки, можно попробовать подключить светодиоды напрямую к АКБ, но при разряде дисплей будет потихоньку «тухнуть». Ещё один «бомж» вариант — разобрать дисплейный модуль, порезать дорожки на ленте и соединить пару светодиодов параллельно, выведя их через отверстие, откуда выходит шлейф дисплея, однако в таком случае, потребление подсветки заметно увеличится.
Правильным выходом будет взять с того-же телефона бустер подсветки с индуктивностью и иной необходимой обвязкой, и собрать бустер самому. Особой популярностью когда-то пользовались вышеупомянутые LTYN из телефонов Samsung (это маркировка известного драйвера LT1937). Уровнем подсветки на подобных бустерах телефоны управляют с помощью встроенного ШИМ-контроллера, чем можете воспользоваться и вы :)
❯ Запускаем дисплейчик на практике
В первой части статьи, я постарался ввести вас в курс дела и кратко рассказать о том, как работают такие дисплейчики «под капотом». Как видите — с теоретической точки зрения, ничего сложного нет: пересылаем данные на дисплей, да вовремя дёргаем пин D/C. Но какого же это на практике?
К сожалению, у меня на руках не нашлось подходящего дисплейчика от мобильного телефона (я ведь брал новые по уценке, не все заработали нормально), поэтому в качестве примера работы мы возьмём фактически такой же «китайский» дисплей с алика. Но будьте уверены — с большинством дисплеев, принцип работы будет идентичен (если мы говорим о дисплеях 2005г.в и моложе).
В качестве МК, мы возьмём мой любимый RP2040, который, по моему мнению, незаслуженно обделен вниманием. Время от времени я делаю всякие прикольные девайсы на базе этого МК, поэтому крайне рекомендую его всем моим читателям :)
Давайте же перейдем к практической части статьи! Обычно при создании проекта, я просто клонирую с гита RPi сэмплы с уже готовыми файлами CMake, беру hello world, конфигурирую CMakeLists.txt и пишу свою программу. На малинке пока что нет такого удобного способа создания проекта, как idf.py create-project :) Само собой, для удобства отладки я всегда включаю встроенную в чипсет эмуляцию UART через USB.
if (TARGET tinyusb_device) add_executable(hello_usb main.cpp )
# pull in common dependencies target_link_libraries(hello_usb pico_stdlib hardware_spi)
# create map/bin/hex/uf2 file etc. pico_add_extra_outputs(hello_usb)
# add url via pico_set_program_url example_auto_set_url(hello_usb) elseif(PICO_ON_DEVICE) message(WARNING "not building hello_usb because TinyUSB submodule is not initialized in the SDK") endif()
И инициализирую USB-стек и биндинги stdout к нему:
stdio_init_all(); sleep_ms(1000);
Задержка здесь важна, иначе девайс отказывается определятся в системе. Переходим, собственно, к разводке дисплея. Для работы нам достаточно лишь питания, подсветки, общей массы и четырёх сигнальных линий: MOSI, CLK, DC, RESET. На CS я обычно ставлю перемычку с массой, т. к обычно не вешаю что-то ещё на одну шину с дисплеем.
Переходим к инициализации дисплея. Наш экранчик работает на базе контроллера ST7735R и имеет разрешение 128x160. Сначала, назначаем функции для пинов и дёргаем RESET:
Весьма негусто скажете вы? Ну, с минорными изменениями, здесь заработает дисплейчик любого разрешения, даже 480x320! Переходим к фактической инициализации:
Прошиваем наш МК и смотрим что получилось. Видим шум на экране? Значит дисплей инициализирован верно!
После инициализации дисплея, мы можем выводить на него данные! Дабы дать возможность процессору заниматься другими делами во время передачи картинки на дисплей, мы настроим один из DMA-каналов. DMA-контроллер занимается пересылкой данных из ОЗУ в другой участок ОЗУ (аппаратный memcpy) или периферию. Как раз для второго случая, т. е. пересылки данных в контроллер SPI, мы и будем использовать DMA!
Аллокейтим фреймбуфер, куда мы будем выводить нашу картинку и настраивает DMA-канал:
Переходим к выводу изображения на дисплей. Для того, чтобы просто установить цвет пикселя в любых координатах экрана, достаточно лишь посчитать смещение от начала указателя на фреймбуфер к определенным координатам экрана. Формула очень простая и понятная: ширина дисплея * Y-координата + x координата и результат предыдущих операций помноженный на число байт в одном пикселе.
__inline void pixelAt(short x, short y, short color) { if(x < 0 || y < 0 || x >= LCM_WIDTH || y >= LCM_HEIGHT) return;
В функции есть валидация границ дисплея. Если уверены, что не зайдете за границы дисплея — можете убрать проверку, будет шустрее.
Теперь для вывода картинки, нам достаточно лишь скопировать изначальное изображение в наш фреймбуфер и попросить DMA-канал вывести изображение на дисплей. Для прозрачных картинок без альфа-канала (т. е. с цветовым ключом), функция будет выглядеть так:
Можно сделать чуть комплекснее, добавив альфа-блендинг и аффинные трансформации (возможность поворота и скейла картинок), но пока-что такой задачи не стоит. Ну что, всё очень просто и понятно? :) Пример прошивки можно найти на моём GitHub!
Производительность такого способ на RP2040 можно увидеть вот в этом видосе (на Пикабу не смог залить из-за ограничения на число медиа-элементов). Обратите внимание, что подход предложенный выше больше подходит именно для динамического вывода изображения без dirty-регионов. Он подойдет для игровых консолей, камер, анимаций или устройств с выводом динамической информации по типу осциллографов. Если вам нужно обновлять картинку реже, например, если вы делаете умные часы с плеером, то нет необходимости занимать довольно большой объем ОЗУ фреймбуфером, ведь вы можете писать напрямую в видеопамять. Тут уже решать в зависимости от конкретной ситуации именно вам :)
❯ Заключение
Вот мы с вами и систематизировали информацию о том, как использовать дисплеи с мобильных телефонов в своих проектах. Надеюсь, информация была достаточно полезной для вас! Однако, у меня к вам просьба: пожалуйста, не «дербаньте» рабочие девайсы «на запчасти» :( Это будет не очень гуманно по отношению к нашему «технобалдежу», где мы наоборот стараемся найти применение стареньким девайсам :)
Был ли для вас материал полезен? Пишите в комментариях.
Полезный материал?
Какие дисплейчики подключали?
❯ Важное объявление для читателей касательно будущей рубрики
Друзья! Я, как и многие мои читатели, помимо программирования и железа обожаю тачки! Особенно те тачки, где что-то нужно доделывать самому… и речь, конечно-же, о ТАЗах! Я долго думал, но всё же решился: сейчас я коплю на будущий интересный проект, связанный с ультрабюджетным электронным дооснащением автомобиля, который старше меня в полтора раза — скорее всего, речь пойдет о ВАЗ 2108/2109/21099, причём не исключено что карбюраторной! В планах довольно крутой проект, заключающийся в следующем: мы спроектируем очень дешевый бортовой компьютер (т.е панель) для управления автомобилем на базе дешевого Б/У планшета за пару сотен рублей. Планшет будет связан с управляющим МК через UART (о подобной коммуникации через хардварные протоколы я уже писал целых две статьи: сам себе Linux смартфон, превращаем планшет с нерабочим тачскрином в игровую консоль), и с планшета мы сможем не только управлять основными системами машины (стеклоподъемники, центральный замок и соленоид багажника), но и собирать и пытаться примерно посчитать некоторую информацию о расходе, километраже и стабильности работы двигателя на карбюраторной(!) машине без электронных систем с завода!
Если вдруг двигатель машины будет живенький и заводиться с полтычка, то может и удаленный прогрев постараюсь реализовать :)
В наши задачи будет входить не только проектирование аппаратной части такого оснащения, но и разработка симпатичного интерфейса для самой панели, дабы было не хуже чем в BMW :D Всеми схемами, исходным кодом и инструкциями я буду делится с вами в каждой статье и, как обычно, расскажу обо всех деталях реализации во всех подробностях! У меня уже есть некоторые идеи и наработки. Собственно, почему-б и не попробовать? Будет новая рубрика в блоге: апгрейд автомобилей глазами электронщика и прожженного программера.
Фото не моё, из интернета
Если вам нравятся мои статьи, вас интересует развитие такой рубрики и у вас есть желание и возможность — можете помочь проекту копеечкой с помощью формы доната ниже. Пикабу позволяет остаться анонимным и донатить даже без регистрации. Сейчас у меня есть 40 тысяч рублей личных накоплений, на покупку самой машины планирую выделить 70-80 тысяч рублей (я живу в Краснодарском крае, так что здесь ещё есть шансы найти что-то +- живое за такие деньги), так что остаётся собрать около 30-35 тысяч рублей. За каждую копейку я готов отчитаться (по факту покупки машины я сделаю пост с фотографиями авто, ДКП, а также оглашу фронт будущих работ и сразу начну заниматься проектом).
Для этого понадобится кулон (открывающийся), микроконтроллер(attiny13), ртутный замыкатель(3мм), ползунковый переключатель, текстолит односторонний, светодиод ws2812b.
Вырезаем из текстолита форму сердца в соответствии с размером внутренней части кулона. Рисуем дорожки (например лаком для ногтей).
Берем емкость с водой,смешиваем лимонную кислоту, таблетки гидроперита, добавляем щепотку соли. Травим плату. Отмываем лак, лудим дорожки. Для батарейного отсека надо подобрать металлические пластины, я приспособил клеммы от зарядки для шуруповерта.
Отрезаем пластины по размеру и гнем под углом 90 градусов, обрабатываем края, припаиваем на плату к площадкам. Расстояние между клеммами должно соответствовать трем батарейкам LR41. Затем припаиваем переключатель, микроконтроллер(прошитый, конечно же)), ртутный замыкатель, проводки вставленные с другой стороны в отверстия.
С другой стороны платы приклеиваем светодиод ws2812b припаиваем к нему проводки. Вклеиваем в кулон,там где отверстие в виде сердца, кусочек рассеивателя. Можно добавить красных ниток в внутрь кулона и покрасить плату красным лаком. Вклеиваем плату в кулон, вставляем батарейки в термоусадку, помещаем в батарейный отсек.
Подарок для жены готов!))))))
При переворачивании кулона меняется эффект.
Прошивку не выложил т.к. считаю что она кривая))).
Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с SD-флэшек, или программы, написанные другими пользователями с помощью SDK для вашего устройства. Тема компиляторов и кодогенерации достаточно сложная: чтобы просто загрузить ELF или EXE (PE) программу, вам нужно досконально разбираться в особенностях вашей архитектуры: что такое ABI, релокации, GOT, отличие -fPIE от -fPIC, как писать скрипты для ld и т. п. Недавно я копал SDK для первых версий Symbian и основываясь на решениях из этой ОС понял, каким образом можно сделать крайне «дешевую» загрузку любого нативного кода практически на любом микроконтроллере, совершенно не вникая в особенности кодогенерации под неё! Сегодня мы с вами: узнаем, что происходит в процессе загрузки программы ядром Linux, рассмотрим концепцию, предложенную Symbian Foundation и реализуем её на практике для относительно малоизвестной архитектуры — XTensa (хотя она используется в ESP32, детали её реализации «под капотом» для многих остаются загадкой). Интересно? Тогда добро пожаловать под кат!
❯ Как это работает?
Думаю, для многих моих читателей реализация процесса загрузки exe-программ и dll-библиотек в память процесса оставалась эдаким чёрным ящиком, в детали реализации которого вдаваться не нужно. Отчасти это так и есть: современные ОС разруливают процесс загрузки бинарников в память сами, не требуя от программиста вообще ничего, даже понимания того, куда будет загружена его библиотека или программа.
Давайте для общего понимания вкратце разберемся, как происходит загрузка программ в Windows/Linux:
1. Система создаёт процесс и загружает в память программы секции из ELF/PE. Обычные программы для своей работы используют 3 секции: .text (код), .data (не-инициализированный сегмент памяти для глобальных переменных), .bss (сегмент памяти для инициализированных переменных). Каждому процессу выделяется собственное адресное пространство, называемое виртуальной памятью, которое не позволяет программе испортить память ядра, а также позволяет не зависеть от разметки физической памяти на выполняющей машине. Концепцию виртуальной памяти реализует специальной модуль в процессоре, называемый MMU.
2. Если бы наши программы не использовали никаких зависимостей в виде динамических библиотек, то на этом процесс загрузки можно было бы закончить: каждая программа имеет свой адрес загрузки, относительно которого линкер строит связи между обращениями к коду/данным программы. Фактически, для самых простых программ линкеру остаётся лишь прибавить адрес загрузки программы (например, 0x100) к каждому абсолютному обращению к памяти. Однако современные программы используют десятки библиотек и для всех предусмотреть собственный адрес загрузки не получится: кто-то где-то всё равно будет пересекаться и вероятно, портить память. Кроме того, современные стандарты безопасности в Linux рекомендуют использовать позиционно-независимый код, дабы использовать преимущества ASLR (Address Space Layout Randomization, или простыми словами возможность загрузить программу в случайное место в памяти, дабы некоторые уязвимости, завязанные на фиксированном адресе загрузки программы перестали работать).
3. Поэтому для решения этой проблемы придуман т. н. динамический линкер, который уже на этапе загрузки программы или библиотеки патчит программу так, чтобы её можно было загрузить в любой участок памяти. Для этого используются данные, полученные от обычного линкера а этапе компиляции программы: помимо .text, .data и .bss, линкер создаёт секции .rel и .rel-plt, которые называются релокациями. Если объяснять совсем условно, то релокации — это просто запись вида «какой абсолютный адрес в коде программы нужно пропатчить» -> «на какое смещение его пропатчить». Самая простая релокация выглядит вот так:
Где по итогу:
.rel-plt же служит для резолвинга вызовов к dll/so: изначально программа ссылается на заранее определенные в процессе компиляции символы, которые уже в процессе загрузки патчатся на физические адреса функций из загруженной библиотеки.
И казалось бы — всё очень просто, пока в дело не вступают GOT (Global Offset Table — глобальная таблица смещений) и особенности реализации конкретного ABI. И ладно бы x86 или ARM, там всё разжевано и понятно, однако на других архитектурах начинаются проблемы и не всегда очевидно что и где за что отвечает.
А ведь чаще всего нужно просто загрузить небольшую программу, которой не нужны комплексные загрузчики: немного кода, немного данных и всё. И тут у нас есть три выхода:
Писать полноценный загрузчик ELF-бинарников. ELF может оказаться громоздким для некоторых окружений и его реализация может оказаться тривиальной не для всех.
Зарезервировать определенный сегмент в памяти (пусть с 0xFFF по 0xFFFF) и скомпилировать нашу программу с адресом загрузки 0xFFF с параметром -fno-pic. В таком случае, линкер сгенерирует обращения к памяти по абсолютным адресам — если переменная лежит по адресу 0xFFF, то программа будет обращаться сразу к этому адресу памяти, без необходимости что либо динамически линковать. Именно такой подход использовался во времена ZX Spectrum, Commodore 64 и MS-DOS (однако там роль «виртуальной памяти» выполняла такая особенность 8086, как сегменты). У такого подхода есть и минусы: относительная невозможность загрузки сразу нескольких программ одновременно, зарезервированное пространство линейно отъест небольшой кусок памяти у основной прошивки, нет возможности динамической аллокации секций. Зато такой код теоретически будет работать быстрее, чем PIC.
Проблемы реализации такого способа: иногда нужно лезть в систему сборки основной прошивки и патчить скрипт линкера так, чтобы он не трогал определенный регион памяти. В случае esp32, например, это требует патча в сам SDK и возможного «откола» от мейнлайн дистрибутива.
Использовать программу с относительной адресацией, однако без сегментов .bss и .data. Самый простой в реализации способ, который к тому же очень экономичен к памяти, позволяет загружать программу в любое место и пользоваться всеми фишками динамического аллокатора и не требует вмешательств в основную прошивку, кроме примитивного загрузчика программ. Именно его я и предлагаю рассмотреть подробнее.
Недавно мы сидели в чате ELF-сцены (разработка нативных программ под телефоны Siemens, Sony Ericsson, Motorola и LG с помощью хаков) и думали, как же можно реализовать загрузчик сторонних программ на практически неизвестных платформах. Кто-то предлагал взять ELF под основу — однако с его реализацией под некоторые платформы есть трудности, а кто-то предлагал писать «бинлоадер» — самопальный формат бинарников, который получается из, например, тех же эльфов.
В это же время я копал SDK для Symbian и хорошо помнил, что в прикладных приложениях для этой ОС нет поддержки глобальных переменных вообще. Да, сегмент .data и .bss полностью отсутствует — переменные предлагается хранить в структурах. Почему так сделано? Всё дело в том, что каждая программа в Symbian — это dll-библиотека, которую загружает EKA и создаёт экземпляр CApaApplication. И дабы была возможность загрузить dll один раз для всех программ (что справедливо для системных библиотек), ребята полностью выкинули возможность использования любых глобальных переменных. А ведь идея интересная!
Однако в таком подходе есть несколько серьезных ограничений:
Отсутствие глобальных переменных может стать проблемой при портированиии уже существующего софта, хотя вашим программам ничего не мешает передавать в каждую функцию структуру с глобальным стейтом, который можно при необходимости изменять. Кроме того, нет ограничений на использование C++ (за исключением необходимости ручной реализации new/delete и отсутствием исключений).
Отсутствие преинициализированных данных. Вот это уже может стать относительно серьёзной проблемой, у которой, тем не менее, есть свои обходные решения. Например если вы храните команды для инициализации дисплея в таблице, или какие-либо калибровочные данные — вы не сможете их объявить, просто используя инициализаторы в C. Тоже самое касается и строковых литерал. Тут есть два варианта: часть таблиц можно вынести на стек (если эти самые таблицы достаточно маленькие), либо подгружать необходимые данные из бинарника с помощью основной прошивки (например, LoadString и т. п.).
Давайте же на практике посмотрим, имеет ли право на жизнь такой подход!
❯ Практическая реализация
Формат нашего бинарника будет до безобразия прост: небольшой заголовок в начале файла и просто сырой дамп сегмента .text, который можно экспортировать из полученного elf даже без необходимости писать скрипт для линкера. При этом нужно учесть, что ESP32 — это микроконтроллер частично Гарвардской архитектуры, т. е. шина данных и кода у него расположены отдельно. Однако у чипа есть полноценный MMU, который позволяет маппить регионы физической памяти в виртуальную память, чем мы и воспользуемся в итоге!
Заголовок нашего бинарника будет выглядеть вот так:
Программа общается с основной прошивкой посредством псевдо-syscall'ов: функции, которая в качестве первого аргумента ожидает номер нужной службы и один 32х-битный указатель для описания структуры с параметрами. Реализация syscall'ов — одна из самых простых и неприхотливых с точки зрения обратной совместимости с будущими прошивками.
Концептуально всё очень просто: GetGlobalStateSize сообщает нашему загрузчику размер структуры для хранения глобального стейта, в то время как Start уже фактически заменяет main() в нашей программе. Необходимости в crt0 нет, поскольку весь необходимый инит выполняет бутлоадер ESP32. Впрочем, при желании вы можете выделить отдельный стек для вашей программы — это повысит надежность, если выполняемая программа удумает испортить стек.
-fno-pic отключает генерацию кода, зависимого от GOT, -nostdlib и -nostartfiles убирает из билда crt0 и stdlib, благодаря чему мы получаем только необходимый код. --section-start задает смещение для загрузки секции .text на 0x0 (в идеале это делать необходимо из скрипта для ld). objcopy скопирует из полученного ELF только необходимую нам секцию .text.
Как же это работает на практике? Давайте дизассемблируем выходной бинарник и посмотрим, что у нас дает на выхлопе cc:
Обратите внимание, что Start вызывает подфункции с помощью инструкции CALLX8, которая в отличии от обычного Immediate-версии CALL8, выполняет переход относительно текущего адреса в PC, благодаря чему переход полностью независим от адреса загрузки программы в памяти. А благодаря тому, что все данные, в том числе и указатель на глобальный стейт передаются через стек, нет необходимости релокейтить сегменты данных.
По итогу всё, что нужно от загрузчика бинарников — это загрузить программу в память для инструкций, выделить память для структуры с стейтом программы и передать управление Start. Всё! Конкретно в случае ESP32, у нас есть два возможных решения задачи загрузки программы в память:
Загрузить программу в IRAM. Такая возможность теоретически есть, однако на практике загрузчик ESP32 устанавливает права только на чтение и выполнение на данный регион памяти. Попытка что-то скопировать туда закончится исключением SIGSEGV. Кроме того, сегмент IRAM относительно небольшой — всего около 200Кб.
Самопрограммирование. Для этого, в esp32 есть два механизма — Partition API и SPI Flash API. Я выбрал Partition API для простоты реализации.
Для нашей прошивки необходимо будет переразметить флэш-память. Для этого запускаем idf.py menuconfig, идём в Partition Table -> Custom partition table CSV. Создаём в папке проекта partitions.csv, куда пишем:
Как видите, ничего сложного в выполнении сторонних программ при условии соблюдении некоторых ограничений нет. Да, в таком подходе есть как серьезные плюсы, так и минусы, однако он делает своё дело и позволяет реализовать запуск игр на кастомных игровых консолях, или сторонних программ на самодельных компьютерах. Ну и конечно же не стоит забывать про плагины! Авось в вашем решении нужна возможность расширения функционала устройства, однако предоставлять исходный код или даже объектные файлы нет возможности — тогда вам может пригодится и такая методика.
Пожалуй, стоит упомянуть ещё один… очень своеобразный метод, который я иногда встречаю при реализации самодельных компьютеров. Люди пишут… эмуляторы 6502/Z80 :) И если такой подход ещё +- применим к ESP32, то в AVR просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?
Полезный материал?
Приходилось ли загружать сторонний код в ваших устройствах?
управление msp430g2210 питание - юсб управление двумя кнопками все цвета, регулировка светимости, таймер 1-4 часа или постоянная работа, память всех этих настроек (энергозависимая)
дизайн - сам вырезание на станке - сам схема, разводка, изготовление платы, пайка - сам программирование - сам
К сожалению, в наше время многие старые, но весьма неплохие по характеристикам гаджеты отправляются напрямую в помойку, и их владельцы не подозревают, что им можно найти применение. Сервер, мультимедийная-станция, да даже просто как TV-приставка — люди в упор не замечают сфер, где старенький планшет мог бы быть полезен. Но как быть, если посвящаешь жизнь портативным гаджетам, кодингу и копанию в железе? Правильно: сделать довольно мощную игровую консоль из старого планшета самому! Сегодня вам расскажу, как я сделал свою портативную приставку из планшета с нерабочим тачскрином, Raspberry Pi Pico и 8 кнопок! За рабочим результатом прячется несколько дней работы: поиск UART на плате, разработка контроллера геймпада на базе RPi Pico, написание приложения-сервиса, которое слушает события и отправляет их в подсистему ввода Linux в обход Android. Интересно? Тогда жду вас под катом!
❯ Мотивация
Прошло уже практически 10 лет с того момента, как у меня появилась моя первая портативная консоль. Несмотря на то, что я был заядлым ПК-игроком, я уже успел посмотреть на PS3 и PSP, но денег на их покупку у меня особо не было, да и к тому времени уже был в наличии Android-планшет. Но к моему 13-летию в 2014 году, когда я ходил и выбирал себе будущий девайс на день рождения, отец и мама решили подарить мне мою первую портативную консоль. Изначально, я уговаривал её купить мне целых два девайса, но бюджет был ограничен 4.000 рублей, а я хотел взять смартфон Fly IQ239 и консоль JXD S601 одновременно:
Однако, увидев здоровую 7-дюймовую консоль в магазине TREC (думаю, жители южной части РФ помнят такой), мама уговорила меня взять именно её, мотивируя это «ну и чего ты будешь тыкаться в этот мелкий экран? Возьми большую». После покупки гаджета, я был доволен: играл какие-то игрушки с ретро-платформ, устанавливал игры на Android, сидел в ВК через Kate Mobile. Что еще нужно было школяру? Однако, планшет прожил у меня недолго: с очередного лага я психанул и ударил по нему кулачком, унеся на тот свет и дисплей и тачскрин. Так консолька и пролежала в подвале около 8 лет. Впрочем, мне продолжали импонировать подобные устройства и в прошлом году я купил и написал про несколько подобных девайсов.
Несколько месяцев назад, мой читатель Кирилл Севостьянов с Хабра прислал мне HTC HD2 в качестве донора и планшет Prestigio PMP7170B3G, который был рабочим, но… у него отказал тачскрин. Я всё думал, чего бы с ним сделать и решил реализовать игровую консольку своими руками из подручных средств. Идея крутилась в голове довольно давно, но реализовал я её только сейчас.
❯ Что нам нужно сделать?
Итак, что должно быть у портативной консоли? Чипсет, дисплей, звук, ОС — это всё нам уже предоставляет планшет. Нам остаётся лишь сделать свой геймпад. Давайте подумаем, что нам будет нужно для того, чтобы его сделать и передавать от него события на планшет:
Контроллер для геймпада: тут нам подойдет практически любой микроконтроллер, который работает от 3.3в. Выбор большой: Arduino Pro Mini 3.3v, ESP32, RPi Pico. Я остановился на последнем: недавно я взял себе две штучки «пощупать» их — и они мне очень понравились!
Физический интерфейс: с планшетом нужно как-то общаться. У нас есть три варианта: USB (не факт, что поддержка преобразователей включена в ядре), UART и SPI/I2C на пятачках тачскрина (потребуют написания драйвера т. к. в android-устройствах нет прямого доступа к SPI/I2C из userland'а). Я остановился на UART: его легко найти на большинстве китайских планшетов, а если не получилось — то на помощь может прийти схема платы.
Программная реализация: как это будет работать? Я решил реализовать геймпад в виде сервиса на Android, который слушает состояния кнопок с UART и «инжектит» события напрямую в драйвер ввода. Таким образом, поддержка нашего геймпада появляется даже в самой системе — можно управлять менюшкой или приложениями как с клавиатуры!
С планом определились, пора начать с программной части: сначала нам обязательно понадобится ROOT-доступ. Его получение на разных девайсах отличается — на prestigio уже был порт CWM и я просто поставил SuperSU. Без ROOT доступа мы не сможем использовать UART!
Теперь нам нужно найти пятачки UART на плате. Разведен он не везде, но в случае устройств на MediaTek — почти всегда, ещё и пятачки подписаны. На моём планшете он нашёлся сразу: был между двух металлических экранов и соответствовал 4-ому каналу UART. Получить к нему доступ можно в /dev/ttyMT3. Я использую ESP32 в качестве UART преобразователя: подпаиваемся к RX/TX, запускаем putty и заходим в adb shell. Определяем бодрейт (скорость) нашего UART порта — на MediaTek он обычно равен 921600, на других чипсетах — 115200. Пытаемся что-то вывести и хоба — мы уже можем «поболтать» с планшетом!
❯ Приложение-сервис
Итак, у нас уже есть доступ к UART и мы можем общаться с планшетом из внешнего мира. Но получить события с кнопок пол дела, нужно их ещё и послать в систему. Для этого есть целых три способа:
InputManager.injectInputEvent — именно этим методом пользуется команда input, которую вы можете использовать через adb. Но увы, он работает только при наличие разрешения INJECT_EVENTS, который доступен только системным приложениям — находятся они в /system/app и подписаны тем же сертификатом, что и остальная прошивка.
Модуль uinput дает возможность создать виртуальное устройство ввода и посылать события из userland'а — т. е. из прикладного приложения. У моего планшета было устройство /dev/uinput, но lsmod показывал, что сам модуль не загружен. Так что отметаем — он есть не везде.
Прямой инжект событий в character устройство — весьма грязный хак, который позволяет инжектить события, не притворяясь системным приложением, но имеет некоторые ограничения. Именно его я и выбрал и о ограничениях ниже.
Сначала нам нужно узнать, какие кнопки поддерживают загруженные устройства ввода в системе. Для этого используем команду getevent -li. Там есть разные устройства ввода, в том числе и тачскрин (если вам нужно симулировать нажатия на экран), мне же подошёл драйвер физических кнопок mtk-kpd. Он занимается обработкой кнопок громкости, включения и т. п. Тут важно обратить внимание на то, что если попытаться послать кнопку, которое устройство не реализует (например пробел), то ничего не произойдет:
Инжект событий я писал на C, т. к. это требовало прямой записи input_event, а в Java прокинул его через Jni. Концепция простая: открываем устройство /dev/input/event2 и посылаем в него события ввода и синхронизации (это обязательно!), которые затем Android читает и обрабатывает:
Основной обработкой занимается сервис, который я реализовал в отдельном потоке: он слушает события с UART и посылает соответствующие изменения состояния через sendKeyEvent. На вход приходят простые сообщения вида:
U L где U/D — нажато, не нажато, а L — однобайтовый идентификатор кнопки. В случае L — это влево, R — вправо и т. п. Вся доступная раскладка хранится в словаре. Причём само чтение из UART реализовано костылем с чтением «чужого» stdout, т. к. android-приложения не умеют сами по себе работать с root правами. В теории, это могло дать неприятный оверхед, но на практике никакого серьезного инпут лага это не создает. Не забываем сделать устройство event записываемым — ставим ему права 777:
Таким образом, если мы отправляем с ПК «D L» — система считает, что мы зажали стрелку влево, а U L — считает что мы отпустили. Но если mtk-kpd поддерживает стрелки и еще некоторые действия без каких либо проблем, то enter в список обрабатываемых кнопок не входит: придется мудрить! И тут нам приходит на помощь механизм трансляции кодов кнопок в действия: они хранятся в специальных файлах .kl в /system/usr/keylayout/. Я назначил DPAD_CENTER на… кнопку регулировки громкости звука! Ну, а почему бы и нет. :) Таким образом можно переназначить уже имеющиеся кнопки громкости на, например, start/select.
❯ Геймпад
После того, как сервис был готов и отлажен, нужно было реализовать хардварную часть проекта — сам геймпад. В качестве контроллера я, как уже говорил, выбрал Raspberry Pi Pico на базе МК RP2040 — бодреньком контроллере с двумя ARM Cortex-M0 ядрами. Стоит копейки, а в отличии от ESP'шек, его SDK не такое перегруженное и выглядит более приближенным к bare-metal.
На данный момент, я решил развести все кнопки на бредборде — макетной плате без пайки, т. к. макеток для пайки у меня под рукой не было. Сделал примитивный геймпад:
Развел на соответствующие GPIO:
И написал примитивную прошивку, которая отслеживает состояние кнопок. В прошивке точно так же есть словарь, задающий ассоциацию между физическими пинами и «виртуальными» кнопками. При нажатии или отжатии кнопки, программа изменяет стейт и отсылает новое состояние планшету.
if(!gpio_get(keys[i].gpio) && !keys[i].pressed && now - keys[i].lastTick > 15500)
{
buf[0] = 'D';
buf[2] = keys[i].key;
puts(buf);
keys[i].lastTick = now;
keys[i].pressed = true;
continue;
}
if(gpio_get(keys[i].gpio) && keys[i].pressed && now - keys[i].lastTick > 15500)
{
buf[0] = 'U';
buf[2] = keys[i].key;
puts(buf);
keys[i].pressed = false;
keys[i].lastTick = now;
}
}
}
}
Собираем всё вместе и тестируем. Хоба, всё работает, мы можем перемещаться по менюшке используя наш геймпад!
А почему бы не попробовать поиграть в какую-нибудь игру? Ну мы же консоль вроде делаем: берём эмулятор NES, биндим кнопки в настройках и наслаждаемся игрой в Марио!
❯ Заключение
Реализация этого проекта заняла у меня не так уж и много времени: всего около 3-х дней работы по вечерам. Вероятно кто-то спросит: «а чего ты просто Bluetooth геймпад не купил?». Так это не прикольно ведь. Гораздо приятнее играть в девайс, к которому ты приложил руку сам. Более того, не у всех старых планшетов есть BT. Обошёлся на данной стадии проект недорого: планшет мне подарили бесплатно (точно также у вас дома может лежать подобный), RPi Pico — 350 рублей, кнопки по 10 рублей/штучка.
В целом, я сам по себе обожаю копаться в различных железках и их софтварной части (вспомнить хотя-бы статью про перекомпиляциюu-boot из вендорских исходников для нонейм консоли), а созидать что-то свое вообще вызывает какие-то нереальные всплески эндорфина — оно и понятно! :)
Однако несмотря на то, что мы уже имеем рабочий «прототип», проект далёк от завершения: я намерен довести его до конца и окончательно перевоплотить старый планшет в автономную игровую консоль (и рассказать об этом во второй части статьи). Для этого мне понадобится распечатать корпус и кнопки на 3D-принтере. К сожалению, у меня в городе ни у кого особо нет 3D-принтеров, поэтому начну копить на Ender 3, а от вас, читателей, с удовольствием почитаю мнение в комментариях и советы касательно выбора принтера!
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать еженедельные статьи про моддинг различных гаджетов!
Для всех поклонников футбола Hisense подготовил крутой конкурс в соцсетях. Попытайте удачу, чтобы получить классный мерч и технику от глобального партнера чемпионата.
А если не любите полагаться на случай и сразу отправляетесь за техникой Hisense, не прячьте далеко чек. Загрузите на сайт и получите подписку на Wink на 3 месяца в подарок.
Дурная голова рукам покоя не даёт… история началась несколько месяцев назад: я увидел на Пикабу забавное видео игры в комнате с пиксельным светодиодным полом и решил сделать подобное для своих детей. За эти месяцы я получил массу удовольствия от процесса разработки и даже заразился идеей масштабирования проекта, но обо всём по порядку! Внимание, ниже будет много фото!
Идея
Идея в целом не уникальна, но я не нашёл в продаже каких-то готовых решений. В том же Китае продаются платформы без обратной связи и без игровых возможностей, у них это называется светодиодный танцевальный пол. Но это всё не то, что я хотел, а значит надо делать самому. Всегда любил работать со светодиодами, это приносит огромное эстетическое удовольствие, и в целом я скучал по работе с электроникой, так что решил сдуть пыль с паяльной станции и прикупить ещё некоторое оборудование.
Пара слов обо мне
Пользуясь случаем, позвольте кратко представиться, так текст будет менее обезличенным.
В жизни меня зовут Анатолием, в прошлом я более 5 лет проработал на крупном заводе инженером-схемотехником-программистом (нужное подчеркнуть), так что присутствует какой-никакой реальный опыт и понимание процесса массового производства электроники, надеюсь ещё пригодится. Последние 5 лет работаю фуллстек разработчиком. Так и решил совместить эти две области в одном проекте.
Меня весьма вдохновляет прорабатывать полный производственный цикл изделия: от разработки схемотехники и написания низкоуровневого ПО на микроконтроллеры до продумывания конструктива и поиска редких метизов для сборки (это когда ты немного ошибся в 3D модели крепления датчика, а их уже напечатано более 320 штук *facepalm*).
пиксельный RGB-светодиодный интерактивный игровой пол с адекватным временем реакции на нажатие;
настенные кнопки для разнообразия игрового процесса;
табло с информацией по игре (название игры, общее время, время этапа, очки, жизни и т.п.);
колонки со звуковым сопровождением игры (озвучивать ошибки/победы/поражения, называть цели этапов, цвета и прочее).
Игровой контроллер:
приёмопередатчик для шины данных;
Ethernet / Wi-Fi канал для связи с внешним миром;
аудио выход для звукового сопровождения;
видео выход для табло.
Админ интерфейс:
отображение текущего состояния платформы и информации по игре;
запуск/остановка игр;
индивидуальная настройка пикселей (назначение адресов, коэффициентов, калибровка, дефектовка и т.д.);
конструктор игр;
всякого рода журналирование (игры, логи контроллера, ошибки и пр.).
Основная цель: на старте заложить техническую возможность масштабирования платформы до размеров средней комнаты ~20-30 м2. На этом этапе лбами сталкиваются проблемы частоты обновления платформы и надёжности связи. По своей сути это взаимовытесняющие вещи: хочешь надёжно — пожертвуй скоростью, хочешь быстро — будь готов к потерям данных. Я не хотел тупо гнать сигнал через адресную ленту на базе WS2812B, это путь в никуда.
* Скриншот из видео Activate Games
По итогу всех изысканий, в качестве интерфейса связи к пикселям, мной была выбрана шина CAN, я считаю она идеально ложится на вышеизложенную концепцию:
количество устройств в одной подсети может достигать до 120 шт. При группировке по 4 пикселя это обеспечит мне теоретический предел в 476 пикселей или примерно 34 м2, чего более чем достаточно на начальном этапе. Далее можно расширять путём введения дополнительных подсетей или увеличения количества пикселей в группах;
скорость передачи данных до 500 Кбит/с на 100 метров кабеля, чего как раз должно хватить, чтобы окольцевать 34 м2 площади. В эту скорость для тех же 476 пикселей, в зависимости от выбора протокола цветопередачи, можно будет уложить от 20 до 80 кадров в секунду;
возможность выстраивания приоритета сообщений в сети и разруливание коллизий через аппаратный механизм арбитража, что хорошо ложится на концепцию быстрого реагирования на нажатия. Короче говоря, сообщения о нажатии отправляются в шину вне очереди;
достаточно устойчивая связь вследствие использования дифференциального сигнала;
широкое распространение и дешевизна микросхем, что немаловажно.
Пессимистично делим все теоретические пределы на 4 и всё равно остаёмся в рамках разумного, жить будет. Поехали дальше!
Пиксель
Пиксель представляет собой классическую рамку с боковым расположением светодиодов, накрытую оргстеклом. Рамку выгрызали на ЧПУ фрезере из чёрной ламинированной фанеры толщиной 21 мм. Оргстекло мне тоже раскроили на ЧПУ при заказе, так доставка ТК обошлась в копейки, нежели доставлять лист 2х3 метра.
Первая сложность возникает при выборе типа датчика нажатия. Рассматривал несколько вариантов:
концевой переключатель;
тензодатчики (как в напольных весах).
Мне сразу не понравилась идея использовать механический переключатель, т.к. для этого потребуется обеспечить подпружиненный свободный ход оргстекла и при этом избежать залипаний. В эту же категорию идут и датчики из двух пластин, работающих на замыкание, как в танцевальных аппаратах.
То ли дело работа с аналоговыми тензодатчиками, когда свободный ход практически отсутствует (вспомните ваши напольные весы). К тому же есть пара идей, как применить аналоговый сигнал в играх…
Так и поступил: было решено собирать ~85 напольных весов собственной разработки с проводным каналом связи и RGB подсветкой. Крепления для датчиков рисовал сам и заказывал печать на 3D принтере. Было напечатано около 340 таких креплений. Конструкцией доволен, получилось весьма надёжно и доступно для массового производства, в т.ч. и для литья. Нижняя часть пикселя выглядит колхозно, но это прототип, да простят меня эстеты.
Электронная начинка и встроенное ПО пикселя
Как я упомянул ранее, я сгруппировал пиксели по 4 шт, а значит нужно два вида плат: групповая плата с модулем связи и контроллером и 4 маленьких платы просто с внешним АЦП для датчиков. По итогу я собрал 21 большую и 84 маленьких платы (на фото маленьких — это только половина от общего количества).
Основная идея была сделать пиксель максимально тупым. Он должен принимать/отображать цвет и отправлять нажатие. На словах это просто, а на деле, т.к. работа идёт с аналоговыми датчиками, нужен был периодический опрос с цифровыми фильтрами, всякими коэффициентами к ним, калибровками нуля и чувствительности и т.д., чтобы, в случае чего, можно было с бэкенда подкрутить параметры прямо на ходу, в т.ч. вывести пиксель из игры, если он начал неадекватно себя вести или залип.
Контроллер и управляющее ПО
Сначала у меня была идея делать собственный 3х канальный USB-CAN преобразователь и управлять платформой с обычного компьютера. Я даже успел развести и заказать платы, но потом передумал и в качестве контроллера выбрал обычную Raspberry Pi 4. В ней есть всё необходимое: Wi-Fi, аудио/hdmi выходы, а также к ней продаются готовые модули CAN шины. Сложной математики там нет, так что процессор справляется легко, я даже вывел метрики в админку на всякий случай.
Управляющее ПО писал сам полностью с нуля: фронтенд — Vue.js, бэкенд — Golang, база данных — SQLite. Из того, что реализовано на данный момент:
отображение текущего состояния платформы (подсветка нажатий и текущего веса в кг);
игровое табло (время, очки, жизни);
просмотр информации по каждому пикселю в отдельности и отправка индивидуальных команд;
отправка широковещательных команд;
вывод метрик контроллера (загрузка/температура CPU, потребление памяти, основные метрики бэкенда);
простой конструктор кадров для игр;
несколько игровых механик: пол — это лава (нужно собрать все синие, не наступая на красные), море волнуется/пиксель дуэль (соревновательные режимы по сбору своего цвета, побеждает самый ловкий), безопасный цвет (робот озвучивает цвет, нужно успеть его найти и занять), классики (пропрыгать случайный паттерн), несколько демо режимов;
старт/стоп/пауза игр с возможностью конфигурации непосредственно в момент старта игры (например, для детей я отключал контроль жизней и увеличивал время этапа);
имитация игр мышкой прямо через админку для непосредственного тестирования игры после конструктора (ну или вмешивания прямо в процесс игры… хе-хе, я так помогал своей дочке побеждать пару раз, чтоб не расстраивалась).
Сборка прототипа и выявленные проблемы
Сборка такого количества плат и пикселей в одиночку у меня заняла больше месяца: сверлить, прикручивать, приклеивать, паять, отлаживать и перепаивать сгоревшее. К расстановке компонентов на платы я привлекал даже дочь… как говорится, любишь играть, люби и платы собирать!
Какие ошибки допустил в процессе разработки:
Ошибка 1: Россыпь плат, а не панель
Я торопился и заказал платы не панелями, а россыпью… это было немного больно и приходилось наносить пасту на платы поштучно. Я купил трафаретный принтер для нанесения пасты и мини стол для оплавления припоя, это в десятки раз ускорило процесс. Трафаретный принтер — самоделка одного замечательного человека с ютуба, кому будет интересно, могу дать контакт в комментариях.
Ошибка 2: Оргстекло
Найти оргстекло или поликарбонат подходящей толщины оказалось проблемой. В наличии из импортного ничего нет, толстое вообще не в почёте, а если заказывать, то нужен объём + большие сроки. Взял лист оргстекла от какого-то российского производителя, а оно оказалось недостаточно молочным (см. фото), очень сильно просвечивал источник света, пришлось каждый квадратик вручную дополнительно матовать шлиф машинкой… то ещё удовольствие.
Ошибка 3: Танталовые конденсаторы
Танталовые конденсаторы сами по себе достаточно капризная штука, а заказывать их с Китая было вдвойне ошибкой… брака было около 40%: они просто взрывались при напряжении в половину от номинала. Я проверял их непосредственно перед пайкой, но даже это не помогло… несколько штук вышло из строя прямо в день мероприятия, проработав перед этим около месяца дома. В следующий раз поставлю бочонки, благо высота позволяет, они не так горят.
Ошибка 4: Таблица на фронтенде
Я ненастоящий фронтендер и умею клепать только админки для внутреннего использования. Как мне кажется, было ошибкой использовать на фронтенде простую таблицу. Хоть обновление ячеек и сделано реактивно на тегах, но рендер всего поля разом немного подтормаживает. Скорее всего нужно будет переходить на графику, проконсультируюсь чуть позже с опытными коллегами.
Ошибка 5: Экономия на протоколе передачи
Цветовые эффекты немного скудные, недостаточная цветопередача, т.к. сэкономил на протоколе. Рассчитать всё в теории — легко, но опыт подсказывал, что теоретические пределы скорости не практике недостижимы, боялся не получить требуемую частоту обновления, поэтому заранее ужимал протокол, хотя при таком размере поля можно было особо не беспокоиться.
Ошибка 6: Размытая граница пикселя и неравномерность засветки
Мне не нравятся размытые контура пикселей, хочется сделать их более чёткими, это будет смотреться гораздо круче. Качество засветки тоже можно улучшить, используя более глубокую рамку и правильное оргстекло.
Ошибка 7: Дешёвая светодиодная лента
Было куплено около 90 метров "высококлассной" китайской светодиодной ленты… которая оказалась явно б/у, имела разное свечение и много раз перегорала. Но тут вынужденная экономия на прототипе.
Идеи на будущее:
Расширение группы до 9 шт. — это будет явное удешевление, повышение надёжности связи за счёт уменьшения устройств на шине и расширение теоретического предела площади игровой зоны;
Соты! Очень хочу гексагональное игровое поле, это должно выглядеть весьма круто!
Настенные кнопки;
Быстрые соединения. Из-за использования в прототипе винтовых клеммников, сборка платформы перед детским праздником у меня заняла около 2.5 часов, что очень много. Буду прорабатывать быстрые соединения;
Ну и конечно, разные-разные механики игр! В голове масса идей: всякого рода змейки, пакман, эстафеты, арканоид, захват территорий, повтор рисунка, те же танцы и твистер…
Как корабль назовёшь… и заключение
При выборе кодового имени проекта было несколько разных вариантов. Больше всего мне симпатизирует название «Pixel Quest» ввиду широкого распространения в народе понятия «квест-комната». Сразу занял под это дело домен и, как это водится, завёл отдельный ТГ канал @pixel_quest для публикации прогресса разработки и дальнейших обсуждений с заинтересовавшимися читателями. Заходите в гости, буду держать в курсе событий.
На Пикабу пишу ради новых знакомств, поиска поддержки и идей для дальнейшего развития проекта. Я технарь, а не предприниматель, и, если честно, плохо представляю, как правильно превратить это в бизнес. Я не умею в эти ваши «найди инвестиции / собери команду / захвати мир» (но это пока что), не умею писать бизнес-планы, хочу просто делать интересный продукт и радовать людей. Буду рад любым советам! Личный телеграм для связи: @AnatoliyB
В ближайший планах найти подходящее помещение у себя в городе (Смоленске) для построения первой комнаты с увеличенной игровой зоной и полноценного тестирования. Хочу развивать идею как по направлению целых игровых квест-комнат, так и небольших игровых платформ 4-6 м2 для установки в детских комнатах или сдачи в аренду на детские праздники.
Итого:
Потрачено: ~300 тыс. руб.
Заработано: 0 руб.
Удовольствие от процесса разработки и праздника для детей: бесценно!
Спасибо всем, кто дочитал! Пишите свои мысли и идеи игр в комментариях!