НЕМЕДЛЕННО, прямо аж большими буквами - не получится, сколько-то там тактов уйдёт всегда :-) А зачем ждать прерывание планировщика? (+) («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

НЕМЕДЛЕННО, прямо аж большими буквами - не получится, сколько-то там тактов уйдёт всегда :-) А зачем ждать прерывание планировщика? (+)

Отправлено ReAl 08 октября 2007 г. 20:37
В ответ на: Получится, еще как получится. Если сразу из прерывания джампануть в переключатель контекста, не дожидаясь очередного прерывания планировщика. Будет немедленно. отправлено SM 08 октября 2007 г. 20:16

Что преривание "осевого" таймера, что всякие set_event(), wikeup() и прочее - пусть вызывают перепланировщик. Тогда никакого другого прерывания ждать не надо.
А напрямую прыгать - это же ещё и с вложенными прерываниями некрасиво может оказаться.
В scmRTOS перепланировщик вызывается при выходе из любого "по-осевому" оформленного прерывания, если счётчик вложенности прерываний становится нулевым.

Составить ответ | Вернуться на конференцию

Ответы

Ответ: А если нужно ещё быстрей(минуя "перепланировщик")? Т.е. допустим в прерывании имеем Event для запуска потока с наивысшим приоритетом — иниипет (08.10.2007 20:52:22 217.118.66.7, пустое)