Начинаем понедельник с очередного экспоната в виртуальном музее. Сегодня это фотокамеры ФК 18х24 и ФК 13х18. Они абсолютно идентичны по конструкции, различаются лишь размером фотоматериала. И выпущены в один год - 1955. Камеры производились вплоть до 1987 года.
ФК 18х24.
ФК 13х18
Из коллекции Черненко А.
Дополнительные фото в источнике материала и комментариях.
Прошлая статья с попыткой собрать что-то наподобие MIDI-модуля, судя по всему, вам понравилась, поэтому держите описание ещё одного модуля — на сей раз голосового синтезатора — с несколько более запутанной историей, более сложным чипом и менее вырвиглазной дыркой вокруг экрана :-)
Начнём со сжатого экскурса в историю.
После того, как люди научились синтезировать произвольные звуки, инженеры всего мира постоянно предпринимали попытки сделать его похожим на человеческий голос. Обыкновенный TTS, вполне пригодный для чтения текстов, существовал ещё в середине прошлого века, однако же заставить его именно петь не удавалось.
Всё изменилось с началом исследовательского проекта в Университете имени Пумпеу Фабра в Испании, возглавленного Хидеки Кенмоти и профинансированного компанией Yamaha. Результаты этого исследования впоследствии вылились в коммерческую технологию под названием Vocaloid.
Первые вокалоиды звучали довольно примитивно. По сравнению со всеми прошлыми технологиями это был прорыв, но оглушительным успехом назвать их было сложно. Ровно до тех пор, пока компания Crypton Future Media в 2007 году, взяв за основу движок Vocaloid 2, не выпустила то, что впоследствии совершило фурор в концепции гострайтинга: Хацуне Мику.
Секретом успеха стал не только и не столько удачный голос, сколько то, что это по сути была «поп-звезда в коробке»: при покупке вы получали не только саму программу для синтеза голоса, но ещё и возможность использовать самого персонажа по Creative Commons CC-BY-NC.
Миловидный персонаж с новым для многих голосом лёг на благодатную почву активно развивавшегося тогда культурного сегмента японского интернета. Эпоху удачнее придумать было нельзя — активный бум User-Generated Media, параллельно с переползанием от Shockwave Flash к видеоконтенту на тогда ещё совсем молодом видеохостинге Nico-Nico Douga. Но главным плюсом было даже не это — ведь в отличие от настоящей, живой поп-звезды, Мику просто физически не могла отказаться спеть то, что вы ей там понаписали.
Это породило множество споров и дебатов, а также западающих в душу песен. Среди прочих отличился, например, deadballP — запаковывая в свои песни с лютейшим джазовым вайбом абсолютно неожиданные слова. Порой настолько неожиданные, что сам Nicovideo композитора неоднократно банил за «нарушение общественного порядка». Для примера, предлагаю читателям ознакомиться с его джазовой импровизацией с лейтмотивом «вот ты выпей молоко — сиськи будут о-го-го!» :-)
Бум user generated content подкрепился выходом игры Project DIVA на PSP, куда взяли самые популярные песни, разбавив 3D-графикой для видеоклипов, до кучи добавив возможность создавать свои клипы и карты из произвольных MP3-файлов.
Таким образом, разработчики получили не только дико популярную франшизу, но и неиссякаемый поток заведомо успешного готового контента для неё.
А популярность была на внутреннем рынке просто невообразимая! Первая версия игры побила все топы продаж в свой сезон, и разлеталась как горячие пирожки.
Вот, например, было подразделение SEGA AM2 — то самое, которое подарило нам такую классику, как Shenmue, Out Run, Virtua Fighter или Daytona USA. Его на тот момент возглавлял Макото Осаки — и даже ему не удалось получить копию игры по внутренним каналам, пришлось покупать в обычном магазине.
Впрочем, игра ему нужна была не для того, чтобы отдохнуть в свободное время, а ради того, чтобы внутри своей команды изобразить порт её на движок Virtua Fighter.
И вот когда порт был уже готов, и Осаки было уже пошёл к продюсеру Уцуми Хироши с идеей сделать аркадную версию Project DIVA — другой сотрудник AM2, Ясуси Ямасита, предложил: «А почему бы нам эти наработки не использовать для создания живого концерта?»
Идея менеджменту понравилась, за каких-то два месяца кранчей они подготовили революционный ивент — Miku Fes 2009. (Обо всей хронологии — как-нибудь в другой раз :-) Концерт собрал аншлаг, начало было положено — Мику и по сей день выступает с концертами чуть ли не каждые полгода, собирая огромные залы.
(Один из самых любимых концертных треков последних лет. До сих пор не верится, что мне выпала честь слушать его прямо из первого ряда!)
А писать для неё песни, в отличие от какой-нибудь Бритни Спирс и иже с ними, могла не только лишь конкретная команда шведов, а любой человек с мало-мальски развитым слухом и каким-никаким компьютером — прямо таки народное творчество во всей красе.
Возможность создавать записи, конечно, весьма хороша, но ведь музыку зачастую принято исполнять живьём. В наше время Ямаха выпускает что-то наподобие клавитары на базе своей платформы от обычных цифровых клавиатур:
(к сожалению, на выставке разобрать и сфоткать процессор и разводку платы не разрешают :-))
Однако среди всего многообразия способов извлечения звуков из Мику и Ко. примерно 11 лет назад проскакивал такой интересный прототип, который и запал мне в душу:
Известно о нём было только то, что рабочие название технологии — eVOCALOID (Embedded Vocaloid). Впоследствии вышел пресс-релиз, в котором анонсировали микросхему с его поддержкой — YMW820-S.
Судя по даташиту и параметрам, мне думается, что это какая-то переработка старых чипов из серии Mobile Audio — из тех, что стояли в корейских телефонах с синтезом голоса для уведомлений.
Самым известным устройством на базе этого чипа был Pocket Miku — стилофон от Gakken из серии журналов «Otona no Kagaku».
[via]
Сколько-то лет назад я покупал такой на Yahoo! Auctions, чтобы переслать другу, и стоил он очень недорого. Тогда я ещё удивился, что оно умеет работать как USB-MIDI синтезатор.
Поэтому, когда в этом году полез во всю эту MIDI-тему, то подумал — MIDI-to-USB-host адаптеры штука обыденная, а стилофон стоит копейки, можно бы что-то и сделать! Но тут меня ждал облом — ценник на эти штуки за последние пару лет вырос примерно на порядок с лишним.
Однако вдумчивое чтение пресс-релиза навело на ещё один вектор — некий шилд для ардуины eVY1 Shield, выпускавшийся компанией AIDES.
Более того, он выпускался и в виде готового устройства eVY1 BOX, но и дизайн и цена (¥27,500 = примерно $250) оставляли желать лучшего.
Зарядник от макбука словил кризис среднего возраста и решил податься в музыку
Поэтому я ухватил один из каким-то чудом оставшихся шести «сырых» модулей на амазоне безо всякой обвязки и решил скрафтить свою коробочку. И вот через пару дней у меня в руках самая дорогая микросхема в моей жизни:
С обратной стороны видим уже знакомый по Pocket Miku процессор GPEL3101A и SPI-флешку — то есть в теории оно должно суметь запустить и голос от Pocket Miku!
Быстренько раскидываем на макетке:
Для минимального включения достаточно лишь пары разъёмов и 10кОм-резистора с VBus на USB_SENSE
И да, оно поёт! Правда тихо и шумно, ведь единственный близкий к линейному выход — «наушниковый», использующий ЦАП внутри процессора GPEL, который и дудок, и жнец, и вообще — трындец, в смысле сочетает в себе полный ящик переферии от флеш-контроллеров и прочих USB до генератора вторичных напряжений питания и ЦАП/АЦП :-)
Поёт этот модуль голосом VY1, также известным как MIZKI — собственный голос от Ямахи. Что, в принципе, логично, ведь Мику для этого модуля не лицензировали. Но хотел-то я чиптюн именно с Мику!
Копание в различных слоях интернета приводит к домашней страничке некоего Hummtaro, который переделал программу-программатор от eVY1 в утилиту для сохранения и прошивки ПЗУ целиком (а я уже за прищепкой на алик бежать хотел...). Также он заботливо забыл удалить оттуда копию ПЗУ своего Pocket Miku :-)
До кучи у него же на канале есть видео, где он наоборот прошивает голос VY1 в Pocket Miku.
Поэтому качаем тулзы, дампим ПЗУ и смотрим, сходства и отличия.
Кажется, где-то тут и начинаются голосовые сэмплы:
Сразу в глаза бросается большой блок данных на #40000h, который, судя по всему, и есть войсбанк. О, ну значит всё так просто! Удаляем из дампа ПЗУ родной блок данных, вставляем таковой из Pocket Miku — впритык, но поместилось. Прошиваем!
И первой композицией, которой мы насладимся в исполнении аппаратной Мику, будет 4'33" Джона Кейджа!
Пытаясь исполнить эту композицию на пианино, мой брат сломал обе ноги и руку:
Всё потому что на выходе ноль. Зеро. Ни-че-го. Ни откликов на ноты, ни даже на SysEx, который должен показать версию прошивки.
Значит, пришло время доставать драконоголовую змею и разбираться, что же там в прошивке. Но вот беда — есть бинарный блоб, который ни по какому адресу грузить непонятно, ни какая у него структура в целом неясно. Всё, что известно о процессоре — это то, что внутри ARMv7-ядро.
Эксперимента ради грузим прошивку от Pocket Miku. Ожидаемо, не работает, но на одном из пинов модуля, отмеченном как «UNUSED», появляется сигнал, подозрительно напоминающий UART. Цепляемся туда консолькой и, о чудо, там логи!
Фраза ptr=20040000 как бы намекает нам, что наш блоб прошивки в адресном пространстве процессора попадает на адрес #20000000h, но как убедиться, что это не отдельный раздел, и исполняемый код находится в том же блоке адресов?
Просто находим в блобе текст ptr=%x,data=%x,r_data_size=%x… и дописываем к нему .%08x%08x%08x %)
Всё развалилось, но не до конца:
После строки логов видим ещё два 32-битных числа — первое является чем-то непонятным, а вот второе — #20003a84h — явно адрес того кода, который вызвал функцию логирования.
Как это работает? Очень просто: каждый следующий аргумент для формирования строки через printf берётся со стека, поэтому если мы возьмём оттуда больше, чем было заложено разработчиком — например, добавив ещё токенов форматирования — то напечатается то, что было на стеке дальше. В нашем случае там был и адрес возврата, который указывал на инструкцию, следующую за той, которая вызвала печать этой строки.
Грузим файл в гидру по адресу #20000000h, прыгаем на смещение #3a84h, жмём Disassemble — и всё взрывается, как попкорн в микроволновке.
Дальше идёт полторы недели медитации над листингом с постоянными попытками перетащить куски инициализации DSP из прошивки Pocket Miku в прошивку eVY1, на случай если просто-напросто не выделяется достаточно памяти перед заливкой войсбанка в него. Но всё тщетно.
В какой-то момент от безысходности я начинаю просто рандомно обрезать войсбанк Мику и прошивать его — и замечаю, что если обрезать его по размеру родного голоса, но сохранив последние 4 байта как в оригинале, то частично всё начинает работать. Ну, пока не попытаешься воспроизвести фонему, которая в прошивку не попала :-)
Постепенно увеличивая блок данных, бинарным поиском прихожу к тому, что всё ломается на превышении прошивкой размера в #1CFE00h байт. Не, ну если бы хотя бы #1D0000h, я бы подумал, что контроллеру флешки не выделяется окно достаточного размера, а так это выглядит как какой-то глупый баг.
Беру родное ПЗУ, добавляю по подозрительному адресу 16 байт мусора — не работает, хотя ту часть памяти мы вообще читать не должны, ведь родной войсбанк существенно короче!
И почти тут же натыкаюсь на странный кусок кода, которого в прошивке Pocket Miku не было. Судя по всему, он проверяет, есть ли по этому самому подозрительному адресу какие-то данные, и если есть — инициализирует USB и вешает систему.
С учётом, что у нас одно ядро и один поток — где-то тут всё и закончится
Обидно, могли бы хоть рядом пасхалочку оставить :-(
Патчим эту проверку и ещё пару похожих, заложенных по разным адресам в разных функциях — и ура, играет, работает!
Во-первых, раз уж у нас теперь есть два голоса, почему бы не иметь возможность их переключать? Благо, это делается очень просто — так как линия Chip Select у флешки инвертированная (активна при лог. «0»), то достаточно лишь двух элементов ИЛИ и одного инвертера, чтобы получить схему, переключающую флешки по необходимости:
Сигнал ALT_ROM выбирает, используется основное или дополнительное ПЗУ, а остальные идут напрямую на шину самого модуля:
После переключения ПЗУ просто дёргаем RESET у модуля и он после перезагрузки начнёт петь другим голосом.
Во-вторых повесим на GPIO модуля светодиоды, раз уж они были на родном шилде. Правда не то в даташите ошибка, не то я криво читал — выходы GPIO там Active Low, поэтому в моём включении они постоянно горят и периодически гаснут, а не наоборот.
Так делать не надо, делать надо не так!
Добавляем операционник для того, чтоб привести звук хоть немного к линейному уровню, обыкновенную схему MIDI-входа как в прошлый раз (заменяя каждый логический буфер на пару инверторов, благо их у нас тут в достатке), и ардуину с экранчиком чтобы ловить SysEx'ы переключения ПЗУ и заодно отображать находящиеся в данный момент в ОЗУ фонемы.
Охапку дров, и плов готов!
Раскидываем на макетке, раунд 2:
Кажется, стоило наконец уже зарегистрироваться на JLC PCB...
Без аудиофильских конденсаторов звучать будет точно так же, но радости никакой не принесёт
В прошлый раз в корпусе осталось много свободного места, поэтому на сей раз я взял корпус на размер меньше. Конечно же, теперь его не хватило и всё пришлось сильно утрамбовывать! Также в этот раз взял вместо клавишного выключателя тумблер, так как с клавишным ощутимо проседает напряжение в зависимости от везения.
До кучи добавился USB-хаб, чтобы можно было прошивать оба чипа без разборки устройства
И вуаля, готово!
Теперь нужно написать хотя бы один MIDI-файл, чтобы на этом всём слушать. Из всего обширного списка дополнительных команд нас интересуют только несколько:
F0 43 79 09 10 07 00 aa bb cc F7: отключение звука для определённых каналов:
Биты в позициях aa, bb, cc отключают воспроизведение части каналов
Например, паттерн 7E 7F 7F оставит только первый канал, что нам и нужно для использования модуля чисто для синтеза голоса без остальных MIDI-инструментов.
F0 43 79 09 01 01 00 F7: перезагружает модуль (например, после переключения ПЗУ).
F0 43 79 09 10 04 nn F7: выставляет режим работы GPIO:
nn = 00: выключить
nn = 01: ритм-визуализатор (вокал, бочка, средний, тарелки)
nn = 02: реакция на note-on/note-off в 1-4 каналах
nn = 03: визуализатор первого канала по нотам
nn = 04: ручная установка в виде битовой маски командой F0 43 79 09 03 00 xx F7
F0 43 79 09 00 50 10 dd dd ... F7: установить список фонем (слова песни):
Где dd: байты null-терминированной CSV-строки с фонемами в ASCII
Фонемы можно найти в документации по системе команд YMW820 на 34 странице
Их можно загружать и через NRPN-сообщения, но пока что обойдёмся без этого
В остальном по эффектам и прочему модуль по большому счёту совместим с системой команд Yamaha XG.
У первого MIDI-канала нельзя сменить инструмент — именно там и находится вокал. После задания фонем через SysEx-команду, каждое Note On событие в первом канале сдвигает указатель в буфере фонем на следующую, а после последней — перематывает его на начало. Проще говоря, одна нота — один слог, и так в цикле, пока не загрузишь новую строку в память :-)
Воспользуемся этим, чтобы отлавливать команды установки фонем ардуиной и отображать скроллер со «словами» на дисплее. До кучи добавим и пару своих команд:
F0 7B 7F F7: «жёсткий» сброс чипа, на случай если тот зависнет :-)
F0 7B 00 0r F7: выбор ПЗУ голоса:
r=0 — основной, r=1 — вторичный
F0 7B 01 F7: установить текущий голос по умолчанию.
F0 7B 02 tt dd dd... 00 [xx xx xx ... 00] F7: показать сообщение на экране:
tt — время в секундах
dd dd… 00 — нуль-терминированная верхняя строка экрана
xx xx… 00 — опциональная нуль-терминированная нижняя строка экрана
После пары часов мучений (и двух-трёх месяцев спровоцированной ими прокрастинации) выяснилось, что ноты, написанные в стиле караоке, уж совсем не совпадают с количеством фонем в песне, а выравнивать их, не видя, на каком месте строка ломается, практически невозможно.
Поэтому берём поллитру, вспоминаем MFC и патчим такой замечательный редактор, как Sekaiju, на отрисовку слогов под нотами:
Если разваливается, то хотя бы сразу видно, где
Дорисовываем остаток совы… В смысле, дописываем аранжировку в Sekaiju, и потом доводим эффектами в Yamaha XGWorks. Попутно я докинул ещё пару партий в формате AYYMIDI (из прошлой статьи), написав их в ProTracker.
Помимо прочего, нашлось ещё несколько подводных камней:
Как и обещал производитель, поёт NSX-1 ну очень медленно. Даже в такой медленной песне есть места, где приходилось делать рокировочки таймингов десятки раз, чтобы получить более-менее вменяемый саунд. Какой-нибудь Intense Voice уж точно по битрейту не пролезет, разве что интерливом в несколько чипов через управляемый микшер :-)
По ощущениям, использование NSX-1 для всех инструментов ещё сильнее замедляет воспроизведение голоса, поэтому лучше использовать его чисто для вокала, даром что по качеству звучания его даже Yamaha MU50 уделывает с лихвой. Сделать это можно последовательностью команд:
F0 43 79 09 10 07 00 7E 7F 7F F7: NSX Channel Mute, оставляем только 1 канал.
GM Volume Ch1 = 127: выставляем громкость вокала на максимум.
XG Volume Ch1 = 0: отключаем первый канал на MU50. За счёт того, что NSX игнорирует многие XG команды на первом канале, его громкость останется на 127.
Из-за того, что Vendor ID у NSX и у серии MU совпадает, использовать тот же MU50 как RS232-MIDI интерфейс не получилось — слишком сильно задерживаются SysEx'ы задания фонем и слова начинают съезжать относительно нот.
Воспроизведение отдельных нот напоминает скорее чтение текста, чем пение, поэтому Note Off каждой ноты вокала лучше ставить чуть дальше, чем Note On следующей за ней:
Это создаёт проблемы, когда несколько слогов идут одним тоном, что нужно учитывать при написании аранжировки.
Однако, эту особенность можно использовать для реализации удвоения (っ、напр. в демо-песне для этой статьи слово わらった [waratta] чаще всего записано путём двух «наложенных» нот [wa] [ra], затем Note Off второй, и только после этого «впритык» Note On для [ta].
Ни сам чип, ни генератор команд eVo Phonetic не поддерживают удвоение согласных, поэтому единственный другой способ — продублировать слог целиком, но обрезать ноту так, чтобы чип «не успел» дойти до гласной. Иногда это работает, но часто звучит странно и упирается в проблему скорости из п. 1.
Ударения как такового в японском языке нет, но лучше всё равно добавлять экспрессии и подрезать редуцирующиеся звуки через Velocity.
Для конвертации файлов под аппаратные плееры многие пользуются программной MIDI Formatter — оказалось, она перемешивает местами каналы, поэтому для композиций написанных под NSX-1 её использовать нельзя. Впрочем, конвертировать файлы в SMF0 можно через диалог «Сохранить как» в программе XGWorks.
Не буду погружать во все остальные тонкости написания MIDI-аранжировок, ведь статья получилась и так слишком длинной — лучше дам послушать итоговый результат :-)
Первым делом, конечно же, была запрограммирована классика жанра: malo — Hajimete no Oto (The First Sound)
Казалось бы, одним треком можно было и ограничиться — голос слышно, вроде как будто даже поёт, всё хорошо. Но хотелось всё-таки выжать из конструкции побольше музыкальности, а не просто мелодию в трёх дорожках… Поэтому статья была отложена больше чем на полгода, пока я допишу аранжировку той самой песни Shabon — как дань уважения всей этой культуре, на удивление тёплоламповому вопреки всем событиям 2020 году, да и в целом, потому что душа просила что-то поинтереснее :-)
Впрочем, чип оказался всё же слишком сложным, поэтому звучания прямо один к одному не вышло.
Увы, код в этот раз слишком простой и никаких особых лайфхаков не содержит, а схема паялась в основном по наитию из головы.
Если вдруг кто-то имеет такой чип и захочет повторить конструкцию — могу, конечно, причесать всё и расшарить, но пока что вот так ¯\_(ツ)_/¯
К огромному сожалению, старые смартфоны всё чаще и чаще находят своё пристанище в мусорном баке. К прошлым, надежным «друзьям» действует исключительно потребительское отношение — чуть устарел и сразу выкинули, словно это ненужный мусор. И ведь люди даже не хотят попытаться придумать какое-либо применение гаджетам прошлых лет! Отчасти, это вина корпораций — Google намеренно тормозит и добивает довольно шустрые девайсы. Отчасти — вина программистов, которые преследуют исключительно бизнес-задачи и не думают об оптимизации приложений совсем. В один день я почувствовал себя Тайлером Дёрденом от мира IT и решил бросить вызов проприетарщине: написать свою прошивку для уже существующего смартфона с нуля. А дабы задачка была ещё интереснее, я выбрал очень распространенную и дешевую модель из 2012 года — Fly IQ245 (цена на барахолках — 200-300 рублей). Кроме того, у этого телефона есть сразу несколько внешних шин, к которым можно подключить компьютер или микроконтроллер, что даёт возможность использовать его в качестве ультрадешевого одноплатника для DIY-проектов. Получилось ли у меня реализовать свои хотелки? Читайте в статье!
Честно сказать, идея попытаться реализовать свою прошивку мне пришла ещё давно. Однако, дабы не завлекать опытного читателя кликбейтом, я сразу поясню, в чём заключается «прошивка с нуля»:
Мы всё ещё используем Linux: в качестве ядра мы продолжаем использовать образ Linux, предоставленный нам производителем. Написание прошивки полностью с нуля заняло бы очень много времени (особенно без схемы на устройство). Однако, мы вообще не загружаем Android никаким образом.
Мы не используем библиотеки AOSP: наша прошивка без необходимости не использует никаких библиотек уже имеющегося образа Android. Вся работа с железом происходит с помощью низкоуровневого API Linux. Это значит, что отрисовка графики, звук, управление ресурсами и питанием ложится полностью на нас.
Прошивка может запускать только нативные программы: да, это тоже камень в сторону Android. Изначально, наша прошивка умеет запускать только нативные программы, написанные на C. Причём она экспортирует собственное C API — дабы приложения могли использовать всю мощь нашего смартфона в виде простого и понятного набора методов.
Проектов по выкидыванию Android из, собственно, Android-смартфонов как минимум несколько: UBPorts — бывший Ubuntu Touch, FireFox OS и его наследник Kai OS и конечно же, postmarketOS. Отчасти можно сюда отнести и Sailfish OS — но там образы имеются в основном на смартфоны от Sony. Все эти проекты объединяет сложность портирования и невозможность их завести на устройствах без исходного кода ядра. Даже если у вас есть исходный код ядра, но, например, устройство использует ядро 2.6 — навряд-ли вы сможете завести современный дистрибутив на нём.
Другой вопрос в том, что можно использовать полу-baremetal подход, когда от Linux берется практически минимальный функционал. Всё, что мы имеем — busybox, libc и низкоуровневый доступ к железу, благодаря API самого ядра. Как под это всё программировать — я рассказывал впрошлойстатье. Этот же подход мы будем использовать и сейчас — как иллюстрация реального применения подобного способа.
Итак, что наша прошивка должна уметь:
Отрисовывать произвольную графику: графическая подсистема нашей прошивки должна работать с фиксированным форматом пикселя, уметь загружать прозрачные и непрозрачные изображения, отрисовывать картинки с альфа-блендингом и т. п.
Уметь звонить и работать с модемом: общение с модемом происходит посредством AT-команд — общепринятого в индустрии стандарта. Однако в случае нашего устройства, есть м-а-а-а-ленький нюанс, о котором я расскажу позже.
Иметь механизм приложений: мы ведь не будем хардкодить все «экраны» в прошивке в виде кучи стейтов, верно? Для этого у нас должен быть простой и понятный механизм слинкованных с прошивкой приложений.
Обрабатывать ввод: обработка тачскрина и жестов — это задача подсистемы ввода.
Реализовывать анимированный UI: здесь всё очевидно, наша прошивка должна иметь готовые элементы пользовательского интерфейса для будущих приложений: кнопки, текстовые поля и т. д. О деталях реализации этой подсистемы, я расскажу ниже (а реализовал я её очень необычно для такой системы).
Начинаем мы с хардварной части. Именно здесь я покажу вам, как использовать внешние шины вашего устройства.
В качестве смартфона для нашего проекта, я выбрал популярную бюджетную модель из 2012 года — Fly IQ245 Wizard. Это простенький китайский смартфон, который работал на базе популярного в прошлом 2G-чипсета: MediaTek MT6573, да и стоил около 2х тысяч рублей новым. Однако вот в чём суть: мне удалось заставить работать «медиатековский» модем и даже позвонить с него на свой основной телефон, но… только ввод и вывод данных из звукового тракта модема происходит через звуковую подсистему Android — к которой доступа у нас нет!
Именно поэтому, мы идём на очень хитрый и занимательный костыль: мы распаяем внешний модем сами! В качестве радиомодуля у нас выступит модуль SIM800 от компании SIMCOM. И даже он очень близок к нашему смартфону в аппаратном плане: ведь в основе этого модуля лежит популярнейший чипсет из кнопочников тех лет: MediaTek MT6261D. Преимущество SIM800 в его цене — он стоит пару сотен рублей, так что по карману выбор модема не влияет.
На весу паять крайне неудобно. В финальном варианте перепаяю нормально.
Но как его подключать? SIM800 общается с другими устройствами посредством протокола UART — универсальный асинхронный приемо-передатчик. И вот тут мы включаем смекалочку. Разбираем устройство и видим то, что я пытаюсь долгое время донести до моих читателей — аж два канала UART: один практически посередине, второй справа. Нам нужны пятачки TXD4 и RXD4:
Обычно на этот канал UART летят логи ядра, которые можно без проблем отключить минорной правкой U-Boot в HEX-редакторе. Впрочем, модем никак не реагирует на «мусор» из консоли и просто отвечает ошибками — хватит лишь очистить буфер сообщений для того, чтобы все работало нормально. Подпаиваемся к UART'у с помощью преобразователя — у меня оным выступает ESP32 с выпаянным чипом.
Увидели логи? Замечательно, пора попытаться что-то отправить на ПК и с ПК. UART работают без тактовых сигналов и зависит исключительно от старт/стоп битов и бодрейта, который на устройствах MediaTek равен 921600. TXD4 и RXD4 обнаруживаются в системе на консоли/dev/ttyMT3. Пробуем что-то отправить: всё работает!
Вот теперь-то можно подключить наш внешний модем и попытаться пообщаться с ним, отправив тестовую командуAT. Модем отвечаетOK! На этот раз я работаю с смартфоном из режимаFactory mode— практически тоже самое, что и режим recovery, но позволяющий, например, получить доступ к камере устройства. Простая и понятная схема, поясняющая что и куда подключать:
На этом модификация аппаратной частипоказакончена. Пора переходить к реализации софта! Я решил разделить материал на каждый модуль, который я реализовывал — дабы вам был понятен процесс разработки и отладки прошивки!
На этот раз я решил загружать смартфон из режима рекавери. Однако никто не мешает в будущем просто прошить раздел recovery вместо boot и получить прямую загрузку прямо в нашу прошивку. Время такой загрузки будет заниматься ~3-4 секунды с холодного старта. Очень даже ничего.
Я взял уже готовый образ TWRP для своего смартфона и пропатчил его, дабы сам рекавери не мешал своим интерфейсом. Для этого я распаковал образ recovery.img с помощью MtkImgTools и убрал в init.rc запуск службы /sbin/recovery. После этого, я залил прошивку обратно на устройство и получил подобную свободу действий — консоль через USB и чистый холст в виде смартфона! Старые смартфоны на чипсетах MediaTek шьются через USB только после замыкания тест-поинта — на моем аппарате его местонахождение очевидно. Замыкаем контакты между собой, подключаем смартфон без АКБ к ПК и ждем прошивки:
Теперь можно деплоить программы! Важный нюанс: в отличии от Makefile из прошлой статьи, для Android 2.3 параметр -fPIE нужно убрать — иначе динамический линкер (/sbin/linker) будет вылетать в segmentation fault.
В комментариях под прошлой статьёй меня похвалили за то, что я делюсь достаточно профильными знаниями касательно эффективной отрисовки 2D-графики. Собственно, к реализации графической подсистемы я подошёл ответственно и постарался реализовать достаточно шустрый рендерер, к которому затем можно подключить другие модули.
Как я уже говорил ранее, графическая подсистема должна уметь загружать картинки, выводить некоторые примитивы, выводить картинки с прозрачностью и без, загружать и отрисовывать заранее подготовленные шрифты, а также управлять отрисовкой бэкбуфера на экран.
В случае с этим устройством (и большинством старых устройств), формат пикселя оказался RGB565 — т. е. 5 бит красный, 6 бит синий, 5 бит зеленый. Конвертация форматов пикселей всегда была занозой в заднице для программных рендереров, поскольку занимает дополнительное время, которое обратно зависимо от размера дисплея. Изначально я решил выделить буфер в том же формате, что и фреймбуфер, но затем решил сделать классический и самый портативный формат — RGB888 (24х-битный цвет), а при копировании кадра на экран, на лету делать преобразования цвета:
Очень важный нюанс, который я не упомянул в предыдущей статье: на устройствах прошлых лет для обновления фреймбуфера необходимо послать структуру var_screeninfo, где хотя бы что-то изменено, иначе никаких изменений мы не увидим. Этот же костыль используется в родном recovery для отрисовки, а судя по исходникам драйвера fb, «правильный» способ обновить экран — послать драйверу ioctl (который я пока что не пробовал).
После того, как я смог управлять дисплеем, я решил загрузить и отобразить какую-нибудь картинку. Пусть это будут обои для нашей прошивки:
Загрузчик TGA сильно не поменялся: я таскаю его в неизменном виде из проекта в проект. Он поддерживает любые форматы пикселя, кроме палитровых, но я его искусственн ограничиваю на RGB888 и RGBA8888 — для поддержки обычных картинок и картинок с альфа-каналом. После этого, я написал не очень шустрые, но достаточно универсальные методы для отрисовки картинок. Для больших участков кода, я буду использовать pastebin, поскольку на Пикабу до сих пор не добавили ни подсветки синтаксиса, не нормальный перенос форматирования табов :(
PutPixel желательно заинлайнить в будущем. В целом, сама отрисовка работает достаточно быстро, но поскольку рендеринг выполняется на ЦПУ — рано или поздно мы упремся в количество картинок на экране. Есть некоторые оптимизации: например, непрозрачные картинки можно просто коприовать сканлайнами прямо в задний буфер.
Сразу же реализовываем методы для рисования шрифтов: они у нас будут совсем простенькими — только моноширинные (все символы имеют одинаковую ширину) и растровыми (для каждого размера придется «запекать» несколько шрифтов). Для этого я написал маленькую программку, которая рисует виндовые шрифты прямо в наш самопальный формат:
Формат примитивнейший:
1 байт говорит нам о размере шрифта и далее идут 255 изображений символов. Да, это не очень эффективно т.к попадают пустые символы из ASCII-таблицы, но в будущем это можно поправить.
Прозрачность в символах обеспечивает фоновый цвет Magena — ярко-розовый. Я не стал делать дополнительный альфа-канал, т. к. иначе будут серьезные лаги при выводе большого количества текста.
Теперь у нас есть отображение картинок и текста! Что с этим можно сделать?
Пока что здесь не хватает обработки «хардварных» кнопок — домой, меню, назад и т. п. Однако в будущем это всё можно реализовать!
Не забыл я и про анимации. Ну кому с такими ресурсами нужен неанимированный топорный интерфейс? Пусть лучше будет анимированный, пусть и примитивный!
Аниматор напоминает оный из ранних версий Android: он имеет фиксированный набор свойств, которые умеет интерполировать в промежутках определенного времени. Если простыми словами: то он оперирует линейными отрезками времени a и b, в промежутке которых мы имеем значение «прогресса» — которое даёт нам результат от 0.0f (начало анимации) до 1.0f (конец анимации). Пока время тикает до необходимого интервала (duration), аниматор интерполирует заранее назначенные ему поля до нужных значений.
Именно так и получается плавность! Похожим образом реализованы анимационные системы во многих играх и мобильных ОС, только там они гораздо более комплексны: есть сериализация/десериализация из файлов, поддержка кейфреймов (несколько последовательных состояний на одном промежутке времени), поддержка кастомных свойств и т. п.
Как я уже говорил раннее, работа с модемом происходит посредством AT-команд. Лучше всего обрабатывать ввод-вывод модема из отдельного потока, поскольку он может отвечать довольно медленно и тормозить UI-поток основной программы, вызывая лаги. В SIM800 уже реализован весь GSM-стек, в том числе декодирование и вывод звука через встроенный усилитель с фильтром — остается только подключить динамики и микрофон от нашего телефона. Пока что я подсобрал аудиотракт на том, что было под рукой — микрофон от нерабочего смартфона и динамик от планшета, но для проверки этого хватает:
Важный нюанс: по умолчанию, tty-устройства в Linux работают по терминальному принципу — т. е. дробят транзакции по символу окончания строки (\n), имеют ограниченный буфер и т. д. Для нормальной работы в условиях модема — когда фактически длина ответа неизвестна, а в сам ответ могут «вклиниваться» Unsolicited-команды (своеобразные флаги о состоянии от модема, которые могут прийти в произвольное время — т. е. при входящем звонке, модем начнёт флудить RING в терминал), необходимо иметь возможность точно прочитать весь буфер до конца и парсить данные «по месту». Для этого используется raw-режим терминала:
tcgetattr(modemFd, &tio);
tio.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON);
tio.c_oflag &= ~(OPOST);
tio.c_cflag |= (CS8);
tio.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG);
tcsetattr(modemFd, TCSAFLUSH, &tio);
После чего можно запросить состояние модема:
И продолжить работу дальше. После этого, можно переходить к реализации самой прослойки между модемом и вашей программой:
Пытаемся позвонить с помощью метода Dial и видим, что всё работает! Это очень круто! А теперь, конечно же, самое время переходить к реализации того, чего вы ждали — пользовательского интерфейса!
К выбору концепции для интерфейса, я поступил максимально просто — «слизал» дизайн первых версий iOS. Как по мне, это одни из самых красивых версий iOS вообще — все эти приятные градиенты и переливания. Конечно, я не так крут, как инженеры Apple, да и мощного UI-фреймворка у меня пока что нет, поэтому я приступил к реализации с «минимальным» функционалом.
Начал я с разделения главного экрана на модули и продумывания архитектуры основного «лаунчера». У нас есть статусбар, который рисуется поверх всех приложений, полка с приложениями — AppDrawer и сами экраны приложений, унаследованные от суперкласса CScreen.
На данный момент, отрисовка достаточно примитивная: сначала рисуются фоновые обои, затем, если нет никаких активных экранов — AppDrawer и в самом конце рисуется статусбар и всевозможные оверлеи.
Практически сразу я решил обкатать анимационную «систему» и добавить первые анимашки — выезжающий статусбар и анимация а-ля айфон:
animator = new CAnimator();
animator->SetTranslation(0, -imFiller->Height, 0, 0);
animator->Run();
Выглядит симпатичненько. Если я смогу поднять хардварный GLES, то это получится сделать в разы плавнее и шустрее — не хуже айфонов тех лет! Реализация самого статусбара примитивненькая, но вполне рабочая:
gLauncher->Graphics->DrawImage(imFiller, animator->X, animator->Y);
gLauncher->Graphics->DrawImage(imBattery[(int)gLauncher->PowerManager->GetBatteryLevel()], imFiller->Width - imBattery[0]->Width - 5, animator->Y + 5);
char timeFmt[64];
time_t _time = time(0);
tm* _localTime = localtime(&_time);
strftime((char*)&timeFmt,
sizeof(timeFmt), "%R", _localTime);
gLauncher->Graphics->DrawString(gLauncher->Font, (char*)&timeFmt, 0, 0);
Кроме этого, я сразу же реализовал предварительный механизм приложений в системе — пока что они слинкованы статически с основным лаунчером. Для этого есть структура CAppDesc, которая содержит минимально-необходимую информацию для показа информации о приложении и фабрику для создания его основного экрана.
Обратите внимание на удобство примененного подхода Immediate GUI. Нам понадобился новый элемент интерфейса, который описывает кнопку номеронабирателя? Мы просто реализовываем ещё один метод, который берет за основу стандартную кнопку и дорисовывает к ней текст. Всё крайне просто и понятно, хотя на данный момент слишком захардкожено. :)
Пришло время совершить первый звонок с нашей по настоящему кастомной прошивки. Набираем номерок и…
Да, всё работает и мы без проблем можем дозвониться :)
Конечно же, это далеко не весь функционал, необходимый любому современному смартфону. Здесь много чего еще нужно реализовать хотя бы для соответствия уровню бюджетных кнопочных телефонов: телефонную книгу, поддержку СМС/ММС, мультимедийный функционал с играми. Однако начало уже положено и самая необходимая часть модулей реализована. Этот проект очень занимательный для меня и я горд, что смог не на словах, а на деле показать вам, моим читателям, возможности моддинга совершенно NoName-устройств, без каких либо опознавательных знаков…
Моя задача заключается в том, чтобы показать вам возможности использования старых телефонов не только в потребительских, но и в гиковских DIY-сферах. Судите сами: огромный классный дисплей, емкостной тачскрин, готовый звук, камера — и всё это за каких-то пару сотен рублей. Главное показать людям, как всю эту мощь использовать в своих целях и делать совершенно новые устройства из существующих, а не выбрасывать их на помойку!
Сейчас смартфоны, подобные Fly из этого поста стоят копейки, а портировать на них прошивку можно без каких-либо трудностей. Я очень надеюсь, что после этого поста читатели попытаются сделать что-то своё из старых смартфонов, благо свои наработки я выкладываю на GitHub!
Хочу рекомендовать получить эстетическое удовольствие с книгой Open Circuits за авторством Eric Schlaepfer и Windell H. Oskay
Книга посвящена внутреннему устройству радиокомпонентов. Фотографии в разрезе, иногда рисунки поясняющие структуру, и немного текста — пояснения. К сожалению текст на английском языке, но если вы его не знаете — то потеряете не много. Основное достоинство книги — сочные фотографии.
Я тоже публиковал фотографии различной распиленной техники (но покрупнее) поэтому могу только восхищаться объемом и качеством работ. В конце книги есть немного о процессе съемок — распил, очистка. Мелкие предметы заливались и пилились в прозрачной смоле. Для макрофотографии производился стекинг (склейка стопки изображений с фокусом на разной глубине в программе, чтобы увеличить глубину резкости).
Хоть многое из показанного я уже видел, ибо за много лет творчества из любопытства многое расковырял. Особенно меня удивила эта фото:
Аналогичную фото я делал для своей книги, чтобы показать разные типы предохранителей, и найти такие предохранители было очень трудно, особенно под санкциями. Для сравнения мое фото:
Добиваться такой же звенящей резкости я пока не умею, впрочем и оборудование у меня сильно проще.
У книги есть сайт https://opencircuitsbook.com/. Второй автор книги Windell Oskay персонаж известный, я с ним столкнулся в интернете еще году наверное в 2008, у него сайт https://www.evilmadscientist.com/. Тогда у него на сайте был раздел с ссылками, и я прислал ссылку на мой сайт licrym.org и он ее добавил) Он делал проекты ЧПУ рисовалок по яйцам, рисовалок акварелью.
Некоторые объекты разрезаны в тонком слое. На фото динамик.
Книгу рекомендую к пролистыванию. Учитывая невозможность ее официального приобретения (ни оплатить, ни заказать. Только через посредников) я без зазрения совести опубликую pdf файл с ней у себя в телеграмм канале. Впрочем найти ее в электронном виде в рунете не сложно, достаточно погуглить название: "Open Circuits: The Inner Beauty of Electronic Components".
Думаю, что заголовок это очередной глупый журналистский штамп. Apple много лет занимались разработкой своих смартфонов и доведением их до ума, невозможно просто вот так взять, влететь с двух ног в сегмент и выпустить "убийцу" iPhone.
И всё же это не значит, что не нужно пытаться. Нужно, ещё как нужно.
НО!!! Жирнющее НО!
Я очень надеюсь, что всё же инфа об этом фейк, потому что... Р-ФОН? Серьёзно? Ну то есть, да, я прекрасно понимаю, что у нас теперь есть кейс "Вкусно и точка", который наглядно демонстрирует, что с неймингом у нас беда, но я думал, что после этого меня уже ничто не удивит. Р-ФОН, хоспаде... Р-ФОН!
