[ReAl 0]

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

Ой!

Что-то мне начинает казаться, что для AVR (порт MEGA, на XMEGA я так толком и не смотрел) как раз в переключении прерыванием могут быть неприятности, там ситуация зеркальная.

 

Тут reti не влияет на бит глобального разрешения EA, но приоритеты обслуживаются аппаратно и очищаются reti

 

Там вход в прерывание выключает, а reti включает прерывания. Но при синхронном переключении (те же .wait() или там .push()) в недрах вызова ОС могла быть критическая секция и восстановить надо бы состояние запрещённых прерываний, как выше писано. Что-то я сейчас уже сонный, а с понедельника не до того. Забил гвоздик в scmRTOS-блокнотике tomboy, но вот не забыть бы туда заглянуть.

 

[a9d 0]

А где спрятан SystemTimer_ISR ??? При программном прерывании должен срабатывать он, нигде нет примера как он должен выглядеть.

 

Все понял. Это неправильный дефайн в порте avr

Изменено 12 ноября, 2012 пользователем a9d

[ReAl 0]

Все понял. Это неправильный дефайн в порте avr

Какой именно и где?

 

[a9d 0]

порт AVR

scmRTOS_TARGET_CFG.h

 

namespace OS
{
#if scmRTOS_CONTEXT_SWITCH_SCHEME == 0
    #pragma vector=SYSTEM_TIMER_VECTOR
    OS_INTERRUPT void OS_SystemTimer_ISR();
#else
    #pragma vector=SYSTEM_TIMER_VECTOR
    __interrupt void SystemTimer_ISR();
#endif // scmRTOS_CONTEXT_SWITCH_SCHEME
}

 

Если scmRTOS_CONTEXT_SWITCH_SCHEME =1 , то пользователю нужно в обязательном порядке писать обработчик системного таймера.

Изменено 14 ноября, 2012 пользователем a9d

[Артём__ 0]

Если scmRTOS_CONTEXT_SWITCH_SCHEME =1 , то пользователю нужно в обязательном порядке писать обработчик системного таймера.

Почему это?

 

Обработчик находится в OS_Target_cpp.cpp уже готовый. Может у вас версия не последняя?

[a9d 0]

Версия новая и там находится только OS_SystemTimer_ISR

[ReAl 0]

порт AVR

scmRTOS_TARGET_CFG.h

Ффухх, я уже за порт испугался.

Спасибо, подправлю как-нибудь те недочистки.

Только не «порт AVR», а «примеры к порту AVR/IAR».

В AVR/GCC вообще всё в порядке и в порту и в примерах, а в AVR/IAR порт в порядке, а в примерах недочищено.

 

Если scmRTOS_CONTEXT_SWITCH_SCHEME =1 , то пользователю нужно в обязательном порядке писать обработчик системного таймера.

Не нужно.

Посмотрите примеры 2 и 3, они в репозитории лежат с scmRTOS_CONTEXT_SWITCH_SCHEME 1 и они так прекрасно собираются. Сборка проверялась и с 0, и с 1, только для scmRTOS_CONTEXT_SWITCH_SCHEME 0 ещё нужно scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE 0

 

В OS_Target_cpp.cpp лежит самодостаточный обработчик, который подключается и работает при любых настройках scmRTOS, так как не охвачен никакими условиями.

//------------------------------------------------------------------------------
#pragma vector=SYSTEM_TIMER_VECTOR
OS_INTERRUPT void OS_SystemTimer_ISR()
{
    scmRTOS_ISRW_TYPE ISR;

#if scmRTOS_SYSTIMER_HOOK_ENABLE == 1
    system_timer_user_hook();
#endif

    Kernel.system_timer();

#if scmRTOS_SYSTIMER_NEST_INTS_ENABLE == 1
    ENABLE_NESTED_INTERRUPTS();
#endif

}

и те предварительные объявления на данный момент никому не нужны и никому не мешают.

Вот только что на всякий случай проверил -- в виртуалке стоит EWB 5.51, пересобрал все примеры.

[a9d 0]

Как подключить CLIB и DLIB к проекту одновременно? Без DLIB не собирается scmRTOS, без CLIB нет printf_P

 

все. Заменил на printf

Изменено 19 ноября, 2012 пользователем a9d

[a9d 0]

из документации

адрес указателя стека текущего процесса, куда будет помещен сам указатель по окончании сохранения контекста текущего процесса.

 

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

 

Передача с программным прерывание лучше, потому-что при входе в прерывание компилятор не сохранит/воcстановит локальный контекс ?

Изменено 23 ноября, 2012 пользователем a9d

[dezna 0]

всем добрый день!

подскажите пожалуйста можно ли принудительно вызвать деструктор TCritSect не дожидаясь конца блока, когда это сделает компилятор?

и если да, то как это организовать?

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

принудительно вызвать деструктор TCritSect не дожидаясь конца блока

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

 

[dezna 0]

Возможно стоит вынести кусок кода в отдельную функцию, по return будет вызван деструктор.

как начал, так и бросил! только граблей понавтыкаю.

я использую стм-овский драйвер SD карты. сейчас пробую руками запрещать/разрешать прерывания.

пока успеха не добился. возможно и придётся переписать их драйвер под ОС. :(

[IgorKossak 0]

Возможно стоит вынести кусок кода в отдельную функцию...

Или обрамить блоком нужный кусок и в начале этого блока объявить TCritSect cs.

[dezna 0]

Или обрамить блоком нужный кусок и в начале этого блока объявить TCritSect cs.

спасибо. как раз в тему.

[WHILE 0]

Господа, возник следующий вопрос - насколько падает производительность системы с РТОС по сравнению с суперлупом при прочих равных? Я понимаю, что что она должна упасть(этот момент хорошо расписано в руководстве по scmRTOS), но вот насколько?

Опишу свою ситуацию. С недавних пор решил перейти на работу с РТОС, т.к. надоело каждый раз организовывать "закат солнца в ручную". Как раз подвернулся один достаточно простой проект,хорошо подходяший для начального освоения работы с РТОС. Все достаточно быстро и без вопросов завелось(спасибо за примеры в комплекте оси) .

После этого решил перепилить на работу через РТОС старый проект на AVR+ ethernet (mac и физика на ENC28j60),компилятор IAR.И был очень удивлен удивлен увеличением времени отклика на ping c бывших 5-6ms

на суперлупе до 150ms на scmRTOS.

По моему в 20 с лишним раз замедление работы это перебор. Проект перепиливал без больших переделок.

Я понимаю.что скорее всего баг у меня, только вот в какую сторону рыть?

 

С уважением.