Прерывание в прерывании или как их правильно разложить?

[rusyvochka]

Доброго времени суток!
На очередной "безделушке" в железе заметил некое отличие от ожидаемого да и от моделирования тоже...
Преамбула :
имеем: PIC16F676; используется два канала АЦП, TMR0, TMR1, INT, флаг RAIF.
Все изделие - зарядное для АКБ, основные жертвы - шуруповерт & 12V 2400 mAh для фотоаппарата)
По подробнее:
INT: используется для отслеживания перехода сетевого через "0";
TMR0: шестиразрядная 7-х LED идикация;
TMR1: использую для формирования импульса открытия тиристоров в силовой - фазоимпульсная регулировка;
АЦП0: напряжение на "жертве", измеряется в момент перехода сетевого через "0", когда зарядного тока нет;
АЦП1: значение тока, измеряется при наличии импулься запуска тиристоров по"кольцу", до прерывания по INT, если больше "0" - суммируется, в обработке INT делится на количество измерений ‹› 0;
RAIF: контролируется, но прерываний не вызывает, задействован для работы с энкодером.
Дабы не ковырять листинг, попробую "на пальцах":
Сетевое в "0" - INT, измеряю напряжение на входе АЦП0, запускаю TMR1 со значения посчитанного от напряжения на шунте (чти - ток, железо не затрагиваю, всё тривиально - rail - to - rail), разрешаю индикацию, делаю вычисления для следующего прохода - сумма токов / кол-во, снимаю импульс запуска тиристоров и др...
После выхода с обработки по INT, идикация по переполнению TMR0. Между INT задался двумя проходами, т.е. два раза 6 разрядов - визуально в железе нормально. На 13 - ом разе (разу?) прерывания от TMR0 запрещаю. Почему? Дочитайте до конца...
Далее: индицирую по очереди разряды, пока не произойдет прерывание от TMR1. Выставляю импульс запуска, разрешаю прерывания от АЦП - второй канал - токовый. По прерыванию от АЦП, снимаю данные, суммирую, инкр. кол-во, в общем математика.
Ну а теперь о грустном:
INT_TMR1
BSF Iz ; выставил импульс запуска
BCF PIR1,TMR1IF
Retfie
; без сохранения контекста
INT_TMR0
movwf copy_w
movfw STATUS
movwf copy_s ; как положено
bcf INTCON,T0IF
bsf INTCON,GIE

; следующий разряд
; выход с восстановлением контекста
; ну вот отсюда по подробнее...
Мои рассуждения (корректируемые в процессе крапания) были такими:
индикация имеет наименьший приоритет;
пока нет импульса запуска, все белое и пушистое;
за полупериод индикация "пробегает" два раза по 6 разрядов, 13- е прерывание от TMR0 просто тушит индикаторы и запрещает INT_TMR0 до следующего INT по переходу сети, дабы индикатор не "ждал длинной обработки INT - много математики и подготовка индикации;
после установки им.запуска, начинается обращение к АЦП, результат читаю по ADIF. В обработке сохраняю контекст в "свои" временные, дабы не подпортить копии в TMR0. Т.е. если идет обработка индикации, а пора выставить Из (максимально короткая обработка) или прочитать данные АЦП (тоже старался не распылятся), индикация "подождет".
Если не разрешить в INT_TMR0, INT_TMR1, он же Из, то Из (сори за тавтологию) выставится только после обработки индикации, т.е. Retfie, а сие меня не устраивает по времени
RAIF используется в обработке установок, точнее определение направления вращения энкодера. Во время установок остается только INT_TMR0 для индикации устанавливаемых величин; тут все гладко и потому не заостряю.
Ну а проблемка в том, что при "движении" Из, увеличении мощности, индикатор, на который, я так догадываюсь, по времени совпадает с установкой Из или обработка прерывания АЦП, неприятно ярче светит.
Всего лишь!
А теперь вопрос: а как великие гуру поступают в таком случае?
(дальше лирика - можно не читать).
P.S. - БОЛЬШАЯ ПРОСЬБА (маленькие не срабатывают ) не надо тыкать пальцем на первоисточник и даташиты. "Игрушка" не первая (именно игрушка), работаю все красиво (именно красиво - ну люблю я индикацию по красивше нарисовать: ЖК не предлагать - дорого и в кармане лишних нет). В этой версии первый раз решился измерять ток после Из, и суммировать пока ›0. Ну и на будущее хотелось бы знать, как правильно обрабатывать несколько прерываний, которые не "терпят" очереди???

[NewWriter]

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

Причина кратковременного увеличения яркости именно в том, что несмотря на запрет работы индикации, она все равно запускается.
А запускается она потому, что наверняка неправильно проверяются возникшие прерывания. Конкретно, не проверяется, что T0IE = 0 (запрещено). Но ведь таймер 0 не отключаемый и прерывания по нему выставляются всегда. И если после проверки T0IF не проверять запрет прерывания (T0IE), то при входе по любому другому прерыванию будет обработано и возникшее T0IF.
Либо при повторном входе в прерывания программа попадает в ту область, в которую не должна войти и от этого портятся ранее сохраненные данные.

в обработке INT делится на

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

С остальным я что-то не очень то понял, что там и как сделано и что такое "Из".
Но выход из прерывания без восстановления ранее сохраненного контекста чреват как минимум потерей актуального состояния битов в регистре STATUS для основной программы на момент возникновения прерывания.
Я когда-то давно ловился на такую фишку с порчей битов статуса. Но по другой причине - у PIC16F873A вообще нет общих для всех банков регистров и при входе в прерывание контекст сохранялся в совсем других регистрах другого банка.

как правильно обрабатывать несколько прерываний, которые не "терпят" очереди???

ну как, так и обрабатывать - по очереди. Ибо у МК только одно вычислительное ядро и только один вектор прерываний.
Нужно просто правильно построить функциональную схему работы программы.
Если всётаки разрешать повторный вход в прерывание, когда выполняется обработка предыдущего входа в прерывание, то нужно не допускать порчи сохраненных ранее данных. Необходимо обязательно устанавливать программный флаг того, что предыдущий вход в прерывание был уже выполнен. Иначе первым делом испортятся данные в регистрах, сохраняющихся при первом входе в прерывание и после возврата полностью в основную часть программы эти данные будут уже ошибочны. Поэтому при первом входе контекст должен не только сохраняться, но и дублироваться во вторую группу регистров. А при выходе определять, какую группу восстанавливать - первого или второго уровня вложенности.
И к тому же, при повторном входе нельзя вновь попадать в то прерывание, которое обрабатывалось до наступления повторного входа. То есть, во время обработки прерывания нужно его запрещать (xxIE=0), а в конце разрешать.
Причем, нужно еще определить, в каком месте можно разрешать повторный вход, и какие прерывания имеют право вызвать повторный вход.
Короче, подводных камней дофига. Не проще ли переделать программу оптимальнее.

Чтобы не перегружать прерывания, может быть вообще изменить схему работы.
Та же самая индикация может прекрасно работать и без прерываний, зацикленная в основном цикле. Но тут есть ограничения по длине всего цикла и по периоду между переключением разрядов.
Чтобы отмерять разные интервалы времени можно использовать всего один таймер, по прерыванию которого будут работать программные таймеры, отсчитывающие интервалы, кратные времени переполнения аппаратного таймера.
С запуском АЦП тоже есть свои тонкости. После переключения канала должно пройти некоторое минимальное время Tacq, указанное в датащите (16-20 мкс достаточно), для заряда интегрирующего конденсатора до измеряемого напряжения. До истечения этого времени запускать АЦП нельзя, иначе значение будет иметь большую погрешность.

ЖК не предлагать - дорого и в кармане лишних нет

Да ну, вы что. Один WH0802 стоит примерно столько же, сколько два трехразрядных или три двухразрядных семисегментника. И это еще не говоря о том, что в PIC-676 просто не войдет 6-разряная дин.индикация без расширителя порта на двух 595. А для ЖКД нужно всего 6 линий, причем 5 из них могут быть мультиплексированы с другими функциями.

[NewWriter]

Да, а если уж совсем честно, то я искренне не понимаю придуманных проблем в этом конкретном случае. Достаточно просто логически подумать и правильно распределить время процессов. Начертить графики и посмотреть.
Времени хватает на всё! А если не хватает времени на последовательную выгрузку битов индикации, то её (выгрузку) можно доверить основной программе, а в прерывании таймера только переключать сигнал разрешения выходов 595-й, предварительно проверив, что все данные были выгружены.
На графике видны точки, в которых могут происходить отложенные прерывания, то есть, когда идет работа с прерыванием T0IF, может возникнуть прерывание ADIF. В этом случае, если обработку ADIF расположить после длинной обработки T0IF, то выйдя и T0IF сразу же попадаем в обработку ADIF, не выходя по retfie из обработчика вообще. Этим мы сокращаем время реакции на ADIF, ведь исключаются операции выхода и входа. А без обработки T0IF время реакции на ADIF будет постоянным и не критичным, ведь этот флаг выставляется по завершению преобразования, а начать следующее преобразование сразу же нельзя, нужно выдержать время Tad. Но вот если между измерениями будет плавать интервал, тогда начнутся накапливаться погрешности из-за неодинаковости временнЫх точек измерения напряжения.




А вот и функциональная схема обработки прерываний в этой поделке:
как видно, никаких особых потерь времени, превосходно всё укладывается даже при 4 МГц тактовой МК.
Вся "математика" должна выполняться в основной программе в любое свободное время.

[Boba_spb]

Глаз - инерционная система. Поэтому индикацию обычно выполняю с частой 1кГц на простое процессора. При мультиплексировании 8 - 125 Гц частота кадров - глаз не замечает изменений. Если есть длинные куски программы , которые держат процессор более 10 милисекунд можно вставать обслуживание индикатора.

[rusyvochka]

Не слабо описано! Сенк приогромный!
"Из" - импульс запуска, выставляется на пине по TMR1IF...
Вот его то как раз и хочется иметь, когда надо.
По ORG 0x04, проверяется сразу разрешение прерывания, а затем флаг , вот пришлось извращаться. Если идет установка, просто запрещаю периферию: TMR1 & ADIF. При выходе из INT, есно сбрасываю флаги T0, T1, ADC (а вдруг разрешил преобразование, а тут сетевое прилетело... флаг выставится, а он уже не нужен), и начальное для Т0 заношу, чтоб после выхода из ИНТ сразу пошла индикация первого разряда.
А теперь из железа:
смена индикации каждые 10 мкс (по INT, переход сети через "0") сильно заметно мерцание по разрядам...
Контекст сохраняется в каждом прерывании в свои временные, возврат из "следующего" прерывания в предыдущее происходит в ту же точку, с тем же Status и W, стек 8 уровней, у меня макс 4, потому перебора не боюсь.
Если разрешить всё время смену разрядов, визуально могу сказать, когда ток › 0 - индикаторы с 6 по первый начнут "ярчать" (ну слово такое придумалось). Такая же "железяка" на 16F886 и 16F873, при кварце 20 - вот там без проблем - прямая запись в порт при смене индикации, короткие обработки, математика - где угодно.
Для 676 таки да - две 595 присутствуют. Сама программа - не нажат ли энкодер для установок, остальное - в прерываниях. Была версия с контролем только флагов - красиво работает визуально но... импульс запуска "дрожит" мкс 20 где то, не критично, но не приятно. Вот и получается - либо красота визуально, либо красота в работе. Ей бы кварц на 25 присоплить.... так ноги кончились ...

[rusyvochka]

Углубился в графически алгоритм...
Обработка TMR1IF совсем три строки, не "портящих" Status и W, и потому может быть первой, без сохранения контекста...
Использую INT только по спаду, за время, пока "вокруг 0", делю сумму на количество измерений тока - 16 бит / 8 бит, в последней полуволне - это есть занимать машинное время. Тут же, если уже 16 раз измеренное напряжение на 16, и так же ток за 16 полуволн - дабы "не мельтишили" показания индикаторов - это то же время - проверка прошло ли 16 измерений, нет - сложить с предыдущей суммой, да поделить на 16, обнулить сами регистры и счетчики и т. д. Тут же сравнение заданного с измеренным, соотв увеличение или уменьшение начального для T1 в следующем цикле, сразу после входа в INT; проверка можно ли еще увеличивать или уменьшать, сравнение с раннее измеренным периодом сетевого... В общем - рутинная математика, но это все время.
Это я к чему?
Если это 16 такт... пока выйти из прерывания INT, T0, при шустрой смене, высокой частоте, уже может переполнится дважды... Отсюда: двойное по длительности и яркости свечение какого нибудь разряда. Проверено. Ну не хватает 4 мгц внутреннего. Чти выше - либо красиво светим, либо "красиво" держим ток.
А вообще, как можно было по моему первому описанию, практически точно повторить алгоритм? Хорошо объяснил или читатель проф?
Только поправочка к картинке. Второй (отрицательной) полуволны нет! Мост. Работаю в каждой полуволне. Вот "куча" времени и сплыла....

[omercury]

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

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

Разбейте программу на тайм-слоты (типа RTOS с вытеснением) и выполняйте в каждом своё действие. Кстати, гасить индикатор имеет смысл только во время захвата АЦП, которое, как тонко подметил NewWriter, не желательно проводить во время зарядного импульса, у Вас же не Ni-Cd, чтоб ловить дельту.

[NewWriter]

смена индикации каждые 10 мкс

имелось в виду 10 миллисекунд?? Потому что 10 микросекунд - это нереально и совсем не нужно (16кГц???).
Вообще я ж на графике нарисовал - индикация от TMR0, каждый разряд по 2,048 миллисекунд = 81 Гц, это незаметно (лично проверял).

Ну не хватает 4 мгц внутреннего. Чти выше - либо красиво светим, либо "красиво" держим ток.

Хм. Во время отрицательной полуволны, когда закрыт тиристор, есть аж 10 миллисекунд времени, это 10'000 команд при 4 МГц! Деление занимает меньше тысячи команд.

Второй (отрицательной) полуволны нет! Мост. Работаю в каждой полуволне. Вот "куча" времени и сплыла....

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

да поделить на 16,

Деление на 16 - это одна смена полубайтов (swap) либо 4 сдвига вправо (rrf) (для одного байта. если для двух, то 4 сдвига по два)
Тяжеловесная математика должна проводиться в основной программе, а сигналом для начала вычислений будет программный флаг готовности, выставляемый в соответствующих прерываниях.

проверяется сразу разрешение прерывания, а затем флаг

С точностью до наоборот рекомендуется. Как раз по причине сокращения времени. Если флага нет, то и разрешение проверяться не будет.
И так нужно делать для каждого проверяемого прерывания.

TMR1IF совсем три строки, не "портящих" Status и W, и потому может быть первой, без сохранения контекста...

А совсем не обязательно сразу же выходить из прерываний. Флаги других прерываний установятся даже тогда, когда GIE=0 и программа находится в обработке прерываний. Как только программа дойдет до проверки флага следующего прерывания, она среагирует на него, даже не выходя в основную программу.
Первоисточники и даташиты как раз об этом и говорят! Там четко написано, что при наступлении события флаг будет выставляться независимо от битов разрешений (в том числе и GIE), а бит GIE определяет только то, что программа из основной части будет перенаправлена по адресу вектора прерываний.

импульс запуска "дрожит" мкс 20 где то, не критично, но не приятно

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

[rusyvochka]

‹А какая разница, это же не лампочка, что с того, что в отрицательной полуволне будет закрыт тиристор.
Ну ладно, раз хочется так, то подцепи 12 МГц кварц - втрое увеличится скорость.
›
...ножки кончились
‹А совсем не обязательно сразу же выходить из прерываний›
... потому в обработке прерывания Т0, индикация, сразу после входа, сроса своего флага и сохранения контекста, разрешены все прерывания, сюда и возврат, после обработки ТМР1.
‹С точностью до наоборот рекомендуется. Как раз по причине сокращения времени. Если флага нет, то и разрешение проверяться не будет. ›
... за это спасибо, логично, учту на будущее.
флаги тоже пробовал контролировать без вызова прерывания. Остался только RAIF, для энкодера... Всё работает, только громоздкой программа получается. Памяти не хватило (справедливо для 676).
‹А реальные оптопары дают гораздо большее отклонение по времени от нулевой точки›
оптопар нет, напрямую с ПИКа управляющие "дёргаю!. У тиристоров тоже реакция не моментальная да еще и управляющий импульс во времени гуляет... Я в каждом полупериоде, как то, измеренный ток и во флеш бросал, потом на программаторе смотрел, чего там токовый канал "намеривает". дык вот разброс - это мягко сказано! При малых токах, до 300 мА, в два раза может отличатся. Ну и нахрена (сори) такой стабилизатор тока с красивой индикацией случайных чисел? Это при том, что вкаждом полупериоде еще и время ТМР1 корректируется. Пусть на дискрет, но плюс задержки до выхода из "другого" прерывания - имеем хрень непредсказуемую. В районе 5-8 ампер все бело и пушисто (в районе пика полуволны.
Ну вообщем как то так в железе то.
‹Вас же не Ni-Cd, чтоб ловить дельту.›
А для шуруповёртного чего? Вредно по дельте отключаться? А ведь срабатывает! И выставленный порог контролируется и дельта. Только чуть не по правилам: при переходе через ноль, при токе = 0. Предыдущее с последним. Больше? будет для сравнения в следущем проходе за "эталон". меньше на (% от установленного) - хватит издеваться над батарейкой

[NewWriter]

чего там токовый канал "намеривает". дык вот разброс - это мягко сказано! При малых токах, до 300 мА, в два раза может отличатся

Такие проблемы могут быть из-за несоблюдения рекомендованных таймингов АЦП. Я ж уже писал - после выбора другого канала нельзя сразу запускать преобразование (время Tacq для заряда конденсатора), нельзя сразу запускать новое преобразование на том же канале после окончания предыдущего преобразования (время 2Tad, в течение которого конденсатор не подключен ко входам), время Tad должно быть минимально возможным, но укладываться в рекомендованный диапазон.

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

оптопар нет, напрямую с ПИКа управляющие "дёргаю!.

Я имел ввиду оптопары на входе для контроля перехода через ноль.

Закончились ножки? Мультиплексирование функций.

обработке прерывания Т0, индикация, сразу после входа, сроса своего флага и сохранения контекста,

Контекст надо сохранять один раз, сразу при входе, еще до проверок флагов. Я ж на блок-схеме рисовал..
В старшем семействе МК контекст аппаратно сохраняется при переходе по вектору прерывания, то есть в самом начале.
И для индикации в прерывании я бы оставил не полную выгрузку последовательных бит, а лишь сигнал передачи загруженных данных на выходы 595-й. Так удастся очень сильно сократить время выполнения и избавиться от лишних наслоений уровней вложенности.