MicroCHIP.RU
Главная Документация Отладочные средства Справочник Поиск Ссылки
 Новости   Конференция   Контакты 
 

вложенные прерывания

 Нoвaя темa  |  Наверх  |  Перейти к теме  |  Поиск  |  Правила  |  Вход 

ВНИМАНИЕ!
Вы просматриваете архив форума.

Этот форум работает только в режиме просмотра и поиска.

Действующий форум переведен на новый движок и
находится по адресу www.microchip.su

 вложенные прерывания
Автор: Vova ()
Дата:   14/11/2003 12:40

кто-нибудь где-нибудь встречал пример реализации вложенных прерываний для mid-range'а ? сижу вот,
велосипед изобретаю ...


 
 Re: вложенные прерывания
Автор: Andrey ()
Дата:   14/11/2003 13:04

Примера нет а соображения как-то были...
Тоже велосипед изобретал.
Собственно в чем проблемма то? В прерывании просто сбрасываешь флаг этого
прерывания и снова включаешь GIE,если что-то очень важное нельзя потерять/пропустить.
И если оно случится то процесс пойдет так-же как если бы ты был просто в основной программе.
Т.е.надо позаботится о раздельном сохранении контекста
И видимо больше 1 вложенного лучше не делать,а лучше вообще так не делать,организуй задачу
по другому еще в корне,меньше будет гемору.


 
 Может обойдешься?(+)
Автор: abivan ()
Дата:   14/11/2003 13:05

Задачку опиши. Лучше подумать как без этого обойтись. Уж очень не кузяво это.


 
 Re: вложенные прерывания
Автор: Zemfir ()
Дата:   14/11/2003 13:28

а чаго сымитировать нельзя?

ну типа в прерывании после каждых скольких нибудь строк ставишь
проверку на нужное прерывание.


 
 хочу чтоб круто ;)
Автор: Vova ()
Дата:   14/11/2003 13:30

abivan писал(а):
> Задачку опиши. Лучше подумать как без этого обойтись.

до этого как раз и обходился, но все равно давно было желание

> Уж очень не кузяво это.

понятное дело, что через жуткое место, но все ж

на счет задачи - ничего конкретного, что-то вдруг загорелось и захотелось сделать
для себя (а может и для всех ;) что-то вроде шаблончика, чтоб вслучАе чего
применить быстренько.


Andrey писал(а):

> Собственно в чем проблемма то? В прерывании просто сбрасываешь
> флаг этого прерывания и снова включаешь GIE

просто так нельзя. надо что-то вроде менеджера задач делать.

> Т.е.надо позаботится о раздельном сохранении контекста
> И видимо больше 1 вложенного лучше не делать

стандартная процедура входа в прерывание.
потом копирование сохраненных регистров (хотя бы W и STATUS, ну и FSR, наверно) в
другое.
потом определение источника прерываний - для перехода на нужную ф-цию.
потом определение, не выполняется ли уже эта нужная ф-ция (флаг она должна
выставлять).
если выполняется, то еще не придумал какбы поскоренькому сделать либо сбрасывать
флаг прерывания и запоминать что оно было - для того, чтобы ф-ция обработчик по
своему окончанию еще раз обработала чтоль, либо еще как-то.
если не выполняется - переходим на нужную ф-цию. она сбросит флаг прерывания (или
менеджер задач его сбросит) и разрешит глобальные прерывания.
когда она отработает, то ... а вот потом-то ... хм ...

запретит глобальные и вернется в менеджер задач.
тот восстановит решистры и выйдет совсем уж из обработки прерывания.

из-за того, что могут возникнуть много прерываний - у менеджера должен быть стек,
для сохранения регистров (то самое копирование в другое место)

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

чего-то путаться уже начинаю.
вот и хотел поглядеть, может есть у кого пример реализации, чтоб посмотреть, да
развить или упростить идею.



Отправка отредактированного (14/11/2003 13:34)


 
 Re: вложенные прерывания
Автор: Vova ()
Дата:   14/11/2003 13:39

Zemfir писал(а):

> а чаго сымитировать нельзя?
> ну типа в прерывании после каждых скольких
нибудь строк ставишь
> проверку на нужное прерывание.

А вот с дуру в прерывании сделаю
использование float или еще какую математику (иногда ну очень хочется туда все вставить - многое
упрощается подчас), а оно длится скажем пару миллисекунд и библиотечные это процедуры и просто так
туда ничего не вставишь ... надо их переписывать и вообще ...


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

иногда ну
тааак хочется ;)


 
 Re: вложенные прерывания
Автор: Zemfir ()
Дата:   14/11/2003 13:43

ну тогда имхо, надо юзать пик18;)

задачу вложеных прерываний однажды решал на пик16 именно
описанным мной способом. Прерывание было длинное для задачи, а мне надо было с какой-либо погрешностью
погасит нужный столбец, и я проверял внутри прерывания флаг от таймера через примерно каждые 10 мкс,
чем не имитация:).


 
 Re: вложенные прерывания
Автор: Zemfir ()
Дата:   14/11/2003 13:52

Кстати, сейчас подумал про предложенный Андреем вариант с одним вложением.
Все получается!

В
начале прерывания стоит что-то типа

btfsc int_flag ;прерывание уже обрабатывается?
goto
int_vlogennoe

а дальше уже идет обычная обработка.

btfsc&goto STATUS не трогают.


 
 Re: вложенные прерывания
Автор: Andrey ()
Дата:   14/11/2003 14:01

Менеджер там получается из 2 битиков чтоб от входа пойти по нужной дорожке
2 набора регистров для сохранения
и несложная логика(для 1 вложения) включения/выключения GIE и флагов разрешений
...а 18 это уже другой разговор
иногда актуально именно для 16 или даже 12


 
 Re: вложенные прерывания
Автор: Zemfir ()
Дата:   14/11/2003 14:03

ну а я что написал?


 
 хм
Автор: Vova ()
Дата:   14/11/2003 14:10

> btfsc int_flag ;прерывание уже обрабатывается?
> goto int_vlogennoe

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

наверно, в частных случаях такое прокатит ...

или туплю опять.
давай
дальше развей.
еще до сохранения статуса и рабочих регистров перешли на одну из двух веток.
в этих
ветках сохраняемся (само собой в разных местах).
а что потом-то ?
определили источник прерывания и
если уже не запущен обработчик (в прошлом прерывании, например) - запускаем, а если запущен, что тогда
?


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

не хочу, чтоб прерывание, которое выполняется долго, возникло вторым и,
соответсвенно, затормозило все нафиг.


нее. надо хитрый и умный менеджер
придумывать.


abivan, а может мне надобно про RTOS какуюнить почитать ? ;)


 
 вы лучше мне растолкуйте ;) (-)
Автор: Vova ()
Дата:   14/11/2003 14:11

вы лучше мне растолкуйте ;) (-)


 
 Re: вложенные прерывания
Автор: Andrey ()
Дата:   14/11/2003 14:12

Ну да почти тоже...

> а дальше уже идет обычная обработка
Вот здесь уже не совсем обычная,надо как-то не забывать откуда мы попали сюда
и куда попадем в конце-концов
(во бл. прям философски звучит)
т.е.поиграть битиками надо не как обычно
я только про это... :))

И ещё дополню
Приоритет в простейшем случае устанавливается руками и топором уже внутри какого-то прерывания.
А вот более формально как сделать(и заранее)можно тоже подумать


 
 Re: хм
Автор: Zemfir ()
Дата:   14/11/2003 14:19

Vova писал(а):

> вложенное долго
> выполняется, то ...
>
> наверно, в частных случаях такое прокатит ...

дык, микроконтроллеры и работают с частными случаями. Попытки делать универсальные подпрограммы п
олучаются очень дорогими.

> если уже не запущен обработчик (в прошлом прерывании, например)
> - запускаем, а если запущен, что тогда?

тогда выходим и флажок ставим, что есть задача.

Но это опять попытка решить частную проблему общими средствами. Это рассчитано как раз на случай,
когда одно прерывание может быть, например, 100 мкс. А вложенное 10 мкс. Т.е. решение конкретной
задачи.

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

Ага, именно так. Т.е. такого быть не должно. Но если такое возможно, то можно создать что-то типа
стека прерывания. Но всё равно, это же микроконтроллер, с его крошечными ресурсами, получить унив
ерсальное решение не получится, всегда надо на чём-либо остановиться. Наверняка, всегда можно убр
ать возможность возникновения двух длинных прерываний с временным наложением.

> нее. надо хитрый и умный менеджер
> придумывать.
> abivan, а может мне надобно про RTOS какуюнить почитать ? ;)

во во, или это надо решать системными средствами:)



Отправка отредактированного (14/11/2003 14:21)


 
 Re: вы лучше мне растолкуйте ;) (-)
Автор: Andrey ()
Дата:   14/11/2003 14:21

Vova писал(а):

> определили источник прерывания и
> если уже не запущен обработчик (в прошлом прерывании, например) - запускаем, а если запущен,
> что тогда
Вот он сишный подход...
А почему обработчик а не обработчики,т.е. на каждую задачу свой и действия совершенно разные
могут быть.Ну и запускай их поочереди(по приоритету).

> не хочу, чтоб прерывание, которое выполняется долго, возникло вторым и,
> соответсвенно, затормозило все нафиг.
Эх кабы всё происходило только по нашим желаниям,вот жизня бы была!!!
Все равно возникнет,а чтоб не тормозило вот и разреши внутри его ещё одно прерывание.
если кому приспичит...но потом чтоб снова возвращалось в тот медленный

Ой пардон,написал-то наоборот всё.
Т.е. долгое прерывание будет просто с низким приоритетом и будет ждать ещё 10-100-...мкс
А вот внутри его (10мс) разрешай быстрое...
> вы лучше мне растолкуйте ;)
:))



Отправка отредактированного (14/11/2003 14:53)


 
 Re: вложенные прерывания
Автор: Zemfir ()
Дата:   14/11/2003 15:07

а вот мне интересно уже давно, как на назком уровне работают РТОС для пиков?

ну в двух
словах?

изначально я думал, что там подменяется каким-либо способом вызов подпрограмм при выходе
из прерывания, потом начал думать, что есть псевдомногозадачность, аля вин3.1 т.е. в каждой задаче
вызываются какие-либо подпрограммы типа idle_func, потом ещё много думал предполагал и т.п. в
результате я вообще перестал понимать как это работает. хотя на уровне несколько более высоком все
логично.

в двух словах можно сказать или это долго объяснять и мне лучше посмотреть
микрочиповский пример создания многозадачности?


 
 Re: вложенные прерывания
Автор: Zemfir ()
Дата:   14/11/2003 15:23

гм, мда, писал вопрос дольше:)
все понятно, спасибо.


 
 ты у меня спрашиваешь ?
Автор: Vova ()
Дата:   14/11/2003 15:23

а я еще не читал %-)

для 16-ого семейства можно сделать только кооперативную ртос.

а в двух
словах, как я представляю, одна задача поработала, вызвала ф-цию системную - переключение задач,
менеджер вызывает следующую. т.е. поработал сам - дай другим.

Иван опять куда-то делся - вот он все
растолкует ;)


 
 Re: ты у меня спрашиваешь ?
Автор: Andrey ()
Дата:   14/11/2003 15:28

А я считал что там всё завязывается на прерывание таймера- тики по 0.5...10мс
По каждому тику вызывается менеджер он быстренько разбирается чья очередь или важность
и запускает поработать нужный кусок до следующего тика.
Интересно угадал я или опять чего-то не понял?

Ива-а-а-н АУ!!!


 
 Re: ты у меня спрашиваешь ?
Автор: Zemfir ()
Дата:   14/11/2003 15:30

Vova писал(а):

ага, это на системном уровне, меня интересовала скорее работа на физическом
уровне. В общем у микрочипа в примере периодически вызывается функция

retlw $+1

а в начале
задчачи стоит

movwf PC,F

т.е. задача что-то поделала и возвратила ссылку на следующую
команду, а диспетчер уже подумал и запустил дургую задачу. А возможно в прерывании где-либо на таймере
уже производится контроль приоритета задачи, выделяемого времени и т.п..
Но это конечно
пример.

:)
сенка!Ё


 
 Re: ты у меня спрашиваешь ?
Автор: Zemfir ()
Дата:   14/11/2003 15:32

Андрей писал(а):

> А я считал что там всё завязывается на прерывание таймера- тики
> по
0.5...10мс
> По каждому тику вызывается менеджер он быстренько разбирается
> чья очередь или
важность


дык, и как ты из прерывания модифицируешь PC в стеке, стек же аппаратный и не
доступный:)


 
 все непросто (философ %-)
Автор: Vova ()
Дата:   14/11/2003 15:40

Andrey писал(а):

> Vova писал(а):
>> определили источник прерывания и
>> если уже не запущен
обработчик (в прошлом прерывании,
> например) - запускаем, а если запущен,
> > что тогда

> Вот он
сишный подход...


Ээээ, я бы попросил ... ;)


> А почему обработчик а не обработчики,т.е. на
каждую задачу свой

я понимаю, но если для прерывания от TMR1 уже запущен обработчик, запускать его
второй раз (пока он не отработал) черевато - типа нереентерабелен.

я ж понимаю, что для каждого
источника - свой обработчик, ну, ты прям обижаешь ;)



нее, ребята, вопросов много все равно и не
так просто получается.


 
 тех. пример
Автор: Vova ()
Дата:   14/11/2003 15:43


вот пример как вызывать чтонить и запомнить откуда был вызов
на
picc

http://www.microchip.ru/phorum/read.php?f=2&i=10365&t=10060#reply_10365


 
 Re: ты у меня спрашиваешь ?
Автор: Andrey ()
Дата:   14/11/2003 15:43

Zemfir писал(а):

> дык, и как ты из прерывания модифицируешь PC в стеке, стек же
> аппаратный и не доступный:)

...ещё не придумал
А это я по мотивам MSC51 говорил,там я примерно так и делал
лет 6 назад,может это RTOS у меня был(?),вот и интересно...


 
 не угадал
Автор: Vova ()
Дата:   14/11/2003 15:44

на pic16 такое технически не реализуемо, потому как стек переходов аппаратный и программно никак не
доступен и если возниклов прерывание (как ты говоришь), то никакими способами не узнать откуда
конкретно (до адреса, а не ф-ции) оно возникло. можно сделать только return туда.


 
 лирика все это
Автор: Vova ()
Дата:   14/11/2003 15:45

значит нет ни у кого конкретных примеров ?


 
 Re: все непросто (философ %-)
Автор: Andrey ()
Дата:   14/11/2003 15:52

Vova писал(а):

> Ээээ, я бы попросил ... ;)
Ладно-ладно молчу-молчу ,а то по ....получу и подвиг свой не совершу...

> я понимаю, но если для прерывания от TMR1 уже запущен
> обработчик, запускать его
> второй раз (пока он не отработал) черевато - типа
> нереентерабелен.
Я вроде упоминал что обработчик (TMR1)запрещает свое прерывание,если уж надо разрешать
общее и например для TMR2...Ну и битики менеджера направят процесс как надо...

> нее, ребята, вопросов много все равно и не
> так просто получается.
Но получается же...для 2 прерываний например

> значит нет ни у кого конкретных примеров ?
Нет ребята,пулемёта я вам не дам...нету у меня.



Отправка отредактированного (14/11/2003 15:54)


 
 все непросто
Автор: Vova ()
Дата:   14/11/2003 15:57

Andrey писал(а):
> Я вроде упоминал что обработчик (TMR1)запрещает свое
> прерывание,если уж
надо разрешать общее и например для TMR2
> Ну и битики менеджера направят процесс как надо...

в
общем (именно в общем) понимаю, только надо еще не забыть, если пришло вдруг прерывания скажем от TMR1,
а оно еще обрабатывается, то запомнить что приходило и как только закончится обработка - опять вызвать
обработчик.

> Нет ребята,пулемёта я вам не дам...нету у меня.

за державу обидно.

если
рожу чтонить - выкладу на обозрение.


 
 Re: Для PIC16 - нельзя
Автор: NickB ()
Дата:   14/11/2003 16:16

Для PIC18 -можно

Попробуйте придумать как сохранить контекст


 
 Re: Для PIC16 - нельзя
Автор: Andrey ()
Дата:   14/11/2003 16:20

NickB писал(а):

> Для PIC16 - нельзя
> Для PIC18 -можно
>
> Попробуйте придумать как сохранить контекст

...сказал как отрезал!!! 8-)))


 
 Я думаю самое время(+)
Автор: abivan ()
Дата:   14/11/2003 16:29

Это тебя займет на некоторое время :-) да и пользы будет поболе, чем изобретать вложенные
прерывания. Да и не решит это всех проблем
Пример:
Была у меня задачка подсчета интервала и одновременного ответа по усарт. Так вот я разрешал в
один момент только одно прерывание, а второе просто проверялось внутри когда срабатывало
незамаскированное. Это гарантировало мне точный временной интервал. Вложенные прерывания здесь
бы не прокатили. Потому как времена жесткие и нет разночтений.
В общем может и не совсем про это но все же. Я что хотел сказать, что универсальное решение все
равно останется не универсальным. Да и потом не трать время. Завтра может ты вообще на 16
семействе работать не будешь. 18 на пятки наступает.
И будет 18 для простых задач, а DSPic - для посложнее.
И вообще поменьше времени на конкретику свойственную конкретному процу. Результаты все равно
потеряют свою актуальность. Побольше времени общим задачам.

Да и этот универсальный подход пожрет кучу времени на сохранение восстановление. И это будет
уже не прерывание.

А float в прерывание это неправильно. Лучше все же на ртос взоры обратить.


Про RTOS
языком владеешь? :-) тогда SALVO читай. Там живой английский. Трудновато мне давался.
А сначала вообще можно и про jacos почитать.

Ну пока все, если не отговорил тогда еще спроси чего-нибудь ;-)


 
 Re: тех. пример
Автор: Zemfir ()
Дата:   14/11/2003 16:39

Vova писал(а):

> http://www.microchip.ru/phorum/read.php?f=2&i=10365&t=10060#reply_10365
ага, это что-то типа как в примере реализации от микрочипа.

CBLOCK
ContextA ; PC for task A
ContextB ; PC for task B
EndC
Initialize
 movlw TASKA
 movwf CONTEXTA
 movlw TASKB
 movwf CONTEXTB
 goto RTOS
RTOS
;add code here to synchronize with the real time if desired
 movf CONTEXTA,W ; fetch A?s PC
 call CALLTASK ; invoke task A
 movwf CONTEXTA ; save context
 movf CONTEXTB,W
 call CALLTASK
 movwf CONTEXTB
 goto RTOS

 CALLTASK movwf PC,F
 macro RELINQUISH
 retlw $ + 1 ; return PC of next instruction
 EndM

TASKA ; initialize task A stuff
 RELINQUISH
LOOPA ; task A does some processing
 RELINQUISH
; etcetra
 RELINQUISH
 goto LOOPA
TASKB ; similar to above



 
 все-то ты знаешь ;)
Автор: Vova ()
Дата:   14/11/2003 17:16

abivan писал(а):
> Да и этот универсальный подход пожрет кучу времени на
> сохранение
восстановление. И это будет уже не прерывание.

это я чувствую и меня это смущает ;)

> Ну пока
все, если не отговорил тогда еще спроси чего-нибудь ;-)

Еще обспрашиваюсь - будь спокоен ;)

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

спасибо.


 
 Re: вложенные прерывания
Автор: moris ()
Дата:   15/11/2003 16:14

Если нет проблемы - нужно ее придумать. Появится dsPIC - будет куда и что вкладывать. Работай
как Мелкочип советует и не парься.
moris




 
 piclist: nested interrupts
Автор: Vova ()
Дата:   19/07/2004 16:29

http://www.piclist.com/techref/microchip/sstack.htm