caxapa.ru :: 1) Софтверные прерывания есть не везде 2) Не все CPU умеют делать вложенные прерывания 3) Не везде возможно задать приоритеты прерываний 4) передача сигналов в софтверное прерывание мало отличается от передачи сигнала в main 5) никакой выгоды не

=AlexD= (29.10.2014 13:48, просмотров: 67) ответил lightelf на Почему бы вместо флага "событие" не задействовать софтверно-генерируемое прерывание?

1) Софтверные прерывания есть не везде 2) Не все CPU умеют делать вложенные прерывания 3) Не везде возможно задать приоритеты прерываний 4) передача сигналов в софтверное прерывание мало отличается от передачи сигнала в main 5) никакой выгоды не даёт Софтверное прерывание идеально для шедулера OS , поэтому большинство использует его именно в этом качестве.

надо придумать объяснение этому мудизму, иначе рехнуться можно

Ответить

- Несогласный я lightelf(784 знак., 29.10.2014 17:37)
  - С таким подходом вы только сад граблей соберёте, а выигрыша будет 0. Проще тогда вообще всю обработку делать в аппаратных прерываниях, если они не могут прервать фоновые задачи. =AlexD=(486 знак., 30.10.2014 12:28)
  - AVR не умеет вложенные прерывание, да и многие другие. - Apтём(29.10.2014 18:45)
    - Это еще почему? При входе в обработчик разрешаете прерывания и вуаля. - lightelf(29.10.2014 19:56)
      - Такими их сделали. Аппаратной поддержки вложенности нет, программно - сколько угодно. - Apтём(30.10.2014 12:47)
      - А потом ипаццо с рекурсивными вызовами прерываний. Ну нафиг такую радость. - =AlexD=(30.10.2014 12:20)
        
        Особой проблемы с рекурсивными вызовами нет - достаточно на входе запретить вызов текущего обработчика, а на выходе разрешить. Делается элементарно. - Apтём(30.10.2014 12:49)
        
        Давай конкретизируем согласно теме ветки. В софтверном прерывании придётся разрашать все остальные прерывания, а софтверное запрещать. Вручную. И что мы выигрываем? Чем это лучше спокойного main со слипом в конце цикла и автоматически клацающими =AlexD=(31 знак., 30.10.2014 13:04)
        
        Придётся запрещать, да (это если про АВР, для других МК запрет может и не понадобится). То что в ручную, это ничего, мелочи. Лучше спокойного main тем, что реакция может быть очень быстрой. - Apтём(30.10.2014 13:15)
        
        Ну не знаю, я уже и так и этак показываю, что реакция будет медленнее, и всё не в коня корм. - =AlexD=(30.10.2014 13:26)
        
        Стоп. Мы о разном говорим. Есть big loop, из которого вызывается куча задач. Каждая задача при входе проверяет флаг, надо ли что-то делать. Если эту задачу повесить на обработчик софтверно-инициируемого прерывания, то ей не придется ждать, пока lightelf(24 знак., 30.10.2014 19:10)
        
        Т.е. весь сыр-бор ради одной единственной задачи из множества? Что это за задача такая, почему её нужно обрабатывать вне очереди, и при этом выносить из прерывания, которое её инициирует? - =AlexD=(31.10.2014 07:50)
        
        Задач может быть и несколько. Выполнение может быть длинным, возникать не на каждое прерывание, но требовать немедленной обработки. Например принимаются данные с АЦП, если значение превысило некий порог, то немедленно запускаем длинную процедуру lightelf(142 знак., 31.10.2014 13:24)
        
        Я правильно понимаю, что на время калибровки АЦП биглуп и его задачи просто умирают? - =AlexD=(31.10.2014 14:49)
        
        Да. А вот прерывания (в том числе следующие отсчеты АЦП) продолжают отрабатываться. В вытесняющей многозадачке можно было бы запулить поток с максимальным приоритетом, но вот в биглупе не все так однозначно. - lightelf(31.10.2014 16:22)
        
        В биглупе можно просто запретить все остальные задачи и оставить только калибровку, причём запрещать можно не только лишь все, а выборочно, самые маловажные, да ещё и следить, скажем, за буферами, что-бы они не переполнились. Проблема =AlexD=(33 знак., 31.10.2014 16:39)
        
        Можно, отчего же нельзя? Можно вообще прерывания не использовать и прямо из биглупа периферию опрашивать. Вольному воля. - lightelf(31.10.2014 18:51)
        
        Когда до main дойдёт - вообще непресказуемо. С помощью софтовых прерываний можно сделать систему в которой нужные прерывания будут всегда готовы к исполнению. И переключить на задачу rtos всяко быстрее чем до main дойдёт. - Apтём(30.10.2014 13:46)
        
        Бред какой-то. Как это вы добьётесь "постоянную готовность нужных прерываний"? Что вообще означает эта фраза? И при чём здесь RTOS ? Про ртос всё понятно, но даже там в прерывании только шедулер. А до main дойдёт сразу после обработки =AlexD=(362 знак., 30.10.2014 13:52)
        
        флаги Вам в руки - lexxx-lexxx(30.10.2014 12:44)
        
        keep it simple, stupid - =AlexD=(30.10.2014 12:46)

Средства и методы разработки