Что-то с ходу не соображу.
У меня для вывода в отладочную в качестве буфера передачи используется OS::channel. Соответственно, если я пытаюсь что-то выдать до вызова OS::Run(), то всё наглухо зависает... Пока придумалось определять, запущена ли ось, и, если нет, то выдавать напрямую в регистр передачи, в обход OS::channel.
Короче, субж

Зачем же пользоваться средствами ОС до ее запуска? Не делайте ничего до запуска, а всю инициализацию в самом приоритетном потоке.

Конструкторы глобальных/статических объектов вызываются до запуска оси. А для них желательно уже иметь инициализированной всю периферию. Так, имхо, идеологически правильнее (и гораздо удобнее, что даже важнее )

Да, проблема для простых OS создающих задачи статически. У меня периферии обычно много + PnP + диагностика... Посему система с динамически создаваемыми задачами поднимается постепенно ядро, idle, консолька с буфером, который в случае чего можно и принудительно разгрузить. Потом отдельная задача медленно и печально читает конфигурацию, продолжает инициализировать перефирию, создает нужные задачи и кончает жизнь самоубийством. В процессе работы тоже могут возникать задачи типа калибровок, заказной диагностики.... Может пора подумать о других системах?

Да на самом деле не так чтоб очень, можно просто флажок добавить и взводить его в OS::Run()
Просто думал, может есть более легитимное решение, без внесения добавлений в исходники оси.

Всё это решаемо, вместо динамически создаваемых задач - статическая задача (или несколько), вызывающая нужные функции - "подзадачи".

Мне плюсы нравятся. И scmRTOS пока вполне покрывает мои потребности. Чего нет - добавим. Да и компания душевная, а это немаловажно для меня

Гениально следующим шагом останется выбросить систему.

В рамках концепции не разгуляешся.

Напрасный сарказм. Делегирование действий одной задачи другой (с иным приоритетом) - мощный паттерн проектирования, и на плюсах получается красиво и безопасно. Конечно, это полностью не покрывает функционала, достигаемого честным созданием и удалением объектов-задач, но позволяет достичь изрядной части целей, ради которых обычно затевается вся эта кухня. Кроме того, делегирование действий позволяет эффективно бороться с проблемами, для решения которых применяется инверсия приоритетов (в mutex'ах).


В определенном смысле да. Но смена концепции - другая цена. Т.ч. везде компромиссы.


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

Читаем первоисточник вызвавший "сарказм":


О чем и речь .

Вопрос в оценке (можете считать субъективной )предлагаемого scmRTOS уровня компромиссов.

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

Действительно! Тоже об этом не подумал. Стереотипы мышления давят.