Программирование микроконтроллеров *

Если вы изучили начала цифровой схемотехники и компьютерной архитектуры по книжке Харрис & Харрис и потом вознамерились пойти собеседоваться на позицию проектировщика микросхем в Apple или NVidia, то вы интервью не пройдете. Посколько вы наверняка получите вопрос про реализацию в хардвере очередей FIFO, а это в Харрис & Харрис не описано.

Хуже того, даже если вы возьмете книжку Digital Design by William Dally & Curtis Harting, которую используют для обучения студентов в Стенфорде, и прочтете ее от корки до корки, то у вас все равно мало шансов, потому что, хотя FIFO там и есть, но в очень базисной форме, а контроль потока данных заканчивается на скид-буферах.

TL,DR: gerbmerge+pdf merge+non-kicad interactivebom позволяет нам эффективно склеивать очень похожие, но при этом разные по форме и нюансам платы электронных блоков управления ДВС. Другие новости про rusEFI, до сих пор ищем единомышленников :)

В статье от 2014 года https://habr.com/ru/post/244737/ рассказ об открытом электронном блоке управления двигателями внутреннего сгорания rusEFI остановился на плате Frankenso. За четыре года мы продали 100 юнитов rusEFI, потом за последние 12 месяцев мы продали ещё 100 более современных юнитов, многому научились - но всё равно продолжаем пытаться понять, чего же именно мы хотим. Сейчас мы смещаем фокус с универсальности на устройства для конкретных семейств автомобилей с конкретными разъёмами и схожими распиновками ЭБУ, этим мы в том числе мечтаем привлекать программистов, которым не комфортно паять.

Давайте для начала я расскажу про Hellen https://github.com/andreika-git/hellen-one - это наш инструментарий разработки семейства модульных, склеенных из кусочков похожих, но всё-таки разных плат под конкретные проводки конкретных автомобилей.

Примерно год назад стало понятно, что универсальные блоки слишком сложны в поддержке: возможность управлять практически любым бензиновым двигателем с почти любыми оригинальными датчиками и формами сигналов ДПКВ/ДПРВ достигается только за счёт огромных усилий по поддержке нашей очень небольшой командой экспертов. При этом результат механически и электрически обычно выглядит всё равно очень плачевно. И со своей стороны мы устали сильно много допаивать руками после изготовления платы сервисом JLCPCB. Вместо большого универсального https://rusefi.com/s/proteus и маленького универсального https://rusefi.com/s/microrusefi ЭБУ мы решили сделать пару десятков ЭБУ под конкретные распиновки конкретных популярных автомобилей, изначально оптимизированных именно под JLCPCB каталог компонентов. Не хотелось разрабатывать и поддерживать много плат под конкретные автомобили ручным копированием блоков схемы и блоков трассировки. Наше решение: Hellen One Framework, это набор скриптов для склеивания gerber, PDF схем, описаний монтажа и HTML просмотрщика плат.

Операционная система реального времени - сердце программного обеспечения разрабатываемого контроллера. На этот раз пробуем Azure RTOS.

Допустим, вы сделали свое собственное устройство «Умного дома» и хотите интегрировать его в платформу домашней автоматизации Samsung SmartThings. Тогда вы сможете включить его в общую экосистему, поддерживающую множество устройств от разных производителей. Пользователи вашего устройства смогут инициализировать его удобным образом, задавать сценарии автоматизации, взаимодействовать с ним через мобильное приложение.

Я покажу, как это сделать, на примере самодельного устройства «Умный чайник». На функциональном уровне оно повторяет существующие на рынке устройства такого типа. Конечно, сам «чайник» мы собирать не будем, сделаем только очень простой прототип. Мой пример будет иллюстрировать в основном программный уровень. На железном уровне, я обошелся минимумом периферийных устройств, а часть из них реализовал как “заглушки”. Чтобы вы могли повторить все описанные в статье шаги самостоятельно, в качестве целевой платформы я выбрал плату микроконтроллера ESP8266 - одну из самых доступных и популярных на рынке. Данный пример я сделал в качестве стажировки в Исследовательском центре Samsung, и он будет полезен всем, кто еще только начинает заниматься разработкой умных устройств.

Всем привет! В процессе работы над гексаподом AIWM я все чаще задумывался о каком-нибудь удобном интерфейсе для общения с ним. В результате тесной работы с Linux через терминал я подумал, а почему бы не использовать такой же интерфейс и в гексаподе? Я был очень удивлен, что по запросу "STM32 terminal" я не нашел готовых реализаций. Ну раз нет готовых, то напишем свою реализацию терминального сервера, которую можно использовать в микроконтроллерах. Сделаем это без использования динамической памяти и прочих опасных радостей.

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

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

Эта статья - краткий гайд о том, как с нуля завести STM32 под CLion, без шелухи в виде HAL и STM32CubeMX.

Попалась задача в проекте реализовать, чтобы по USB микроконтроллер прикидывался несколькими дисковыми устройствами для MicroSD, встроенной EEPROM и нескольких страничек оперативной памяти. Решил, что вполне логично, пойти по пути наименьшего сопротивления, попробовав запустить из коробки, то что ST реализовали в своей библиотеке. Работа c USB разделена у них на уровни абстракции: драйвер + MiddleWare:

В статье говорится как заставить работать USB Mass Storage multi LUN путём исправления ошибок в библиотеке Middlewares ST, а также побороть сопутствующие проблеммы. Исравлялось для stm32l4, но может быть достаточно легко адаптированно для остальных серий. Каждый LUN, по сути - независимый диск со своей таблицей разделов и адресацией. В конце статьи приводится ссылка на репозиторий с исправленной библиотекой. Также отправил Pull Request в ST - ждём официальных исправлений!

В процессе переделки игрушки-осциллографа DSO138, как уже описывалось в предыдущей статье, возникла идея в DSO303 попробовать фокус с удвоением частоты дискретизации. В самом деле для STM32F303 теоретически максимально достижимая скорость дискретизации с точки зрения входа АЦП, а это определяется минимальным временем открытия УВХ, которое в нашем случае 1,5 такта х (1 / 72 МГц), или примерно 20,8 наносекунд, что дает 48 MSPS (миллионов отсчетов в секунду). Однако при параллельной работе 4-х АЦП на 6 МГц получается достичь только 24 MSPS из-за ограниченного быстродействия АЦП.

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

Очень часто появляется необходимость отсчитывать время, отработанное некоторым устройством. Для ведения счетчика наработки необходимо периодически с определенным интервалом времени, например каждую минуту, обновлять значение, хранящееся в ячейке энергонезависимой памяти EEPROM. К сожалению, ресурс циклов записи и стирания этих ячеек памяти обычно мал и составляет около 10.000 циклов (по оценке производителя). Значит, если стирать и перезаписывать значение в одну и туже ячейку памяти с интервалом в 1 минуту, то ресурс ячейки будет израсходован примерно за неделю. Для увеличения этого времени можно использовать не одну ячейку, а все ячейки некоторой, свободной страницы памяти, например последней. Это даст нам 1024 * 10.000 запас циклов записи и стирания, что эквивалентно, примерно 19 годам при ежеминутной перезаписи значений счетчика.

На Али продается за очень недорого интересная игрушка – осциллограф под названием DSO138. Он снискал уже довольно большую популярность среди любителей электроники, но параметры этого приборчика, увы, позволяют его более-менее полноценно использовать только для отладки очень низкочастотных схем. Собственно, он и не позиционируется как инструмент, а скорее, как DIY-kit для начинающих электронщиков.

Собран этот «игрушечный» осциллограф на микроконтроллере STM32F103, и при достаточно грамотном схемотехническом решении цифровой части, наличии довольно приличного цветного дисплея 320Х240 точек, и не самом поганом аналоговом тракте, все, увы, гробится очень слабыми АЦП на борту 32F103. Заявленная полоса в 200 кГц может быть признана таковой только с очень большой натяжкой. Да, наличие или отсутствие сигнала с такой частотой он покажет, но вот реально посмотреть что-то сверх этого не получиться.

При этом есть у 103-й серии чуть более старший брат – STM32F303, по ножкам совместим практически полностью, но по интересующим нас параметрам существенно лучше, на борту 4 АЦП с частотой преобразования 5 МГц (6 МГц с 10-ти битным разрешением). При таком раскладе, если использовать все 4 АЦП параллельно с 10-ти битным разрешением, можно получить временное разрешение до честных 24 MSPS (миллионов отсчетов в секунду). Стоит микроконтроллер тоже недорого, на том же Али можно легко найти за опять же весьма умеренные деньги. Понятно, что идея поменять микроконтроллер возникла практически сразу после того, как я этот самый DSO138 и попробовал.

О том, что получилось в результате, и написана эта статья.

Зачастую разработчику, или даже пользователю, требуется посмотреть, что происходит внутри устройства. Обычно в таких ситуациях используют либо текстовой вывод в терминал (через голый UART или самописный протокол гарантированной доставки), либо пишут свои собственные системы логирования. Однако, всегда ли оправдан такой подход? Есть ли решение проще и производительнее? В данной статье мы рассмотрим одно из таких - библиотеку логирования uP7.