Пользователь
Встраиваем Lua интерпретатор в проект для микроконтроллера (stm32)
![](https://habrastorage.org/webt/p6/9j/kz/p69jkzome873c4rbil8fftedrxs.png)
В достаточно крупных приложениях немалую часть проекта составляет бизнес-логика. Эту часть программы удобно отлаживать на компьютере, после чего встраивать в состав проекта для микроконтроллера, ожидая, что эта часть будет выполняться в точности так, как было задумано без какой-либо отладки (идеальный случай).
Так как большинство программ для микроконтроллеров пишется на С/C++, то для этих целей обычно используют абстрактные классы, предоставляющие интерфейсы к низкоуровневым сущностям (в случае, если проект пишется только с использованием C, то зачастую используются структуры указателей на функции). Данный подход предоставляет требуемый уровень абстракции над железом, однако чреват надобностью в постоянной повторной компиляции проекта с последующим программированием энергонезависимой памяти микроконтроллера бинарным файлом прошивки большого объема.
Однако есть и другой путь — использование скриптового языка, позволяющего производить отладку бизнес-логики в реальном времени на самом устройстве или загружать сценарии работы прямо с внешней памяти, не включая данного кода в состав прошивки микроконтроллера.
В качестве скриптового языка я выбрал Lua.
Загрузка ОС на ARM
Загрузка ARM в четырех прямоугольниках — под катом.
Простейшее профилирование памяти на STM32 и других микроконтроллерах
— Jack Ganssle, «The Art of Designing Embedded Systems»
Привет, Хабр!
Как ни странно, но в абсолютном большинстве виденных мной «учебников для начинающих» по STM32 в частности и микроконтроллерам вообще нет, как правило, вообще ничего про такую вещь, как распределение памяти, размещение стека и, главное, недопущение переполнения памяти — в результате которого одна область перетирает другую и всё рушится, обычно с феерическими эффектами.
Отчасти это объясняется простотой учебных проектов, выполняемых при этом на отладочных платах с относительно жирными микроконтроллерами, на которых влететь в нехватку памяти, мигая светодиодом, довольно сложно — однако в последнее время даже у начинающих любителей мне всё чаще встречаются упоминания, например, контроллеров типа STM32F030F4P6, простых в монтаже, стоящих копейки, но и памяти имеющих единицы килобайт.
Такие контроллеры позволяют делать вполне себе серьёзные штуки (ну вот у нас, например, такая вполне себе годная измериловка сделана на STM32F042K6T6 с 6 КБ ОЗУ, от которых свободными остаются чуть больше 100 байт), но при обращении с памятью при работе с ними нужна определённая аккуратность.
Об этой аккуратности и хочу поговорить. Статья будет короткая, профессионалы ничего нового не узнают — но начинающим эти знания очень рекомендуется иметь.
Профилирование памяти на STM32 и других микроконтроллерах: статический анализ размера стека
В прошлой статье и я сам упоминал, и в комментариях спрашивали — ок, хорошо, методом научного тыка мы подобрали размер стека, вроде ничего не падает, а можно как-то надёжнее оценить, чему он равен и кто вообще столько сожрал?
Отвечаем коротко: да, но нет.
Нет, методами статического анализа невозможно точно измерить размер потребного программе стека — но, тем не менее, эти методы могут пригодиться.
Ответ немного длиннее — под катом.
STM32 — правильно используем встроенный flash
Предисловие
Давно ни для кого не секрет, что STMicroelectronics производит замечательные 32-битные ARM микроконтроллеры STM32. В последнее время они набирают всё большую популярность, и на то есть веские причины, которые в рамках этой статьи я повторять не намерен. Кому интересно — раз, два и три.
Однако у резкого повышения популярности есть и неприятные минусы — довольно часто авторы статей повторяют одни и те-же ошибки. А если ещё и в официальном документе производителя нужный момент описан поверхностно — то тут черт ногу сломит, пока найдёт решение проблемы.
Именно о таком моменте я и хочу рассказать. А именно — как правильно использовать возможность записи во встроенный flash нашего МК. Добро пожаловать под кат.
Как защититься от переполнения стека (на Cortex M)?
![image](https://habrastorage.org/getpro/habr/post_images/b12/c2c/358/b12c2c358fa3a040589578b71521957b.png)
Но вот если вы программируете микроконтроллеры, то проблема выглядит немного иначе. Для начала нужно заметить, что стек переполняется.
В этой статье я расскажу о собственных изысканиях на эту тему. Поскольку я программирую в основном под STM32 и под Миландр 1986 — на них я и фокусировался.
ARM-ы для самых маленьких: тонкости компиляции и компоновщик
![](https://habrastorage.org/storage2/438/be0/c60/438be0c60295fa01fbec0ec54947c008.jpg)
Продолжая серию статей про разработку с нуля для ARM, сегодня я затрону тему написания скриптов компоновщика для GNU ld. Эта тема может пригодиться не только тем, кто работает со встраиваемыми системами, но и тем, кто хочет лучше понять строение исполняемых файлов. Хотя примеры так или иначе основаны на тулчейне arm-none-eabi, суть компоновки та же и у компоновщика Visual Studio, например.
Предыдущие статьи:
Примеры кода из статьи: https://github.com/farcaller/arm-demos
Кросскомпиляция под ARM
В данном посте будут описаны:
- Инструменты
- Элементарная технология кросскомпиляции
- И, собственно, HOW2
Кому это интересно, прошу под кат.
Как загружается ARM
main()
. Первая часть статьи посвящена инструментам сборки и отладки. Вторая — обработке векторов исключений, третья — инициализации стеков и памяти.Но сначала хочу сделать одно уточнение. Многие почему-то считают, что ARM — это обязательно монстр со внешней памятью, кучей обвязки, работающий на частоте не менее 600Mhz, и т.д. Это правда лишь отчасти (если говорить об ARM9 и более поздних семействах). Тот чип, с которым я обычно работаю (AT91SAM7X512), не намного сложнее знакомых многим AVR. Ему для работы нужны только кварц и питание (можно и без кварца, но тогда будет совсем грустно). Всё. Но возможностей у него, конечно, больше, много больше, чем у AVR. Но об этом позже. Сегодняшняя статья никак не будет привязана к конкретному железу.
О языке С и производительности
![](https://habrastorage.org/files/cb5/a2b/007/cb5a2b00719a45b784986117015c9079.jpg)
Если программист хорошо знаком только с высокоуровневыми языками, например PHP, то ему не так просто освоить некоторые идеи, свойственные низкоуровневым языкам и критичные для понимания возможностей информационно-вычислительных процессов. По большей части причина в том, что в низко- и высокоуровневых языках мы решаем разные проблемы.
Но как можно считать себя профессионалом в каком-либо (высокоуровневом) языке, если даже не знаешь, как именно работает процессор, как он выполняет вычисления, эффективным ли способом? Сегодня автоматическое управление памятью становится главной проблемой в большинстве высокоуровневых языков, и многие программисты подходят к её решению без достаточной теоретической базы. Я уверен, что знание низкоуровневых процессов сильно помогает в разработке эффективных высокоуровневых программ.
Что необходимо знать, чтобы написать свою Embedded RTOS (часть 1)
![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/58b/203/196/58b2031964b739ce1a174fc1773af66b.png)
Хотел бы написать небольшой цикл статей посвященных тому, как я написал свою RTOS с какими трудностями столкнулся и зачем вообще писать свою RTOS если уже есть FreeRTOS, RTX, embOS и т.д. список достаточно большой.
Начнем с того, что по мере работы я сталкивался с тем, что часть разработчиков (и я в том числе когда-то и сам) относятся к RTOS как к некоторому черному магическому ящику, мол что-то там происходит как-то все это работает и лучше туда не лесть, а то поломается ящик и проекту «ХАНА». И все хорошо пока хорошо, но как только появляются проблемы, то начинаются бессонные ночи с отладчиком, сроки по проекту горят, а самое главное и коварное, что ошибки в RTOS отловить крайне сложно. Зачастую они имеют плавающий характер и такие эффекты как переполнение стека, инверсия приоритетов, взаимные блокировки, и все, что связанное со средствами синхронизации отладить крайне сложно.
Cо всем этим я решил разобраться в корне, и чисто в академичесеких целях начал писать свою RTOS, чтобы так сказать прочувствовать все изнутри.
В итоге, оказалось, что написать RTOS ни так уж и сложно как кажется. И есть один существенный плюс, когда пишешь все сам и осознанно, то на поиск артефактов в виде багов уходит гораздо меньше времени (пара часов или полдня максиму). Кроме того открываются внутренние чакры и начинаешь чувствовать как работают другие RTOS в чем плюсы или минусы разных RTOS, в общем возникает чувство явного прозрения.
При написании RTOS, я осознанно отказался от поддержки проприетарных архитектур как AVR, PIC и мой выбор пал на семействе CORTEX, поскольку cortex-mX, на сегодня самая распространенная архитектура в Embedded.
Как сделать context switch на STM32
![](https://habrastorage.org/web/243/7a4/22c/2437a422ca614eaa8524f06617712576.png)
Потоки… Переключение контекстов… Базовая сущность ОС. И конечно, при разработке библиотек и приложений мы всегда полагаемся на то, что реализация потоков безошибочна. Поэтому было неожиданно найти грубую ошибку в переключении потоков для STM32 на ОСРВ Embox, когда уже продолжительное время работали и сеть, и файловая система и многие сторонние библиотеки. И мы даже успели похвастаться о своих достижениях на Хабре.
Я бы хотел рассказать про то, как мы делали переключение потоков для Cortex-M, и тестировали на STM32. Кроме того, постараюсь рассказать о том как это сделано в других ОС — NuttX и FreeRTOS.
Модуль универсального контроллера для интернета вещей. Тестирование FatFs
![](https://habrastorage.org/getpro/geektimes/post_images/a10/d19/e62/a10d19e628ece2a53ba5c69e85db3f1f.png)
В этой статье я продемонстрирую проекты тестирования библиотеки FatFs портированой на модуль K66BLEZ1. Библиотека с открытым исходным кодом FatFs хорошо известна программистам микроконтроллеров и реализует поддержку файловой системы FAT32 на SD и MMC картах. Незаменимая вещь при разработке логгеров, программируемых логических контроллеров, звукозаписывающих устройств, треккеров и проч. Но иногда она может стать узким местом в системах реального времени.
Регулярные выражения: никакой магии
![image](https://habrastorage.org/getpro/habr/post_images/7cc/1be/18b/7cc1be18b5537994537cd6fff234713b.png)
Код этого поста, как и сам пост, выложен на github.
До недавнего времени регулярные выражения казались мне какой-то магией. Я никак не мог понять, как можно определить, соответствует ли строка заданному регулярному выражению. А теперь я это понял! Ниже представлена реализация простого движка регулярных выражений менее чем в 200 строках кода.
Часть 1: Парсинг
Спецификация
Реализация регулярных выражений полностью — довольно сложная задача; хуже того, она мало чему вас научит. Реализуемой нами версии достаточно для того, чтобы изучить тему, не скатываясь в рутину. Наш язык регулярных выражений будет поддерживать следующее:
.
— соответствие любому символу|
— соответствиеabc
илиcde
+
— соответствие одному или более предыдущего паттерна*
— соответствие 0 или более предыдущего паттерна(
и)
— для группировки
Хотя набор опций невелик, с его помощью можно создать интересные regex-ы, например,
m (t|n| ) | b
позволяющий найти субтитры к Star Wars без субтитров к Star Trek, или (..)*
для нахождения множества всех строк чётной длины.План атаки
Мы будем анализировать регулярные выражения в три этапа:
- Парсинг (синтаксический анализ) регулярного выражения в синтаксическое дерево
- Преобразование синтаксического дерева в конечный автомат
- Анализ конечного автомата для нашей строки
Для анализа регулярных выражений (подробнее об этом ниже) мы будем использовать конечный автомат под названием NFA. На высоком уровне NFA будет представлять наш regex. При получении входных данных мы будем перемещаться в NFA от состояния к состоянию. Если мы придём в точку, из которой невозможно совершить допустимого перехода, то регулярное выражение не соответствует строке.
STM32 + CMSIS + STM32CubeIDE
Возможно STM32CubeIDE и обладает рядом недостатков, но у нее, на мой взгляд, есть несколько преимуществ – таких как проприетарность и бесплатность, ради которых, как минимум, стоит обратить внимание на эту среду разработки, если вы не сделали этого раньше.
![](https://habrastorage.org/webt/dv/qc/r8/dvqcr8nj-bvc6u_45zida8xayd8.jpeg)
RTOS или не RTOS вот в чем вопрос
![image](https://habrastorage.org/files/3ff/676/da5/3ff676da5b2f4acabdd782f871f1b782.jpg)
Сохраняем настройки и лог файл во внутренней памяти микроконтроллера
![image](https://habrastorage.org/files/c92/874/069/c92874069b4e49d4ae65eb48e6d6af19.png)
Как работает stack trace на ARM
Элементы языка С, которые являются неподдерживаемыми в языке С++
Нижеприведенный список является моей небольшой коллекцией примеров кода на языке С, которые не являются корректными с точки зрения языка С++ или имеют какое-то специфичное именно для языка С поведение. (Именно в эту сторону: С код, являющийся некорректным с точки зрения С++.)
Этот материал я уже публиковал на другом ресурсе в менее причесанном виде, Я бы, наверное, поддался прокрастинации и никогда не собрался опубликовать эту коллекцию здесь, но из-за горизонта уже доносится стук копыт неумолимо приближающегося С23, который безжалостно принесет некоторые жемчужины моей коллекции в жертву богам С-С++ совместимости. Поэтому мне и пришлось встать с печи, пока они еще актуальны...
Разумеется, язык С имеет много существенных отличий от языка С++, т.е. не составит никакого труда привести примеры несовместимостей, основанные, скажем, на ключевых словах или других очевидных эксклюзивных свойствах С99. Таких примеров вы не найдете в списке ниже. Мой основной критерий для включения примеров в этот список заключался именно в том, что пример кода должен выглядеть на первый взгляд достаточно "невинно" для С++-наблюдателя, т.е. не содержать бросающихся в глаза С-эксклюзивов, но тем не менее являться специфичным именно для языка С.
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность