Уже не первый пост мой с подобным вопросом, так что сначала предыстория.
Во времена короны меня сократили и я решил попробовать себя в работе с микроконтроллерами. Я был полный 0 в этой области, а про с/с++ знал только, что это языки программирования и что 1с не из их серии. За пол года немного подружился с esp32, понял главные моменты с масштабированием кода и используя чужие библиотеки мог собрать что угодно, что укладывалось в функционал библиотек. Даже начал ковырять freertos, разобрался с mitt app inventor, что бы делать примитивные приложения под андроид. Ну и нашел заказчика на такие не высокие требования, потому что я умел всего по чуть-чуть, мог и корпус замоделить и плату развести (посмотрев один ролик гайвера по EasyEDA) ну и какой то код составить из экзамплов, который на удивление еще и работал. На покушать хватало. Но будучи самоучкой дальше я столкнулся со стеной нехватки доступной инфы, так как это уже не популярно в массах, а интересует только профессионалов. И тут мне предложили помонтажить РЭА. Монтаж не сложный, но много и деньги платили не плохие... и все... на 2 года я забыл про программирование, по сути опять просрал 2 года. И вот после этого нового года у меня начало резко ухудшаться здоровье, сначала спина, что уже не мог сидеть паять, потом еще несколько неприятных недугов подтянулись, в общем пока работать вообще не могу и на восстановление наверное уйдет несколько месяцев, благо я отложил денюжку и мне хватит на пол года жизни или на год, если урезаться по максимум.
И вот тут у меня встал вопрос что делать дальше. Это место с монтажом я уже 100% потерял, потому что сам сказал, что выбыл на долго и пусть ищут замену. Я прошерстил вакансии на hh и даже на самые низкооплачиваемы в этой области я пришел к выводу что я должен овладеть следующими навыками:
- Знание языка С/С++ на высоком уровне (я же, если брать классический учебник, только первые главы освоил С++, С вообще не касался)
- Работа с STM32 - и тут самое веселое, даже если я разберусь с инструментарием GСС в VS Code + Cube MX, еще надо разобрать особенности типовых видов архитектуры этого семейства МК, при том не просто блок-схемы разобрать, а глубоко понимать, что бы я мог все это настраивать правильно и понимать как оно взаимодействует, потом разобрать работу всех видов периферии МК, а тут не как в arduino ide, не выйдет, просто, например для i2c написать Wire.begin(); и дальше даже не думать что оно делает, тут надо на низком уровне взаимодействовать, а я попытался разобраться в том же i2c, тайминги в нем это просто жесть, а это еще все и кодить надо, а я до битовых операций даже не добирался. Есть вроде либа hal от самих ST для упрощения работы, но как я понял там тоже не все так прекрасно.
- Знание основ схемотехники и теории цепей. Я только закон Ома на практики применял. Начал их читать, 3 закона Кирхгофа самое легкое, дальше начинается жуть с морем высшей математики, а я даже не помню как интегрировать, не то что как сигнал разложить в ряд Фурье для фильтрации гармонических составляющих. Это все фактически надо учить по новой. Плюс физика. Я на практике убедился как важно понимание взаимодействия электромагнитных полей при проектирование печатной платы, что бы у тебя сигнал не превращался в кашу только от того, что ты землю не правильно развел.
- Работа в Altium Designer - саму программу освоить не проблема, но вот я начал читать про проектирование помехоустойчивых систем и понял, что просто так на плату накидать по схеме элементов, что бы просто не пересекались дорожки не выйдет. Во-первых надо хорошо знать элементную базу и понимать как работает каждый из этих элементов, про ОТЦ и физику писал выше. Я нашел серию ГОСТ 61188, надо хорошо их знать и понимать.
-Английский язык... что у меня с ним всегда так не клеится, сейчас можно перевести все гугл переводчиком, но в профессиональной деятельности это явно не пойдет, так как может быть утерян какой то ключевой момент при переводе документации.
Это только самые часто встречаемые требования для людей с опытом от года, при этом почти всегда требуют, что бы это была твоя не первая работа в этой области. А я описал, только то, что я понимаю, что нужно, при этом я на stm32 смог пока только помигать светодиодом а в познании С++ мне еще предстоит долгий путь.
И вот я думаю, у меня есть несколько месяцев свободного времени, а успею ли освоить хоть какой то минимум, что бы меня взяли джуном? Или не имея только что законченного универа в этой области со свежими знаниями или уже не поработав в этой области, не имеет смысл вообще в нее суваться и попробовать себя в чем-то попроще? Я бы через пару месяцев, когда самочувствие будет получше, хотел бы найти какую то удаленную работу (но только не на обзвонах), тут тоже бы принял пару советов, в городе у меня больше не осталось вариантов, потом работу скорее всего придется искать в Ростове\Москве, но с учетом съёма жилья это все так грустно становится.
Я единственное что за последние 2 года не бесполезно потратил, это я с каждой получки что-то покупал. У меня есть макетки Nucleo-64 STM32F446, Discovery STM32F407, несколько F103, куча esp32, недавно купил несколько esp32-S3, ардуинки и малинки, осциллограф Hantec DSO02D15 (и еще USBишный), мультиметр uni-t UT61E+, лог анализатор DSLogic Plus, JTAG отладчик, ЛБП, 3D принтер 5й медведь, все для пайки, куча всевозможных датчиков, экранов, двигателей и драйверов для них. В общем для учебы у меня есть не плохая элементная база.
Почему в среде Proteus таймер/счётчик2 м/к Atmega16A в асинхронном режиме работает без кварцевого резонатора (32768Hz)? В дополнение могу сказать, что бит AS2 в регистре ASSR установлен в единицу. Наличие/отсутствие кварца между TOSC1 и TOSC2 роли не играет. С выхода счётчика OC2 снимается выход частотой 64 Гц = (2^15 (32768) / 256 (8-bit) / 2). Я понимаю, что протеус это симуляция, но как сделать так, чтобы он работал так, как описано в даташите? Сбивает с толку.
Пожалуй, немалая часть моих читателей так или иначе интересуется 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 тысяч рублей. За каждую копейку я готов отчитаться (по факту покупки машины я сделаю пост с фотографиями авто, ДКП, а также оглашу фронт будущих работ и сразу начну заниматься проектом).
Мы постарались сделать каждый город, с которого начинается еженедельный заед в нашей новой игре, по-настоящему уникальным. Оценить можно на странице совместной игры Torero и Пикабу.
Доброго времени суток. Есть у меня тонкий клиент TONK TN1000 с Linux Embedded на борту. Хочу сделать из него микросервер на Debian, но штатными методами систему на нём поменять нельзя. Может быть, можно ему как-то её незаметно подсунуть… Характеристики у него, как у Линукс-машины, вполне себе неплохие. В идеале - справиться без пайки. Предвещая будущие вопросы: доступа к консоли нет, по сети на него тоже не попасть.Гуглить пробовал - безрезультатно.
Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с 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 просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?
Полезный материал?
Приходилось ли загружать сторонний код в ваших устройствах?
Китайские производители не перестают удивлять: многие видят явные перспективы рынка одноплатных компьютеров и стараются представить целую линейку девайсов на самых разных чипсетах, а разработчики стараются использовать уже привычное и поддерживаемое долгие годы железо. К ним относятся решения на чипсетах AllWinner, RockChip, Tegra. Другие же стараются взять малоизвестный, но дешевый чип для иного круга применений, развести на нем компактную плату и продавать по цене пачки сухарей, подобные решения появляются регулярно. Один из таких одноплатников я недавно купил на AliExpress — некий DongShan Pi Pico W, на базе экзотического чипсета SigmaStar SSD210, всего за 600 рублей. И тут действительно есть на что посмотреть: два ядра Cortex-A7, контроллер TTL матриц, 2D GPU, Wi-Fi, 64Мб ОЗУ и Embedded Linux на борту. Более того, девайс поставляется в виде System on Module с переходной Evaluation-платой, что позволяет использовать это устройство в составе других гаджетов! Что это за красавец и на что он способен? Читайте в статье!!
❯ Что это за девайс?
Думаю, большинство моих читателей когда-либо слышали об одноплатных компьютерах. Это компактные и достаточно мощные устройства, которые можно использовать как в качестве компактных серверов или даже десктопных машин, так и собрать своё устройство на базе готового одноплатного компьютера. Одноплатники используется во многих сферах: вендинговые автоматы, умные экраны, самопальные игровые консоли и смартфоны, DIY-ноутбуки!
Однако чаще всего можно увидеть обзоры и проекты на базе довольно известных устройств: Raspberry Pi, Orange Pi, Olimex. Эти платы, скажем так, достаточно дорогие: и если Orange Pi One/Zero ещё можно ухватить за 1.000 рублей на вторичке (один из таких я купил еще летом. Узнав о моем блоге, продавец стал моим читателем и вместо одного OPi прислал мне целых два — один в подарок!), а за RPi Zero придется выложить как минимум 2.000 рублей. Однако есть ещё один сегмент одноплатных компьютеров: ультра-дешевые, разработанные на базе чипов для конкретного применения. Один из самых известных представителей — MangoPi/CherryPi R3, который работает на базе AllWinner F1C200s — чипа для… электронных книг!
Информации по дешевым, почти неизвестным одноплатникам довольно мало. У них не очень хорошая поддержка (кроме AllWinner, там почти все чипсеты есть в mainline-ветке Linux), в них могут обнаружится аппаратные баги, да и многие люди вообще не замарачиваются с ними, предпочитая переплатить, но купить что-то более стабильное. Но не я! Я просто обожаю различные ультрадешевые девайсики, поэтому недавно по наводке моего активного читателя NutsUnderline, я заказал интереснейший девайс — DongShan Pi Pico-W. Устройство обошлось мне всего в 600 рублей, но в первую очередь, меня привлек форм-фактор устройства и его чипсет. Некий SigmaStar SSD210!
Я заказал сразу два устройства: первую партию очень быстро разобрали, поэтому я взял «с запасом». Сейчас конкретно этот одноплатник пока-что не доступен в магазине продавца, однако у него же продаются другие устройства на базе SSD210. Можете найти их по ключевому слову: «SSD210» (прямые линки публиковать не буду, дабы не сочли за рекламу). Через месяц оба красавца пришли ко мне и я принялся их изучать.
Какое же было моё удивление, когда я обнаружил, что это по сути System on Module, который вручную надо припаять к Evaluation-плате! Вкратце это значит, что на базе таких SoM вы можете развести плату, протравить её, а затем припаять одноплатник поверх нее и сделать своё полноценное устройство, «без соплей»! Производителю плюсик за такую гибкость — я не очень люблю одноплатники с штырьковыми гребенками. Хотя, конечно, это очень сильно помогает при разработке макета устройства.
❯ Характеристики
Но чем он так меня привлек, помимо SoM направленности? Своим крутым чипсетом! Давайте ознакомимся с его характеристиками поближе:
Процессор: SigmaStar SSD210. 2 ядра Cortex-A7, работающие на частоте до 1ГГц. 16Кб кэш инструкций и 16Кб кэш данных, плюс 128Кб L2-кэша. В процессоре есть FPU и поддержка SIMD-инструкций Neon (альтернатива SSE в x86). Нехило, правда?
Поддержка дисплеев: У чипсета есть выделенный модуль для работы с внешними матрицами. Поддерживаются TTL дисплеи (до 1024x768), SPI-матрицы с клоком до 54МГц (480x320), а также прямой RGB аналоговый RGB сигнал (этот интерфейс можно использовать для подключения к ТВ с тюльпанами или аналоговым матрицам). Про типы дисплеев, вы можете прочитать в моей статье.
2D GPU: Поддержка отрисовки линий, прямоугольников, градиентной заливки, BitBLT, клиппинг, дизеринг, автоматическая конвертация формата пикселя (с RGB888 в RGB565). Это серьёзно снимает нагрузку с ЦПУ при рисовании графики, однако поддерживается ли он в Linux — вопрос другой.
ОЗУ: 64Мб DDR2 памяти «бутербродом» прямо с чипсетом, плюс поддержка до 512Мб DDR2 внешней памяти, до 1333Мб/с.
Звук: Один моно-выход DAC, два выходных канала I2S, вход микрофона. Входные каналы поддерживают частоту дискретизации до 96КГц. Можно организовать вывод звука лишь подключив внешний усилитель. Внешний ЦАП не обязателен, если вам не нужен стерео-звук.
Память: Контроллер NOR/NAND SPI-памяти, до двух параллельно подключенных чипов, плюс поддержка SDIO. BootROM поддерживают загрузку с MicroSD карт.
Сеть: Ethernet, на DongShan Pi есть Wi-Fi.
USB: Как хост, так и ведомое устройство
Периферия: 4 канала ШИМ, GPIO, 4 UART, 2 канала SPI, 2 канала I2C
Камера: До двух камер по интерфейсу MIPI CSI
Безопасность: Есть аппаратное шифрование.
Питание: 0.9В ядро, 1.8В ОЗУ, 3.3В I/O
Очень даже бодро, согласитесь? Вообще, производитель подразумевает SSD210 как чипсет для HMI-дисплеев — т. е. умные дисплеи, которые могут, например, служить стендами в музеях, или служить для заказа билетов в кино. Есть внешние HMI-дисплеи, которыми можно управлять используя другие МК: просто посылая команды и реагируя на нажатия кнопок. Тут мы и видим, как китайский производитель решил применить этот чипсет для другой сферы: одноплатный компьютер для DIY!
На SSD210 есть порт Linux, предлагается использовать Embedded Linux в качестве основной системы. Никаких дистрибутивов по типу Ubuntu для устройства нет — предполагается, что вы сами реализуете весь необходимый для ваших программ функционал (отрисовку графики, обработку ввода, звук и т. п.). Есть Build root и исходный код ядра, а также U-Boot.
Помимо этого, вендор предлагает целое SDK для разработки уже готовых устройств на этом чипсете. Но есть один нюанс: документации практически нет :( Такие пакеты предлагаются крупным коммерческим производителям устройств, поэтому и основная поддержка есть только для них. Есть некоторые сэмплы, как, например, использовать графические дисплеи (показан пример с TTL-матрицей 1024x600), но совершенно не ясно как использовать SPI-матрицы, поскольку они требуют отдельной инициализации.
Но сначала наш одноплатник нужно собрать и запустить. И здесь есть множество тонких моментов, которые необходимо знать перед покупкой такого девайса. Переходим к сборке!
❯ Сборка и запуск
Для более удобного процесса разработки нашего устройства, лучше всего заказывать сразу две платы: одну припаять к переходной плате с штырями, а другую использовать на нашем устройстве. Как я уже говорил ранее, одноплатник предлагается в виде System on Module, которые можно при желании распаять на переходной плате:
Честно сказать, я очень люблю такой тип монтажа и топлю за то, чтобы другие одноплатники не форсировали использование штырьков, а позволяли припаять себя «бутербродом» к другой плате. Обычно SoM дороже чем простые одноплатники, один из примеров — Olimex A20 SoM. Припаиваем основную плату к eval-плате. Обратите внимание, что припой должен находится «скосом» с внешней стороны пинов!
После этого, можно распаять гребенку. После окончания процесса сборки, вызваниваем все пятачки на плате и гребенку, дабы исключить непропай в каком-то месте.
Теперь подключаем питание. На плате уже разведены Step-down преобразователи с 5В на 3.3В (основная логика), 1.8В (DDR2), и 0.9В/1.0В (ядро), нам достаточно подключить лишь 5В, либо запитать плату от 3.7В аккумулятора. Устройство стабильно работает и от 0.5А порта ПК (если не юзать Wi-Fi).
Для работы с одноплатником, обязательно нужен COM-преобразователь. Открываем Putty, задаем COM-порт, выставляем бодрейт 115200 и отключаем контроль четности. После подачи питания на устройство, в консоли побегут логи, U-Boot начнет загружать систему… однако, есть один важный нюанс…
Все платы прошиваются на заводе с помощью фирменного флэшера SSD210. Но фирменный флэшер, по каким-то причинам, на некоторых платах не может сохранить U-Boot Environment (переменные окружения, которые в том числе определяют таблицу разделов и коммандлайн ядра).
Поэтому если ваша плата повисла на CRC Error, нужно ввести следующие команды:
После этого отправляем плату в ресет и система загружается как ни в чем не бывало!
Поскольку на плате не разведен разъем USB, для прошивки нужно распустить нерабочий кабель для зарядки смартфона, либо купить внешний USB-разъем на плате. VBUS кидаем на вход питания, белый провод на DM-, зелёный на DM+. Не забывайте провести общую землю между UART-преобразователем и основным питанием платы, дабы не потерять логи.
Замыкаем два пина в центре платы пинцетом и жмем RESET. Плата определится как MSDC-флэшка (не удивляйтесь). Прошивальщик глючный и бывает не с первого раза может прошить устройство. Если девайс после прошивки не включается — введите команды в консоль U-Boot выше.
Теперь переходим к самой системе.
❯ Система
Девайс работает на базе ядра Linux 4.9. Тем не менее, производителем заявлена поддержка Mainline-ядра, что даёт надежду на поддержку устройства в будущем.
Таблица разделов устройства организована в виде ubifs. Вообще, предполагается, что для тестов можно будет запускать ваш софт без перезагрузки, однако когда речь заходит о серьезных модификациях, ребут и прошивка устройства глючным софтом — дело неизбежное.
«Из коробки» на устройстве доступен лишь i2cdev, благодаря которому можно свободно общаться с i2c-устройствами из юзерспейса. Хотите получить доступ к SPI? Готовьтесь качать билдрут, вручную включать spidev в конфиге и редактировать DeviceTree, дабы spidev мог получить доступ к физическим spi-устройствам ядра.
Кроме того, конечно же, есть доступ к GPIO из sysfs.
На самой плате, Wi-Fi реализован в виде внешнего USB-хаба + Wi-Fi адаптера. Чипсет также поддерживает Ethernet.
Для разработки устройств, производитель предлагает отдельное SDK для общения с периферией устройства из юзерспейса. С помощью этого SDK, можно получить доступ к камере, аппаратному декодеру, звуку и настроить матрицу. Судя по всему, общение происходит с помощью ioctl к необходимым устройствам. Это сделано для того, чтобы разработчики не копались в низкоуровневых драйверах, ведь например, ALSA, на устройстве нет совсем.
Если включить нужные нам модули в юзерспейс (spidev, i2cdev, gpio), то можно будет проектировать устройства более простым путем. Например, подключить дисплейчик и прямо из юзерспейса выводить на него графическую информацию. Это открывает перспективы для самых разных применений: опрос датчиков и хранение информации в внутренней памяти, умные сигнализации, самодельные часы, DIY игровые консоли, самодельные телефоны и т. п. Применений просто куча!
❯ Заключение
Вот мы и посмотрели с вами на дешевые одноплатники, где используются чипсеты, которые разработаны для использования в совершенно других сферах. Девайсы весьма своеобразные и для полноценной работы с ними нужно обладать навыками прожженного линуксоида и иметь навыки системного программирования. Но, чего уж точно нельзя отрицать, так это перспектив подобных девайсов для своих проектов. Да, под них нет готовых гайдов, как для Raspberry Pi или Orange Pi, информации по ним минимум… но если захочется — то всегда можно «сварганить» самопальное устройство за минимальный прайс!
Вероятнее всего, я применю один из этих одноплатников для своего проекта немного позже. И конечно же, я напишу об этом отдельный материал — ведь про экзотические чипсеты на Пикабу пишут не так часто!
Чуть позже выйдет материал про Repka Pi. Их одноплатник получился не менее интересным и как раз таки метит в нишу одноплатников с хорошей поддержкой, где есть уже готовые гайды, информация и даже сами разработчики могут помочь с решением некоторых проблем. Без косяков не обошлось: есть пару аппаратных проблем, о которых я расскажу открыто, но в целом девайс выглядит интересным!
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud , дабы не пропускать свежие статьи каждую неделю!
Чтобы работать с устройствами через C#, вам потребуется использовать соответствующие библиотеки и API.
Использование библиотеки Windows.Devices: Эта библиотека предоставляет доступ к различным устройствам, подключенным к компьютеру с операционной системой Windows. Вы можете использовать классы и методы этой библиотеки для работы с устройствами, такими как принтеры, сканеры, камеры и другие.
Использование библиотеки System.IO.Ports: Если вам нужно работать с устройствами, подключенными через последовательный порт (COM-порт), вы можете использовать классы и методы этой библиотеки. Она позволяет открывать и управлять COM-портами, отправлять и принимать данные.
Использование API устройства: Некоторые устройства имеют свои собственные API, которые позволяют взаимодействовать с ними через C#. Например, если вы хотите работать с принтером, вы можете использовать API принтера для отправки печатных заданий и получения статуса печати.
Использование сторонних библиотек: Существуют сторонние библиотеки, которые предоставляют дополнительные функциональные возможности для работы с устройствами через C#. Например, вы можете использовать библиотеку LibUsbDotNet для работы с USB-устройствами.
Важно помнить, что для работы с конкретными устройствами вам может потребоваться изучить их документацию и использовать соответствующие драйверы или SDK. Кроме того, учтите, что работа с устройствами может потребовать определенных разрешений или привилегий на компьютере или устройстве, с которым вы работаете.
Интересные факты и фичи языков программирования у нас в канале, заходи :)
В наше время большинство портативных устройств работает на базе достаточно мощных микроконтроллеров, которые способны запускать даже интерпретируемый код на Lua/Python. Чего уж там говорить — даже современная кофеварка или умный электрочайник может быть в разы мощнее оригинального IBM-PC, не говоря уже о автомобильных бортовых компьютерах, которые зачастую мощнее топовых ПК из начала нулевых. Но давайте вспомним конец 90-х и начало 2000-х, когда разработка собственной электроники была практически недоступна рядовому пользователю, а микроконтроллеры программировались в основном только на ассемблере. Недавно я нашёл некоторую информацию о том, какой процессор вероятно использовался в таких знакомых нам приставках Brick Game, которые мы называли «Тетрисами»! Более того, мне удалось найти полный даташит с описанием всех модулей этого процессора, который гордо можно назвать «система на кристалле». Какой была разработка микроэлектроники в 90-х? Читайте в статье!
❯ Немного о «Тетрисе»
Пожалуй, Тетрис или Brick Game был одной из самых популярных портативных игровых консолей в странах СНГ. Появившись где-то в конце 90-х, этот гаджет быстро стал бестселлером среди детишек благодаря наличию сразу нескольких игр, полноценного ЖК-экрана, звука и невероятной дешевизны. Не знаю, сколько Тетрис стоил в момент выхода, но в нулевых цена на него была крайне низкой — около 100-200 рублей в зависимости от корпуса. Типичный школяр мог накопить на собственный Тетрис за несколько недель, что делало его самым доступным игровым девайсом на рынке.
Конечно же, на рынке уже были различные консоли с гораздо более богатым функционалом — например GameBoy и даже GameBoy Color с цветным дисплеем, а люди, родившиеся в конце 90-х или начале 2000-х уже застали PlayStation Portable с реально крутой 3D-графикой и телефоны с хорошим игровым потенциалом — как, например, SE K500i. Однако цена на них была непозволительной роскошью для небогатых семей: PSP стоила 250$ (около 7-8 тысяч рублей по тому курсу), плюс каждый UMD-диск с игрой стоил около 1.000 рублей, GameBoy были относительно редкими в России, а телефоны — это всё же прерогатива более юных ребят, да и в нулевых далеко не всем перепадал крутой K500i — чаще всего покупали телефон попроще типа Siemens A55 (грузчика помним?) или Motorola C350 (а мотоциклиста?). Поэтому тетрисы оставались чуть ли не единственным средством развлечения у небогатых ребят.
Ощутимым плюсом было и то, что Тетрис работал от батареек: они были не слишком дорогими в то время, а если носить с собой в кармане парочку, то можно не бояться, что консоль сядет в долгой дороге и продолжать себя забавлять, да и сам Тетрис работал довольно долго, мне хватало на неделю игры (может и меньше). Несмотря на низкое разрешением всего в 10x20 пикселей, Тетрис обладал достаточно большим монохромным дисплеем без подсветки, на котором было комфортно играть. Ещё одним немаловажным плюсом консоли была возможность «кооперативной» игры и эдакого азарта: будучи неискушенными детьми, многие из нас пытались поставить рекорды и выбить как можно больший счёт в каждой из доступных игр. Чем больше счёт, тем ты круче среди друзей!
Но что же у Тетриса «под капотом»? На чём он работал внутри? Недавно я нашёл информацию о том, что потенциально в Тетрисе могла использоваться 4х-битная система на чипеHoltek HT1130, которая использовалась в самой разной носимой электроники: от часов на батарейках, до полноценных игровых консолей. Причём я ничуть не преувеличиваю, это действительно SoC: уже в 90-х, тайваньская компания смогла объединить звуковой модуль, контроллер ЖК-дисплея, ввод/вывод и таймер в один чип! Однако тут важно понять, что 100% сказать, на чём работал Тетрис, нельзя — процессор спрятан под компаундом и у него нет корпуса с маркировкой, лишь «голый» кристалл. Тем не менее, мы можем предположить, что это был один из чипов Holtek и посмотреть, на чём же работала портативная электроника тех лет поближе!
Заранее прошу прощения за отсутствие нормальных фотографий. Под рукой у меня не оказалось «старого» Тетриса, а на новодельных показывать как-то не очень.
На данный чипсет есть «утёкший» в сеть даташит с полным описанием регистров микроконтроллера и его ТТХ. Чип был спроектирован так, чтобы не требовать практически никакой обвязки в виде конденсаторов/резисторов и других SMD-элементов — он работал фактически напрямую от пальчиковых батареек и его легко было развести на плате даже начинающему инженеру. Микроконтроллер стабильно оперировал при напряжении от 2.4в до 3.3в, что позволяло просто вставить две последовательно соединенные AA или AAA батарейки с напряжением 1.5-1.6в и получить необходимое питание для работы всей «приставки».
❯ Вычислительное ядро
Саму систему на кристалле можно разделить на несколько соединенных модулей в один чип. Основным, конечно же, является 4х-битное вычислительное ядро неизвестной архитектуры, которое компания Holtek разработала сама или лицензировала как IP-ядро у другой компании для использования в собственном чипе (как, например, MediaTek лицензирует у ARM ядра Cortex). Система команд, по крайней мере, описание мнемоник ассемблера в даташите наводят на мысли о некоторой схожести с микроконтроллером Intel 8051 (однако 8051 был 8-битным) и в целом, напоминают типичную интеловскую архитектуру из 80х. Однако только по мнемоникам точно определить архитектуру невозможно: здесь есть «проприетарные» команды типа SOUND и TIMER.
Чип работает на частоте 1мгц от встроенного тактового генератора, большинство команд выполняется за один такт, максимум — два. Если говорить совсем грубо, то даже ATMega328 в Arduino условно в 16-раз мощнее HT1130, хотя это совсем некорректное сравнение.
Длина машинного слова HT1130 — 4 бита, что отсылает нас в начало 70х годов, если мы говорим о компьютерах. Это означает, что процессор «аппаратно» мог выполнять операции только с числами от 0 до 16, хотя при программной реализации мог пересчитывать хоть 32х-битные числа. Ширина шины данных — 12 бит, что позволяло адресовать вплоть до 4Кб встроенной ROM-памяти. Кроме того, в МК было встроено 128 ячеек оперативной памяти (или 64 байта), где в00H..7FHхранились временные данные программы (например, позиция танчиков на экране) и сE0H..FFHхранился «буфер» кадра, который определял текущую на экране. Также у микроконтроллера были следующие регистры:
R0-R4 — регистры общего назначения. Пары из регистров используются для адресации памяти.
ACC — регистр-аккумулятор, который хранит результаты текущей операции.
PC — указатель на текущую инструкцию в ROM, которую выполняет процессор.
Стековый регистр — судя по всему, «невидимая» связка регистров, которую процессор использует для хранения PC при вызове функций. Ограничен максимум двумя адресами, что не даёт возможность писать программы с вложенностью более двух функций.
С стековым регистром всё интересно получается. В отличии от привычных нам архитектур, HT1130 не хранит в этом регистре указатель на память, он сам по себе как-бы является стеком. Пример допустимого и недопустимого кода:
Выбор 4х-битного процессора очевиден — они очень недорогие в производстве и достаточно простые. Примеры использования 4х-битных архитектур можно найти даже в советских играх: например, в игре «Волк и яйца» (клоне Nintendo Game & Watch) использовалась «микроЭВМ» КБ1013ВК1-2. В встраиваемой и переносной электронике, 4х-битные вычислительные ядра продолжают использоваться и сейчас: в калькуляторах, в пультах для управления техникой, в часах. Связано это с простой и дешевизной подобных решений, да и если честно, реализация этих устройств была готова ещё в прошлом веке. Зачем дополнительно тратить деньги на R&D существующих решений? :)
❯ Графика
HT1130 специально разрабатывался для переносимых устройств с новомодными LCD-дисплеями. В те годы было нормой, когда на дисплейной матрице не было собственного контроллера с распространенным интерфейсом по типу 8080 или MIPI: частенько, драйвер дисплея либо выделялся в отдельный чип, либо реализовывался прямо в системе на кристалле. У Brick Game был дисплей разрешением в 10x20 пикселей, причём кастомизированный — с «захардкоженными» значками и сегментными индикаторами:
Работа с дисплеем была не особо сложной: один сегмент памяти был отведен специально под эдакий «фреймбуфер» — всё, что мы записывали туда, контроллер дисплея моментально отображал на нашу ЖК-матрицу. Поскольку дисплей был одноцветным, без градаций цвета, память была организована 1 бит — 1 пиксель. Работать со всем этим было как-то так:
MOV A, 0 ; Первая часть адреса (если я не напутал endianness)
MOV R1, A
MOV A, 0b0111 ; Вторая часть адреса. Не удивляйтесь, что по факту получается 224 при 128 байт ОЗУ - часть адресного пространства была как-бы зарезервирована
MOV R0, A
MOV A, 1 ; Закрасим первый пиксель в строке
MOV [R1R0], A ; И запишем это значение в ОЗУ
Частичным доказательством того, что этот чип мог использоваться в Brick Game — это то, что компания Holtek производила готовые «игры на кристалле» — вероятно, уже запрограммированные с завода HT1130 с определенными играми:
Примечательно, что даташит на готовые игры датируются ноябрём 1998 года, в то время как даташит на HT1130 — 1999. Если у вас появился Тетрис раньше этого времени — напишите пожалуйста в комментариях!
❯ Звук
Помимо этого, чипсет имел собственный генератор звука, или как вы вероятно подумаете — «пищалку». В чип (или SDK, если честно, не особо понятно из даташита) была уже встроена звуковая библиотека — причём половину из них как раз таки для игр, что ещё раз косвенно подтверждает догадки об использовании этого чипа в «Тетрисе». Всего поддерживалось до 16 «каналов», в которых было по 3 тональности. В звуковой библиотеке содержались следующие звуки:
Шумы
Мелодии
Выстрелы
Будильники
Управлять звуковым трактом было очень просто — буквально несколькими командами на ассемблере. Команда SOUND <номер канала> выбирала один из предопределенных звуков (причем не совсем ясно, где они хранились — возможно в ROM), а команда SOUND ONE/LOOP воспроизводила его в одном из режимов — один раз или повторяющийся. SOUND OFF же выключала звук совсем. Как-то так:
play:
SOUND A
SOUND ONE
SOUND OFF
CLC ; А если нет, то снова выполняем, пока не переполнится, эта операция очищает флаг переноса
loop:
INC A ; Увеличиваем значение в аккумуляторе
JC play ; Если флаг переноса установлен, то наш "таймер" как-бы переполнился и пора снова проиграть звук
JMP loop;
Совсем немудрено, согласитесь? :)
❯ Порты ввода/вывода и кнопки
Кроме этого, HT1130 имел несколько портов ввода-вывода, которые, однако, назвать GPIO нельзя — было 12 портов для вывода, которые могли читать логический уровень (для кнопок), и 4 пина, который мог задавать логический уровень (например, управлять вибромотором или светодиодом). Настройки портов задавались с помощью флагов: можно было настроить встроенные pull-up резисторы и они могли вызывать прерывания при переходе из высокого уровня в низкий.
Выходной порт мог быть сконфигурирован под тип выхода — CMOS или NMOS. Работа с портами шла с помощью команд IN и OUT — как в x86, а обрабатывать их можно было как-то так:
loop: IN A,0b00110010 ; Загрузить в аккумулятор значение порта PM
AND A,0b0001 ; Отсекаем биты состояний других кнопок и проверяем, нажата ли первая кнопка?
JNZ A, btn_pressed ; Если в аккумуляторе не 0 (а значит кнопка нажата) - то переходим на другую метку
JMP loop ; Если нет - то проверяем по новой
btn_pressed:
SOUND 0
SOUND ONE ; Воспроизвести звук при нажатии
❯ Таймер
В чипсете есть встроенный таймер — ну его ж не просто так для часов использовали. :) Основная суть работы аппаратных таймеров заключается в том, что его тактирует какой-либо внешний тактовый генератор с определенным делителем, в нашем случае — от 1 до 6 относительно системного генератора частоты (т.е 1мгц) и с определенной частотой он делает инкремент внутреннего регистра. Как только регистр переполняется — он очищается и вызывается соответствующее прерывание в основном процессоре.
Это позволяет регулировать скорость работы таймера, а посчитать количество тиков в таком случае не особо сложно. Однако учтите, что чем выше делитель таймера (а значит и обратно-пропорционально снижается точность таймера) — тем реже вызываются прерывания и меньше «кушают» наше процессорное время!
❯ Можно ли написать свою программу для Тетриса?
К сожалению, написать какую-нибудь свою игру для этой консоли в домашних условиях невозможно — таких удобных инструментов для прошивки, как у AVR ещё не было. Holtek предлагала собственный SDK, в которое входила IDE, ассемблер и симулятор отладки финальной программы. Однако дабы получить настоящее «хардварное» устройство, необходимо было заказывать у компании Holtek производство кастомизированного чипа с вашей программой на борту.
Чипсет использовал настоящую масочную Read-Only Memory, которая прожигалась один раз и навсегда на заводе. Производитель электроники отсылал скомпилированную программу Holtek, а они в свою очередь производили кастомный чип с прошитой программой. Несмотря на всю простоту ассемблера и устройства в целом, самому под него ничего написать не получится — внешних шин то у него нет. :(
Однако, в наше время можно разработать и собрать «Тетрис» самому: в том числе, с цветным дисплеем и на базе гораздо более мощного железа! Тут тебе и готовые мощные микроконтроллеры, и возможность собрать приставку на базе легендарного процессора Z80, да при желании можно симулировать почти настоящий HT1130 на FPGA!
❯ Заключение
Разработка вычислительной и при этом недорогой электроники в 90-х было весьма веселым занятием. Несмотря на то, что устройства были на первый взгляд достаточно примитивными, в них всё равно крылось много разных нюансов, которые ограничивали программистов во многом.
Однако embedded-разработка тех лет была весьма интересной: когда полноценные игры вмещали в ПЗУ размером пару килобайт, на ремейки Space Invaders на современных движках весом в под сотню мегабайт смотришь с некоторой улыбкой. :)
Выкручивайте остроумие на максимум и придумайте надпись для стикера из шаблонов ниже. Лучшие идеи войдут в стикерпак, а их авторы получат полугодовую подписку на сервис «Пакет».
Кто сделал и отправил мемас на конкурс — молодец! Результаты конкурса мы объявим уже 3 мая, поделимся лучшими шутками по мнению жюри и ссылкой на стикерпак в телеграме. Полные правила конкурса.
А пока предлагаем посмотреть видео, из которых мы сделали шаблоны для мемов. В главной роли Валентин Выгодный и «Пакет» от Х5 — сервис для выгодных покупок в «Пятёрочке» и «Перекрёстке».
Реклама ООО «Корпоративный центр ИКС 5», ИНН: 7728632689