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

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

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

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

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

Сообщение отредактировал a9d - Nov 12 2012, 03:38

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

порт AVR
scmRTOS_TARGET_CFG.h



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

Сообщение отредактировал a9d - Nov 14 2012, 13:47

Почему это?

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

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

Ффухх, я уже за порт испугался.
Спасибо, подправлю как-нибудь те недочистки.
Только не «порт AVR», а «примеры к порту AVR/IAR».
В AVR/GCC вообще всё в порядке и в порту и в примерах, а в AVR/IAR порт в порядке, а в примерах недочищено.

Не нужно.
Посмотрите примеры 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, так как не охвачен никакими условиями.
и те предварительные объявления на данный момент никому не нужны и никому не мешают.
Вот только что на всякий случай проверил -- в виртуалке стоит EWB 5.51, пересобрал все примеры.

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

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

Сообщение отредактировал a9d - Nov 19 2012, 00:09

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


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

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

Сообщение отредактировал a9d - Nov 23 2012, 15:57

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

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

как начал, так и бросил! только граблей понавтыкаю.
я использую стм-овский драйвер SD карты. сейчас пробую руками запрещать/разрешать прерывания.
пока успеха не добился. возможно и придётся переписать их драйвер под ОС.

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

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

Господа, возник следующий вопрос - насколько падает производительность системы с РТОС по сравнению с суперлупом при прочих равных? Я понимаю, что что она должна упасть(этот момент хорошо расписано в руководстве по scmRTOS), но вот насколько?
Опишу свою ситуацию. С недавних пор решил перейти на работу с РТОС, т.к. надоело каждый раз организовывать "закат солнца в ручную". Как раз подвернулся один достаточно простой проект,хорошо подходяший для начального освоения работы с РТОС. Все достаточно быстро и без вопросов завелось(спасибо за примеры в комплекте оси) .
После этого решил перепилить на работу через РТОС старый проект на AVR+ ethernet (mac и физика на ENC28j60),компилятор IAR.И был очень удивлен удивлен увеличением времени отклика на ping c бывших 5-6ms
на суперлупе до 150ms на scmRTOS.
По моему в 20 с лишним раз замедление работы это перебор. Проект перепиливал без больших переделок.
Я понимаю.что скорее всего баг у меня, только вот в какую сторону рыть?

С уважением.