Прерывание от TC, ищу совета в организации обработки Опции

[sailor]

Имеем: AT91SAM7(X256 - но это уже не важно). Опыт работы с ним пока небольшой.
Используем таймер-счетчик. Нужно считать частоту. Т.е. работаем в режиме захвата. Используем прерывание. При этом при прохождении импульсов от 1 до N-1 в обработчике прерываний производим только фильтрацию, а по приходу N-го импульса, необходимо выполнить гораздо большую обработку: фильтрация + собственно вычисление частоты + расчет управляющего(их) воздействия(ий). Причем последняя часть довольно весома. И так по кругу.
Так вот вопрос связан с тем, как это все сорганизовать, что б задача расчета в обработчике прерывания не мешала работе самого ТС (подсчет интерчала следующего цикла) и в тго же время, что б решение не было б "тяжелым" по ресурсоемкости.
Есть конечно варинт с выставлением флага в обработчике при приходе N-го импульса, с проверкой данного флага в фоновой задаче и выполнением расчетов в фоновой задаче. Но, IMHO, не очень красиво.
Может кто-то подскажет что-то более оптимальное и красивое?
Не знаю, возможен ли вариант, когда в обработчике прерывания TC генерится программное прерывание, сам обработчик ТС при этом завершает работу, а расчет производится в обработчике программногго прерывания?
С уважением.

[_dem]

Не знаю, возможен ли вариант

- возможен. Выставьте программному прерыванию более низкий приоритет

А чем вам не нравится вариант с флагом ?

ps - TC должен не генерить прерывание, а разрешать уже сгенеренное и активное

Сообщение отредактировал _dem - Dec 19 2007, 10:28

[sailor]

[quote name='_dem' date='Dec 19 2007, 13:27' post='340318']
- возможен. Выставьте программному прерыванию более низкий приоритет
[/quote]
Усек.
[quote name='_dem' date='Dec 19 2007, 13:27' post='340318']
А чем вам не нравится вариант с флагом ?
[/quote]
Задача описана упрощенно. Там еще куча чего будет напихано. И в т.ч. будут и прерывания (в т.ч. и от USART-а, от других ТС etc.). Они будут "отодвигать" фоновую задачу на неопределенные интервалы. Т.е. интервал между измерением и вычислением воздействия будет "плавающим", возможно с большим разбросом, что для данного типа задач не есть хорошо. С прерыванием (соответствующего приоритета), как мне кажется, данный интервал будет боле-мене стабилен.
Впрочем, это может только мои домыслы
[/quote]
[quote name='_dem' date='Dec 19 2007, 13:27' post='340318']
ps - TC должен не генерить прерывание, а разрешать уже сгенеренное и активное
[/quote]
Чутка поподробней можно? К своему стыду с программными прерываниями на девайсе еще не работал. Все с аппаратными. Можно просто тыкнуть пальцем в пример. коий надо посмотреть. Так собственно все и осваивал: примеры + даташит.

Блин, не силен я в ХТМЛовских тегах Приношу извинения.

Сообщение отредактировал sailor - Dec 19 2007, 10:40

[_dem]

Операционка будет ?

[aaarrr]

Не знаю, возможен ли вариант, когда в обработчике прерывания TC генерится программное прерывание, сам обработчик ТС при этом завершает работу, а расчет производится в обработчике программногго прерывания?

SWI начнет выполняться немедленно; отложить выполнение, задать приоритет или запретить его нельзя.
ИМХО, вариант с флагом наиболее правильный.

UPD: Или речь шла о софтварном прерывании при помощи AIC? Тогда можно, но все равно как-то криво, по-моему.

[sailor]

Операционка будет ?

А зачем козе баян? Точнее, зачем регулятору частоты вращения операционка?
Нет.

[Сергей Борщ]

Задача описана упрощенно. Там еще куча чего будет напихано.
Т.е. интервал между измерением и вычислением воздействия будет "плавающим", возможно с большим разбросом, что для данного типа задач не есть хорошо.

Так и просится операционка.

[spf]

А зачем козе баян? Точнее, зачем регулятору частоты вращения операционка?

Тогда бы не возникало подобных вопросов, там все для этого как раз уже есть.

Нет.

Вот тогда и изобретайте ее некое подобие...

[sailor]

Вот тогда и изобретайте ее некое подобие...

Для одного такого маленького частного случая (я бы даже сказал случайка) подобие операционки???
Нормальный подход
Повторяюсь: операционки не будет. Мне вполне хватит PIT-а с одной задачей, фоновой задачи и обработчиков прерываний. Просьба о совете касалась (и касается) исключительно описанной проблемки, а еще точнее вариантов "красивого" ее решения.
Я очень сильно извиняюсь, но решение таких задач (имеется ввиду весь регулятор) с использованием операционки, IMHO, очень громоздкое и посему чрезвычайно "некрасивое" решение.

[_dem]

Или речь шла о софтварном прерывании при помощи AIC

Именно это я и имел в виду - обработка вешается на прерывание с более низким приоритетом.

но решение таких задач (имеется ввиду весь регулятор) с использованием операционки, IMHO, очень громоздкое и посему чрезвычайно "некрасивое" решение

Как раз очень удобное и предсказуемое по таймингам решение Но, хозяин - барин.

Так почему же не использовать флаг ? Если нет операционки, то вам в любом случае надо подобие семафора. Можно вывернутся через AIC, но ... вешайте свою обработку на аппаратное прерывание-от-чего-угодно, например PIO или USART, далее либо вызывайте прерывание (дрыгнув ножкой), либо разрешайте его (например, сделайте один раз дрыг а потом разрешайте обработку).

После выхода из PIT AIC вызовет второй обработчик, в конце которого он отключит сам себя, _не сбрасывая_ активный уровень прерывания. Причем во время работы обработчика прерывание PITC будет работать, т.к. у него более высокий приоритет.

Это выход, но как-то некрасиво

И в т.ч. будут и прерывания (в т.ч. и от USART-а, от других ТС etc.). Они будут "отодвигать" фоновую задачу на неопределенные интервалы. Т.е. интервал между измерением и вычислением воздействия будет "плавающим", возможно с большим разбросом, что для данного типа задач не есть хорошо. С прерыванием (соответствующего приоритета), как мне кажется, данный интервал будет боле-мене стабилен.

Тут я чего-то не понимаю. Если у вас получается так, что из-за "USART-а, от других ТС" может не хватить времени на основную задачу, то "что-то неладно в датском королевстве". Такая проблема решается блокировкой "лишних" прерываний на время выполнения критичного кода.

[sailor]

Такая проблема решается блокировкой "лишних" прерываний на время выполнения критичного кода.

А це уже дило. Чей-то мне в голову и не пришло *бьется покрасневшим от стыда фэйсом об тэйбл*
Спасибо, хорошая подсказка.

[_dem]

будь ласка, звертайтесь