Понял, спасибо.
Получается есть всё-таки несколько вариантов: загнать все ОСевые прерывания на один уровень (как сейчас по сути в тех же АВР), использовать для ОСи два или три уровня с ContextSwitcher настроенным на низший уровень.

Глянул в репозитории в папку /trunk/Ports/AVR/IAR, увидел

Какой в этом смысл на АВР? У него же Interrupt conrtoller не nested.
И как тогда может выглядеть TCritSect при scmRTOS_USER_DEFINED_CRITSECT_ENABLE=1?

«пусть и безобразно, зато единообразно»
Оно-то (пользовательские крит. секции) проходит транзитом от scmRTOS_TARGET_CFG.h к OS_Target.h и не используется в потрохах собсвтенно ОС (кроме проверки и значения по умолчанию в scmRTOS_defs.h), но всё равно проще иметь это однотипным во всех портах.

(там где-то на горизонте болтается xmega, у нее три уровня приоритетов, брать за основу этот порт тоже будет проще, когда все заготовки на месте)

Для MegaAVR ещё добавить надо что-то такое в OS_Target_asm.s90:


Будет ли после такого изменения работать - вопрос. И при каких условиях, если будет.


Да у хмеги отличий не много видимо.
Прикидывал как может быть сделано на xmega:



В OS_Target_asm.s90:

Но так наверное однобразия не выйдет.

Не желаете продолжить абортированную дискуссию? Меня по-прежнему очень интересует вопрос - как практически написать на С++ так, чтобы один из методов статического класса вызывался по прерыванию, и адрес точки входа в эту ISR был бы помещен компилятором+линкером в .intvect ? Если нетрудно, то конкретный листинг для STM32 Cortex.

Aprox
Создайте отдельную тему в разделе "Программирование" и там обсуждайте сколько влезет.
Встревать в чужую тему не этично.
Проявитесь подобным образом ещё раз - получите отпуск на месяц.
Модератор.

Возможность запуска задач с одинаковым приоритетом имеет смысл. На пример нужно принимать данные допустим с 4х портов, делать сложную тяжелую обработку для каждого канала и выводить результат на дисплей. На пример:
Есть 4 порта uart. Над каждым больпим блоком данных по каждому порту надо выполнять FFT и выводить на дисплей результат по каждому каналу отдельно. Все каналы асинхронные по отношению друг к другу.
Задача легко решается созданием 4х процессов с одинаковым приоритетом для каждого порта, которые принимают данные,обрабатывают и передают 5-му процессу, который это дело оформляет в виде картинки.
Если будут разные приоритеты - обрабатываться будет самый приоритетный канал при большой его загрузке, а остальные будут спать и рано или поздно их очереди переполнятся.
Тут какраз карусель хорошо идет либо возможность вытеснения друг другом процессов с одинаковым приоритетом.

Сама реализация очереди на базе двусвязных списков и карусели всего на несколько инструкций сложнее реализации на bitmap (при наличии инструкции а-ля clz, конечно), тут проблем нету.
Проблема в поиске самого приоритетного процесса в очереди мютекса и др. синхр.примитив. Иначе просыпаться будет не самый приоритетный процесс, а тот, который первый в очереди. Мне пока известно 3 реализации - либо просмотр всего списка(как в TNKernel), либо очередь в виде бинарного дерева - оба варианта тормознутые, каждый в своем случаи. Либо держать массив голов списков - очень быстро, зато каждый обьект ядра будет весить минимум по 33 слова для 32х уровней приоритета.

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

Окажите пожалуйста любезность, Вы не могли бы привести примеры применения функций terminate() и start() , а то в мануале самый минимум миниморум) - буквально пара слов. И мне как начинающему поклоннику scm )) не очень понятно как их применять. Спасибо.

На правах оффтопа к оффтопу, отпишу как я реализовал диспетчер в mkernel. У меня есть упорядоченный вектор с уникальными приоритетами. Каждый элемент вектора - это приоритет элемента и указатель на список активных процессов с этим приоритетом. Поиск - простой бинарный. Да, на вставление и удаление уникального элемента (сдвиг вектора) нужно время, но время это не столь критично. Зато нет никаких программных ограничений.

Сейчас переделываю диспетчер с вектора на красно-черные деревья. К концу октября должен управиться.

Естественно, речь о списке активных задач, а не ожидающих. Активных задач при грамотном проектировании крайне мало. К тому же, система у меня без тиков, поэтому не нужно дергать супервизора 100 раз в секунду (а в это время можно спать и экономить батарейку ). Ну и вдобавок, отзывчивость на тайм-ауты от 1 микросекунды, а не 1 тик.

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

А что не понятно? С чем возникли трудности? С запуском <process_name>.terminate() или с <process_name>.start()?

К сожалению при попытке вставить запись типа OS::process::terminate(); в функцию процесса вылазит ошибка типа - error: cannot call member function 'void OS::process<pr, stack_size>::terminate() [with OS::TPriority pr = (OS::TPriority)0u, unsigned int stack_size = 80u]' without object , к сожалению любого рода манипуляции с видом записи ни к какому результату не приводят (уже просто дошел до банального перебора всего что может быть и чего не может -( ) сообщения об ошибке только разные Может быть к этому какое-либо отношение имеет то что четверка под авр студией вообще собирается с варнингами типа - \scmRTOS\Common/OS_Services.h:261:18: warning: ignoring packed attribute because of unpacked non-POD field 'OS::TMutex& OS::TMutexLocker::Mutex' avr-g++ -mmcu=atmega8 -Wl,-Map=scm_event__4.map scm_event__4.o OS_Target_asm.o OS_Target_cpp.o OS_Kernel.o OS_Services.o usrlib.o -o scm_event__4.elf - имеются в виду проекты с пустыми процессами и с отключенными тиками и хуками, хотя вообще-то тестовые проекты со всеми средствами межпроцессного взаимодействия в том числе с мьютексами работали нормально. Со второй функцией, в принципе я понял что ее надо пихать в idle_process_user_hook(), результат к сожалению аналогичный.

А так :

не пробовали?
Так правильно кстати?
У вас scmRTOS_PROCESS_RESTART_ENABLE чему равен?

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