Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Хочется программно инициировать прерывание
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Страницы: 1, 2
Rst7
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?

Самый простой способ - использовать INT0, например, и сконфигурировать прерывание по изменению состояния ноги (нога на вывод), в результате - достаточно шевельнуть ножкой (изменив ее, скажем OUT'ом в PINx) и флаг прерывания установится; соответственно, когда будет разрешено прерывание INT0 - оно и произойдет. Но, к сожалению, INT0 и INT1 заняты, надо изобретать что-то другое.

Вот мысль появилась использовать прерывание от компаратора, причем следующим образом:

Компаратор штатно выключен (он не нужен в проекте), для установки флага прерывания от него использовать последовательность
Код
ACSR=(1<<ACD)|(1<<ACIS1)|(1<<ACIS0); //Comparator Interrupt on Rising Output Edge.
ACSR=(1<<ACD)|(1<<ACIS1); //Comparator Interrupt on Falling Output Edge.


Т.е. переключить туда-сюда "по фронту/по спаду". На идею натолкнула фраза
Цитата
When changing the ACIS1/ACIS0 bits, the Analog Comparator Interrupt must be disabled by clearing its Interrupt Enable bit in the ACSR Register. Otherwise an interrupt can occur when the bits are changed.

в даташите.

К сожалению, сейчас негде попробовать этот чит. Посему пара вопросов:

1. Может кто делал такое и уже знает результат?
2. Может у кого есть под рукой макеточка, проверить бы?
3. А может кто гламурнее способ знает?
prottoss
Цитата(Rst7 @ May 20 2008, 19:52) *
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?
в scmRTOS, по моему, что то подобное реализовано именно для программных прерываний.
VladimirYU
Цитата(Rst7 @ May 20 2008, 15:52) *
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?

Самый простой способ - использовать INT0, например, и сконфигурировать прерывание по изменению состояния ноги (нога на вывод), в результате - достаточно шевельнуть ножкой (изменив ее, скажем OUT'ом в PINx) и флаг прерывания установится; соответственно, когда будет разрешено прерывание INT0 - оно и произойдет. Но, к сожалению, INT0 и INT1 заняты, надо изобретать что-то другое.

Вот мысль появилась использовать прерывание от компаратора, причем следующим образом:

Компаратор штатно выключен (он не нужен в проекте), для установки флага прерывания от него использовать последовательность
Код
ACSR=(1<<ACD)|(1<<ACIS1)|(1<<ACIS0); //Comparator Interrupt on Rising Output Edge.
ACSR=(1<<ACD)|(1<<ACIS1); //Comparator Interrupt on Falling Output Edge.


Т.е. переключить туда-сюда "по фронту/по спаду". На идею натолкнула фраза

в даташите.

К сожалению, сейчас негде попробовать этот чит. Посему пара вопросов:

1. Может кто делал такое и уже знает результат?
2. Может у кого есть под рукой макеточка, проверить бы?
3. А может кто гламурнее способ знает?


А почему хочется именно пограммное прерывание, почему нелзя обычный вызов обработчика.
prottoss
Цитата(Rst7 @ May 20 2008, 19:52) *
,Вот мысль появилась использовать прерывание от компаратора
Как раз от компаратора в scmRTOS и используют, но вроде как внешне что то к выводу компаратора припаивать надо... Лучше обратиться к первоисточнику. К сожалению адреса не знаю - но по моему в форуме про RTOS тема травой не заростает.
Rst7
Цитата
А почему хочется именно пограммное прерывание, почему нелзя обычный вызов обработчика.


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

Как бы так объяснить, нафиг это надо... Ну типа эмуляция прерываний с приоритетом...
sKWO
Цитата(Rst7 @ May 20 2008, 14:52) *
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?

Не знаю для чего Вам это нужно, но если строить програму на прерываниях то основной код я обычно пишу в следующем прерывании
Код
USART_UDRE_vect   /* USART, Data Register Empty */

а оно возникает когда пустой регистр данных передатчика УСАП
galjoen
Цитата(Rst7 @ May 20 2008, 15:52) *
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?
3. А может кто гламурнее способ знает?

А использование прерывания от EEPROM не будет гламурным способом?
1. Думаю, что его никто не использует. По крайней мере я - ни разу.
2. Разрешается одной командой sbi EECR,EERIE.
3. Генерируется всё время пока EEWE сброшен (EEPROM не пишется).
Rst7
Цитата
а оно возникает когда пустой регистр данных передатчика УСАП


Занято, и кроме того, как и следующий вариант

Цитата
А использование прерывания от EEPROM не будет гламурным способом?


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

Ну нечто такое:

Код
__interrupt void slow_irq(void)
{
  DISABLE_SLOW_IRQ();
  SLOW_IRQ_LOCK=1;
  __enable_interrupt();
  ....
  ....много всякой долгой каки...
  ....
  __disable_interrupt();
  SLOW_IRQ_LOCK=0;
  ENABLE_SLOW_IRQ();
}

__interrupt void fast_irq(void)
{
  DISABLE_SLOW_IRQ();
  __enable_interrupt();
  ....
  ....
  ....
  if (....) SET_SLOW_IRQ();
  ....
  ....
  __disable_interrupt();
  if (!SLOW_IRQ_LOCK) ENABLE_SLOW_IRQ();
}
Палыч
Цитата(Rst7 @ May 20 2008, 14:52) *
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?... Но, к сожалению, INT0 и INT1 заняты, надо изобретать что-то другое.
ИМХО, в начале нужно определиться - какие ресурсы у Вас свободны? В зависимости от используемого МК можно, наверное, использовать
INT0-INT7
EEPROM Ready
USART0 Data Register Empty
USART1 Data Register Empty
SPM Ready

Возможно, не обязательно дрыгать ногой для вызова INTx. Может быть "подрыгать" режимом - аналогично компаратору. Такая же мысль и мне приходила в голову, но не проверял...
Rst7
Цитата
Как раз от компаратора в scmRTOS и используют


Ага, прерыванием от компаратора и пользуются. Щас посмотрел в сорсы. Только raise делается ногодрыгом. А у меня эти лапы заняты.

Цитата
INT0-INT7

Всего 2, оба заняты
Цитата
EEPROM Ready
USART0 Data Register Empty
USART1 Data Register Empty
SPM Ready

Все не годятся, причину объяснил выше.
Палыч
Не понятно, чем Вам не угодило прерывание от EEPROM. Если, память не используете, то "ручками" делаете чтение, и получаете прерывание. Не чуть не хуже дрыгания ногой для получения INTx.

Так какие ресурсы у Вас свободны? Как вариант - использование прерывания от свободного таймера. Настроить его на работу без прескалера с генерацией прерывания по одному тику. Разрешили прерывание - получили прерывание.
singlskv
Цитата(Rst7 @ May 20 2008, 16:52) *
Только raise делается ногодрыгом. А у меня эти лапы заняты.
А какие ноги свободные ? (если есть конечно)
и что из переферии не задействованно ?
и какой чип ?
andrvisht
Цитата(Rst7 @ May 20 2008, 15:52) *
Ага, прерыванием от компаратора и пользуются. Щас посмотрел в сорсы. Только raise делается ногодрыгом. А у меня эти лапы заняты.
Всего 2, оба заняты

Все не годятся, причину объяснил выше.

Код
ICR ?
Rst7
Цитата
Если, память не используете,

Использую.

Кроме того, "The EEPROM Ready interrupt generates a constant interrupt
when EEPE is cleared."

Т.е. пока EEPE очищен, прерывание генерируется. А мне так не годится. Мне нужно флаг установить, а сбросится он при выполнении процедуры прерывания.
Палыч
Цитата(Rst7 @ May 20 2008, 16:03) *
Мне нужно флаг установить, а сбросится он при выполнении процедуры прерывания.
Руками сбросить в процедуре обработки прерывания - религия не позволяет?

Какой у Вас контроллер и какие ресурсы свободны?
Rst7
Цитата
Разрешили прерывание - получили прерывание.


Да не годится мне так. Мне нужно раздельное управление flag и enable. Так понятнее?


Цитата
Руками сбросить в процедуре обработки прерывания - религия не позволяет?


Он не сбросится для EEPROM'а, единственный выход - запрещать, а мне так не годится...


Цитата
Какой у Вас контроллер и какие ресурсы свободны?


Разные контроллеры. На данный момент ATMega168.
andrvisht
так и не понял, нога которая ICP используется ?
Rst7
Цитата
ICP используется ?


Занята. Да и дрыгать ножками не хотелось бы, они могут пригодиться для других целей.
ILYAUL
Цитата(Rst7 @ May 20 2008, 15:52) *
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?.............

Как-то не очень понятна вообще логика вопроса. Понятно , что программно это иногда необходимо ( кнопка - таймер) тут есть логика , но из Ваших пояснений не прослеживается мысль - зачем Вам это нужно.
У любого устройства в MK есть регистра флага - по которому и происходит прерывание ( устанавливается и сбрасывается программным путём в большинстве случаев) .
Но не понятно зачем Вам надо вызвать прерывание - зная, что оно точно произойдёт- затем, что-то сделать и при этом по сути прерывание не использовать . Не поняттно зачем при обработке (например входов порта) зачем-то дёрнуть прерывание компаратора или таймера или EEPROM и при этом узнать что pin1 порта установлен в 1
galjoen
Цитата(Rst7 @ May 20 2008, 16:34) *
Мне не нужно прерывание, запрос которого сам по себе устанавливается, мне нужно его запрос руками (программно) поднять только в нужный мне момент времени. Т.е. из более приоритетного прерывания запустить менее приоритетное после окончания обработки более приоритетного.

Так вроде с готовностью EEPROM всё хорошо получается. Только ещё флаг в ОЗУ нужно завести, а м.б. счётчик (от задачи зависит). В обработчике __interrupt void fast_irq(void) вместо if (....) SET_SLOW_IRQ(); пишите if (....) Счётчик++;, а в конце вместо if (!SLOW_IRQ_LOCK) ENABLE_SLOW_IRQ(); пишите if (!Счётчик) ENABLE_SLOW_IRQ();. А в обработчике __interrupt void slow_irq(void) в начале DISABLE_SLOW_IRQ() (==cbi EECR,EERIE), а в конце делаете Счётчик--; и ещё раз if (!Счётчик) ENABLE_SLOW_IRQ();

Ещё могу рекомендовать более экзотический способ: использования совпадений у таймеров/счётчиков. Там при обработке флаг прерывания сам сбрасывается.

2 Палыч
Чтобы прерывание от EEPROM возникло никакого чтения EEPROM делать не нужно. Оно сразу возникнет - после его разрешения (если в этот момент EEPROM не пишется/читается).
Rst7
Цитата
Так вроде с готовностью EEPROM всё хорошо получается.


Тут следующий момент: счетчики надо инкрементировать/декрементировать с запрещенными прерываниями. Да еще и сохранять регистр SREG. К сожалению, это занимает слишком много времени, у меня тут жестко все...

Цитата
Как-то не очень понятна вообще логика вопроса.


Логика Вашего текста тоже не ясна ни разу wink.gif

Цитата
У любого устройства в MK есть регистра флага - по которому и происходит прерывание ( устанавливается и сбрасывается программным путём в большинстве случаев) .


Сбрасывается программным путем - да, устанавливается - нет. Из-за этого и весь сыр-бор.
prottoss
Цитата(Rst7 @ May 20 2008, 20:34) *
Мне не нужно прерывание, запрос которого сам по себе устанавливается, мне нужно его запрос руками (программно) поднять только в нужный мне момент времени. Т.е. из более приоритетного прерывания запустить менее приоритетное после окончания обработки более приоритетного.
Можно пойти таким путем - в конце более приоритетного прерывания закидывать в стек возврата адрес менее приоритетного прерывания. Правда, надо будет вставочку на асме соорудить, и после вставочки не должно буть, естественно, ни каких вызовов.
Палыч
Цитата(galjoen @ May 20 2008, 16:39) *
Чтобы прерывание от EEPROM возникло никакого чтения EEPROM делать не нужно. Оно сразу возникнет - после его разрешения (если в этот момент EEPROM не пишется/читается).
Да, конечно! Это результат спешки... Вместо "делаете чтение" - "разрешаете прерывание"...

Счетчик предлагаете завести для подсчета числа разрешений прерывания?

2 Rst7
Почему запрещать прерывания - не годиться? Это равнозначно сбросу флага. Желаете иметь два "рычага" управления: разрешение прерывания и флаг? Ну, и аппетиты у Вас... Так, что из ресурсов свободно?



Цитата(prottoss @ May 20 2008, 16:53) *
Можно пойти таким путем - в конце более приоритетного прерывания закидывать в стек возврата адрес менее приоритетного прерывания. Правда, надо будет вставочку на асме соорудить, и после вставочки не должно буть, естественно, ни каких вызовов.
Тагда уж и закидывание в стек адреса - не нужно: в конце процедуры обработки прерывания сделать вызов процедуры обработки другого прерывания. Но, автору вопроса понадобилось зачем-то настоящее прерывание

Цитата(Rst7 @ May 20 2008, 16:49) *
Тут следующий момент: счетчики надо инкрементировать/декрементировать с запрещенными прерываниями. Да еще и сохранять регистр SREG. К сожалению, это занимает слишком много времени, у меня тут жестко все...
Из-за этого - весь сыр-бор? Но, ведь запретить/разрешить прерывания - гораздо быстрее, чем вход/выход в/из прерывания...
galjoen
Цитата(Rst7 @ May 20 2008, 17:49) *
К сожалению, это занимает слишком много времени, у меня тут жестко все...

Кстати регистр можно сохранять в регистр адреса EEPROM EEARL (out 1 такт), или использовать его и EEARH как данные (в т.ч. командами cbi, sbi, sbic, sbis). Всегда так делаю у тех процессоров где они до 0x20.
А прерывание от 8ми битных таймеров/счётчиков по сравнению (если есть свободные) чем вас не устраивает?
=GM=
Цитата(Rst7 @ May 20 2008, 10:52) *
Тут задача возникла следующего характера. Как бы инициировать прерывание программным путем?
3. А может кто гламурнее способ знает?

А почему так нельзя: RCALL INTERRUPTVECTOR? Вот вам и будет вызов прерывания программным путём.
defunct
Цитата(Rst7 @ May 20 2008, 15:52) *
Все не годятся, причину объяснил выше.

Ну дык и устанавливайте руками - UDRIE = 1.
так же руками и убирайте - UDRIE = 0.

Вы вероятно не приняли во внимание, что прерывание можно сгенерить не только по условию события возбуждения прерывания, а и просто разрещением этого прерывания (с учетом, что все внешние факторы уже готовы сгененерить прерывание).. E.g. установить прерывание по уровню INT0, держать INT0 всегда в соотв уровне, а прерывание возбуждать не дерганием пина, а дерганием GIMSK.
SasaVitebsk
Я использую от таймера. У меня мега640 - там этих таймеров.... smile.gif

Код
    if(Flag.EnShow)    TIMSK0=2;                            // Выполнить прерывание
defunct
Цитата(Rst7 @ May 20 2008, 16:49) *
Сбрасывается программным путем - да, устанавливается - нет. Из-за этого и весь сыр-бор.

Зато маска чудесно контроллируется программным путем. Включать маску везде где нужно, тушить только в обработчике.
SasaVitebsk
2 GM - ты немного задачу не осознал. smile.gif

Например я делаю 100 прерываний от таймера, а вот после сотого мне надо выполнить хороший кусок работы. За это время придёт 4 прерывания от таймера. Короче надо в прерывании от таймера, по какому-то событию вызвать другое прерывание. Прямой вызов - не проходит, надо чтобы из того вернулась и вошла в новое.

smile.gif Короче не умею я объяснять. smile.gif Пусть кто другой попробует.
defunct
Цитата(SasaVitebsk @ May 20 2008, 18:11) *
Например я делаю 100 прерываний от таймера, а вот после сотого мне надо выполнить хороший кусок работы. За это время придёт 4 прерывания от таймера.

Не, такой пример не пойдет, разобъют сразу тупым и в тоже время справедливым вопросом - почему бы не выполнить хороший кусок работы в основном цикле программы. smile.gif
Палыч
Цитата(SasaVitebsk @ May 20 2008, 18:11) *
Прямой вызов - не проходит, надо чтобы из того вернулась и вошла в новое.
Почему - "не проходит"? Перед вызовом - разрешил прерывания - и все дела...
SasaVitebsk
Цитата(Палыч @ May 20 2008, 18:19) *
Почему - "не проходит"? Перед вызовом - разрешил прерывания - и все дела...

Надо выйти из предыдущего прерывания. Можно это конечно сделать и ручками, но зачем? Я, к примеру задействовал незадействованый таймер. Приведу пример ...

Код
#pragma    vector=TIMER1_COMPA_vect, INT7_vect                // Отображение картинки     Master, Slave
__interrupt    static void    Regeneration(void)
{
...
   NPrer_COMPA++;
   if(NPrer_COMPA==16)TIMSK0=2;                            // Выполнить прерывание
}
...
#pragma    vector=TIMER0_COMPA_vect                        // Исполнение комманд
__interrupt    static void    ShowActive(void)
{
....
TIMSK0=0;                // Запретить прерывание
__enable_interrupt();
....
}


Таким образом у меня второе прерывание выполняется 1 раз за 16 прерываний первого и может длиться несколько прерываний первого.
Палыч
Цитата(SasaVitebsk @ May 20 2008, 18:35) *
Надо выйти из предыдущего прерывания.
Зачем? Экономия стека? Можно вызывать и не процедуру обработки прерывания, а обыкновенную процедуру... Из предыдущего прерывания выходить и входить в новое - вовсе не обязательно! От этого ничего не изменится
galjoen
Цитата(defunct @ May 20 2008, 19:16) *
Не, такой пример не пойдет, разобъют сразу тупым и в тоже время справедливым вопросом - почему бы не выполнить хороший кусок работы в основном цикле программы. smile.gif

Не. В основном цикле не пойдёт. Вдруг там уже что-то выполняется, тогда туда и вернёмся. Кроме того написано, что нужно быстро - каждый такт на счету. Т.е. видимо нужно сделать что-то более приоритетное чем основной цикл, но менее приоритетное, чем прерывания (некоторые). Например рассчёт CRC блока, который в флешку записать надо. В таких случаях приходится и с возможностью рекурсии бороться, и со стеком колдовать, и смотреть кого это мы прервали то. Только на асме такое делается (я делал). А тут видимо на C, используя прерывания, такое же хотят сделать.
_Pasha
Привет, телепаты smile.gif
1. Какая у Вас мега в проекте?

<удалил чушь>
Палыч
Цитата(galjoen @ May 20 2008, 18:51) *
Т.е. видимо нужно сделать что-то более приоритетное чем основной цикл, но менее приоритетное, чем прерывания (некоторые).
О чём речь? Ну, нет в AVR приоритетов выполняемого кода! Или прерывания разрешены - прерывания возможны, или они запрещены - тогда прерывание никакое не произайдет! Reset - не всчёт! Нельзя в AVR выполнять код при разрешенных прирываниях, и, чтобы при этом одни прерывания могли прервать выполнение, а другие - нет (если они, конечно, все разрешены)! Приоритеты прерываний - это "из другой оперы"...
SasaVitebsk
Вот уж не знаю как вам объяснить. smile.gif

Ещё раз! Обзовём процедуры прерывания по мере их написания в моём предыдущем посте - 1 и 2.

Представьте, что прерывание 1 выполняется каждую мс. Соответственно п2 исполняется каждые 16мс. Предположем, что длительность исполнения п1 составляет 100мкс, а длительность п2 составляет 10мс.

В вашем варианте, если не принять специальных мер прервётся исполнение процедуры1, после начала исполнения процедуры2. Мало этого во много раз возростёт контекст в п1, что совершенно неоправдано увеличит загрузку процессора, так как они часто вызываются. Неисключено, что может произойти крах, так как выход из п1 завершён не будет, а будет повторный вход. Ну и как минимум будет оверхед по стеку.

Итак недостатки я перечислил - какие преимущества?
Rst7
Давайте я попробую все-таки подробностей добавить.

Есть 4 задачи. В порядке возрастания приоритетов:

1. Основной поток (тот который main()). На данный момент там банальный for(;;). Чего там будет, я пока не знаю, и поэтому, этот поток трогать мне нельзя.
2. Задача обработки. Длительная, выполняется намного дольше, чем промежуток между вызовами задач 3,4. Во время выполнения должны уметь получать управление задачи 3,4, причем с минимальным временем отклика (особенно 4). Запуск задачи происходит от события. По окончанию обработки задача засыпает до следующего события.
3. Задача - не самое приоритетное прерывание. От таймера, но вызывается часто - 256/512 тактов. В задаче - по быстренькому опрос периферии и по результатам - возможна генерация события для задачи 2. Во время выполнения этой задачи необходимо обеспечить возможность быстрого реагирования на прерывание для задачи 4.
4. Самое приоритетное прерывание. Входит, выполняет дело, по результатам дела генерирует или не генерирует событие, выходит.

Да, забыл. Задача 1 тоже потом может будет генерить события для задачи 2, а может и не будет.

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

План у меня таков - задача 2 - это обработчик прерывания, запрос на выполнение которого я могу создать в любой момент (это генерация события), а вот обработать - только тогда, когда не выполняются задачи 3 или 4 (и не находимся внутри задачи 2, дабы не допустить вложенности). Для этого мне и необходимо раздельное управление флагом запроса и битом разрешения прерывания.

Вариант со счетчиком плохо проходит в связи с тем, что увеличение/уменьшение счетчика требует сохранения SREG (с последующим восстановлением) и работу с самим счетчиком до разрешения прерываний.


Вот примерно такой код
Код
#define TASK2_LOCK GPIOR0_Bit0
#define TASK3_LOCK GPIOR0_Bit1

#define DISABLE_TASK2() {asm("PUSH R16");ACSR=(1<<ACD)|(1<<ACIS1);asm("POP R16");}
#define ENABLE_TASK2() {asm("PUSH R16");ACSR=(1<<ACD)|(1<<ACIS1)|(1<<ACIE);asm("POP R16");}
#define WAKEUP_TASK2() {ACSR=(1<<ACD)|(1<<ACIS1)|(1<<ACIS0);}

#pragma diag_suppress=Ta006
__interrupt void TASK2(void)
{
  __no_operation();
  //....
  //....много всякой долгой каки...
  main(); //Например так
  //....
  __no_operation();
}
#pragma diag_default=Ta006


#pragma vector=ANA_COMP_vect
__interrupt __raw void TASK2dispatch(void)
{
  DISABLE_TASK2();
  TASK2_LOCK=1;
  __enable_interrupt();
  ((void(*)(void))TASK2)();  
  __disable_interrupt();
  TASK2_LOCK=0;
  ENABLE_TASK2();
}

#pragma diag_suppress=Ta006
__interrupt void TASK3(void)
{
  __no_operation();
  //....
  //....не очень много всякой долгой каки...
  if (PINB_Bit0) WAKEUP_TASK2(); //К примеру
  //....
  __no_operation();
}
#pragma diag_default=Ta006

#pragma vector=TIMER0_OVF_vect
__interrupt __raw void TASK3dispatch(void)
{
  if (TASK3_LOCK) return;
  TASK3_LOCK=1;
  DISABLE_TASK2();
  __enable_interrupt();
  ((void(*)(void))TASK3)();  
  __disable_interrupt();
  TASK3_LOCK=0;
  if (!TASK2_LOCK) ENABLE_TASK2();
}

#pragma vector=INT0_vect
__interrupt void TASK4(void)
{
  //Тут тоже колдовство, запрещаем все прерывания, например
  TIMSK0=0;
  //Запрещаем и TASK2
  DISABLE_TASK2();
  __enable_interrupt();
  //Чего-то делаем, тут еще бывает INT1, но это уже не суть
  __disable_interrupt();
  if (PINB_Bit1) WAKEUP_TASK2(); //К примеру
  TIMSK0=1<<TOV0;
  if (!TASK2_LOCK) ENABLE_TASK2();
}


А вот чего выходит после компилятора
Код
        RSEG CODE:CODE:NOROOT(1)
//  176 __interrupt void TASK2(void)
TASK2:
//  177 {
        ST      -Y, R24
        ST      -Y, R31
        ST      -Y, R30
        ST      -Y, R3
        ST      -Y, R2
        ST      -Y, R1
        ST      -Y, R0
        ST      -Y, R23
        ST      -Y, R22
        ST      -Y, R21
        ST      -Y, R20
        ST      -Y, R19
        ST      -Y, R18
        ST      -Y, R17
        ST      -Y, R16
        IN      R24, 0x3F
//  178   __no_operation();
        NOP
//  179   //....
//  180   //....много всякой долгой каки...
//  181   main(); //Например так
        RCALL   main
//  182   //....
//  183   __no_operation();
        NOP
//  184 }
        OUT     0x3F, R24
        LD      R16, Y+
        LD      R17, Y+
        LD      R18, Y+
        LD      R19, Y+
        LD      R20, Y+
        LD      R21, Y+
        LD      R22, Y+
        LD      R23, Y+
        LD      R0, Y+
        LD      R1, Y+
        LD      R2, Y+
        LD      R3, Y+
        LD      R30, Y+
        LD      R31, Y+
        LD      R24, Y+
        RETI
//  185 #pragma diag_default=Ta006
//  186
//  187
//  188 #pragma vector=ANA_COMP_vect

        RSEG CODE:CODE:NOROOT(1)
//  189 __interrupt __raw void TASK2dispatch(void)
TASK2dispatch:
//  190 {
//  191   DISABLE_TASK2();
        PUSH R16
        LDI     R16, 130
        OUT     0x30, R16
        POP R16
//  192   TASK2_LOCK=1;
        SBI     0x1E, 0x00
//  193   __enable_interrupt();
        SEI
//  194   ((void(*)(void))TASK2)();  
        RCALL   TASK2
//  195   __disable_interrupt();
        CLI
//  196   TASK2_LOCK=0;
        CBI     0x1E, 0x00
//  197   ENABLE_TASK2();
        PUSH R16
        LDI     R16, 138
        OUT     0x30, R16
        POP R16
//  198 }
        RETI
        REQUIRE _A_ACSR
        REQUIRE _A_GPIOR0
//  199
//  200 #pragma diag_suppress=Ta006

        RSEG CODE:CODE:NOROOT(1)
//  201 __interrupt void TASK3(void)
TASK3:
//  202 {
        ST      -Y, R16
//  203   __no_operation();
        NOP
//  204   //....
//  205   //....не очень много всякой долгой каки...
//  206   if (PINB_Bit0) WAKEUP_TASK2(); //К примеру
        SBIS    0x03, 0x00
        RJMP    ??TASK3_0
        LDI     R16, 131
        OUT     0x30, R16
//  207   //....
//  208   __no_operation();
??TASK3_0:
        NOP
//  209 }
        LD      R16, Y+
        RETI
        REQUIRE _A_ACSR
        REQUIRE _A_PINB
//  210 #pragma diag_default=Ta006
//  211
//  212 #pragma vector=TIMER0_OVF_vect

        RSEG CODE:CODE:NOROOT(1)
//  213 __interrupt __raw void TASK3dispatch(void)
TASK3dispatch:
//  214 {
//  215   if (TASK3_LOCK) return;
        SBIC    0x1E, 0x01
        RJMP    ??TASK3dispatch_0
//  216   TASK3_LOCK=1;
        SBI     0x1E, 0x01
//  217   DISABLE_TASK2();
        PUSH R16
        LDI     R16, 130
        OUT     0x30, R16
        POP R16
//  218   __enable_interrupt();
        SEI
//  219   ((void(*)(void))TASK3)();  
        RCALL   TASK3
//  220   __disable_interrupt();
        CLI
//  221   TASK3_LOCK=0;
        CBI     0x1E, 0x01
//  221   if (!TASK2_LOCK) ENABLE_TASK2();
        SBIC    0x1E, 0x00
        RJMP    ??TASK3dispatch_0
        PUSH R16
        LDI     R16, 138
        OUT     0x30, R16
        POP R16
??TASK3dispatch_0:
        RETI
        REQUIRE _A_ACSR
        REQUIRE _A_GPIOR0
//  222 }
//  223
//  224 #pragma vector=INT0_vect

        RSEG CODE:CODE:NOROOT(1)
//  225 __interrupt void TASK4(void)
TASK4:
//  226 {
        ST      -Y, R17
        ST      -Y, R16
        IN      R17, 0x3F
//  227   //Тут тоже колдовство, запрещаем все прерывания, например
//  228   TIMSK0=0;
        LDI     R16, 0
        STS     110, R16
//  229   //Запрещаем и TASK2
//  230   DISABLE_TASK2();
        PUSH R16
        LDI     R16, 130
        OUT     0x30, R16
        POP R16
//  231   __enable_interrupt();
        SEI
//  232   //Чего-то делаем, тут еще бывает INT1, но это уже не суть
//  233   __disable_interrupt();
        CLI
//  234   if (PINB_Bit1) WAKEUP_TASK2(); //К примеру
        SBIS    0x03, 0x01
        RJMP    ??TASK4_0
        LDI     R16, 131
        OUT     0x30, R16
//  235   TIMSK0=1<<TOV0;
??TASK4_0:
        LDI     R16, 1
        STS     110, R16
//  236   if (!TASK2_LOCK) ENABLE_TASK2();
        SBIC    0x1E, 0x00
        RJMP    ??TASK4_1
        PUSH R16
        LDI     R16, 138
        OUT     0x30, R16
        POP R16
//  237 }
??TASK4_1:
        OUT     0x3F, R17
        LD      R16, Y+
        LD      R17, Y+
        RETI


Вариант с прерываниями хорош еще и тем, что в задаче 1 я могу выполнить WAKEUP_TASK2();ENABLE_TASK2() - и сразу полетит выполять задачу 2. Все приоритеты красиво соблюдаются.
Палыч
Цитата(SasaVitebsk @ May 20 2008, 19:12) *
В вашем варианте, если не принять специальных мер прервётся исполнение процедуры1, после начала исполнения процедуры2. Мало этого во много раз возростёт контекст в п1, что совершенно неоправдано увеличит загрузку процессора, так как они часто вызываются. Неисключено, что может произойти крах, так как выход из п1 завершён не будет, а будет повторный вход. Ну и как минимум будет оверхед по стеку.
Как сделать так, чтобы контекст не возрастал - уже обсуждалось... Крах при повторном входе? С чего бы это?
Обсуждение, кажется, ушло в сторону от заданного вопроса... Как я понял автора (пост №21): ему нужно изменить счетчики до возврата в основную программу, но чтобы при этом была возможность прерывания выполнять. Самое простое решение - прерывания разрешить.
galjoen
Цитата(Палыч @ May 20 2008, 20:08) *
Приоритеты прерываний - это "из другой оперы"...

Именно такую задачу я имел ввиду и решал (с приоритетами прерываний). Для этого обработчики располагаются во FLASH определённым образом. Чем выше приоритет, тем в более младших адресах обработчик. Основной цикл (низший приоритет) в самых старших адресах. При входе в обработчик - прерывания с младшими приоритетами запрещаются. В обработчике прерывания - прерывания разрешены. По адресу возврата (реально нужен только старший байт) в стеке перед выходом определяется какие прерывания разрешить (дополнительно к уже разрешённым). Т.е. получается система прерываний (и выполняемого кода) с приоритетами. И без RTOS. Из-за этого быстро между задачами переключается.

В простых случаях (мало приоритетов) можно флагами обойтись. А для флагов какой-нибудь неиспользуемый регистр ввода-вывода (адрес до 0x20) использовать - для скорости. Я обычно там где такого специального нет (в AT90 есть) регистры адреса EEPROM использую.
singlskv
Не знаю точно поможет ли это Вам в конкретной задачке, но я бы размышлял примерно так:
>>4. Самое приоритетное прерывание. Входит, выполняет дело, по результатам дела генерирует или >>не генерирует событие, выходит.
Ну вот это явно претендент на свое собственное прерывание.

>>3. Задача - не самое приоритетное прерывание. От таймера, но вызывается часто - 256/512 тактов. В >>задаче - по быстренькому опрос периферии и по результатам - возможна генерация события для >>задачи 2. Во время выполнения этой задачи необходимо обеспечить возможность быстрого >>реагирования на прерывание для задачи 4.
типичное таймерное прерывание, для разрешения других прерываний достаточно "легко"
делается сохранение контекста(если конечно задачка действительно простенькая...)

задачки 1 и 2 разумнее(скорее всего, делать в основном цикле), для
задачки N2 возможно подойдет просто опрос полингом флага другого таймера(специально закрепленного за этой задачкой)
ReAl
Цитата(prottoss @ May 20 2008, 15:01) *
Как раз от компаратора в scmRTOS и используют, но вроде как внешне что то к выводу компаратора припаивать надо... Лучше обратиться к первоисточнику. К сожалению адреса не знаю - но по моему в форуме про RTOS тема травой не заростает.
Ничего припаивать не надо.
Но одна нога занята.
Один из входов компаратора ставится на внутренний ИОН, второй остаётся на ножке, ножка ставится на выход. Этого достаточно.

В порт avr-gcc в примеры внесён ещё и другой вариант - используется прерывание SPM_ready (считается, что не используется при работе приложения, а не загрузчика).
При необходимости вызвать прерывание поднимается бит SPMIE, в обработчике он сбрасывается.
Ничего плохого в таком варианте не вижу.
singlskv
Если свободен пин nSS(SPI SlaveSelect) я бы еще подумал насчет него...
ну типа:
Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility
that SS is driven low, the interrupt should always check that the MSTR bit is still set. If the
MSTR bit has been cleared by a slave select, it must be set by the user to re-enable SPI Master
mode.
defunct
Цитата(galjoen @ May 20 2008, 18:51) *
Не. В основном цикле не пойдёт. Вдруг там уже что-то выполняется, тогда туда и вернёмся. Кроме того написано, что нужно быстро - каждый такт на счету.

Смотря как построен основной цикл.
У меня в основном цикле выполняется диспетчер задач, точнее даже диспетчер функций-обработчиков событий. Т.к. задачи выполняются бесконечно, а функции - конечно и быстро. Функции делятся по приоритетам. Приоритет драйверов периферии (диспетчер крутит их постоянно) и пользовательские приоритеты. Работает все это как часы. Никаких проблем с сохранением контекстов, никаких накладных расходов на отдельные стеки задач.
В прерываниях устаналивается готовность соотв. функций. В основном цикле - производится запуск обработчика события.
Насчет каждый такт на счету - не верю, не может каждый такт быть на счету для чего-то настолько длительного, что ест аж 4 периода таймера и в то же время настолько редкого, что происходит раз в 100 периодов таймера. Нестукуется с таким событием понятие каждый такт на счету.
ReAl
Кстати, я очень обижен на атмел в том, что битики force output compare у таймеров не вызывают соответствующее прерывание output compare :-(
singlskv
Цитата(defunct @ May 21 2008, 00:56) *
Насчет каждый такт на счету - не верю, не может каждый такт быть на счету для чего-то настолько длительного, что ест аж 4 периода таймера и в то же время настолько редкого, что происходит раз в 100 периодов таймера. Нестукуется с таким событием понятие каждый такт на счету.
Ну и почему же это не стыкуется ?
допустим хочу:
- передачу по SPI на максимальной скорости(кб этак 250-500 в сек) но при этом чтобы
джиттер был минимален и предсказуем
- опрос кнопок(типа процесс в 100 раз более медленный)
- запись в EEPROM когда надо(тоже не быстро).
- итд итп

ну и кто мешает это все совместить ?


Цитата(ReAl @ May 21 2008, 01:03) *
Кстати, я очень обижен на атмел в том, что битики force output compare у таймеров не вызывают соответствующее прерывание output compare :-(
А Вы ими пробовали вобще пользоваться ? (битиками)
я нет, поэтому и интересно...
но кстати таймером тож можно чего-нить такое намутить, тока топикстартер не сознается какие
узлы кроме комаратора у него еще не задействованны...
defunct
Цитата(singlskv @ May 21 2008, 00:11) *
Ну и почему же это не стыкуется ?

Несктыкуется это событие (длиной в 4 периода таймера) с надобностью обработки в прерывании.

Цитата
допустим хочу:
- передачу по SPI на максимальной скорости(кб этак 250-500 в сек) но при этом чтобы
джиттер был минимален и предсказуем
- опрос кнопок(типа процесс в 100 раз более медленный)
- запись в EEPROM когда надо(тоже не быстро).
- итд итп

ну и кто мешает это все совместить ?

Ничто и не помешает все это совместить если обработку события длиной в 4 периода таймера кинуть в основной цикл.
singlskv
Цитата(defunct @ May 21 2008, 01:19) *
Несктыкуется это событие (длиной в 4 периода таймера) с надобностью обработки в прерывании.
Ничто и не помешает все это совместить если обработку события длиной в 4 периода таймера кинуть в основной цикл.
А кто сказал что это событие обязательно нужно обработать за один присест ?
Вне зависимости от того где оно будет обрабатывться, всегда есть возможность
обработать его по частям.
Те просто делаем автомат обработки события с внутренним разбиением на части...

Те например пусть нам нужно записать X байт в EEPROM,
запись каждого байта это процесс который может растянуться на очень много периодов
нашего таймера, но у нас автомат который запустил запись X байтов и пока они все не записались
он не освободился.
Ну конечно если там голые рассчеты без всяких ожиданий то они конечно должны
жить в главном цикле...
galjoen
Цитата(defunct @ May 21 2008, 01:19) *
Несктыкуется это событие (длиной в 4 периода таймера) с надобностью обработки в прерывании.

Тут прерывание ТОЛЬКО для того, чтоб приоритет этого события поднять, а основной цикл отдать кому то другому (на, делай в нём что хочешь, всё равно мне не навредишь).
defunct
Цитата(singlskv @ May 21 2008, 00:35) *
Те просто делаем автомат обработки события с внутренним разбиением на части...

Ну так ведь ничто не мешает этот автомат сделать в основном цикле. Ввести там сколько надо приоритетов 10-100-1000 (на скоко памяти хватит) и следовать им.

Цитата
Тут прерывание ТОЛЬКО для того, чтоб приоритет этого события поднять

Если только для этого, то обрабатывать можно в том же прерывании, зачем еще одно плодить?
результат одинаковый будет.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.