lightelf (29.10.2014 13:35, просмотров: 7025) CкpипaчНе надо делать мне как лучше, оставьте мне как хорошо
-
- 1) Софтверные прерывания есть не везде 2) Не все CPU умеют делать вложенные прерывания 3) Не везде возможно задать приоритеты прерываний 4) передача сигналов в софтверное прерывание мало отличается от передачи сигнала в main 5) никакой выгоды не =AlexD=(114 знак., 29.10.2014 13:48)
- Несогласный я 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=(31.10.2014 14:49)
- Задач может быть и несколько. Выполнение может быть длинным, возникать не на каждое прерывание, но требовать немедленной обработки. Например принимаются данные с АЦП, если значение превысило некий порог, то немедленно запускаем длинную процедуру lightelf(142 знак., 31.10.2014 13:24)
- Т.е. весь сыр-бор ради одной единственной задачи из множества? Что это за задача такая, почему её нужно обрабатывать вне очереди, и при этом выносить из прерывания, которое её инициирует? - =AlexD=(31.10.2014 07:50)
- Когда до main дойдёт - вообще непресказуемо. С помощью софтовых прерываний можно сделать систему в которой нужные прерывания будут всегда готовы к исполнению. И переключить на задачу rtos всяко быстрее чем до main дойдёт. - Apтём(30.10.2014 13:46)
- Стоп. Мы о разном говорим. Есть big loop, из которого вызывается куча задач. Каждая задача при входе проверяет флаг, надо ли что-то делать. Если эту задачу повесить на обработчик софтверно-инициируемого прерывания, то ей не придется ждать, пока lightelf(24 знак., 30.10.2014 19:10)
- Ну не знаю, я уже и так и этак показываю, что реакция будет медленнее, и всё не в коня корм. - =AlexD=(30.10.2014 13:26)
- Придётся запрещать, да (это если про АВР, для других МК запрет может и не понадобится). То что в ручную, это ничего, мелочи. Лучше спокойного main тем, что реакция может быть очень быстрой. - Apтём(30.10.2014 13:15)
- Давай конкретизируем согласно теме ветки. В софтверном прерывании придётся разрашать все остальные прерывания, а софтверное запрещать. Вручную. И что мы выигрываем? Чем это лучше спокойного main со слипом в конце цикла и автоматически клацающими =AlexD=(31 знак., 30.10.2014 13:04)
- флаги Вам в руки - lexxx-lexxx(30.10.2014 12:44)
- keep it simple, stupid - =AlexD=(30.10.2014 12:46)
- Особой проблемы с рекурсивными вызовами нет - достаточно на входе запретить вызов текущего обработчика, а на выходе разрешить. Делается элементарно. - Apтём(30.10.2014 12:49)
- Это еще почему? При входе в обработчик разрешаете прерывания и вуаля. - lightelf(29.10.2014 19:56)
- Несогласный я lightelf(784 знак., 29.10.2014 17:37)
- 1) Софтверные прерывания есть не везде 2) Не все CPU умеют делать вложенные прерывания 3) Не везде возможно задать приоритеты прерываний 4) передача сигналов в софтверное прерывание мало отличается от передачи сигнала в main 5) никакой выгоды не =AlexD=(114 знак., 29.10.2014 13:48)