В этой статье пойдет речь о первом поколении микроконтроллеров от Raspberry Pi Foundation — RP2040 на основе двух ядер ARM Cortex‑M0+, и о плате, которая базируется на этом чипе — Raspberry Pi Pico. Статья призвана облегчить понимание некоторых принципов работы RP2040 и микроконтроллеров в целом.
Все знают авто-электриков и диагностов. Я IT-автоэлектрик объединяю знание физики автомобильных цепей и низкоуровневого программирования на С для создания инструментов анализа и изучения j1939.
CAN шина это мост между двумя мирами авто-электриков и IT специалиста. Но для многих этот мост, увы кажется непреодолимой пропастью. Ребята попробуйте программировать на Си и вы пойдёте по этому мосту. Я начинал программировать в телефоне termux. То есть для этого нужно только желание.
Я себя не считаю самым умным. Я просто нашел для себя мощную точку пересечения этих профессий и стал называть этот подход IT-автоэлектрик. Писать свои собственные утилиты на С чтоб заглянуть под капот CAN шины. Под капотом ДВС менее интересно.
Размер моих логов на сегодняшний день 1 - 3 мегабайта. Если вес лога гигабайты то по идее данные нужно положить в голову страницы и процессор полетит как пуля. Размер скомпилированного файла map_id_j1939.c и viz_j1939.c по 16.5 КБ.
Данная статья является продолжением публикаций про созданную мною систему "Умный дом" на основе проводного интерфейса CAN. Также предлагаемый проект может быть использован для разработки каких то других пользовательских программ, так как оформлен в виде задачи (Task) в FreeRTOS. Программа написана на языке программирования C/C++ в среде программирования ESP-IDFv5.
Как оживить старый ВЛИ (VFD) без родной электроники? В этой статье разберем подключение неизвестного дисплея, управление сетками и сегментами, работу с высоким напряжением и создание собственного драйвера на Arduino Nano, который позволит управлять индикатором через Serial‑порт.
Приветствую!
В этой части мы рассмотрим что такое guard variables и как под капотом работают синглтоны Майерса.
И так, стандарт начиная с С++11 гарантирует нам что локальные статические переменные инициализируются потокобезопасно. Но кто и как это обеспечивает? Это делает ABI.
И все таки о чем же идет речь? Представьте себе что есть вот такая структура:
Каждый, кто работает с SSH, наизусть знает ритуал первого подключения (TOFU) и страшный ворнинг о смене ключей хоста. Но почему в 99% случаев мы просто слепо сносим записи через ssh-keygen -R, превращая важный механизм ИБ в формальность, а known_hosts в бездонный кэш?
В этой статье мы приоткроем капот SSH-хэндшейка, поглядим одним глазком на пакет SSH_MSG_KEX_ECDH_REPLY и выясним, почему для проверки идентичности сервера не нужен полноценный SSH-клиент. А в конце наведём порядок в многолетних залежах админского мусора с помощью компактной утилиты на чистом Си.
В этом тексте я покажу, как на основе микроконтроллера, аудиокодека и SD карты запрограммировать самый настоящий диктофон.
Перечислены особенности разработки звукозаписывающей аппаратуры и типичные трудности разработки диктофонов.
Мне всегда было лень доставать телефон ради TOTP-кода, а вручную вводить длинные сложные пароли — удовольствие тоже сомнительное. С паролями эту проблему часто решают плохо: делают пароль попроще и покороче, чтобы его было удобно набирать. Но с TOTP так не получится — код живёт отдельно, его всё равно нужно открыть, посмотреть и перепечатать.
Поэтому я решил сделать маленький «вписыватель паролей»: USB-устройство, которое притворяется клавиатурой и само вводит TOTP-код или сохранённый пароль.
В этом тексте я показал как можно разработать прототип музыкального проигрывателя на основе микроконтроллера STM32F407VG и аудио кодека WM8731. Показал как спроектировать прошивку проигрывателя wav файлов на основе I2C, I2S, DMA, SDIO и FatFs.
Предисловие
Возможно то, про что я хочу рассказать в своей первой статье тут, покажется не новым, уже знакомым велосипедом. Речь пойдет о контроллерах на базе ESP32 и программном обеспечении. Да, современных решений, открытых и бесплатных – много. А сейчас зарождается еще одно (а опенсорса мало не бывает, я считаю).
В статье я упущу и не буду рассказывать ни про свое знакомство с ардуиной, esp, php, python, js ни про то, что пришел сюда давным-давно гуманитарием. И да простят мой, вероятно не корректный, «жаргон» истинные профессионалы в микроэлектронике и программировании - итак, приступим.
Совсем недавно я отключил RPI4 с HA и наконец «воткнул» в котельную очередную, но «готовую к деплою» версию контроллера (разрешите его далее называть «УМНЫЙ К1», спасибо).
Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика.
В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали.
Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки.
Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз!
В этой главе мы поговорим о структуре очередей для драйверов устройств.
Наш загрузчик оказался слишком медленным. Требование было чётким: загружаться менее чем за 500 миллисекунд. Показатели оставались не менее чёткими: 720 миллисекунд. Мы отставали от нужного значения на 44%.
Это требование не было «мягким». Загрузчик должен был работать в промышленном контроллере, обязанном реагировать вскоре после включения питания. Каждая секунда времени загрузки — это потерянная продуктивность. В спецификации к изделию был указан максимум в 500 мс. Мы обязаны были их обеспечить.
Задача загрузчика была простой:
1. Инициализировать оборудование (UART, SPI, DDR-контроллер)
2. Загрузить ядро из флэш-памяти
3. Спарсить дерево устройств
4. Перейти ко точке входа ядра
Реализация казалась логичной: стандартные структуры данных из библиотеки C. Проблема выявилась при профилировании: 45% времени загрузки тратилось на malloc/free! В загрузчике всего с 64 КБ ОЗУ динамическое распределение роняло производительность.
Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.
Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.
«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.
Этот вопрос изменил всё. На самом деле, идеальная точность не требуется. Если мы случайно обработаем одну страницу дважды, то впустую потратим часть пропускной способности, но ничего не поломаем. Главным ограничением была память.
Приветствую!
Это обзорная статья на этот раз совсем простая. Используется уже написанный аллокатор. Я лишь ставлю в известность читателей о существовании в osdev-libstdc вполне стандартных функций aligned_alloc, malloc, calloc, realloc и free. Их реализация примитивна:
Представим задачу: хайлоад-сервис гонит поток данных — логи, IP-адреса, ID пользователей, миллиарды записей в сутки. Ваша задача — посчитать количество уникальных посетителей за неделю.
Первым решением может показаться завести HashSet и кидать туда ключи, а в конце посмотреть размер. Решение неплохое, но когда речь заходит о миллиардах записей — память будет слабым местом. Один IP-адрес (4 байта) как ключ в HashSet потянет за собой накладные расходы на ноды, указатели и хеши. На практике один элемент сжирает не меньше 50–100 байт. Поток в миллиард уникальных записей потребует под сотню гигабайт оперативной памяти. Это дорого, а если инстансов десять — то просто нереально.
Но существует алгоритм, который способен решить эту задачу примерно в 1.5 килобайта памяти с погрешностью около 2%? Без хранения самих данных и гигантских кластеров. Достаточно одного прохода по потоку и пары битовых трюков — именно так и работает HyperLogLog, алгоритм родом из математической статистики, который перевернул подход к подсчёту уникальности в Big Data.
HyperLogLog используют в Redis, BigQuery, ClickHouse, Presto. В этой статье мы разберем и реализуем этот алгоритм на C, а также узнаем его предысторию.
Мне всегда хотелось посмотреть параметры окружающей среды вдали от дома и прямо на месте. Например, какое давление в самолёте на крейсерской высоте или какая влажность на берегу моря. Отсюда и родилась идея сделать компактную метеостанцию в виде брелока, который всегда с собой и работает продолжительное время на одном заряде. Чтобы не мелочиться, решил сделать сразу мелкую серию таких брелоков.
Двоичный интерфейс приложений, чаще именуемый просто ABI — это концепция, которая кажется знакомой и незнакомой одновременно. В каком смысле знакомой? Об ABI часто говорят в контексте устранения неисправностей, упоминают в статьях. Иногда даже приходится решать проблемы с совместимостью, которые провоцирует этот интерфейс. А в каком смысле незнакомый? Дело в том, что, если кто-то попросит вас описать, что такое ABI — то вы обнаружите, что понимаете, о чём речь, но чётко сформулировать ответ на этот вопрос сложновато. В конце концов, можно ограничиться формулировкой, указанной в Википедии: «набор соглашений для доступа приложения к операционной системе и другим низкоуровневым сервисам, спроектированный для переносимости исполняемого кода между машинами, имеющими совместимые ABI». Возникает ли проблема с такой формулировкой? Нет, в качестве общего описания этого вполне достаточно. Но оно может казаться немного поверхностным.
На самом деле, в информатике такая ситуация встречается нередко. Информатика — это дисциплина, не стремящаяся к абсолютной строгости. У многих концепций нет чёткого определения, зачастую бывает достаточно, чтобы описываемый феномен был общепонятным. Итак, чтобы не увязнуть в определениях, давайте рассмотрим, что именно представляют собой такие двоичные интерфейсы, и какие факторы влияют на их стабильность.
Или: как embedded-разработчик случайно написал визуализатор временных рядов
Это моя первая статья и сразу на тему в которой я разбираюсь примерно никак. Ее можно воспринимать как условный "дневник разработчика".
Статья написана не без помощи LLM, от нее по большей части редактура. Прошу камнями не кидаться
Приятного чтения!
С чего всё началось
В миру я позиционирую себя как Embedded-разработчик, а как принято во многих местах в России разработчик встраиваемых систем - это инженер-разнорабочий. Написать firmware, развести не сложную PCB, поколдовать над ядром Linux, провести исследования датчиков с китайского завода, напаять концевиков, собрать тестовый стенд, а если еще и осталось время - по возможности спроектировать корпус для устройства и произвести его прототип.
И в этот(и так немаленький список) периодически добавляется потребность в написании ПО под Пк, для работы с разрабатываемыми устройствами/датчиками и т.д. В основном, это несложные внутренние консольные утилиты, которые помогают общаться с устройством, логгировать данные, калибровать датчики и все в таком духе.
Но иногда появляется потребность в визуализации. Пока речь идет о низкочастотных датчиках и малом количестве данных - все довольно просто, но как только данных становится больше, а частоты выше - всплывает множество нюансов. При 70 кГц через 10 секунд работы датчика у меня уже 700 000 точек. Через минуту – 4.2 миллиона. А пользователь при этом хочет масштабировать/панорамировать оси, выделять области, нажимать кнопки – и всё это должно отзываться мгновенно. Стандартный подход «передать всё в библиотеку» ломается очень быстро.
