Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Портирование scmRTOS на Xtensa. Вопрос о переключнении процессов
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > scmRTOS
dsp4us
Мы благополучно спортировали scmRTOS на Xtensa процессор и эта штука худо бедно работает. Сейчас мы усиленно занимаемся тестированием. Вот входе этого тестирования возникла ситуация которую не совсем понятно как решить. Переключение процессов осуществляется по программному прерыванию - естественно в критической секции где мы запоминаем маску разрешенных прерываний и отключаем их, в новом процесс - востанавливаем маску их стека этого нового процесса и т.д. Все замечательно. Но что происходит когда в контексте какого либо процесса какое либо прерывание глобально маскируется или наоборот разрешается - в этом случае в контексте другого процесса об этом никто не знает и все сбрасывается в первоначальное состояние?! Тоесть олучается при нашей реализации мы можем изменять прерывания только в контексте процессов а не глобально. Что не есть хорошо. Кто то может меня просвятить на зту тему - как в принцыпе в scmRTOS можно управлять прерываниями глобально и возможно ли это в других портах на других процессорах?

И еще небольшое замечание/просьба для тех кто поддерживает веб сайт scmRTOS - сайт на английском но когда кликаешь на линк документации вываливает описание на русском языке. Английская версия там тоже есть но нужно изголяться и шарить ручками. Я думаю это займет всго лишь 5 минут добавить/исправить линк в тексте - все мои коллеги кому я давал ссылки на эту ОС по русски не говорят. Спасибо.
solosh
Сохраняется признак глобального состояния прерываний (разрешены/запрещены или текущий приоритет если есть таковой) плюс состояние флагов CPU. Маски отдельных прерываний не сохраняютя, т.е. если один процесс изменит, то увидят все.
Black Pahan
Автор данной ОСи в отпуске до 25.08 (ориентировочно). Он появляется в этом форуме под ником dxp. Так что ждите. Ответит и посоветует в полной мере и по-русски.
Сайт поправят.
sergeeff
Если уж очень хочется запоминать маску прерываний, то кто мешает ее запомнить в какой-нибудь глобальной переменной. Вот она и будет доступна для всех процессов. Какое это отношение имеет к сохранению/восстановлению контекста процесса? На мой взгляд - никакого. Контекст - это совокупность регистров процессора.
dsp4us
<Black Pahan> - Спасибо за инфу, подождем ...

<solosh> - Вы правы "Сохраняется признак глобального состояния прерываний (разрешены/запрещены или текущий приоритет если есть таковой) плюс состояние флагов CPU.". Но дело то в том что "признак" я называю его маской прерываний запоминается в критической секции в стеке "старого/уходящего" процесса а новый признак востанавливается из стека "нового/приходящего" процесса. То есть все изменения сделанные в этой маске прерываний становяться не видными как только мы переключили процессы.

<sergeeff> - тут вопрос не в том что я хочу чего то - Критическая секция и сделана с этой целью чтобы отменить все прерывания и сохранить всю информацию о тех которые были разрешены до этого что бы можно было востановить их состояния. Критическая секция выполнена как объект в конструкторе которого все это "сохранение" и происходит а в деструкторе востанавливается. Но при переключении процесса деструктор то выполняется в контексте другого процесса. тоесть StatusReg будет другой! Вот в чем загвоздка!

Код
//-----------------------------------------------------------------------------
//
//     The Critital Section Wrapper
//
//
class TCritSect
{
public:
    TCritSect () : StatusReg(_xtos_ints_off(0xFFFFFFFF)) { }
    ~TCritSect() { _xtos_ints_on(StatusReg); }

private:
    TStatusReg StatusReg;
};


Удачи всем.
solosh
Цитата(dsp4us @ Aug 15 2008, 06:40) *
<solosh> - Вы правы "Сохраняется признак глобального состояния прерываний (разрешены/запрещены или текущий приоритет если есть таковой) плюс состояние флагов CPU.". Но дело то в том что "признак" я называю его маской прерываний запоминается в критической секции в стеке "старого/уходящего" процесса а новый признак востанавливается из стека "нового/приходящего" процесса. То есть все изменения сделанные в этой маске прерываний становяться не видными как только мы переключили процессы.


Есть ли другой способ запретить все прерывания на вашем процессоре кроме как через маски ? Бит в регистре, например, или приоритет. И покажите еще код _xtos_ints_off/_xtos_ints_on, а то непонятно что в StatusReg у вас сохраняется.
dxp
Цитата(dsp4us @ Aug 14 2008, 12:51) *
Переключение процессов осуществляется по программному прерыванию - естественно в критической секции где мы запоминаем маску разрешенных прерываний и отключаем их, в новом процесс - востанавливаем маску их стека этого нового процесса и т.д. Все замечательно. Но что происходит когда в контексте какого либо процесса какое либо прерывание глобально маскируется или наоборот разрешается - в этом случае в контексте другого процесса об этом никто не знает и все сбрасывается в первоначальное состояние?! Тоесть олучается при нашей реализации мы можем изменять прерывания только в контексте процессов а не глобально. Что не есть хорошо. Кто то может меня просвятить на зту тему - как в принцыпе в scmRTOS можно управлять прерываниями глобально и возможно ли это в других портах на других процессорах?

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

Цитата(dsp4us @ Aug 14 2008, 12:51) *
И еще небольшое замечание/просьба для тех кто поддерживает веб сайт scmRTOS - сайт на английском но когда кликаешь на линк документации вываливает описание на русском языке. Английская версия там тоже есть но нужно изголяться и шарить ручками. Я думаю это займет всго лишь 5 минут добавить/исправить линк в тексте - все мои коллеги кому я давал ссылки на эту ОС по русски не говорят.

Поправлено.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.