Здравствуйте! Меня зовут Александр, и я работаю программистом микроконтроллеров.

Наверное, любой разработчик встраиваемых систем время от времени подумывает написать свою собственную ось. Такую, чтобы другим неповадно было!

И ваш автор не исключение.

Как по мне - дело не то чтобы запредельно сложное, сколько кропотливое. Если у вас, как и у меня, увлечение и(или) карьера крутится вокруг Arm Cortex-M серии, то вооружаемся стволами (раз, два и три) и выдвигаемся за Джеффом. Но, написав и запустив ядро своей "best of the best" оси около года назад, я вскоре забросил разработку, ибо как я ни креативил, вместо Сокола Тысячелетия у меня получался крепенький, но банальный и скучный велосипед.

А ведь хотелось оригинальности и бесстыдного выпендрёжа.

И тут в 20-й стандарт плюсов завезли корутины.

Здравствуйте! Меня зовут Александр и я работаю программистом микроконтроллеров.

Начиная на работе новый проект, я привычно набрасывал в project tree исходники всяческих полезных утилит. И на хедере app_debug.h несколько подзавис.

Дело в том, что в декабре прошлого года у GNU Arm Embedded Toolchain вышел релиз 10-2020-q4-major, включающий все GCC 10.2 features, а значит и поддержку Concepts, Ranges, Coroutines вкупе с другими, менее "громкими" новинками С++20.

Воодушевленное новым стандартом воображение рисовало мой будущий С++ код ультрасовременным и лаконично-поэтичным. И старый добрый printf("Debug message\n") в это благостное видение не очень-то вписывался.

Хотелось бескомпромиссной плюсовой функциональности и стандартных удобств!

Доброго времени суток!

Меня зовут Александр, я работаю программистом микроконтроллеров, и это история о Фрэнки.

. . .Фрэнки родился чуднЫм. Родителями были пионэрский задор вашего автора и требования заказчика.

Когда младенца скомпилировали и по его венам потекли животворные байты, мой коллега процедил:

- Вы слепили монстра, герр Франкейштейн, но он не лишен некоторого очарования. . .

В то время я писал прошивку для станка с ЧПУ, причем заказчик наложил ограничения - строго Си, никаких сторонних библиотек, допускался только HAL с открытыми исходниками от производителя МК.

Был предоставлен забугорный образец станка, который мы должны были воспроизвести на собственных схемотехнике и ПО.

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

Ну хорошо, а какой тогда должна быть архитектура приложения, когда нет итогового ТЗ и при этом низзя(!) ни в какие сторонние РТОСы и диспетчеры? Как выстроить программу, чтобы не перелопачивать все исходники, если вдруг осознаешь в середине проекта, что логику нужно править?

Здравствуйте! Меня зовут Александр, я работаю инженером-программистом микроконтроллеров.

Пишу на С/С++, причем предпочитаю плюсы, ибо верую в их эволюционную неизбежность в embedded.

Мир встроенного ПО, язык С++ динамично развиваются, поэтому разработчикам важно не отставать и поддерживать свои скиллы и наработки актуальными моменту.

Я стараюсь следовать этому очевидному посылу, благо небожители ведущие С++ программисты и консультанты щедро делятся своим опытом и идеями на разных площадках (например здесь, или здесь).

Некоторое время назад я посмотрел мощный доклад Сергея Федорова про построение конечного автомата с таблицей переходов на шаблонах.