А отчего бы просто не сбросить I-флаг и не вызвать функцию?

Вырубить прерывания и из обработчика вызвать?)

Э-э-э... Пардон, таки врубить прерывания. Я ошибся. Не сбросить I, а поставить.

То есть, врубить и функцию? хм...можно попробовать) или функцию и врубить?

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

Поставить-то поставим... Но смысл? Этим мы всего лишь разрешим глобальные прерывания. А сами источники прерываний будут устанавливать свои флаги прерываний в своих регистрах флагов прерываний... Вот по ним и можно определять - совпало ли время с установленным на будильнике...

Вот блин проблему создали....
По сути, все делается проще. Просто берем переменную и заюсываем ее как набор различных флагов.
Устанавливаем флаг в одном месте, по определенному событию и проверяем в другом месте, если необходимо. Если флаг выставлен, то сбрасываем его и выполняем действие, если не выставлен, то едем далее по программе. Длинные задержки организовываются через системный таймер и срабатывание этих программных таймеров опять же по флагам. Самое интересное - что через флаги можно управлять устройством параллельно с разных интерфейсов. Например как через кнопки, так и по UARTу одновременно.

А манипуляции с обработчиком прерывания и стеком, ИМХО даже на АСМе, мазохизм.

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

Если честно, я не вникал в суть задачи. Меня спросили "как" - я ответил. Может, флаг в этом случае и правда более удачное решение.

Итак, сделал с флагом-работаааееет)) Спасибо за советы!

То - то и оно. Кстати, качественная программа так же требует и обработки исключений. Тупые бесконечные циклы ожидания, к примеру, готовности EEPROM к записи тоже опасны. Я недавно только из-за этого хотел отсеять одного программера, что его программа на разных мелочах могла просто повиснуть в бесконечных циклах, ожидая чего то. Страдала в основном грамотность построения алгоритмов. Пожалел только потому, что больше не к чему было придраться. В остальном, код был довольно хорош, особенно в плане переносимости.

Спасибо за советы) Теперь даже научился немного оптимизации-из-за вложенных циклов и кучи временных переменных 8 мега иногда уходила в резет))) Зато горд-я смог забить всё ОЗУ) Чтобы не плодить темы, спрошу тут-код на С можно без особых изменений(поправить регистры, инклуды) перенести с 8 меги на 168? По ногам они идентичны.

Вот тут юзай директивы. Смоя основная, это #define Все архитектурнозависимое надо переопределять. Это для того, чтобы во время правок при переносе не приходилось шастать по всему исходнику.

А так, для переноса, тебе надо включить другой заголовочник, если это ИАР или изменить МК в свойствах проекта, если это GCC.
Переопределить порты, если у них названия другие. Ну и перенастроить прочую периферию, которая отличается. Типа таймеров и прочего.

Все архитектуронезависимое(имена портов итд) итак уже в дефайне. Просто поменять заголовочник и периферию переиниацилизировать, значит. Спасибо за советы!

Весьма спорное утверждение. Встраиваемое ПО состоит сплошь из таких мест: тут надо ждать EEPROM, там SPI, еще где-то АЦП и т.п. Если на каждый такой участок лепить всякую шелуху для проверки, то программа вырастет как на дрожжах, естественно став сложнее для понимания и поддержки. При этом, данные неисправности чисто железные (сгорел чип, брак, наводки), программа ничего с ними не сможет сделать.

Хотя, конечно же есть области, где применяется именно такой подход - космос, мирный атом, и, возможно, авионика. Там да, дублирование всего и вся плюс куча проверок. Но мы же не спутники запускаем. Требовать такой мега надежности от обычных промышленных систем - тоже самое, что требовать от ПК, чтобы при выдергивании процессора он вежливо нам об этом сообщал, прося вернуть его на место. Так что думаю сторожевого таймера более чем достаточно, ведь это есть тот максимум, что может сделать ПО - перезагрузить железку.

ПС: Конечно я несколько утрирую. Если вы запускаете спутники, то извините. Если я неправильно вас понял, то тоже извиняйте.

Тогда ещё вопрос-когда ОЗУ заполнено, МК может сам резетиться? А то фигня была такая(

Это естественно, т.к. в ОЗУ и стэк располагается..... И при заполнении ОЗУ под завязку, иногда можно не правильно оценить необходимый остаток памяти под стэк. Надо учесть все возможные варианты пути алгоритма..... (программа кстати может не только ресетится, но и вести себя фантастическим образом.....)
Я както дизассемблировал одну прогу (на С прога была), дак там при вызове прерывания, сохранялся практически весь набор рабочих регистров около 20, а еще если представить, что прерывание вызвалось в момент обработки нескольких вложенных функций, у которых тоже сохраняются регистры, да еще при каждом вызове ф-ции\прерывания, приплюсовать надо сохранение адреса возврата.....
В обчем под стэк надо оставлять чуть больше места чем может казаться.....

+1.

В абсолютном большинстве случаев хватает watchdog'а. Собственно, он для того и придуман, чтобы, в частности, обезопасить прошивку от зависания на таких участках без затрат програмных ресурсов.

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

Для простых поделок оно-то и понятно, что можно и без всего этого. Но если времени, терпения и памяти достаточно, то почему бы и нет?

Тема интересная! Сейчас работаю над часами. пишу на асме для PIC, будильником управляю при помощи флагов, как описывалось ранее. И все бы ни чего, но если в программе есть продолжительная пауза(например задержка на преобразования температуры датчиком ds18b20) в 800мс. То срабатывание будильника запаздывает на секунду. А зрительно это очень заметно. Но и это вроде ничего, можно перетерпеть. Вход в меню у меня организован тоже через флаги и тут, то не очень приятно выходит - нажал кнопку и ждешь секунду пока в меню попадешь. Может кто поможет советом? Как справиться? Флаги устанавливаю в прерываниях, а при выполнении основной программы проверяю их. У меня пока только одно решение - перенести фрагмент кода обработки меню в обработчик прерываний.

Не делать ожидание датчика блокирующим выполнение циклом, а ориентироваться по времени.

1. Пришло время мерять температуру? Послали команду, поставили флаг измерения + запомнили время начала.
2. Флаг измерения стоит? Секунда по часам прошла? Читаем из датчика. Сбрасываем флаг измерения, задаем следующее время опроса датчика.