Зачем ставить внешнюю IC памяти или SD карту если в микроконтроллере осталось много свободной Flash памяти! 

Микроконтроллеры семейства STM32H снабжены двумя независимыми банками Flash памяти и это очень удобно. В одном банке можно расположить программный код, а в другом временные перезаписываемые данные.  

Как сделать из внутренней Flash подобие EEPROM сравнительно неплохо написано в этом апноуте от ST. Но с некоторого уровня комплексности встроенного ПО хранить данные в именованных файлах удобнее чем в жёстких структурах. Файлы упрощают реюзинг, облегчают поддержку преемственности версий, апгрейды и даунгрейды. Файлы освобождают от хлопот с планированием размещения во флэш и разруливанием конфликтов размещения, особенно если приложение модульное и модули разрабатываются отдельно. 

Здравствуйте, меня зовут Дмитрий Карловский и я… прилетел к вам на турбо-реактивном самолёте. Основная суть реактивного двигателя изображена на картинке.

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

Это — текстовая расшифровка выступления на SECON.Weekend Frontend'21. Вы можете посмотреть видео запись, прочитать как статью, либо открыть в интерфейсе проведения презентаций.

Контейнеры Docker уже довольно давно стали неотъемлемой частью инструментария разработчика, позволяя собирать, распространять и развертывать приложения стандартизированным способом.

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

Так уж случилось, что я пишу код для разных IoT-железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основным фокусом является не экономия каждого байта и такта процессора, а понятный и надежный код. Поэтому в проекте разрабатывают под Embedded Linux и в качестве основного языка используют C++ в его современном варианте - C++17, активно поглядывая на фичи из стандарта 20-го года и новее.

Иногда запускаются новые проекты на той же платформе, с теми же процессами и с переиспользованием многих уже существующих компонентов, и тогда в эти проекты мы ищем программистов, с учетом вышесказанного - программистов на C++. В embedded, тем не менее, чистый C все еще очень популярен, и нередко собеседоваться на вакансию C++ Developer'а приходят именно сишники. Логика у человека простая: языки, на первый взгляд, довольно близкие, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится.

При проектировании устройства на микроконтроллере бывает встает вопрос об обновлении прошивки прибора. Причем сам процесс обновления прошивки должен быть простым и доступным для обыкновенного пользователя. И конкретно для микроконтроллера STM32F103C8 возможна загрузка прошивки по UART. То есть к схеме необходимо добавлять микросхему конвертера USB-UART. Либо воспользоваться аппаратными возможностями USB микроконтроллера, что я и сделал. Меня заинтересовал вопрос о возможности обновления прошивки по USB. На некоторых МК даже есть аппаратный USB-загрузчик, но только не на STM32F103C8, поэтому пришлось все программно реализовывать. По программной части для STM32 существует USB Library от STMicroelectronics с реализованными классами USB и примерами. В частности заинтересовал класс DFU т.е. загрузка прошивки по USB. В данном классе уже реализован свой набор команд для взаимодействия МК и приложения на ПК "STM32CubeProgrammer". Но мне хотелось что-то своё, кастомное и неограниченное данным набором команд. И пришла мысль "А почему бы не реализовать всё это в классе CDC?". Тут и размер загрузчика примерно таким же оказался, но главное можно реализовать свой набор команд, работать на ПК с последовательным портом и соответственно понятнее, как написать приложение для ПК. У меня есть небольшой опыт написания приложений с использованием библиотеки QT на С++, поэтому с ее помощью была создана программа для USB загрузчика.

Здесь разберем следующие темы:

• Специфика конфигурации Azure RTOS на платформе BACKPMAN v2.0 с микроконтроллером STM32H753.

• Подключение на один порт USB одновременно трех разных интерфейсов: Mass Storage, Virtual COM, RNDIS 

• Универсальный драйвер последовательного ввода-вывода способный работать через UART, USB,  Telnet, FreeMaster и прочие каналы связи. 

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

Начать свою статью хочу с известных многим слов:

«Что нам стоит, дом построить?
нарисуем, будем жить,
и уж, точно, непременно,
в нём не будем мы тужить.»

Что нам стоит собрать усилитель с ДСП обработкой сигнала, да еще с красивым веб интерфейсом и различными другими интерфейсами управления? Легко? На практике это оказывается достаточно сложная задача.

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

ВАЖНО: это мой личный взгляд на разработку, он не обязательно будет совпадать с вашим мнением. А возможно наоборот, я озвучу некоторые мысли, которые вам кажутся родными, но это просто совпадение. Мой взгляд может не совпадать с классическими подходами к разработке оборудования. Но он имеет место быть, так как подтвержден успешным запуском в производство некоторого количества оборудования.

Если интересно - добро пожаловать.

Думаю, что каждый из embeded-разработчиков хотя бы раз в жизни пользовался терминалом для работы с COM-портом ПК - простой программой, позволяющей персональному компьютеру через встроенный интерфейс RS-232 (или USB-переходник) общаться с внешними устройствами, например такими, как GSM-модем или просто обмениваться данными с микроконтроллером в процессе разработки и отладки прошивки.

Таких терминалов на данный момент создано довольно много, как говорится "на любой вкус". Однако, как часто бывает, когда начинаешь более-менее длительно работать в какой-либо программе, начинает постоянно не хватать то одной функции, то другой, то одно кажется сделано неудобно, то другое. Всё время ловишь себя на мысли: "это лучше сделать было бы так, а это - вот эдак" :)

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

Привет, дорогой хабровчанин! Хотел выразить тебе огромное спасибо, за то, что смог побудить меня написать эту статью… ?

Заваривайте чаёк, кофеёк или что-то покрепче и погнали читать вместе!

Этот текст предназначен для тех, кто только осваивает программирование. Я читаю лекции по C++ на первом курсе местного университета, и в качестве практикума предлагаю запрограммировать любую игру (не выношу проектов типа "софт бронирования книг в местной библиотеке"). Соответственно, чтобы помочь начинающим, я сделал некоторое количество заготовок, с которых можно стартовать свой проект. Например, заготовку олдскульного 3д шутера в 486 строк C++ я уже описывал, а вот тут можно посмотреть, что из неё сделали первокурсники.

В этот раз всё будет ещё проще, я хочу сделать заготовку под простейший платформер, вот так выглядит результат:

На данный момент проект содержит менее трёхсот строчек цпп:

ssloy@khronos:~/sdl2-demo/src$ cat *.cpp *.h | wc -l
296

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

Итак, поехали!

Здесь рассматривается технология отладки платы контроллера резервного питания и его программного обеспечения . Используются: адаптер SWD, осциллограф, VT100 терминал через UART, движок FreeMaster, экспорт и анализ в MATLAB. Дан пример реализации регулируемого источника напряжения. Заключительный тюнинг платы.

Добрый день, жители Хабра. Данный пост будет посвящен программированию на C++, и использованию constexpr объектов с целью повышения уровня удобства и одновременно оптимизации кода с точки зрения размера и производительности.

В процессе работы над одним из проектов, задумался: "нельзя ли сделать удобный доступ к GPIO портам на STM32, и при этом сделать его оптимальным по размеру кода и производительности". Что я хотел получить...

Любой программист, решивший заняться разработкой под Embedded Linux, придя буть-то из высокоуровневых языков программирования, либо из программирования микроконтроллеров на С/С++, неизбежно оказывается удивлен крайней недружелюбностью embedded linux. Текстовый блокнот и консольные утилиты вместо столь привычных IDE, и отладка по логам вместо отладки программатором сильно замедляют процесс разработки. В статье описывается, как мне удалось снизить время доставки изменений до целевого железа при кросс-компиляции в 10 раз.