ContextSwitcher_ISR (MegaAVR) Опции

[_Артём_]

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

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

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

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

[_Артём_]

Нет, не нарушит. Для такого прерывания 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 кГц (самая скоростная задача, остальное всё медленнее и соответственно проблем не вижу (пока не вижу?). Такая ситуёвина.