С++ обертка для «всех» Операционных Систем Реального Времени для CortexM4

Ну, за отказ от макросов поклевать немного и можно :) В Contiki OS, не к ночи будь помянута, многозадачность построена на «протопотоках» (protothreads), очень забавной конструкции на чистых макросах, подобный же механизм используется в «со-процедурах» (coroutines) FreeRTOS. Сомневаюсь, что это можно обернуть в C++.

По поводу Clion, да собирал тулчейн, + OpenOCD/GDB, плагином не пользовался. У меня STLink китайский через openOCD не прошивается, ресет не выведен на микронтроллер, приходилось при прошивке кнопку ресет рукой нажимать, поэтому плагин не подошёл, я подключился к STLink-Utility, и она после сборки и конвертации в двоичный файл прошивает, а потом уже запускается OpenOCD, чисто на отладку.

Без простыни дефайнов ну никак жить нельзя

Есть задачи, которые не решаются без макросов(некоторые пока что)
Пара примеров:
* Q_OBJECT
* SCOPED_EXIT
* библиотека nan — там можно без макросов, но какой смысл
* включение различных участков кода
* поключение различных заголовочных файлов

Спасибо, удалить надо этот метод вообще, не нужен он.

Конкретно с FreeRTOS вечная путаница из-за того, что это не операционная система, а только ядро операционной системы, о чём чёрным по белому прямо в заголовке её сайта и сказано. Всё прочее там — обвес на усмотрение пользователя.

А ядро — это действительно треды, шедулер и IPC. Остальное не его забота.

Да это ядро, которое занимается многозадачностью, но как бы это и подразумевает под собой определение ОСРВ, по поводу прерываний и флагов, да в жизни так не используется. Есть промежуточный класс InterruptController, который все эти флаги скидывает, а потом вызывает обработчик конкртеного объекта, можно его сделать на основе механизма подписки, в итоге обработчик прерывания скажем кнопки из этого примера выглядел бы просто как:

void Button::HandleInterrupt() {       
         myTask.Signal();   
}

Но обвязку сделать уже не дело ОСРВ, так как этот механизм можно сделать по разному, можно сделать быстрым но жрущим много памяти, можно чтобы быстро, мало памяти, но много ручной работы,… т.е. не дело обертке решать за пользователя, как это реализовывать, так как зависит от конкретного проекта и контретных требований. Например, реализую я этот механизм с помощью шаблона подписчик, так чтобы любой мог подписаться на прерывание, но сколько этих подписчитков может быть? 10-100, динамически выделять память я же запретил себе :) Придется память выделить, а может у вас уже памяти нет. Поэтому пусть пользователь сам решает, как ему прерывание обрабатывать.

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

Да, можно потому что вначале пользовали операционку, которая довольная старая, но очень популярная, после того, как мы наткнулись на 1001 баг в ней, мы решили от неё отказаться и перейти на более надежную с сертификатом надежности. FreeRtos я использую для обучения студентов. Сейчас договариваемся по использованию МАКС ОСРВ в университете.

1, Потому что IAR не совсем поддерживает thread (With C11 enabled, the IAR C/C++ Compiler for Arm can compile all C11 source code files, except for those that depend on thread-related system header files. The IAR C/C++ compiler does not support source code that depends on thread-related system headers.), и вообще микропроцессор не всегда имеет 512 кБайт ПЗУ и 64 кб ОЗУ, бывает и 32 кБ ПЗУ и 8 кБ ОЗУ — это именно для этих целей. Если вы выпускаете 100 000 датчиков в год, то 30 центов сэкономленных на процессоре, это 30 000 долларов, а если доллар уже 100 000. Представляете потери из-за того, что я решил выпендриться и использовать навороченную универсальную библиотеку или вектор?
2. Написано, что не отказ, а по возможности, это не моя прихоть, а требования стандартов надежности, да приведение типов есть, но они все из-за того, что по другому никак. Но избегать надо.
3. Вектор помогает, согласен, но жить без него можно :) также как и без стринга, когда у вас ограничения в ОЗУ. Boost хорошая библиоткеа, но половина из неё не будет работать с IAR, как не работает полностью atomic.
Мое мнение что мир emdedded разделен все таки на три части — 1 — это те кто делает, что-то на основе, чего-то типа Linux, вторые это те кто юзает большие микроконтроллеры с 1 МБ ПЗУ и 512 ОЗУ и третьи это те кто юзает небольшие до 256 кБайт ПЗУ и 32 кБ ОЗУ микро для датчиков — вот, я думаю, что как раз моя статься ориентирована на них, чтобы продвигать переход на С++. А так я полностью согласен с вами, чем больше уже готовых решений принимать, тем лучше, но все таки специфика есть везде…

враппер над «тредами», «семафорами», «мьютексами» и тп. если это уже было сделано в boost а также в стандартной библиотеке начиная с C++11

Очевидно, треды и средства их синхронизации должны взаимодействовать с ядром ОС. Т.е. надо писать порт STL на конкретную операционку. Пока, к сожалению, таких супергероев не видно…

С привидениями нет проблем

Да нету никаких проблем с приведениями типов. Если никогда не ошибаться. А если в макрос, внутри которого cast на cast'е, передать что-то не то, компилятор это тихо сожрёт без каких-то варнингов.

Как жить без std::string и std::vector?

Продумать и описать протоколы, по которым идёт взаимодействие с внешним миром, статически выделить необходимые буферы (хоть сишные, хоть std::array), и жить…

Посмотрите в сторону использования библиотеки boost

В описываемом случае (контроллер относительно мелкий, malloc по каким-то соображениям не используется) лучше смотреть куда-то в район etlcpp.com. Бустом, правда, я никогда не пользовался — посмотрел, испугался, и закрыл.