Всем привет!
Вторая статья про революционный проект Vodka, где будут реальные замеры производительности nginx.exe. А ещё на этот раз я более подробно расскажу про архитектуру проекта. И даже покажу, как это, установить Windows на Linux!
В предыдущей части статьи я рассказал об особенностях реализации многозадачности для ВПО. Однако, какой бы ни был выбран подход к многозадачности, архитектура самих задач напрямую влияет на эффективность работы всей встраиваемой системы.
Для достижения оптимальной работы системы, задачи необходимо проектировать по принципу эффективного использования процессорного времени. Т.е. задача должна использовать процессорное время исключительно для полезной нагрузки. Данный принцип выполняет 2 основные функции: Улучшение отзывчивости системы и эффективного потребления электроэнергии.
В статье описано, как реализовать многоканальный звук на RP2040 с использованием HD аудиокодека ALC889. Будет краткий разбор интерфейса HDA link и ссылки на пару рабочих демо-проектов с описанием их работы.
Чтобы устройство умного дома присылало уведомления на телефон, писать мобильное приложение не обязательно. Приложение, экран устройства и рассылку пушей берет на себя Tuya, а нам остаются прошивка и пара настроек на платформе. Все это делается с помощью open-source решения TuyaOpen, расскажу про это в статье :)
Когда устройству нужна относительно большая энергонезависимая память с возможностью быстрой замены, SD или microSD-карта — один из самых удобных и доступных вариантов.
Компактность, простое подключение, поддержка микроконтроллерами и низкая цена при большом объёме делают SD-карту стандартом для логирования, хранения конфигураций и обновления прошивок.
Многие считают работу с SD-картой чем-то сложным и низкоуровневым. На практике, если использовать SDIO + FatFS, бо́льшая часть сложности уже спрятана библиотеками и аппаратными модулями микроконтроллера.
В этой статье я покажу, как добавить поддержку SD-карт в проекты на STM32: что лежит в основе, и как она настраивается.
Всем привет!
Сегодня я хочу рассмотреть довольно интересную возможность на Zynq SoC, связанную с отладкой с помощью ILA (Integrated Logic Analyzer) без физического подключения через JTAG.
В этой статье мы попробуем разобраться, как использовать Xilinx Virtual Cable, соберем драйвера, посмотрим как подключаться из Hardware Manager Vivado.
Будущее наступило, старик 👴🏻🧢🛹✌️
В этой статье мы покажем, что биометрию уже пора внедрять; расскажем, почему это просто и относительно дёшево, а также поделимся техническими деталями для разработчиков.
Будет интересно менеджерам, которым не хватает традиционных 2FA, и разработчикам, которым предстоит с этим работать.
P.S. При написании данной статьи не использовались генеративные модели! 100% ручной труд разработчика Георгия. Я просто люблю смайлики 😇
Привет, Хабр! Ни для кого не секрет, что в языке C существует множество красивых способов положить вашу программу со всеми вытекающими последствиями, но большинство из них обходятся банальными средствами гигиены, санитайзерами, статическими анализаторами, линтерами, да и компиляторы в целом не плохо помогают решать большинство проблем до их обнаружения в продакшене. Но существуют проблемы, которые возникают только во время исполнения и понять, в чем причина, не так просто, хотя сама проблема может оказаться очень даже понятной после установления причинно-следственной связи.
Останавливаться на том, что такое ABI, я не буду, дабы не разводить лишнюю полемику, на Хабре достаточно отличных статей на эту тему. Поговорим предметно о том что такое ABI‑разрыв или ABI‑несовместимость. ABI‑разрыв - это ситуация, когда два и более бинарных файла представляют работу с одними данными по-разному. Представим ситуацию в кофейне, вы заказали большой кофе, бариста готовит нужный объем, но стажер подает ему стакан меньшего объема, как результат вы либо получите меньше кофе, либо произойдет потеря ценных миллилитров. Это и есть ABI‑разрыв, один компонент системы представляет себе работу не так как другой и на стыке их взаимодействия получатся поведение, которое не закладывалось изначально.
Есть классическая проблема: изолированные процессы — хорошо для надёжности, но хочется иногда вызвать функцию из другого процесса, как будто она лежала в той же библиотеке. Стандартные IPC — это всегда протокол: описал интерфейс, сгенерировал стабы, поднял сервер, прописал адреса. Simplerpc предлагает путь короче: пишешь обычную функцию на Си, линкуешь библиотеку — и она автоматически становится RPC-методом, доступным другим процессам на той же машине.
В этой статье пойдет речь о немаловажных особенностях разработки встраиваемого программного обеспечения (далее ВПО) для микроконтроллеров (далее МК) с низким уровнем абстракции аппаратного обеспечения.
Это не полноценный гайд по написанию кода ВПО, которых на просторах интернета сегодня тьма, а лишь нюансы, которые помогут писать хороший код.
Особенности этой огромной отрасли, embedded-разработки, лежат на поверхности и вытекают из ответа на вопрос: а какая вообще стоит задача? Если обобщить, то прозвучит это так: закодировать алгоритм работы, как правило, многозадачной однопоточной системы с низким уровнем абстракции аппаратного обеспечения.
Когда пишут программу HelloWorld на C, обычно выводят текст “Hello, World!”. Но когда программа пишется для микроконтроллера, часто ограничиваются миганием светодиода, особенно для микроконтроллеров семейства STM32.
В статье я разберу, как можно вывести “Hello World” в программе для микроконтроллеров этого семейства.
Си отлично работает на микроконтроллерах и никуда не исчезает. Но часть правил, которые в Си держатся на архитектуре проекта и дисциплине разработчика, в Rust можно выразить так, чтобы их проверял компилятор.
Разберём это на DMA, владении периферией, состояниях GPIO, прерываниях и unsafe — без попытки доказать, что Rust должен заменить Си.
Я работаю над bffi‑rs, экспериментальным фреймворком для нативных биндингов Bun, написанным на Rust.
Проект появился из довольно практичной задачи. Я хотел сделать небольшое desktop‑приложение с нативным WebView, но при этом оставить Bun основным рантаймом.
В экосистеме уже есть решения для подобных приложений. Например, некоторые интеграции WebView для Bun используют Rust и napi-rs. В варианте Electrobun, который я рассматривал, для WebView используется Wry, а связка между Rust и JavaScript строится через napi-rs. Эти проекты решают реальные задачи, но у меня появился другой вопрос: что будет, если строить нативную часть приложения вокруг Bun, а не вокруг совместимости с Node.js?
Недавно я гонял бенчмарки на свежей сборке CPython (ветка с tail-call интерпретатором, PGO + LTO, GCC) и снял флеймграф стандартного бенчмарка async_generators из набора pyperformance (рекурсивный обход дерева на 100 000 нод с глубиной вложенности ~17).
Картина на профиле оказалась фееричной: почти треть всего процессорного времени (29%) сжиралась кодом, который вообще не делал никакой полезной работы.
Рантайм создавал, настраивал, а затем тут же уничтожал объекты исключений StopIteration, о существовании которых Python-код даже не догадывался.
Ниже о том, откуда растут ноги у этой проблемы в Си-коде CPython и как пара правок в genobject.c дали ускорение в 1.33x — 1.53x.
В экосистемах со сложившейся моделью пакетных индексов вроде Python, Java или JavaScript состав проекта обычно начинают анализировать с манифеста, где разработчик перечисляет прямые зависимости проекта и их допустимые версии. Менеджер пакетов читает эти требования, выбирает совместимые версии и подтягивает зависимости, которые нужны самим пакетам. Конкретный результат выбора сохраняется в lock-файле, где фиксируется уже не диапазон, а точные версии прямых и транзитивных зависимостей. В результате получается список всех пакетов, необходимых для работы с проектом.
В проектах на C и C++ такой общей записи, как правило, нет. Одну библиотеку могут устанавливать через менеджер системных пакетов, другую собирать из исходников в отдельном пайплайне, третью копировать прямо в каталог с исходным кодом проекта. Все они могут оказаться в рабочем приложении, хотя ни один источник не обязан перечислять их все в одном месте.
На крупной кодовой базе это быстро становится проблемой. Например, в нашем разборе автоматизации SBOM для LibreOffice в проекте была сотня с лишним C/C++ библиотек, собственная сборочная система и ресурсы вроде шрифтов и словарей, которые тоже попадают в поставку. За каждым компонентом такого SBOM стоит отдельное расследование от файла и команды сборки к имени проекта, версии и источнику. На каждом переходе теряется своя часть данных.
В CodeScoring мы анализируем состав программных продуктов и на практике часто сталкиваемся с ограничениями разных экосистем. Разбор проектов на C/C++ требует особого внимания. В этой статье мы разобрали особенности этой экосистемы, которые осложняют построение SBOM, и постарались рассказать, что позволяют выяснить разные методы анализа.
Рассмотрим класс задач, который встречается в разных областях. Долгоживущий процесс держит состояние из нескольких миллионов объектов по 2 КБ каждый. На это состояние напрямую указывают и другие потоки, в том числе внешние, и заменить эти указатели копированием или доступом через менеджер не позволяет сама архитектура. Например, потокам интерфейса с аппаратной частью нужно читать данные в реальном времени, без какой‑либо синхронизации с главным потоком. Рядом крутится цикл обработки событий, и его итерация обязана завершаться за десять миллисекунд. Это строгий RT дедлайн.
Такая связка требований почти не оставляет выбора в организации хранения и управлении таймерами. Ни один стандартный контейнер не закрывает все свойства сразу. И каждое упущенное свойство на таком масштабе превращается либо в уязвимость, либо в срыв дедлайна.
Статья расскажет о двух технических решениях, которые закрывают эти задачи. Первое даёт хранилище, в котором адрес записи неизменен всё время её существования. Второе ограничивает обход только активными объектами.
Решения взяты из реального проекта, библиотеки‑ядра libgsml3parser для построения программной GSM/2G базовой станции. Там роль объекта играет сессия абонента, а 3GPP правила задают конкретные таймеры. Оба решения переносятся на любую систему того же класса ограничений почти без изменений.
Сегодня широко используют cmake add_subdirectory и сборку через Gradle для кросс-компиляции сишных библиотек под андроид. Мы же рассмотрим более продвинутый и универсальный способ, который работает со множеством систем сборки и позволяет любым проектам найти свои зависимости без написания отдельных костылей под каждый проект: будем отдельно собирать каждую библиотеку ее собственной системой сборки в общий $PREFIX
Ученики подарили мне ESP32. В коробке было всё, что обычно: датчик температуры, реле, горсть светодиодов, круглый дисплей и провода, которых, как выяснится позже, всегда не хватает ровно на один.
Нормальный человек собирает из этого термостат за вечер. Я собрал термостат, посмотрел на него и подумал: а неприятно же будет каждый раз лезть с кабелем, если я захочу поменять порог с 22 на 23 градуса.
Дальше мысль поехала не туда, и в итоге на плате оказался интерпретатор eBPF со своим верификатором байткода. Логика управления теперь заливается по Wi-Fi обычной программой на C, скомпилированной clang -target bpf. А потом я взял десять маленьких программ и прогнал каждую через свой верификатор и через верификатор ядра Linux, чтобы посмотреть, кто из нас двоих что думает.
Сошлись шесть из десяти. Про оставшиеся четыре и написана статья — они оказались интереснее, чем сам проект.
В прошлой статье я сделал обзор популярных способов отладки embedded: GDB-клиент -> GDB-сервер (OpenOCD) -> программатор -> целевой МК. Тогда я сформулировал свои субъективные требования к “идеальному” программатору. И на тот момент у меня уже был минимально рабочий вариант такого программатора. И вот спешу представить к чему привели меня изыскания в этом направлении.
Я давненько подписан на TDMLab вконтакте и под одним из постов про новый отечественный микроконтроллер возник вопрос про аппаратный криптографический ускоритель данного МК. Так получилось что у меня на руках есть отладочная плата на К1921ВГ015 и я как раз работаю с криптографией в том числе. Поэтому решил написать небольшой тест и представить общественности, потому что многие относятся настороженно к отечественным микроконтроллерам (как и я по началу), а зря.
