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

Нет, не нарушит. Для такого прерывания ContextSwitcher_ISR ничем не отличается от фоновой задачи в "обычной" системе. И раз "обычные" системы работают...

Только запретить прерывание системного таймера может быть мало — другие «осевые» прерывания могут возникать. Разрешить прерывания — и они полезут.
Или в конкретном приложении переключения процессов возникают только от таймера, асинхронно от периферии не возникают?

На мой взгляд, если переключение контекста (менее двухсот тактов процессора для AVR) — это слишком долго, то нужно что-то менять. Или более быстрый процессор, или невытесняющая ОС со всем «быстрым» в прерываниях.

Понятно.
Тогда можно в дополнении к разрешению прерываний в ContextSwitcher_ISR убрать TCritSect из OS_ContextSwitchHook(правда там не очень долгий код).


Если плохо запретить, то полузут и всё посыпется, это ясно.



Только от таймера.
От периферии не возникают (если и будут, то - вне ОСи).


Менять нужно, согласен. Но сложно.


АВР быстее не может.
ARM ещё не освоен, то есть быстро не поменяешь.

Не нашёл пока подходящего варианта.

Продолжаем разговор?
Имеет ли смысл такой код?

Использовать предполагаю, в прерываниях не вызываюших сервисы ОС:

Или эти действия излишни, и лучше использовать TISRW_SS?
В TISRW_SS не нравится следующий код:

Зачем вызывать Kernel.SchedISR(), если в прерывании CurProcPriority изменится не может?

Если прерывание не использует сервисов ОС, то обертку OS::TISRW или подобную заводить в нем не нужно и TISR_StackSwitcher как-бы не нужен совсем.

Тогда я что-то не понимаю.



TISRW_SS как я понял делает след. действия:
1) переключение стека, если не переключено.
2) востановление стека процесса, если Kernel.ISR_NestCount=1
3) запуск планировщика
Переключение стека делается для экономии стека процессов. Или нет?

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

Цитаты лучше приводить из актуальной на данный момент доки (v4). Там тоже на эту тему есть слова (п 3.2.7.2), особенно текст предупреждения и и после него. Краткий вывод - не надо на процах, где нет аппаратной поддержки стека прерываний, это делать. Куда лучше организовывать код так, чтобы прерывания были быстрыми и "лёгкими" (если проблема с памятью под стеки процессов).

Пока до v4 не добрался, застрял на v3.


То есть практика показала, что переключать - выходит себе дороже?
Но тем не менее TISRW_SS из v4 никуда не делся и не изменился (на первый взгляд).



Буду думать...



Есть ли проблема... это для меня большой вопрос, т.к. до недавнего времени ни какие Оси не использовал, то оценить мне трудно.
А что есть: АВР с 128/256 кБ flash + до 16кБ ram, на чём нужно написать сбор данных с АЦП с частотой 10-20 кГц (самая скоростная задача, остальное всё медленнее и соответственно проблем не вижу (пока не вижу?). Такая ситуёвина.

Это напрасно. v4 сейчас уже практически стабильна, содержит несколько полезных улучшений и важных исправлений. Тем более, если вы только начинаете работу с scmRTOS, то у вас нет старых проектов на третьей версии, и, следовательно, нет совсем никаких резонов её использовать.

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

Оставили для совместимости. Ну или для крайних случаев, когда надо впихнуть невпихуемое

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

Да надо переходить, хотя фраза "практически стабильна" настораживает.
Ну да ладно, авось пронесёт.


Ясно, буду пробовать без переключателей.


Если на процесс выделить байт по 100-200-300, и таких процессов десяток/другой.
Вагон , не вагон, а тележка совсем не маленькая остаётся.
Только блокировку прерываний аккуратно убрать остаётся.

Хм..интересно, если TISRW_SS убрать то что мешает её на xmeg-е запустить? Надо попробовать.
Update: хорошая мысля приходит опосля. Мешает PMIC - Programmable Multi-level Interrupt Controller - без переделки не запустится. И пробовать не стоит.

A в scmRTOS v4 количество процессов по прежнему 32? Не маловато будет? Или увеличение количества просто приведёт к недопустимому увеличению времени переключения (или т.п. негативнем эффектам)? В uCOS вроде 54 процесса, что где-то логично - объёмы памяти выросли в разы за последние несколько лет.


Offtop. А для STM32F40x в v4 порта нет?

Я неправильно выразился. Имелось в виду - фактически является текущей стабильной версией.

Не представляю, зачем нужно столько процессов. По процессу на каждый из десятка датчиков? А смысл? Сделайте один процесс на все датчики, и опрашивайте их поочерёдно. Это выйдет и быстрее (нет накладных расходов на переключение задач), и менее затратно по памяти (нет расходов на контекст кучи процессов).

Нет. Но по идее должен пойти порт от STM32F1xx.

Я так и думал...


А сколько бывало нужно?



Нет смысла. Если датчики одинаковы, то один процесс на все безусловно.
Попробую прикинуть сколько нужно процессов, может насчёт того что 31 мало я ошибаюсь (не использовал ОС раньше - не отчего оттолкнуться).


Ясно.
p.s. Чот я не одного порта под ARM-Keil не вижу, компилятор у них что ли не той системы? Вроде продукт качественный, лучше IAR. Странно.

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

Дык, напишите, вот и будет порт

Семь. Хм...может программа простая...


У меня как-то наоборот: если сокет какой слушает порт или com-порт (к примеру), то поток, если таких сокетов/портов несколько, то каждый в своём потоке и в итоге потоков с десяток легко набегает. А программы не бог весть какие сложные...


Весь мой опыт работы а Keil-ARM:
Установил.
Подключил, не заработало.
Поставил драйвера, заработало.
Зашил программу моргания светодиодом, походил немного в отладчике.
Выключил.
Всё.

Так что мне до порта, как до Луны (даже готовый зашить - и то дистанция не маленькая).

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

У меня другой подход, я предпочитаю обрабатывать однообразные сокеты/порты в одном потоке (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().

С уважением.

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

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