Дело закончилось обидами. А ведь я хотел как лучше! Чтобы отличная задумка авторов не отставала бы от времени, от прогресса в хардвере микроконтроллеров. Но раз обиделись, зачит чувствуете свою неправоту. Что же касается "придется писать собственную OS"- нет не придется. Ибо не вижу жгучей необходимости.

Остается искренне порадоваться, что вы идете в ногу "с прогрессом в хардвере микроконтроллеров". %)

ScmRTOS изначально задумывалась как легковесная ось для "тонких" контроллеров с 512Б ОЗУ.
Для "переднего края хардверного фронта" есть другие.
А авторы, прежде всего, разрушили два расхожих мифа: что операционкам, и тем более на с++, в мелкоте типа AVR и MSP430 не место.
За что им заслуженный респект.

Дело в том, что с типами данных действительно БЕДА.. Нестандартные размерности char, int как правило, действительно бесят, вынуждая программистов вытворять финты ушами. С этим ничего не сделаешь. Обижаться или придираться по этому поводу - бессмысленно. Приходится приспосабливаться к тому что есть.

Да, наверное есть, но программирование в системе реального времени на С++ я лично не встречал.

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

Хочется надеяться, что на том и порешили.
Дальше, если можно, по делу.

Хотелось бы в рантайме иметь возможность определения типа контроллера на котором работает scmRTOS (хотя бы один байт). Чтобы не плодить плагины для IAR под разные типы контроллеров.

Тип контроллера задается при сборке (или его можно как define задать) и использовать в коде. Задать статическую переменную и её использовать по своему усмотрению (иногда надо было). Это же не связано с RTOS.
Или я вопроса не понял?

Что мешает этот байт вставить в прошивку в виде константы и считывать ее из памяти контроллера плагином?

Все правильно, но из плагина я читаю переменную или по имени или по адресу. Второе делать постоянным (для плагина) нет возможности, а первое делать постоянным лучше внутри OS.

А о каких плагинах речь?

А по делу, - хочется видеть в составе scmRTOS класс задач, которые умеют ожидать настоящие прерывания от периферии. Безумный вариант через SW не предлагать. Еще хочется видеть эти прерывания вложенными по приоритету, т.е никаких запретов на время исполнения ISR. Видите, как просто -хочется, чтобы C++ наконец-то заработал на современных чипах.

PS. Забыл совсем. SW прерывания для медленных фоновых задач вполне можно оставить, какие они сейчас уже есть.

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

Я вижу то, что Ваше пожелание никоим образом C++ не касается.

А вы сами как это себе представляете?
Задача, целиком размещенная в обработчике прерывания?
По-моему, это будет уже совершенно другая система со своей идеологией.

Я думаю — никак. Иначе уже хотя бы какой-то конструктив проскочил. В виде «высокоуровневого» (на человеческом языке) описания происходящих процессов.

Не, это будет то, что тут сказано — задача, спрятанная в обработчик целиком. А не ожидающая "настоящие прерывания".
Если я правильно понял многократно повторенное желание — то-то в духе того, что можно сейчас сделать путём:

Но только чтобы это было без этой SomeISR(). Вот как только аппаратное прерывание возникло, так с точки за ef.wait() и продолжить. А как в другом месте поднимется флаг прерывания, кторого ждёт более приоритетный процесс, так чтобы так же без отдельного обработчика и флага сразу туда. А если менее приоритетный, то чтобы «оно» ждало.
Я не могу понять

• Причём к этой хотелке фраза "C++ наконец-то заработал на современных чипах" (если бы такое можно было сделать, то это можно было бы и на С)
• Чем так кардинально отличается Cortex-M3 или там ARM9 от AVR или MSP430, что в нём уже можно это сделать. На мой взгляд, такая хотелка подразумевает аппаратную реализацию планировщика ОС и переключения контекста, всё остальное по реально происходящим действиям (вход в ISR, отмашка конкретного события и отметка задачи как готовой к исполнению, перепланирование и переключение консткста) и временам (отрабатываемым инструкциям процессора) практически не будет отличаться от приведенного выше примера с вырожденным обработчиком прерывания, даже если при помощи каких-то языковых или внеязыковых средств визуально оно будет выглядеть без такого вырожденного обработчика и с каким-то OS::Wait(TIMER1_IRQ); в коде процесса.

Повторюсь — с точки зрения хотелки, если я её правильно понял, все используемые нами микроконтроллеры одинаковые (ну некоторые не имеют приоритетной системы прерываний). Это где-то в районе могилы iAPX 432 копать надо.