ContextSwitcher_ISR выполняется с запретом вложенных прерываний (что логично).
Не понимаю такой момент: может ли нарушить работу системы прерывание не используещие сервисы Оси(если разрешить прерывания в ContextSwitcher_ISR), при том что гарантированно не будет прерываний используюший Ос (например записью 0 в TIMSK, ETIMSK - прерываний немного).
Вопрос возник потому что величина времи с полным запретом прерываний очень велика, теряются данные.
Спасибо.

Ну хорошо, давайте навскидку придумайте больше семи независимых процессов в микроконтроллерной программе

У меня другой подход, я предпочитаю обрабатывать однообразные сокеты/порты в одном потоке (WSACreateEvent/WSAWaitForMultipleEvents для сокетов, WaitCommEvent + OVERLAPPED + оконные сообщения для портов). Просто с давних пор привык считать, что лишние потоки - это весьма накладно. Хотя при нынешних компьютерах это наверное уже не так.

На днях попробую придумать программку на десяток потоков, если получится выложу мысли - посмеёмся.
P.S. Независимых == не взаимодействующих между собой?
Или достаточно так?



При нынешних контроллерах скоро не накладно будет (или уже не накладно?).

Я имел в виду такие процессы, которые не могут быть обслужены одним потоком выполнения поочерёдно. То есть, например, ждущие различных прерываний.
(Хотя и в этом случае зачастую можно утоптать их в один поток, например, ставя из прерываний некие сообщения в очередь)

Да, переключение контекста в scmRTOS на кортексе 100 МГц всяко побыстрее, чем под win95 на 486DX4-100. Но памяти пока всё же поменьше

Понятно.



Он же cortex-m3. Или разница между M3 и M4 для scmRtos не существенна?

Я не занимался ещё ими, но там вроде только плавучка добавляется? Если так, то, имхо, да, пойдёт.

А если прерывание использует сервис ОС-сигналит флаг, но вложенные прерывания запрещены и срочной обработки(немедленного вызова шедулера) не требуется - можно также не использовать в нем обертку OS::TISRW?

Т.е., просто откладываем реакцию на этот флаг до того, как пройдет следующее перепланирование из-за соответствующего вызова из какого-то потока либо из-за другого прерывания, имеющего TISRW ?

Похоже, можно.
Всякие signal_isr() ничего такого по цепочке вызовов не делают, что могло бы в неправильное состояние потроха ОС поставить.

Можно. Передача управления произойдёт при одном из следующих вызовов планировщика (в зависимости от приоритета).

Спасибо. У меня и работало в железе в таком варианте, но лучше быть уверенным,что сам себе бомбу не подкладываешь...

З.Ы. И что-бы два раза не вставать - исправьте,пожалуйста, очепятку в руководстве по scmRTOS version 4 в описании доступных операций с семафором OS::TMutex на стр.87 TMutex::unlock_usr() на TMutex::unlock_isr().

С уважением.

Хоть бы букву выделил, а то я целую минуту искал отличия ))

У вас, очевидно, не самая свежая ревизия документа. Посмотрел, этой опечатки там нет. Смутно припоминаю, что несколько месяцев назад уже указывали на это приватно, было исправлено. Но всё равно спасибо!