Здравствуйте! Вопрос, наверое, к авторам в первую очередь.
Можно ли в scmRTOS организовать перезапуск процесса (повторный вход в Exec со сбросом стека в начальное состояние), е еще лучше - подмену процесса другим, пусть даже с тем же размером стека и приоритетом. Обьясню зачем - устройство может работать в различных режимах и в каждом из них нужен свой набор примерно похожих, но отличающихся процессов. Одновременно держать их в памяти слишком накладно из-за стеков. Приходится на один процесс вешать разную функциональность в разных режимах. При этом каждый раз при смене режима выпутываться из вложенных циклов в кажом процессе, чтобы выйти на верхний уровень. Вот если бы была возможность просто плюнуть на текущий процесс, зная что он мне уже не нужен, и запустить вместо него другой, пусть с тем же стеком и приоритетом... или, на худой конец, просто быстро выскочить в начальное состояние процеса и пустить его по другой ветке... Понимаю, что в принципе должно быть возможно, но мешает не блестящее знание плюсов и раскиданнность самой ОС по нескольким файлам + дефицит времени для принятия решения. Тупой вызов Exec для процесса перезапускает его, но только один раз. дальше система начинает чудить. Очевидно, надо чистить стек, но как- пока не пойму. Буду признателен за помощь.

Посто нужно воспользоваться более сложными системами. Оптимальной в этом отношении представляется FreeRTOS. Динамическое выделение памяти под контекст задачи позволяет порождать, убивать, заменять задачи, создавать наборы задач в зависимости от конкретной конфигурации... Передача параметров при создании задачи штатно тоже предусмотрнна. scmRTOS уж слишком во многих случаях минималистична и не всегда сособна быть "доработана" ввиду изначально заложеной концепции.

Беда в том, что контроллер - MSP430 с их традиционно микроскопической оперативкой. scmRTOS и была выбрана из-за ее минималистчности и самых низких требований к ОЗУ. В ней как раз есть все то, что мне иужно и ничего сверх этого для решения моей конкретной задачи. Еще бы позможность перезапуска процессов или их подмены...

Оффтоп, навеянный аватаром - давно ищу в сети сборник рисунков Бидструпа. Случайно не знаете, где его можно найти?

Почему бы не поступить так: для реализации разных по функциональности вариантов написать соответствующее количество функций и вызывать их из одного и того же процесса. Если функция уже не нужна, то делать return из нее и запускать другую, нужную.

Да, это резко меняет дело.

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

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

То-же самое. Только библиотека эта теперь далеко....

Дописать нечто, сбрасывающего контекст некоего процесса в состояние "как перед OS::Run()" не проблема (а там пусть проверяет глобальную переменную режима и вызывает нужную функцию).
Только этот процесс мог в данный момент чего-то ждать, т.е. его бит может сидеть в маске какого-то синхронизирующего объекта. Поскольку минимализм - эти объекты никак недоступны ядру, т.е. не сидят в каком-то списке всех (активных) объектов - нельзя пройтись по всем и сбросить бит данного процесса (уровня приоритета).
Если вдруг активируется event, которого ждал данный процесс в прошлой жизни, то процессу взведётся готовность к выполнению. А он в это время уже может ждать чего-то другого. Во что это выльется - надо внимательно смотреть исходники всех синхронизирующих объектов.
А ещё он в прошлой жизни мог lock-нуть какой-то ресурс, а в новой не помнить, что он это сделал - кто разлочит?
Если бы все объекты сидели в общем списке (помещали туда себя в своём конструкторе либо в "активирующих" функциях) - можно было бы при "перезапуске" процесса пройтись и убрать все ожидания и освободить все ресурсы, но это усложнение, оправданность которого подлежит обсуждению.


Аналогично... Но скоро на недельку собираюсь поближе :-)
отмазка - времени на сканирование того же сотворения мира не будет :-)

2 ReAl
Да уж... Собственно, когда я начинал тему, думал, что данные процессов (статическая часть, естественно) находятся в ROM, и больше думал, как обойти это ограничение. Сегодня полез в отладчик, обнаружил, что они в RАМ и радостно полез все править. Потихоньку дошел и до высказанных Вами соображений. Ну у меня в любом случае выбора нет, придется все-таки идти этим путем, но включение этой возможности в ОС мне лично кажется весьма полезным.