embedded разработчик (bare-metal)
Мы продолжаем цикл статей по 32-разрядным микроконтроллерам компании Megawin на ядре Cortex-M0. В этой статье будут рассмотрены средства разработки и программирования МК на gcc-arm, контроллер flash-памяти МК, пакет OpenOCD для взаимодействия с программатором ST-LINK, модуль GPIO и простейшая программа управления светодиодом.
Данная статья - что-то типа небольшого ликбеза, на который меня сподвигла недавняя статья на Хабре, про буферизацию источников питания.
Очень часто разработчикам приходится иметь дело с нестабильными или пульсирующими источниками питания, либо с пульсирующим потреблением. Соответственно, это приводит к провалам и броскам напряжения, вплоть до того, что устройством становится невозможно пользоваться, или оно вообще выходит из строя. Первое, что приходит в голову в таких случаях - поставить буферный конденсатор. Но для того, чтобы этот конденсатор реально помог - необходимо его правильно выбрать. Рассмотрим простейший пример - пропадание питания, которое устройство должно пережить без сбоев.
В предыдущей паре статей я рассуждал про ПЛИС Lattice. Давайте сегодня поговорим об эффективной разработке под них. Один наш крупный руководитель уверяет, что из разговоров с иностранными Заказчиками, он выяснил, что российских разработчиков считают пишущими классные вещи, но делающими это крайне медленно. Ну, разумеется, по сравнению с разработчиками из других стран. И разумеется, «классные» идёт на первом месте.
Один из методов обхода проблемы скорости разработки – использование готовой инфраструктуры для проектов. Я делал цикл статей про комплекс Redd, где продвигал использование готовой шинной инфраструктуры в среде разработки Quartus. Сначала это была честная процессорная система, потом – процессор мы изъяли, а шины – оставили.
Затем я делал пару циклов, где активно использовал данный подход. Мне приходилось дописывать только проблемно-ориентированные модули, остальное — среда разработки создавала за меня.
Есть ли что-то подобное для Lattice в частности и сцепки Yosys/NextPNR в целом? Вы не поверите! Решение не просто есть, но оно ещё и настолько кроссплатформенное, что подойдёт и для Yosys/NextPNR, и для Quartus, и для Vivado! И называется оно Litex. Итак, давайте попробуем поэкспериментировать с ним для подхода, который я уже давно продвигаю: «делаем штатную основу, а на неё нанизываем свои целевые блоки».
Когда я видел на Хабре упоминание о ПЛИС Lattice, у меня всегда возникал простой вопрос: «А зачем ещё одна ПЛИС?». Вроде всю жизнь хватало пары базовых. Но полгода назад случилось то, что сняло этот вопрос для меня. Пришёл Заказчик и сказал: «Мы делаем проект на ECP5». Против требований Заказчика не попрёшь!
А пока я осваивал работу с этим железом и пытался понять, как обосновать необходимость попробовать то же самое для остальных, мой знакомый, ныне живущий в Штатах, обрадовал новостью, что у его любимого поставщика подходит к концу запас десятых Циклонов и шестых Спартанов. В целом, через три года будет построен новый завод Intel, но что именно там будут производить, он не в курсе. И три года продержаться в любом случае, будет нужно. Короче, сейчас надо иметь возможность быстро мигрировать с одной ПЛИС на другую.
Итого, вчера делать ознакомительную статью про Lattice было рано, завтра – может быть поздно.
Сегодня я расскажу, где купить более-менее дешёвые платы для опытов, как быстро освоить Open Source среду разработки и какие готовые проекты осмотреть в первую очередь.
В предыдущей статье был описан процесс настройки IDE Eclipse для кросс-платформенной отладки загрузчика U-boot. В данной статье описывается устранение последних ограничений, препятствовавших полноценной его отладки. После чего, получив возможность полноценной отладки кода, пройдемся по всей процедуре инициализации загрузчика от первой инструкции и до конца в режиме отладки.
Собственно идея написать эту статью как памятку себе любимому, ну может ещё кому пригодится пришла в голову год назад, после того как убил немало времени на это нехитрое занятие. Недавно оказалось, что проблема актуальна по сей день. Почему-то ни один из найденных вариантов сам по себе не помогает и данная статься является результатом обработки всей найденной информации. При решении вопроса, больше всего бесило - возьмите мой проект и будет вам счастье, а проекта там уже и нет... Такой подход я плохо переношу, поэтому и сам делать так не буду.
Всё ниже описанное является следствием моего личного опыта, и ни на какую истинность не претендует. Все советы рассчитаны не людей только решившихся на переход с AVR на STM32
Вопросы типа почему Linux, VSCode и прочее, думаю, освещения не требуют. Считаю, что все заинтересованные в вопросе, на эти мелочи давно нашли СВОЙ ответ. Однако отмечу, в Винде всё это тоже работает, проверено, и проекты спокойно переживают миграцию между машинами.
Пожалуй начнём!
Моя версия популярного балансирующего робота. Для тех, кто хочет разобраться в математике, железе и алгоритме стабилизации.
Продолжаем изучать Rust нетрадиционным способом. В этом раз будем разбираться в нюансах работы с кучей, для их понимания понадобятся: сырые указатели, выделение памяти в куче, размер экземпляра типа, запись значений в кучу и чтение из нее, const и static, unit-like структуры, переопределение глобального аллокатора.
Это, определенно, overkill для одной статьи, а вот половину списка вполне можно освоить.
Если вы не знаете ни одного ассемблера, или, возможно, не имеете большого опыта кодинга как такового, то ассемблер RISC-V может быть одним из лучших вариантов для того, чтобы погрузиться в эту тему. Конечно, материалов по ассемблеру x86 гораздо больше. Больше людей, которые могут в этом помочь. Но x86 - это чудовище, имеющее более 1500 различных инструкций.
Архитектура RISC-V, напротив, придумана специально для того, чтобы быть простой в изучении и вместе с тем, практически эффективна для реализации высокопроизводительных микропроцессоров.
Если вам необходим хороший старт, и вы не знаете ничего о микропроцессорах, вы можете прочесть мою статью "Как работает современный микропроцессор?" (How Does a Modern Microprocessor Work?).
Если вы хотите чего-нибудь простого и весёлого, можете начать с различных игр, в основе которых лежит программирование на ассемблере: Learn Assembly Programming the Fun Way.
Другим может понравиться ретропроцессор, такой, как 6502, использовавшийся в Commodore 64. Но проблема в том, что он окончательно устарел. При его разработке не учитывались реалии сегодняшнего дня.
Большой плюс RISC-V состоит в том, что он обладает современным и простым набором команд, спроектированным с учётом современных требований, таких как медленный доступ к памяти, использование предсказателя переходов, суперскалярного out-of-order выполнения команд и т.д.
Если вам интересно всё это, прочтите: Why Is Apple’s M1 Chip So Fast?
Перед тем, как мы начнём, можете распечатать это: James Zhu RISC-V Reference.
В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.
В предыдущей части рассматривалось создание базовой системы, не выполняющей каких-либо полезных действий, но демонстрирующей, на своем примере, один из способов сборки подобных систем.
В этой части речь пойдет о таком инструменте автоматизации как Buildroot, о создании драйверов согласно современным веяниям драйверостроения, и реализации функционала, анонсированного в первой части, в виде отправки смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта.
В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.
Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.
В этом туториале я хотел бы рассказать о том, как использовать ультрабюджетные JTAG-отладчики CJMCU FT232H и RV-Degugger-Lite в PlatformIO для прошивки и отладки устройств на платформах ESP32 и GD32. Полноценной инструкции на просторах интернета я не нашел, и в процессе настройки столкнулся со многими проблемами, поэтому этот туториал появляется здесь для вашего удобства. Оговорюсь сразу, что настройка прописана для Linux, но для Windows принципиальной разницы нет за исключением танцев с Zadig.
В Си стандарта 2011 года добавили небольшую возможность "перегрузки" функций с помощью макроса. (Generic selection) Мне, очень интересно стало написать какую-нибудь функцию, которая максимально использовала бы эту возможность
Задумка: написать (макро) функцию print, которая выводит через пробел все переданные в нее аргументы. Звучит невероятно для Си, где обычно указывают тип принимаемого аргумента одной буквой в имени, и явно указывают число переданных аргументов. Но с джейнериками из C11 это возможно
В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.
Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.
В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.
Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.
Зачем собирать свой дистрибутив? Зачастую нужен ограниченный функционал при ограниченных ресурсах. Ещё чаще в автоматизации нужно создавать прошивки. Приспосабливать дистрибутив общего назначения, вычищая лишние пакеты и превращать его в прошивку путь более трудоёмкий, чем собрать новый дистриб. Использование Gentoo тоже имеет свои ограничения.
Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.
Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.