В наше время, из-за санкций одноплатники стали стоить каких-то «конских» денег. Даже б/у RaspberryPi Zero стоит 2-3 тысячи рублей на барахолках, что, мягко скажем, не совсем лояльная цена для «самого дешевого одноплатного компьютера в мире». Конечно, Orange Pi Zero всё ещё можно купить в пределах 1.500-2.000 рублей, но как по мне и эта цена не слишком лояльна за те характеристики, который предлагает такой одноплатник. С другой стороны, Android-планшеты 10-летней давности продаются на барахолках по 100-300 рублей, что выглядит гораздо привлекательнее, причём на некоторые устройства практически без костылей можно установить полноценный дистрибутив Linux! Вероятно, многие читатели скажут мол «автор бомж» и будут правы: ведь в рамках этой статьи, я хочу рассказать о том, как использовать полурабочий древний планшет в качестве полноценного одноплатника путём подключения его к микроконтроллеру и выводу GPIO! Сегодня мы с вами: узнаем, как подключить микроконтроллер к шине UART в планшете и научимся работать с последовательной шиной в Android прямо из Java и нативных программ. Интересна моя концепция антикризисного одноплатника? Тогда добро пожаловать под кат!
❯ Зачем это нужно?
Пожалуй, нельзя сказать, что подобная концепция пристраивания старых планшетов — вопрос исключительно цены. 2-3 тысячи рублей не такие уж и большие деньги и при желании можно купить хотя-бы Б/У, но всё таки полноценный одноплатник с нормальной GPIO-гребенкой. Однако здесь стоит вопрос не столько дешевизны, сколько E-Waste: зачем выкидывать в помойку потенциально рабочие планшеты с живым процессором, если их можно пристроить куда-то ещё?
На самом деле, планшеты с ROOT-доступом уже из коробки могут выполнять весьма полезные задачи, как, например, хостинг http-сервера для домашней страницы, работать как панель с часиками и погодой, или, например, работать в качестве HMI-панели для оформления заказов в шаурмечной. Кроме того, многие планшеты на базе смартфонных чипсетов (MediaTek, Spreadtrum) имеют полноценный Bluetooth-модуль, что позволяет «подружить» планшет с микроконтроллером через радиоканал, что значительно расширяет возможный спектр применений.
Преимуществ у такого подхода много: у «пожилого» планшета уже есть большой, достаточно качественный (хороший TN, либо даже IPS) дисплей с тачскрином, который поддерживает мультитач, GPU для вывода 3D-графики, 3.5мм для вывода звука + встроенные динамики, а также весьма неплохое, по сравнению с дешевыми одноплатниками, железо. Звучит весьма вкусно для цены в 300 рублей: собрать хоть немного похожую конфигурацию на базе RPi выйдет в 10-15 тысяч рублей (учитывая дороговизну MIPI-матриц с тачскринами + цену самой «малинки» и обвязки для аудиотракта).
Но при всех перечисленных достоинствах, атрибутом любого полноценного одноплатника является наличие GPIO — и даже здесь мы сможем с вами выкрутится! Первый способ, о котором я чуть выше вскользь рассказал, позволяет реализовать общение с МК и «ногодрыг» через BT-радиоканал, но минусы такого подхода очевидны (МК с BT дороже, радиоканал потребляет дополнительную энергию, некоторые могут посчитать BT небезопасным). Однако есть и второй подход, который заключается в использовании диагностических пятачков UART на плате устройства для наших личных целей!
С таким подходом можно использовать как «голый» Linux, используя концепцию, которую я представил в этой статье, так и взаимодействовать из Java-приложений для Android (что даёт уже, как минимум, удобный GUI-фреймворк). Сегодняшняя статья будет «без воды», только чистая конкретика, поэтому давайте перейдем к реализации!
❯ Подготовка
Как я уже говорил выше — в рамках данной статьи мы рассмотрим использование UART в планшете для наших собственных целей. UART — это двунаправленная полнодуплексная цифровая шина, которая позволяет обеспечить стабильную передачу данных при относительно невысокой скорости, измеряемой вбодах. То есть, быстро стримить картинку с её помощью вы не сможете, но сможете, например, получить состояние входов МК, прочитать что-то на шине I2C, используя мост UART -> I2C или, например, прочитать показания датчиков, которые МК предварительно опросил.
Сама по себе концепция очень простая: многие китайские производители планшетов и смартфонов не только разводят UART в виде отдельного пятачка на плате, но и подписывают его, задействуя UART-канал как вывод для логов ядра, а иногда и предоставляя доступ к рутовой консоли! В свою очередь, из юзерспейса мы можем получить доступ к UART с помощью устройства/dev/ttyS<x>на подавляющем числе чипсетов и/dev/ttyMT<x>на MediaTek. Однако учтите, что в некоторых случаях придется патчить загрузчик, дабы редиректнуть логи ядра в /dev/null.
Однако наличие UART на плате — не всегда признак того, что он сконфигурирован в системе верно. Например, на смартфонах с чипсетами SC6820 нормально завести UART я так и не смог, а на некоторых устройствах на базе MT657x нужно патчить загрузчик, дабы он «увидел» нужный канал UART! В моём случае, героем статьи стал планшет Prestigio, у которого отказал тачскрин, но был доступен UART:
Конкретно в моём случае, после установки последней официальной прошивки планшет перестал слать логи на UART и устройство /dev/ttyMT3 оказалось доступным для наших операций, в вашем же случае может потребоваться настройка devicetree, или просто патчинг загрузчика, дабы редиректнуть консоль на другой вывод UART. Кроме того, необходимо обязательно получить root-доступ хотя-бы к adb shell, поскольку доступ к /dev/tty устройствам возможен только от имени суперпользователя. Как же проверить UART на возможность чтения/записи? Сначала нам необходимо взять ESP32 или любой UART-USB преобразователь, припаять сигнальные линии RX/TX и использовать любую программу для работы с последовательным портом, например Putty. Заходим в adb shell, и пишем что-нибудь в консоль:
Вуаля! Всё работает :)
Работает? Замечательно, значит мы сможем использовать планшет вместе с микроконтроллером! Переходим к практической реализации нашего приложения!
❯ Используем из Java
Я специально решил выделить для Java-подхода отдельный раздел, поскольку просто взять и открыть /dev/ttyMT3 с помощью FileInputStream не выйдет. Дело в том, что даже несмотря на наличие root-доступа, по факту ни одно Android-приложение его не имеет (за исключением подписанных системных в папке /system/app/) и для всех операций, требующих повышенных привилегий, либо распаковывают и запускают внешнюю нативную программу из под суперпользователя, либо с помощью специального костыля с запуском sh-программ читают/пишут нужные блочные устройства сами. Связано это с тем, что все Android-приложения работают в хост-процессе app_process, который форкается (отпочковывается) от «главного» процесса, который запущен из под «простого» пользователя, который не находится в группе system.
Здесь концепция также очень простая: su имеет аргумент -c, который позволяет запустить команду от имени root-пользователя и возвращает объект процесса, дабы мы потом могли перехватить stdout:
Таким образом, для чтения текстовых данных из UART'а нам достаточно лишь периодически «слушать» stdout команды cat и обрабатывать данные:
Костыль, но со вкусом :) Если вас не устраивает такой подход или ваше приложение значительно более комплексное, вы можете использовать UART и из под нативных программ.
❯ Используем из C
Работа с последовательными портами в Linux не отличается от работы с любыми другими файлами и устройствами: вызовов open, read, write и close обычно хватает и лишь иногда к ним в довесок нужен ioctl.
int fd = open("/dev/ttyMT3", O_RDWR); int result = write(fd, command, strlen(command));
Для работы с терминалом необходимо использовать модуль termio который предоставляет все необходимые структуры для настройки режима работы терминала, в т.ч и бодрейт. Дело в том, что изначально последовательное устройство настроено на режим работы в качестве терминала, т.е драйвер отдаст данные только после того, как устройство на UART пошлёт \n, или превысит размер внутреннего буфера для сообщения. Если вам нужно работать с бинарными данными и получать их «на лету» — необходимо настроить последовательный порт в «binary» режим:
Если же вам достаточно текстового терминального режима, то можно продолжить как есть и использовать fgets, fscanf и прочие удобные функции из libc! О том, как собрать нативную программу для смартфона и как вообще выбросить Android из него, читайте в моей отдельной статье.
❯ Заключение
Вот таким образом можно использовать проводную шину в планшете для собственных нужд! Как видите, совершенно ничего сложного и используя эти наработки, я реализовал уже не один проект! Надеюсь, материал вам был интересен и полезен :) Пишите своё мнение, можно ли использовать дешевые планшеты по 300 рублей в качестве одноплатников?
Статья была подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю! Ну а больше подробностей о будущем контенте, как обычно, в первом комменте! Также у меня есть свой Telegram-канал, куда я выкладываю свои мысли, советы по ремонту и моддингу различных гаджетов, а также вовремя публикую ссылки на новые статьи!
Не знал, что они статьи и на пикабу выкладывают. Но самое главное отвалилось в посте — видео с итоговым результатом!
Вот такие часики-метеостанцию я запилил за пару недель из плазменного дисплея от старого японского автобуса.
Шрифты плюс-минус обычные, иконки погоды вышли как по мне шикарные, но самым тёплоламповым получился эффект дождя, который отрисовывается в дождливые (по прогнозу погоды) дни.
Ну и музыка тоже своя, да.
Кто нашёл отсылочки в видео (помимо самой очевидной на "Матрицу"), тому приз — два прекрасных нихуя %)
Мы уже сопоставили заявленные характеристики лампочки от производителя Rev ее фактическим и теперь самое время измерить температуру работы микросхем, измерить световой поток и также разобраться с количеством кристаллов светодиодов в лампе.
Данное видео специфично и будет интересно скорее людям с инженерными склонностями.
Взять с собой побольше вкусняшек, запасное колесо и знак аварийной остановки. А что сделать еще — посмотрите в нашем чек-листе. Бонусом — маршруты для отдыха, которые можно проехать даже в плохую погоду.
Вы уже ознакомились с очень короткой версией обзора лампы Rev за 15 секунд. Сегодня же я буду рад вам показать детальное исследование этой удивительной лампы, которую ни в коем случае нельзя покупать.
В рамках проекта нашего сайта "Доморост" эта лампа уже была оценена экспертами-светотехниками, не набрала ни одного положительного голоса и заняла соответствующую позицию в рейтинге.
Данный обзор не требует специфических знаний и будет любопытен технарям.
Привет любителям качественного звука! Меня зовут Даниил и я хочу рассказать о нашем с друзьями проекте по разработке бюджетного аудио процессора для любителей, использующих многополосную домашнюю и авто акустику.
Перед описанием характеристик устройства, думаю будет полезным рассказать об основных функциях аудио процессоров:
1) Кривая АЧХ. Невозможно найти динамик, имеющий абсолютно ровную и линейную амплитудно-частотную характеристику. Особенно усугубляет ситуацию наличие нескольких разных излучателей в многополосных акустических системах, где просто выровнять АЧХ нельзя при помощи простого эквалайзера, как в случае с широкополосной акустикой. Кривизна АЧХ может создавать ощущение “ненатуральности звука”, призвука “пластмассы” и т. п. К тому же, сильная нелинейность не позволит услышать определенные инструменты во всей красе, так как часть их диапазона по-просту не будет слышно. Аудио процессор, обладающий продвинутым эквалайзером и множеством аудио выходов, способен избавить от описанных проблем.
2) Функция кроссовера. Звуковой процессор позволяет разделить частотных диапазон для разных динамиков путем выставления частоты среза и её крутизны спада, будь то второй, третий и четвертый порядок. Это позволяет динамикам работать только в своем, наиболее эффективном диапазоне, избавляя нас от ненужных хрипов и искажений звука. Тем самым становится лучше детальность.
3) Задержки звука. В комнате и тем более в автомобиле на пути звуковой волны встречается множество препятствий, при встрече которых волна переотражается и возникают задержки. Задержки меньше нескольких миллисекунд слышат все люди. И для этого даже не надо специально тренироваться и не нужно быть звукорежиссером. При правильной настройке данного параметра возникает ощущение “приближения” и более полного погружения в музыкальный ряд.
Таким образом, мы рассмотрели список основных проблем, легко устраняемых использованием аудио процессора. Перейдем к технической части.
За основу взят МК ESP32, а в роли АЦП выступает микросхема PCM1808, ЦАП PCM5102A. Сейчас собран макет устройства и для управления микроконтроллера написана программа на C++
Макет аудио процессора
Вот характеристики, полученные на макете:
1/2
Функциями эквализации, настройки задержек и кроссовера устройство еще не обладает. Планируется разработка приложения для Android, через которое будет осуществляться настройка процессора.
Интересно ваше мнение о будущем данного устройства.
Расширение сферы применения биометрической системы контроля доступа на других существ, открывает поистине потрясающие возможности.
Так сложилось, что на территории мануфактуры, где я располагаюсь, живёт достаточно большое семейство иссиня-чёрных котов, все братья от одной матери, но из разных помётов. Весь этот прайд мы именуем просто Бандиты, по соответствующему характеру и поведению. Из всей этой стаи один кошак полюбился мне больше всего: самый адекватный и интеллигентный; и именно его я иногда пускаю в свои кабинеты.
И возжелал я пускать того прекрасного кошака, а остальных отсеивать, дабы не хулиганили в моё отсутствие. И пришла в мою голову мысль о пропускной системе, именуемой КотСКУД — кошачья система контроля доступа.
❯ Концепция КотСКУДа
Долго размышлял о том, каким образом это решение сделать простым, дешёвым, повторяемым и не требующим серьёзного электропитания. В очередной раз, почесав за холку любимого Бандита, пришёл к выводу, что лучше всего использовать для этих целей сканер отпечатков пальцев.
Чешу любимого Бандита
Кошачий нос или лапка имеет уникальный рисунок, точно так же как рисунок отпечатка пальцев у человека. Значит осталось найти способ сканировать подушечку лап или носик (зависимости от того, что коту больше понравится).
Достаточно долго анализировал, что же есть доступного и недорогого на рынке, а после остановился на оптическом сканере отпечатков пальца модели FPM10A. Для него имеется огромное количество примеров, ПО, есть куча библиотек на Python и Arduino, а значит, по идее, с ним проблем возникнуть не должно.
❯ Пару слов об устройстве оптического сканера отпечатков
Оптический сканер отпечатков работает по принципу того, что свет под определённым углом полностью отражается на границе двух сред. И если какой-то объект прикасается к этой границе, то такое отражение нарушается и можно считать отпечаток этого объекта. Для примера приведу схему устройства оптического датчика R307, взятую с этого сайта:
Оптический сенсор — весьма сложное устройство, в котором есть призма, реализующая границу сред, и полноценная камера с процессором, которая позволяет считывать отпечатки. Когда нет прикосновения, то ровный белый свет попадает в объектив камеры. А если прикасается носик к нашему КотСКУДу, то интенсивность света уменьшается, и камера таким образом фотографирует отпечаток.
Далее там идёт сложная система распознавания отпечатков по базе данных, по каким-то хитрым алгоритмам, действие которых мне неведомо.
❯ Подключение сканера FPM10A
Прелесть сканера FPM10A заключается в том, что он подключается по-обычному UART и питается от 3,3 вольта. Для его подключения понадобится любой обычный переходник USB-UART. Не буду подробно останавливаться на способе подключения этого датчика, всё достаточно подробно расписано в официальном документе.
Мне понадобилось сделать несколько пассов паяльником, чтобы подключить его к компьютеру, но с этим справиться даже ребёнок.
Сканер моего КотСКУД подключён и готов к работе
Дело стало только за программным обеспечением. Возиться с Python библиотеками мне было лениво, поэтому решил использовать для начала демонстрационную программу для этих датчиков, запустив её на виртуальной машине. Программа работает весьма нестабильно, иногда вылетает, не всегда видит датчик. И, думаю, это связано с тем, что она очень плохо реализована.
Но в целом, всё как в анекдоте: мой кот раньше не любил пылесосы, но ничего, потом втянулся… Так и я, втянулся, и а потом она даже начала мне нравиться.
Подготовка ПО к испытаниям
Настало самое интересное – перейти к натурным испытаниям.
❯ Натурные испытания
Наверное, самый сложный и волнительный момент. Бандит был накормлен, и максимально обласкан. Думаю, он ни разу в жизни не испытывал такого тёплого внимания к своей персоне со времён своего рождения и уж тем более не ожидал, что ему перепадёт столько вкусняшек. Во всех опытах со сканером проявлял живое участие и интерес и даже смотрел, что же будет.
Сканер отпечатка лапы
Вообще, мне казалось, что научить кота тыкать лапой в сканер будет самым простым действием. Плюс, это достаточно простая и лёгкая операция.
Но я столкнулся с суровой реальностью: в отличие от домашних питомцев, у которых мягчайшие розовые подушечки, у заводских Бандитов подошва лап больше напоминает твёрдую наждачную бумагу. И как бы это странно не звучало, сканер наотрез отказывался сканировать какую-либо кошачью лапку. Или если уж и делал, то на выходе было что-то совсем неразборчивое. Поэтому отпечаток кошачьей лапы я вам не покажу.
Отпечаток кошачьего носа
Не могу сказать, что Бандит был в восторге, что ему хотят отсканировать носик, но и большого сопротивления не оказывал. Вообще, в этой всей процедуре никаких насильственных или неприятных действий к любимому котику не применялось, всё было достаточно добровольно, да и кот очень разумен. Проблема была скорее в том, что он не хотел прикоснуться к сканеру и замереть, чтобы качественно носопырка его была отсканирована.
Сканируем кошачий носик
Всё же, после нескольких не самых удачных попыток, Бандит согласился более спокойно ткнуться носом в эту светящуюся штуку, и отпечатки удались. После этого я начал сохранять результаты на компьютере, и он с невероятным любопытством, следил за всеми моими действиями, чем просто поразил меня, будто бы он сам всё понимал, что я там делаю.
Что же ты там такое делаешь?
Настал момент истины, можно ли использовать оптический сканер отпечатков для кошачьих носиков и далее реализовывать мой КотСКУД?
❯ Результаты
Вам же тоже, как и мне не терпится посмотреть, что же там удалось насканировать? Удачных сканов не так много, как я уже говорил, Бандит достаточно резво крутил мордой, а проявлять насилие или как-то фиксировать его — мне не позволяла совесть.
Вот первые два более-менее удачных снимка отпечатка кошачьего носика, ощутите уникальность момента: вы видите их первыми.
Первые отпечатки кошачьих носиков
В конце концов, мне удалось получить более-менее чёткий снимок котоноса. И как раз к этому моменту, Бандиту надоела эта игра, и он решил слинять.
Чёткий снимок кошачьего носа
Считаю это настоящим успехом!
❯ Выводы
Главный вывод из всей этой затеи такой: отпечаток кошачьего носика можно использовать в системе КотСКУД для доступа животного в помещение.
Однако я не учёл несколько факторов:
Сбор массива отпечатков одного носика. Чтобы собрать достаточное количество отпечатков носа с разных ракурсов, для корректного распознавания и добавления в базу данных, требуется длительное время. А кот не желает так долго заниматься этими глупостями и начинает сопротивляться.
Дрессировка. Второй фактор, который почему-то мне не пришёл в голову – что котика надо будет обучить тыкать носом в эту светящуюся штуковину. А, как показала практика, тыкать носом, да ещё с достаточным усилием, чтобы отпечаток чётко читался, кот не хочет. И никакие вкусняшки и поглаживания его не соблазнят в этом действе.
Носик мокрый. А это означает, что сам сканер будет достаточно быстро пачкаться кошачьими соплями и потребуется регулярная очистка.
Так что научно-исследовательская работа по внедрению КотСКУДа продолжается. Думаю, следующие результаты будут обнародованы через год, ровно первого апреля.
Пожалуй, немалая часть моих читателей так или иначе интересуется 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 тысяч рублей. За каждую копейку я готов отчитаться (по факту покупки машины я сделаю пост с фотографиями авто, ДКП, а также оглашу фронт будущих работ и сразу начну заниматься проектом).