ContextSwitcher_ISR (MegaAVR) Опции

[_Артём_]

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

[Сергей Борщ]

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

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

[ReAl]

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

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

[_Артём_]

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

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

Только запретить прерывание системного таймера может быть мало — другие «осевые» прерывания могут возникать. Разрешить прерывания — и они полезут.

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

Или в конкретном приложении переключения процессов возникают только от таймера, асинхронно от периферии не возникают?

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

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

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

Или более быстрый процессор.

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

или невытесняющая ОС со всем «быстрым» в прерываниях.

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

[_Артём_]

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

Код

    class TISR_StackSwitcher {
    public:
        INLINE TISR_StackSwitcher() {
            ISR_Enter();
        }
        INLINE ~TISR_StackSwitcher() {
            ISR_Exit();
        }
    private:
        INLINE void ISR_Enter() {
            TCritSect cs;
            if(Kernel.ISR_NestCount++ == 0) {
                SavedSP.DataSP   = GetDataSP();
                SavedSP.ReturnSP = GetReturnSP();
                SetISRStackPointers();
            }
        }
        INLINE void ISR_Exit() {
            TCritSect cs;
            if (--Kernel.ISR_NestCount==0) {
                SetReturnSP(SavedSP.ReturnSP);
                SetDataSP  (SavedSP.DataSP);
            }
        }
    };

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

Код

#pragma vector=USARTE0_RXC_vect
__interrupt void ExtUartRx()
{
    OS::TISR_StackSwitcher ss;
    do {
        unsigned char i=USART_GetChar(&USARTE0);
        GsmRxPtr.WriteByte(i);
    } while (USART_IsRXComplete(&USARTE0));
}

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

Код

INLINE void ISR_Exit()
{
    TCritSect cs;
    if (--Kernel.ISR_NestCount==0) {
        SetReturnSP(SavedSP.ReturnSP);
        SetDataSP  (SavedSP.DataSP);
    }

    Kernel.SchedISR();
}

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

[Сергей Борщ]

Имеет ли смысл такой код?

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

[_Артём_]

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

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

Когда возникает прерывание, управление передается обработчику преры-
вания, который работает со стеком прерванного процесса. Это означает, что стек
процесса должен иметь размер, достаточный для работы как кода самого процес-
са, так и кода обработчиков прерываний. Причем дополнительные требования к
размеру стека определяются самым потребляющим обработчиком прерывания.
Более того, эти требования распространяются на все процессы, т.е. любой процесс
должен иметь размер стека с учетом возможности работы в этом стеке самого
«толстого» обработчика прерывания. В случае вложенных прерываний ситуация
еще более усугубляется.

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

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

[dxp]

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

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

[_Артём_]

Цитаты лучше приводить из актуальной на данный момент доки (v4).

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

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

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

Куда лучше организовывать код так, чтобы прерывания были быстрыми и "лёгкими" (если проблема с памятью под стеки процессов).

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

(если проблема с памятью под стеки процессов).

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

[AHTOXA]

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

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

То есть практика показала, что переключать - выходит себе дороже?

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

Но тем не менее 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 порта нет?

[AHTOXA]

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

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

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

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

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

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

[_Артём_]

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

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

Не представляю, зачем нужно столько процессов.

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

По процессу на каждый из десятка датчиков? А смысл?

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

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

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

[AHTOXA]

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

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

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

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

[_Артём_]

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

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

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

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

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

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

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