scmRTOS холостой ход и системный таймер Опции

[Acvarif]

"Продолжаем разговор" как говорил Карлсон.
Запустил ОСь на mega128a в WinAvr (в скрепке проект - сделан на базе http://real.kiev.ua/scmrtos/1-eventflag/)

В железе холостой ход явно просматривается, а прерываний системного таймера нет. Все, что зависит от него (это proc1, proc2 ..) естественнго не работает.
Поскольку нет отладчика то понять в чем дело сложно.

В IAR (v5501) ОСь не работает совсем (проект приложен в скрепке). В проекте сделана визуализация холостого хода и переполнения системного таймера (чего уж может быть проще). Поскольку в железе не видать не только системного таймера, но и холостого хода то получается, что зацикливание происходит в OS::Run(); Подсобите please разобраться ...

Спасибо.

Сообщение отредактировал Acvarif - Jul 4 2011, 12:25

Прикрепленные файлы

 WinAvrPrj.rar ( 117.63 килобайт ) Кол-во скачиваний: 11
 TestScmRtosV310.rar ( 136.2 килобайт ) Кол-во скачиваний: 27

 

[Acvarif]

ОСь таки запустилась. Проблема была таки в компиляторе. Он не умеет правильно отличать mega128a от 128, хотя они ничем не отличаются кроме некоторых электрических характеристик (пример slon 1-EventFlag для mega128a, в настройках компилятора IAR AVR 5501,5511 нужно ставить mega128 в скрепке ).

Просмотрев в железе прерывания системного таймера стало чуть грустно.
Прерывания системного таймера (период 1,2 ms) явно нестабильны, хотя вроде ничего на прерывания T0 не должно влиять.
Тоесть использовать системные тики для каких-либо более менее точных отсчетов нельзя.
Но посмотрев на взаимодействие между вторым и третьим процессом особой нестабильности не заметил. ОСь начинает нравиться.

Код

template<> void TProc2::Exec()
{
    for(;;)
    {
      ef.Wait();
      PORTC |= (1 << 3);

    }
}
//---------------------------------------------------------------------------
template<> void TProc3::Exec()
{
    for(;;)
    {

       Sleep(20);
       ef.Signal();
      PORTC &= ~(1 << 3);
    }
}

Так до сих пор и не понял зачем в примере нужен аналоговый компаратор?

Код

    ACSR |= (1 << ACBG) | (1 << ACIE); /* Ref ON, IE ON */  
    DDRB |= (1 << 4);                  /* AIN1*/

Если закоментировать этот код ничего не изменится.
В документацци сказано о переключении контекстов. Дергание ногой должно вызывать прерывания по компаратору и соответственно переключение контекстов.
Но где это дергание происходит? И какая все же разница между контекстом и процессом? Я так понимаю, что процесс это все вместе взятое - нить со своими переменными, регистрами стеком.

Прикрепленные файлы

 scmrtos_avr_iar_snapshot.rar ( 301.64 килобайт ) Кол-во скачиваний: 9

 

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

Так до сих пор и не понял зачем в примере нужен аналоговый компаратор?

Посмотрите внимательно в scmRTOS_config.h чему равно scmRTOS_CONTEXT_SWITCH_SCHEME. Если 0, то компаратор не нужен. Если 1, то таки да, его прерывание переключает контекст.

Но где это дергание происходит?

Смотрите OS_Kernel.h, там есть строки

CODE

void OS::TKernel::SchedISR()
{
    TPriority NextPrty = GetHighPriority(ReadyProcessMap);
    if(NextPrty != CurProcPriority)
    {
        SchedProcPriority    = NextPrty;
        RaiseContextSwitch();
    }
}

Вот RaiseContextSwitch() и есть дерганье ногой. Ищите его определение в OS_Target.h

Я так понимаю, что процесс это все вместе взятое - нить со своими переменными, регистрами стеком.

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

[Acvarif]

Спасибо. Стало немного светлее.

Посмотрите внимательно в scmRTOS_config.h чему равно scmRTOS_CONTEXT_SWITCH_SCHEME. Если 0, то компаратор не нужен. Если 1, то таки да, его прерывание переключает контекст.

Код

#define  scmRTOS_CONTEXT_SWITCH_SCHEME      1

Получается, что если scmRTOS_CONTEXT_SWITCH_SCHEME = 1
то функция RaiseContextSwitch() просто разрешает глобальные прерывания

Код

#if scmRTOS_CONTEXT_SWITCH_SCHEME == 1

    INLINE inline void RaiseContextSwitch() { SPM_CONTROL_REG |= (1 << SPMIE);  } // enable SPM interrupt
    INLINE inline void BlockContextSwitch() { SPM_CONTROL_REG &= ~(1 << SPMIE); } // disable SPM interrupt

Кто или что тогда всетаки переключает процессы? Или с какой частотой переключаются процессы? Кто ее формирует?
Я так понимаю, что переключатель контекста и есть переключатель процессов? Может глупость сморозил...

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

Получается, что если scmRTOS_CONTEXT_SWITCH_SCHEME = 1
то функция RaiseContextSwitch() просто разрешает глобальные прерывания

Вы, похоже, взяли исходник из другого примера или же настройка компаратора - рудимент от предыдущей версии.

CODE

#if scmRTOS_CONTEXT_SWITCH_SCHEME == 1

    INLINE inline void RaiseContextSwitch() { SPM_CONTROL_REG |= (1 << SPMIE);  } // enable SPM interrupt
    INLINE inline void BlockContextSwitch() { SPM_CONTROL_REG &= ~(1 << SPMIE); } // disable SPM interrupt

Тут разрешаются не глобальные прерывания, а прерывание по окончанию записи во флешь. Этот такой трюк - флаг этого прерывания при нормальной работе всегда взведен, и разрешение этого прерывания (естетсвенно, при разрешенных глобальных прерываниях) вызовет переход на его обработчик. А уже в обработчике произойдет, собственно, переключение контекстов. Следствием которого является переключение текущего процесса. Если же переключение контекстов потребовалось во время обработки какого-либо прерывания, то глобально прерывания в этот момент запрещены и будут разрешены по команде RETI. В этот-то момент и вызовется обработчик.

Кто или что тогда всетаки переключает процессы? Или с какой частотой переключаются процессы? Кто ее формирует?

Это вытесняющая ОСь. Здесь переключение происходит в тот момент, когда процесс отдает управление в ожидании какого-либо сервиса либо уходя в спячку либо если произошло событие (вызов сервиса из прерывания или текушего процесса), требующее пробуждения более приоритетного процесса.

[ReAl]

Вы, похоже, взяли исходник из другого примера или же настройка компаратора - рудимент от предыдущей версии.

В AVR/IAR 3.10 -- рудимент после замены на прерывание SPM_READY. Когда я это обнаружил, то уже думал, что вот-вот 4.00 выйдт и не стал править. А потом забыл.
В AVR/GCC 3.10 всё нормально и в примере 2, в котором компаратор оставлен для примера, инициализация компаратора охвачена
#if scmRTOS_CONTEXT_SWITCH_SCHEME == 1

В pre-400 поправлено и для AVR/IAR.

Acvarif, кстати, в pre-400 и в AVR/IAR пример 1-EventFlag приведён в почти полное соответствие с упомянутой в первом сообщении статьёй. "Почти", так как в порте в репозитории в переключатель контекста в OS_Target_asm, естественно, не вставлено махание ножкой осциллографу.

Код

#define  scmRTOS_CONTEXT_SWITCH_SCHEME      1

У меня все работает одинаково (во всяком случае внешне) при 0 и при 1

Потому что в примерах реализованы оба способа.

Получается,что в случае когда scmRTOS_CONTEXT_SWITCH_SCHEME = 1 - выбрана передача управления на основе программного прерывания. Поскольку все при этом работает, не пойму какого прерывания?

Задаётся в scmRTOS_TARGET_CFG.h, например,

Код

#define CONTEXT_SWITCH_ISR_VECTOR  SPM_READY_vect

или

Код

#define CONTEXT_SWITCH_ISR_VECTOR  ANA_COMP_vect

Это дело передаётся в OS_Target_asm.S (.s90 для IAR), где и используется для организации входа в обработчик прерывания.

[Acvarif]

Спасибо.

Значит в примере от IAR 310 пропущено только дрыгание ногой по прерываниям компаратора при scmRTOS_CONTEXT_SWITCH_SCHEME 1?
Или я опять недопонял...

Для уточнения
если

Код

#define  scmRTOS_CONTEXT_SWITCH_SCHEME      0

переключение контекстов происходит по прерыванию записи во флешь (он - вектор прерывания все время взведен)
если

Код

#define  scmRTOS_CONTEXT_SWITCH_SCHEME      1

по прерываниям от аналогового компаратора
В последнем случае немного непонятно. Получается, что прерывания по аналоговому компаратору тоже должны быть все время взведены?
Вобщем и целом тогда особой разницы в scmRTOS_CONTEXT_SWITCH_SCHEME нет?

Посмотрел pre 400, там код под IAR очень похож на WinAvr:

Код

//---------------------------------------------------------------------------
//  "Hello, scope!" pins in pin_macros.h notation.
#define TIMER1_ISR      D,5,H
#define TIMER1_TO_PROC1 B,0,H
#define PROC1           B,1,H
#define PROC2           B,2,H
#define PROC3           B,3,H
#define TIMER_HOOK      B,4,H
#define IDLE_HOOK       B,5,H


//---------------------------------------------------------------------------
//
//      Process types
//

// demonstrate process switching from Proc2 to Proc3 in sleep() or ef.signal() call
#if PROC2_HIGHER_THAN_PROC3
# define PROC2_PRIO OS::pr1
# define PROC3_PRIO OS::pr2
#else
# define PROC2_PRIO OS::pr2
# define PROC3_PRIO OS::pr1
#endif


typedef OS::process<OS::pr0, 120, 32> TProc1;
typedef OS::process<PROC2_PRIO, 160, 32> TProc2;
typedef OS::process<PROC3_PRIO, 120, 32> TProc3;

template<> void TProc1::exec();
template<> void TProc2::exec();
template<> void TProc3::exec();

//---------------------------------------------------------------------------
//
//      Process objects
//
TProc1 Proc1;
TProc2 Proc2;
TProc3 Proc3;

//---------------------------------------------------------------------------
tick_count_t tick_count;    // global variable for OS::GetTickCount testing

OS::TEventFlag Timer1_Ovf;  // set in TIMER1_COMPA_vect(), waited in Proc1
OS::TEventFlag ef;          // set in Proc3, waited in Proc2

//---------------------------------------------------------------------------
int main()
{
    TCCR1B = (1 << WGM12) | (1 << CS10);    // CTC mode, clk/1
    OCR1A  = 40000U;
    TIMSK = (1 << OCIE1A); // Timer1 OC interrupt enable

    // Start System Timer
    TCCR0  = (1 << CS01) | (1 << CS00); // clk/64
    TIMSK |= (1 << TOIE0);

    DRIVER(TIMER1_ISR,OUT);
    DRIVER(TIMER_HOOK,OUT);
    DRIVER(IDLE_HOOK,OUT);
    //
    OS::run();
}

Правда компилится без проблем
Я так понял, что там для идентичности с gcc добавлены функции типа DRIVER(TIMER1_ISR,OUT);
и др.

Сообщение отредактировал Acvarif - Jul 7 2011, 07:38

[ReAl]

Значит в примере от IAR 310 пропущено только дрыгание ногой по прерываниям компаратора при scmRTOS_CONTEXT_SWITCH_SCHEME 1?

Нет. В IAR310 вариант "1" переведен с аналогового компаратора на готовность записи во флеш, но из main недовычищено то, что касалось компаратора.

если

Код

#define  scmRTOS_CONTEXT_SWITCH_SCHEME      0

переключение контекстов происходит по прерыванию записи во флешь (он - вектор прерывания все время взведен)
если

Код

#define  scmRTOS_CONTEXT_SWITCH_SCHEME      1

по прерываниям от аналогового компаратора
В последнем случае немного непонятно. Получается, что прерывания по аналоговому компаратору тоже должны быть все время взведены?
Вобщем и целом тогда особой разницы в scmRTOS_CONTEXT_SWITCH_SCHEME нет?

В случае "0" переключение производится прямым вызовом os_context_switcher.
В случае "1" переключение производится обработчиком специального прерывания, которое возбуждается при помощи raise_context_switch. Какое именно прерывание будет задействовано (а хоть и от свободного канала output compare) -- зависит от настроек проекта в scmRTOS_TARGET_CFG.h
В AVR/IAR-овских примерах было всё на компараторе, потом всё перевелось на запись во флеш. В AVR/GCC-шніх во втором примере оставлен компаратор, в остальных -- флеш. Сравните файлы scmRTOS_TARGET_CFG.h от первого и второго примера AVR/GCC (не важно, 310 или pre-400).
Для компаратора raise делается дёрганьем ноги, а само прерывание всегда разрешено. Для вектора записи во флеш запрос всегда взведён, а raise делается разрешением.

Посмотрел pre 400, там код под IAR очень похож на WinAvr:
...
Я так понял, что там для идентичности с gcc добавлены функции типа DRIVER(TIMER1_ISR,OUT); и др.

"Волковские" макросы из pin_macros.h добавлены для простоты обеспечения идентичности.
Просто скопирован кусок из AVR/GCC-шных примеров для полного соответствия поведения, чтобы можно было пользоваться статьёй-описанием для обеих компиляторов.
Если (когда ) доберусь до CM3-шного примера, то тогда перепишу под тамошний pin.h