flipper zero

У меня тут спросили, использую ли «Флиппер Зеро», — давно ничего про него не рассказывал. Использую, конечно, и очень интенсивно! С тех пор как потерял магнитный ключ от подъезда, каждый день туда и обратно прохожу, прикладывая вместо него «Флиппер». Всё недосуг заняться этим вопросом.

Хорошо, что ещё в самом начале я записал на «Флиппер» данные всех магнитных ключей, которые у меня были — домашний, рабочий, родственников и так далее.

К заметке, где я писал про камеру для «Флиппера», один из читателей прислал ссылку на часы «Casio WQV-1» начала 2000-х. Интересны они тем, что у них тоже есть камера, позволяющая делать чёрно-белые снимки в оттенках серого с разрешением 120×120.

Разумеется я загорелся их купить.

На «Ебее» их можно найти без проблем, но с пересылкой часов через границу сейчас большие проблемы. Без особой надежды я пошерстил «Авито» и оказалось, что, хотя первой модели часов там нет, зато лежит третья, которую я тут же себе купил и ношу уже несколько дней.

Оцените какой ретро-футуристичный дизайн! Как будто из второй части трилогии «Назад в будущее».

Всего в линейке таких часов было четыре модели с номерами «1», «2», «3» и, почему-то, «10». Третья модель, которую я и купил, отличается от первой внешним видом и другой камерой — цветной с разрешением 176×144. Правда экранчик цвет не показывает, да и снимок умещается не весь — при просмотре видно только центральную часть.

Конечно снимки хочется из часов как-то выковырять. Проблема в том, что с часами мне не досталось ни софта, ни касиовского инфракрасного адаптера, который найти — та ещё эпопея.

Под рукой, из того, что поддерживает инфракрасный обмен, у меня только «Флиппер». В принципе, если знать протокол, можно под него написать программу, которая списывала бы снимки на карточку, оттуда перекинуть на ноутбук — ноль проблем.

Описание протокола найти было нетрудно. Но позже оказалось, что в третьей модели «Касио» перешли на некий стандартный протокол передачи, а его описание я ещё даже не искал. Возможно, раз протокол стандартный, снимки можно получить как-то проще, посмотрим. Если нет, то придётся писать программу под «Флиппер».

Я немного посмотрел АПИ для работы с инфракрасником во «Флиппере» и, пока не забыл узнанное, сделаю заметки для себя.

Для передачи сигналов подойдёт одна из двух функций. Если повезёт это будет infrared_send, которая принимает команды в одном из стандартных кодеков, либо infrared_send_raw_ext, где придётся возиться с ручным кодированием битов.

Зависит от того, что за кодировка сигналов используется в этом самом «стандартном протоколе». Если это что-то из того, что умеет «Флиппер», дело упрощается, иначе надо будет выяснять тайминги, скорость передачи и прочие технические подробности.

Наименее очевидными были для меня тайминги. Я как-то не задумывался никогда как именно кодируются «нули» и «единицы» в передачах через инфракрасный порт. Оказывается «ноль» и «единица» имеют просто разные тайминги, то есть разное время на которое загорается светодиод.

Когда берёшь в руки молоток, всё вокруг становится похожим на гвозди. Раз уж я примотал камеру к «Флипперу», надо всё вокруг пофотографировать. Мы с дочкой решили сфоткать домочадцев.

Жена на работе, себя я фоткал вчера, поэтому слева направо: улитки Тайгер и Найгер, кот Марсик, пёс Бейсик и дочь Ева.

Около трёх месяцев назад, болтаясь по интернету, я, волею случая, наткнулся на репозиторий с софтом, позволяющим подключить к «Флипперу» небольшую веб-камеру. Для подключения внешних модулей у него на боку есть специальный разъём.

Выглядело это забавно, да и цена вопроса — всего 400 рублей, плюс комплект перемычек за 30. Невеликие траты за такую прикольную штуку. Я что-то тянул с этой покупкой, но, в конечном счёте, купил, конечно. Кстати, камеру можно было найти и дешевле, но я побоялся, что приедет какой-нибудь мусор, а тут хотя бы продавец с хороший рейтингом.

«Флиппер Зеро» с камерой в сборе

Из-за того, что нужные программы довольно долго скачивались, собрал всё вместе и поставил нужный софт примерно за час. Чистого времени ушло минут двадцать, мог бы и меньше потратить, но перепутал штырьки.

Если внимательно следовать инструкции, то всё просто: четырьмя перемычками соединяешь «Флиппер» и плату, ещё одной замыкаешь между собой два штырька — это нужно, чтобы залить в камеру прошивку. Потом скачиваешь редактор для «Ардуино», там ставишь плагин, далее через «Флиппер» с его помощью заливаешь в камеру прошивку, размыкаешь перемычку. Потом через магазин приложений ставишь нужную программу и развлекаешься.

Единственная хитрость — плагин надо ставить второй версии, а не третьей, в третьей почему-то нет поддержки нужной платы.

Экранчик у «Флиппера» маленький и чёрно-белый, поэтому изображение посредственное, но так только интереснее — качественное изображение я могу и на смартфоне увидеть, а тут настоящий олдскул!

Глаза боятся, руки делают. Что-то я сначала приуныл, когда понял сколько возни предстоит, чтобы сделать интерфейс ввода часового пояса, который я решил добавить в программу для получения инженерного пароля «Войи» под «Флиппер».Flipper Zero Даже как-то руки опустились.

Начал потихоньку — накидал сначала функций-заглушек, а потом всё реализовал в течение дня. Всё, теперь программа приобрела законченный вид. Публиковать в каталог, правда, не планирую — очень уж невелика аудитория. Много ли владельцев «Войи» с «Флиппером»?

Программа, запущенная на «Флипере Зеро». Виден указанный часовой пояс — GMT+03:00

В этот раз столкнулся с кое-чем новеньким. В одном месте мне надо было нарисовать две большие стрелки — влево и вправо. Открыл редактор, нарисовал в одну строну, наложил, посмотрел как смотрится в интерфейсе, всё прекрасно.

Чтобы получить стрелку в другу строну, повернул её в редакторе, проделал всё то же, что с первой, но при отображении стрелка получалась в какую-то неравномерную крапинку.

Интерфейс задания часового пояса

Как я уже рассказывал, инструментарий для компиляции программ сам конвертирует картинки в нужный «Флипперу» формат. Я не ковырял, но по виду это обычный XBM — формат двухцветной чёрно-белой графики.

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

Сначала я решил это проверить. Поводил «пипеткой» на картинке, не нашёл. Нарисовал заново. Это ситуацию не исправило. Решил посмотреть в бинарном виде сконвертированные файлы, оказалось сложновато, плюнул. Пошёл смотреть в чём разница у исходных файлов. Оказалось, что один у меня в формате 1-bit colormap PNG, а второй (который с дырками) — 1-bit grayscale PNG.

Подумал, что проблема в этом, но как преобразовать одно в другое сходу не разобрался. Утилитой magick начал конвертировать проблемную картинку в PNG, перебирая все известные мне ключи подряд, пока в один момент дырки не пропали. Я так и не выяснил какое сочетание настроек мне помогло, потому что в процессе потерял исходную «дырявую» картинку, а делать новую не хотелось — мне ещё предстояло много программировать.

«Что это было, Бэрримор» — непонятно до сих пор, но на всякий случай записываю себе этот случай, чтобы в следующий раз хотя бы примерно понимать как с ним бороться.

Одна штука мне очень не нравилась в программировании под «Флиппер». Фреймворк устроен так, что картинки, используемые в приложениях, должны внедряться определённым способом.

А именно — в манифесте приложения, в директиве fap_icon_assets мы указываем папку, каждая картинка в которой, позже, на этапе сборки, будет преобразована в специальный массив. Этот массив всегда называется I_имя_файла_картинки. Массивы засовываются в файл со специальным именем, который надо импортировать в код через #include.

Поскольку это происходит во время сборки, редактор (я использую «Визуал Студио Код») этот файл не видит, поэтому подчёркивает мне его импорт и все использования массивов, которые в нём описаны, как ошибку.

Лично меня такое раздражает. В редакторе мне хочется видеть полное отсутствие ошибок.

Пример того как отображаются упомянутые ошибки в приложении «Пароль для Войи»

В «Виселице» я с этим смирился, а сегодня каким-то чудом вспомнил про нестандартную директиву __has_include, которую как-то не доводилось использовать прежде. Она проверяет как раз то, что мне нужно — доступен файл для импорта или нет.

Реальный пример того как можно сделать, чтобы редактор не считал, что у меня ошибка

Получается, что если файл для импорта ещё не готов, то мы его не импортируем, а нужный нам массив объявляем, как имеющий внешнюю реализацию. В итоге, в редакторе ошибок не остаётся.

Ну началось 😅 Теперь меня не отпускают мысли как можно доработать приложение для получения инженерного пароля, которое я написал вчера.

Как я говорил, у «Флиппера» есть проблема — он ничего не знает о часовом поясе. В каждом приложении, где нужно его знать, приходится что-то решать отдельно, централизованного решения нет.

Я пока не стал заморачиваться, просто показываю три кода из трёх разных дней. Это, конечно, не совсем правильно. Учитывая, что часовые пояса у нас бывают от GMT-12:00 до GMT+14:00, есть небольшое окошко, где можно показать не три, а два кода. Но вряд ли это существенно что-то меняет, поэтому я этого делать не стал.

В общем, решил сделать как все — окошко с настройкой часового пояса. Если пояс задан, он будет показан на кнопке и выводиться будет только один код, если нет, на кнопке будет написано что-то типа «set timezone» и кодов будет три.

Проектирование интерфейса для установки часового пояса

Чтобы совсем не позабыть как писать и компилировать программы для «Флиппера», написал небольшую программу, которая выводит инженерный пароль для моей машины.

Пароль там можно даже на калькуляторе вычислять, но это неудобно — надо сложить поциферно месяц-день с годом. Поэтому я написал программу.

День берётся по часовому поясу Китая, а поскольку «Флиппер» ничего про часовые пояса не знает, поэтому приходится показывать три числа — для разных дней.

Пароль от инженерного меню «Войи» на сегодня

Полезное упражнение, подзабыл некоторые особенности, как самой сборки, так и наличествующего АПИ.

Меня тут недавно спросили — куда пропали мои посты про «Флиппер»? Пропали, потому что писать особо нечего. У меня в голове есть идея небольшого, полезного лично для меня приложения для него, кроме того, незакрытым гештальтом висит на душе добавление туда Юникода, но времени нет ни на первое, ни на второе.

Пока лето, в выходные я в разъездах, в будни тоже хочется куда-нибудь сходить, — ведь тепло. Холодно станет, может тогда и займусь.

Пока же я его использую только в быту — чтобы что-нибудь открыть. В последний раз пользовался сегодня — командовал шлагбаумом около дома, где мы снимали квартиру в Йошкар-Оле. Иначе пришлось бы возвращаться в квартиру, чтобы оставить брелок от шлагбаума.

Завтра отпуск. Я надеялся позаниматься «Флиппером Зеро», но вовремя сообразил, что отношение к этому устройству по всему миру неоднозначное. Лучше его за границу не возить, тем более со снимающей ограничения прошивкой, которая стоит у меня.

В принципе, устройство везти не обязательно, можно использовать «песочницу» с минимальный кодом. Его хватит для моей задачи — добавить, наконец, в прошивку поддержку Юникода. Я пока забросил эту задачу, планирую заняться в отпуске, не всё же на пляже тюленить.

Юникод во «Флиппере» неисчерпаем, как атом.

Сначала мне стало просто интересно почему для «Флиппера» нет ни одного русскоязычного приложения, потом я выяснил что мешает это сделать и научился обходить эти ограничения, потом написал русскоязычную игру, после чего залез в прошивку и начал добавлять в неё поддержку Юникода, погружаясь всё глубже и глубже.

К моим коммитам отнеслись довольно благосклонно, но в один момент дело застопорилось — авторы прошивки решили обновить сторонний фреймворк для вывода на экран, что могло повлиять на мои изменения, поэтому работу над ними я отложил. Но уже тогда у меня возникла мысль, что надо бы добавить Юникод и в библиотеку работы со строками, которую использует «Флиппер Зеро».

Пока я ждал обновления, занял себя векторизацией функции подсчёта длины строки в кодировке UTF-8, а когда коммит отклонили, поставил всю эту движуху на паузу.

И вот сегодня я получил новый комментарий к моему коммиту от авторов прошивки — мне порекомендовали заняться тем, о чём я когда-то размышлял, а именно — поддержкой Юникода в библиотеке работы со строками и только после этого закончить свой предыдущий коммит.

Размер доработок всё ширится, а результат всё дальше. Интересно, насколько глубока кроличья нора?

В итоге, эпопея с ускорением функции замера длины строки в кодировке UTF-8 на «Флиппере Зеро» подошла к концу — коммит не взяли.

У меня с самого начала этой затеи были сомнения. Я понимал, что для того, чтобы решить чью-то проблему, надо сначала доказать, что она существует, чему я должного внимания не уделил. Кроме того, сейчас в мире программирования очень важно решить проблему понятным образом, а векторное ускорение мало кому знакомо.

Тем не менее, я с удовольствием повозился инструкциями SIMD. До этого мини-проекта у меня было теоретическое понимание о том, что это за функции, но на практике я их не использовал.

Моя функция, кстати, претерпела некоторые изменения:

size_t furi_string_utf8_length(FuriString* str) {
    size_t len = string_size(str->string);
    const char * cstr = string_get_cstr(str->string);
    const char* end = cstr + len;

    if(len >= sizeof(uint8x4_t)) {
        const char* vend = end - sizeof(uint8x4_t);

        int8x4_t zero = 0x00000000;
        int8x4_t one = 0x01010101;
        int8x4_t threshold = -1077952577; // -65, -65, -65, -65

        do {
            int8x4_t vec = *(int8x4_t*)cstr;

            __ssub8(threshold, vec);
            uint8x4_t result = __sel(one, zero);

            len -= __usada8(result, zero, 0);

            cstr += sizeof(uint8x4_t);
        } while(cstr <= vend);
    }

    while(cstr < end) {
        signed char c = *cstr++;
        len -= c < -64;
    }

    return len;
}

Оказалось, что тип FuriString хранит в себе бинарную длину строки, поэтому я переделал код, чтобы он не пытался читать чужую память. В векторизованой части это было вероятно, но своих рассуждений и дискуссии по коммиту я сделал вывод, что в случае «Флиппера» это не имеет какого-либо значения.

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

В итоге, решая эту, возможно несуществующую, проблему, я опробовал на практике векторные инструкции расширений NEON и DSP SIMD, научился делать два параллельных запроса на вливание в «Гитхабе» и ещё раз вспомнил как компилировать и заливать свою прошивку во «Флиппер Зеро».

Спасибо Шурику Бабаеву за помощь, добавил свой коммит с векторизованной функцией для измерения длины строки в кодировке UTF-8 в кодовую базу прошивки «Флиппера».

Попутно выяснилось, что «Флиппер» использует функцию замера длины из библиотеки M*LIB. Можно было бы закоммитить новую версию в неё, но не стал этого делать по двум причинам.

Во-первых, моя версия заточена под конкретную платформу, а M*LIB, кажется, универсальная библиотека. Во-вторых, если бы мой коммит в неё и приняли, надо было бы ещё каким-то образом добиться обновления библиотеки в прошивке «Флиппера», а это, наверняка, непростая задача.

Кстати, сделал итоговые замеры. Миллион итераций с четырьмя короткими строками (от ЯБ12341 до ЯБ12341234) моя версия делает за шесть секунд, тогда как прежняя — за 39.

Можно подумать, что я забросил возню с «Флиппером», так как какое-то время писал об этом часто, а сейчас поутих. На самом деле я всё жду, когда разработчики прошивки вмержат мой коммит для поддержки Юникода, плюс потихоньку вожусь со своей векторной реализацией функции для определения длины строки в кодировке UTF-8.

До недавнего времени я её надеялся ускорить, поэтому пытался вносить какие-то мелкие улучшения, но все они никакого эффекта не дали. Зато при аккуратном тестировании нашёл ошибку, — неправильно задал граничное условие в векторизованном куске. Хорошо, что проверил. В блоге у меня уже исправленная версия.

Будем считать, что с этим вопросом я закончил, хочу теперь попробовать добавить этот код в прошивку «Флиппера». Остались сделать два шага.

На замерах моя реализация обогнала встроенную на порядок — восемь секунд против 55 на двух миллионах итераций по небольшой строке. Но теперь надо воткнуть её в прошивку, чтобы учесть влияние реализации строкового типа FuriString, в котором будет использоваться эта функция и провести новые замеры. Надеюсь сделать это в ближайшие выходные.

Второй шаг для меня сложнее. У меня уже есть выписанная прошивка «Флиппера», в которой торчит непринятый коммит. Я никогда раньше не создавал на «Гитхабе» два разных запроса в рамках одного чужого проекта, не знаю как это делается. Если кто-то умеет, расскажите в комментариях.

Ну что же, я наконец сравнил свой вариант функции определения длины строки в кодировке UTF-8 с наивной реализацией и чужим быстрым вариантом.

Оказалось, что обычные функции замера времени под «Флиппером» не работают. мне не удалось получить значение текущего времени ни одним из способов к которым я привык на Си, поэтому опять пришлось читать исходники прошивки «Флиппера».

В итоге обнаружился метод, выводящий затраченное время с секундной точностью:

FuriHalRtcDateTime curr_dt;
furi_hal_rtc_get_datetime(&curr_dt);
uint32_t start = furi_hal_rtc_datetime_to_timestamp(&curr_dt);

for (int i = 0; i<1000000; i++)
len += strlen_utf8("This is a test и русских букв тоже");

furi_hal_rtc_get_datetime(&curr_dt);
uint32_t stop = furi_hal_rtc_datetime_to_timestamp(&curr_dt);

Хотелось бы точнее, но этого, в принципе, хватает, чтобы понять какая функция быстрее и на сколько. Надо просто сделать очень много итераций. Я попробовал запускать на миллионе и десяти миллионах.

Скриншот экрана «Флиппера», снятый через специальную программу; отображается суммарная длина и время работы — пять секунд

В итоге, на десяти миллионах наивная реализация выполняется примерно за 80 секунд, моя и чужая быстрая — около 50, явного лидера из этих двух реализаций выделить не удалось. Все замеры делал несколько раз.

В этом версии нет никакой защиты цикла от чтения за границей буфера, мне показалось, что во «Флиппере» это неважно, но возможно это не так.

Ну что ж, разобрался я что за зверь такой этот DSP SIMD и запрограммировал на нём векторизированную версию функции для измерения длины строки.

Сегодня описывать и замерять уже не буду, и так времени много ушло, но по крайней мере всё работает на настоящем «Флиппере».

Сразу можно заметить, что вектора тут вдвое короче — всего четыре байта, да и функций для работы с ними гораздо меньше, но этого набора оказалось достаточно, чтобы всё векторизовать.

#include <arm_acle.h>

size_t strlen_arm_utf8(char * str) {
    uint32_t len = 0;
    int8x4_t zero = 0x00000000;
    int8x4_t one  = 0x01010101;
    int8x4_t threshold = -1077952577; // -65, -65, -65, -65

    for (;;) {
        uint8x4_t result;
        int8x4_t vec = *(int8x4_t *) str;

        __uadd8(0xFFFFFFFF, vec); result = __sel(zero, one);
        if (result > 0) {
            if (result == 0x01000000) {
                __ssub8(threshold, vec); result = __sel(zero, one);
                return __usada8(result, 1, len);
            }
            break;
        }

        __ssub8(threshold, vec); result = __sel(zero, one);
        len = __usada8(result, zero, len);

        str += sizeof(uint8x4_t);
    }

    for (signed char c; (c = *str); str++) {
        if (c >= -64) {
            len++;
        }
    }    

    return len;
}

Преодолев внутреннее сопротивление, я всё-таки занялся переносом векторизованной функции измерения длины строки на «Флиппер Зеро». Почти сразу выяснилось, что моя интуиция меня не обманула — на этом пути куча проблем.

Во «Флиппере» стоит процессор ARM, а они, как оказалось, бывают очень разные.

Я ещё в самом начале посмотрел спецификацию процессора «Флиппера» и, увидев слово SIMD, совершенно успокоился — в моём понимании это означало, что я могу использовать любые команды векторизации, которые мне необходимы. Тут я немного поторопился, но меня подгоняло желание разобраться как устроена векторизация. Теорию я знал, а тут подвернулась, пусть немного синтетическая, но задача, которую руки чесались решить.

Некоторые ошибки компиляции упомянутой функции под «Флиппер Зеро»

Как я уже говорил, мне захотелось срезать углы, поэтому функцию до этого момента я писал на своём ноутбуке, раз так случилось, что у меня на нём тоже процессор ARM. И лишь сегодня я попробовал вставить её в одну из своих программ и собрать её для «Флиппера».

Сначала компилятор заявил мне, что не нашёл некоторые векторные функции, в частности функцию нахождения минимума vminvq_u8 и суммы vaddvq_u8.

Ветку с vminvq_u8 я временно убрал, а функцию суммы vaddvq_u8 решил заменить на поэлементное сложение (vaddq_u8), которая, вроде, компилятору знакома.

Мысль простая — в векторах, сумму которых мы находим, на каждой позиции нули и единицы, поскольку каждый элемент вектора у нас восьмибитный, в общем случае у нас поместится результат 255 операций, а потом я могу просто просуммировать элементы циклом. Как-то так:

uint8x16_t len_v = vdupq_n_u8(0);
int reset = 0;

// тут у нас цикл
uint8x16_t gt = vcgtq_s8(operand, threshold);
len_v = vaddq_u8(vandq_u8(gt, delta), len_v);

if (++reset >= 255) {
    for (size_t i = 0; i < sizeof(uint8x16_t); i++) {
        len += *((uint8_t *)&len_v + i);
    }

    reset = 0;
    len_v = vdupq_n_u8(0);
}

Я был очень доволен решением (оно не совсем моё, его мне навеял код, используемый в PHP), но оказалось, что оно тоже не компилируется.

Сборка заругалась на ошибку target specific option mismatch, означающую, что указанное при компиляции железо не поддерживает те возможности, которые я пытаюсь использовать в коде. Пришлось лезть в тулчейн, чтобы разобраться какие ключи компиляции сейчас используются.

В файле compile_commands.json можно увидеть, что при сборке используется ключ -mfpu=fpv4-sp-d16, тогда как мне, чтобы использовать нужные команды векторизации нужен ключ -mfpu=neon.

Так как ключи компиляции указывали разработчики «Флиппера», думаю, они в точности знали в какие значения их выставить. Согласно спецификации на борту использованного во «Флиппере» процессора SIMD есть, но, видимо, какой-то другой. Так как SIMD написано в разделе DSP Extension, надо смотреть что это такое, может всё-таки можно использовать эти команды для ускорения.

Кажется я то ли прокрастинирую, то ли боюсь неудачи. Предполагалось, что векторизованный алгоритм измерения длины строки в кодировке UTF-8 я в конечном счёте портирую под «Флиппер», но что-то мне мешает сделать этот шаг.

Он вполне может не скомпилироваться — не уверен, что на «Флиппере» есть 128-битные вектора. Судя по спецификации, скорее нет, чем есть. Наверное намечающиеся сложности заставляют меня колебаться. Надеюсь пост в блоге, как это нередко бывало раньше, подтолкнёт меня к действию.

Пока проект внедрения Юникода во «Флиппер Зеро» на паузе, — разработчики занимаются обновлением одной из важных библиотек, я вспомнил, что вообще-то в природе существуют разные способы ускорения обработки строки в кодировке UTF-8. Именно её я выбрал для хранения строк. А поскольку железо у «Флиппера» весьма ограниченное, может быть имеет смысл подумать как сэкономить ресурсы.

Например, когда-то, ещё во времена работы в «Яндексе», я сравнивал между собой различные реализации функции strlen, где ускорение достигалось за счёт векторизации.

Любопытно посмотреть как обстоят дела с ускорением таких вещей на процессоре, который установлен на «Флиппере». Правда до него у меня руки ещё не дошли, но я уже потренировался на своём «Макбуке», благо тут процессор той же архитектуры.

Идея всё та же — векторизация. За референс я взял наивную реализацию с перебором по одному байту:

size_t strlen_naive(const char* str) {
    size_t len = 0;
    char ch;
	
    while ((ch = *str++)) {
        len += (ch & 0b11000000) != 0b10000000;
    }

    return len;
}

Попробовал несколько вариантов, но лучше всех показали себя две функции: та, которую я упоминал в первом абзаце и переделанная нашими общими с братишкой усилиями реализация, найденная в недрах PHP.

После переделки она стала выглядеть так:

size_t strlen_php(unsigned char * p) {
    size_t len = 0;

    const int8x16_t threshold = vdupq_n_s8(-64);
    const uint8x16_t delta = vdupq_n_u8(1);

    for(;;) {
        int8x16_t operand = vld1q_s8((const int8_t * ) p);
        if (vminvq_u8(operand) == 0) {
            break;
        }

        uint8x16_t lt = vcltq_s8(operand, threshold);
        len += sizeof(uint8x16_t) - vaddvq_u8(vandq_u8(lt, delta));
        p += sizeof(uint8x16_t);
    }

    for (signed char c; (c = *p); p++) {
        if (c >= -64) {
            len++;
        }
    }

    return len;
}

Повторюсь, у меня пока не дошли руки попробовать это всё на «Флиппере», но на моём «Макбуке» результаты выглядят следующим образом. Это десять тысяч прогонов на русскоязычном тексте, размер которого чуть больше ста тысяч символов.

Name   Length  Time
----   ------  ----
PHP    117465   97797
Fast   117465  143780
Naïve  117465  531535

Не скажу, что я делал всё как положено, — надо бы считать среднее и отклонение, разносить по разным файлам, научиться прибивать процесс к производительным ядрам, но разница в результатах достаточно показательна (я запускал несколько десятков раз), поэтому, как мне кажется, и так нормально.

Цифры в попугаях (больше — хуже), которые выдаёт сишная функция clock(), компилировал компилятором Clang 15 с ключом -O3.

Я долго не знал как выглядит наша с дочкой игра «Виселица» в магазине приложений «Флиппера Зеро» — смартфон-то у меня «Хуавей», а под него нужного приложения нет.

А на днях вспомнил, что походный-то смартфон у меня с обычным «Андроидом»! В общем посмотрел, даже скриншот снял на память. Надо бы, кстати, выпустить новую версию — у меня там есть досадная опечатка в английской локализации — loose, вместо lose.

Честно сказать, необходимость постоянно использовать какие-то дополнительные приседания, чтобы поставить часть приложений на «Хуавей» меня сильно утомила. Думал, что смогу с этим жить, но нет. Продержался более трёх лет, но сил моих больше нет. Кажется буду переходить. Вот только на что ещё не решил.