Вы находитесь на странице: 1из 11

2-2/3.

"Ваяние" основных режимов работы устройства (создание и детализация


"глобальных" сценариев работы устройства), с учетом "пороговых дел".
Сохранение установок текущего режима в EEPROM-памяти PIC16F873A.

"Промать" это конечно прекрасно и чудесно, но "по закону жанра", она должна/обязана
что-то "родить", ведь в нее "заложены детородные функции" (а без них, будет
"куриный смех" и сплошной конфуз).
В конечном итоге, она должна "родить слона (желательно), а не мышь (можно, но за
что кровь проливается?)".
И не сразу.
ВНИМАНИЕ: без тренировки/предподготовки "рожать слона" опасно !!!
Вот я и коварно сформулировал дальнейшую "свехзадачу", решение которой должно
быть строго поэтапным (напоминаю про поэтапное "разделяй и властвуй").
Америку не открываю, так как сие есть основа любой методологии.
Опять "упираюсь" в расстановку приоритетов.
Сложность заключается не только в их определении, но и в "расстановке по ранжиру".
"Строй" текущих задач должен представлять собой "пилу с хорошей линейностью"
(X="суперважняк"-N, где N = 0,1,2,3, …), а не спектральное разложение звука "му".
"Железобетонные правила игры" того, чем мы с Вами занимаемся, все-равно заставят
"упереться лбом в эту пилу".
И шутить с этим совсем не стоит, так как речь идет не о "детском саде", а об
"армии", только своеобразной. Она даже строже привычной.
Например, бросишь окурок не в урну à заставят (100%) его похоронить в глубокой яме.
И яму будет рыть/закапывать конкретный "нарушитель".
А если "с первого (и т.д.) захода не прошибло" (в смысле "бросания окурков туда,
куда нужно"), то в дальнейшем, велика вероятность приобретения квалификации типа
"могильщик окурков".
"Могильщик окурков" тоже "пахарь", но только бестолковый. И это его беда.
Об "армейских дедушках": "дедушки" это те люди, которые никогда повторно (но один
раз можно/нужно) не наступают на одни и те же "грабли" (толковые "пахари").
Кстати, я не считаю себя "дедушкой", но всячески стремлюсь им стать.
Как Вам такая "могильная" перспектива? Лично мне, она вообще не нравится.
Выводы делайте сами.
В сформулированном ранее, 2-м пункте "глобального" плана работы (1-й пункт, в
основном, отработан), речь идет о "пороговых делах".
Это и есть то, что сейчас нужно "планово задетализировать".
Естественно, что если, в контексте "глобальной" функциональности разрабатываемого
устройства, речь идет о "пороговых делах", то перво-наперво нужно определиться с
внешним управлением.
В качестве "внешней управлялки", буду использовать транзистор ("дешево и сердито").
Значит, под управление этим транзистором, нужно задействовать один вывод порта.
Вопрос: "Вывод какого именно порта"?
Если Вы думаете, что этот вопрос можно "закидать шапками" (типа "свободных
выводов много и можно задействовать любой"), то Вы ошибаетесь.
Во избежание дальнейших "бяк", под это дело, не нужно использовать ни один из
свободных выводов порта В и С.
Вопрос: "Почему"?
Ответ: потому, что часть выводов этих портов задействованы (см. принципиальную
схему), и при работе "на выход", для управления их состояниями, используются байт-
ориентированные команды, влияющие на состояния всех выводов порта.
Если проигнорировать сказанное, то по ходу отработки программы, на сигнал
управления транзистором, будет наложен "сигнал-паразит", добра от которого можно
совсем не ждать (он и близко не стоит к тому, что нужно), так как, за счет этого
"гада", транзистор будет кратковременно открываться тогда, когда он должен быть
закрыт, и кратковременно закрываться тогда, когда он должен быть открыт (если имеет
место быть любознательность, то для отслеживания этой "бяки", желателен осциллограф).
В крайнем случае, можно программно "извернуться", но это приведет к усложнению
программы.

1
"Крайнего случая", слава Богу, нет, так как есть свободные выводы порта А.
Имеется 6 выводов порта А: RA0…RA5.
- 2 вывода (RA0 и RA1) используются под АЦП. "Трогать их" нельзя.
- 2 вывода резервирую еще под пару каналов АЦП (в будущем может пригодиться),
- вывод RA4/TOCKI тоже резервирую (в будущем может пригодиться),
Остается один "лишний" канал АЦП.
Вот его-то и задействую под управление транзистором.
Вопрос: "Какой именно, из числа трех, пока свободных, каналов АЦП (RA2, RA4, RA5),
задействовать под управление транзистором"?
Ответ: в принципе, любой. Я выбрал вывод RA2 (канал AN2).
Никакой иной, дополнительной функциональности, кроме управления транзистором, он
иметь не должен.
В ПП START, настраиваю его на работу "на выход" (по ходу отработки программы, эта
настройка не изменяется), и все дела.
Все 5 каналов АЦП делаю активными (с "прицелом" на
будущее), так как в настройках, активность 4-х каналов
АЦП не предусмотрена (можно либо 3, либо 5).
В данном случае, то что канал AN2 активен, не в коем
разе не отразится на управлении транзистором, так как
после настройки вывода RA2 на работу "на выход",
вход канала AN2 не подключается к этому выводу.
Транзистор пока применять не буду, а вместо него
поставлю светодиод (см. рис. 1).
Так оно проще и нагляднее (имитация управления
транзистором), а транзистором озабочусь потом.
Но это так … "Мелочь пузатая", хотя и существенно.
Общая стратегия программы, в контексте "пороговых дел"
На рис. 2, Вы видите алгоритм
работы "новорожденной"
программы BP_2.asm.
В моем понимании.
Пока, я организовал два
"глобальных" сценария работы
программы: сценарий работы
с выключенной защитой и
сценарий работы с
включенной защитой.
Это и есть два основных
режима работы.

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

Во всех этих случаях,


имеются "закольцовки",
которые позволяют
длительное время
находиться в текущем
режиме.
А как же иначе?

2
На рис. 2, они показаны черными, зелеными и красными линиями.
Естественно, что для переключений основных режимов работы устройства, нужно
организовать однокнопочную клавиатуру, что и имеет место быть.
Кнопка называется "Переключение режимов".
Кроме того, оганизована энергонезависимая память режимов/порогов.
То есть, после включения питания, автоматически устанавливается именно тот режим и
именно те пороги, которые имели место быть на момент предыдущего выключения
питания.
В ПП START, производится чтение, из EEPROM-памяти данных ПИКа, "режимного"
байта, сохраненного в ней на момент предыдущего выключения питания.
В дальнейшем, по результату чтения "режимного" байта, будет осуществлен
программный переход в один из двух основных режимов (см. выше).
Далее, производится подготовка ЖК-модуля к дальнейшей работе (инициализация),
которая достаточно подробно "расписана" ранее.

После этого, производится предварительное разрешение прерываний по переполнению


TMR2.
То есть, делается все то, что необходимо для разрешения прерываний по
переполнению TMR2, кроме "глобального" разрешения прерываний".
Естественно, что после такого "кастрированного" разрешения, все прерывания, в том
числе и по переполнению TMR2, будут запрещены.
Вопрос: "Зачем это сделано"?
Ответ: в первую очередь, для дальнейшего, "программного удобства", ведь гораздо
сподручнее разрешить (запретить) прерывания по переполнению TMR2 с помощью
всего-лишь одной команды bsf IntCon,7 (bcf IntCon,7), чем возиться с бОльшим их
количеством.
Гнусный голос из-за кулис: "За что ранее пролита кровь? Как понимать предтарахтенье
по поводу максимального расширения зоны разрешения прерываний"?
Ответ: в нашем деле, и вообще в жизни, существует такое понятие, как
целесообразность.
Достойные гомо-сапиенсы его очень уважают и любят. Поэтому они и достойные.
А кто не имеет об этом понятия, то это его проблемы.
В ПП START, транзистор программно закрывается (зачем его, без особой на то
надобности, открывать?).
Это соответствует отключению нагрузки от блока питания.
Его нужно открывать только в "закольцовках" основных сценариев.
Если его нужно открывать только в "закольцовках" основных сценариев (а до них еще
далековато), и не ранее того (см. целесообразность), то какой смысл затягивать цикл
программы посредством преждевременных (бестолковых) уходов в прерывания,
результаты отработки которых будут востребованы значительно позднее?
Если же, в ПП START, открыть транзистор и разрешить прерывания, то из-за того, что
защита длительное время не будет работать, а нагрузка, в течение всего этого
времени, будет запитываться, может произойти "бяка". И совсем не слабая.
Вот Вам и весь "сермяжный" смысл.

Далее следует процедура опроса однокнопочной клавиатуры, на начало которой


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

1. Если кнопка отжата, то с целью ответа на вопрос: "Как дальше жить будем"? (в
какой "режимный" сценарий "уходить"), производится опрос текущего состояния
"режимного" байта.
"Режимный" байт содержит в себе информацию о текущем "режимном" сценарии.
Она находится в одном-разъединственном бите с №0.
3
Состояния остальны битов совсем не важны (пусть хоть "на голове стоят").
Вопрос: "Почему в одном-разъединственном и почему всем остальным можно стоять на
голове"?
Ответ: потому, что сценариев всего 2 и можно обойтись одним битом самого
младшего разряда (аналог триггера со счетным входом).
Ранее, эта "комбинация из двух пальцев", несколько раз проделывалась ("нудеть" не
буду).
Если бит №0 "режимного" байта = 0, то будет отработан сценарий работы с
выключенной защитой.
Если бит №0 "режимного" байта = 1, то будет отработан сценарий работы с
включенной защитой.

2. Если кнопка нажата, то это соответствует смене режима.


В целях обеспечения надежного переключения режимов, применена противодребезговая
задержка.
Пробовал и без нее. Сбоев не заметил (наверное кнопка качественная).
Но пусть лучше будет "противодребезг". Так оно на душе спокойнее.
Далее следует "плавающая" задержка, ориентированная на отжатие кнопки
(пережидание нажатия кнопки).
Если ее не будет, то в случае долговременного нажатия кнопки, будет наблюдаться
"чехарда" смены режимов по причине того, что будут последовательно отрабатываться
полные циклы программы.
Таким образом, можно "жать" кнопку хоть час. "Жизнь замрет", только и всего.
Смена режима происходит только после отжатия кнопки.
После этого, текущий режим сменится на другой, и уже "другой" режим будет текущим.
"Механика" смены режима проста: инкремент или декремент (без разницы) содержимого
"режимного" регистра, и все дела.
А раз уж произошла смена режима, то его "числовой эквивалент" нужно "шустренько
задокументировать" в соответствующей ячейке EEPROM-памяти данных ПИКа.
То есть, нужно произвести запись "режимного" байта в эту ячейку.
На случай типа, "а вдруг смертушка наступит" (выключение питания).
После этого, никакая "смертушка" (в пределах вида) не страшна (напоминаю про
детородные функции).
Что и имеет место быть.

Итак, выше была осуществлена "стратегическая прогулка", от начала исполнения


программы и до выхода рабочей точки программы из процедуры опроса клавиатуры.
На выходе этой процедуры à конкретное решение о выборе одного из двух
"режимных" сценариев дальнейшей работы устройства.
Этот выбор, изначально, зависит от состояния бита №0 "режимного" байта, считанного
из EEPROM-памяти данных ПИКа, а в дальнейшем, от факта/фактов нажатия кнопки
"Переключение режимов".
Таким образом, после включения питания, происходит автоматический выбор того
режима, который был установлен на момент предыдущего выключения питания
устройства.
Это можно назвать "режимной настройкой по умолчанию".
После того, как будет произведена эта настройка, пользователь, нажимая на кнопку
"Переключение режимов", может установить тот режим, который ему хочется.
Сразу же после отжатия кнопки "Переключение режимов", установленный
пользователем режим, становится текущим и записывается в EEPROM-память данных
ПИКа.

Предположим, что текущий режим работы благополучно выбран.


Теперь нужно "вгрызаться" в эти режимы ("раскручивать цепочку" далее).
Их два.
Нужно выбирать.
Самый простой - режим сценария работы с выключенной защитой или, проще говоря,
режим выключенной защиты.
В общем виде, это выглядит так:
4
Сразу возникает вопрос: "Как выключить защиту"?
По этому поводу, "нагородить" можно много всякого.
На мой взгляд, самое простое и эффективное решение - выставление максимальных
порогов защиты как по напряжению, так и по току.
А так как они максимальные, то и никогда не будут превышены.
Это просто, как звук "му", и логика железная.
"Пахнет детсадом", но и "гениальностью" тоже (см. колесо, гвоздь, бумеранг и т.п.).
В самом начале сценария, они (максимальные пороги) и выставляются.
Далее, замерять нужно, а иначе теряется смысл всей этой "свистопляски".
Измерение происходит в ПП прерывания.
Значит, нужно ее "посетить".
И желательно не один раз (для того чтобы результат измерения как следует
"устаканился").
Поэтому, прерывания разрешаются, и сразу же после этого начинается отработка
фиксированной задержки.
Она "играет роль добытчика" результатов измерения.
После окончания отработки фиксированной задержки, прерывания запрещаются (а
зачем, далее, они нужны? Чтобы "тормозить"?).
Таким образом, результаты измерения "добыты", после чего следует достаточно
стандартный, "набор", состоящий из процедур 2/10 преобразования, вывода на
индикацию "обслугонадписей" и вывода на индикацию результатов 2/10 преобразования.
Только этот "набор сдвоенный". В этом и заключается его немудреная специфика.
В конце сценария, транзистор открывается (светодиод "загорается"), и все дела.
Транзистор открывается только при первом вхождении рабочей точки программы в
сценарий выключенной (и включенной тоже) защиты, а далее, по мере "мотания
витков" полного цикла сценария выключенной защиты, открытие транзистора
периодически подтверждается.
Полный цикл сценария выключенной защиты организован путем программной
"закольцовки" на начало опроса клавиатуры (см. рис. 2).
Это позволяет постоянно отслеживать состояние кнопки "Переключение режимов".
То есть, если во время отработки сценария выключенной защиты, нажать/отжать
кнопку, то произойдет смена режима, и рабочая точка программы "улетит", из цикла
сценария выключенной защиты, в цикл сценария включенной защиты, в котором и
благополучно "закольцуется" (до следующего нажатия/отжатия кнопки).
Вот такая получается "петрушка".

5
Если кто-то из Вас скажет, что это стратегически сложно, то я "уйду в монастырь".
Далее, нужно разобраться с режимом включенной защиты.
По здравому разумению, проверка превышения/не превышения порогов должна
производиться сразу же после измерения, то есть, в ПП прерывания.
Ее можно произвести и в "основном теле" программы, но в этом случае, о малой
инерционности отклика защиты на "бяку" можно даже и не мечтать (догадайтесь,
почему?).
Сама по себе, проверка ровным счетом ничего не значит (ну проверили, а дальше?).
Следовательно, по результату этой проверки, в той же ПП прерывания, быстренько
должен/обязан быть выработан некий признак (критерий) превышения/не превышения
порога защиты, на который можно было бы ориентироваться при отработке сценария
включенной защиты (отрабатывается в "основном теле" программы).
А иначе, получится "ежик в тумане и полнейшее бардальеро", с тяжелейшими
последствиями.
По бестолковке, в "реанимацию" как-то не хочется попадать.
Кстати, я там был. Один раз реально и несколько раз "виртуально".
Впечатление: хуже только в преисподней.
Вывод: преде чем разбираться со сценарием включенной защиты, нужно разобраться с
ПП прерывания:

За основу взят принцип отработки ПП прерывания программы BP_1.asm.


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

6
Зачем замерять ток, если от блока питания отключена нагрузка (это и имеет место
быть)?
Теперь о процедуре приведения 2-байтного результата измерения к 1-байтному.
Вопрос: "Зачем приводить 2-байтный результат измерения (результат измерения
является 2-байтным) к 1-байтному"?
Ответ: затем, что вычесть однобайтное число из однобайтного, гораздо проще и
"скоростнее", чем вычесть 2-байтное число из 2-байтного.
Что касается "проще", то, как говорится, черт с ним. Можно и "сложно".
Свободного места в памяти программ - "выше крыши".
Не это главное.
В данном случае, главное - скорость, ведь речь идет о ПП прерывания, от времени
отработки которой напрямую зависит инерционность защиты.
Поэтому, в ПП прерывания, каждый машинный цикл "на вес золота".
Главный интерес и заключается в том, чтобы добиться как можно более высокой
скорости отработки ПП прерывания.
А если в нее "засунуть" процедуру вычитания 2-байтного числа из 2-байтного (хоть в
каком виде), то в смысле скорости, будет большой конфуз и недоразумение.
Я "извернулся" путем приведения 2-байтных чисел к однобайтным.
С учетом того, что используется 10-разрядное АЦП, результат АЦП нужно просто
разделить на 4 путем организации двух сдвигов 2-байтного числа вправо.
Это гораздо проще и скоростнее, чем "лежащий на поверхности, 2-байтный геморрой".
И в смысле делимого, и в смысле делителя, и в смысле результата, и в смысле
процедуры, обеспечивающей оное.
Правда за это "счастье" нужно "расплатиться" снижением порогового разрешения
(с 1 градации до 4-х), но это вполне приемлемо.
4 градации будет в самый раз.
БОльшего порогового разрешения, в принципе, и не нужно.
Обращаю Ваше внимание на то, что это никоим образом не относится к результату
измерения (выводится на индикацию без деления. Такой, какой есть).
Он как был 2-байтным, 10-разрядным, так таким и останется.
Речь идет о задании порогов.
То есть, в данном случае, шагом порога будет не одна квантовка, а четыре.
Например, при измерении напряжения в диапазоне от 0 до 99,9 вольта, максимальная
"пороговая" погрешность будет составлять 0,4 вольта, а при измерении напряжения в
диапазоне от 0 до 49,9 вольта, максимальная "пороговая" погрешность будет
составлять всего 0,2 вольта, и т.д.
Таким образом, в диапазоне квантовок от 0 до 999, можно задать одну из 249-ти
градаций порогов защиты (и по U, и по I), что вполне прилично и приемлемо.
Однобайтный результат деления на 4 сохраняется в регистре общего назначения,
который используется и в дальнейшей проверке превышения (или нет) порога защиты
по напряжению, и в процедуре вычисления величины превышения порога защиты по
напряжению аварийного подрежима ("дислоцируется" в "основном теле" программы).
После приведения 2-байтного результата измерения к 1-байтному, производится
проверка превышения (или нет) порога защиты по напряжению.
С учетом реализации сказанного, она очень проста и отрабатывается быстро.
На выходе из этой проверки, организованный под это дело, флаг превышения порога
защиты по напряжению либо опускается (порог не превышен), либо поднимается (порог
превышен).
В последнем случае, срабатывает защита.
То есть, транзистор закрывается (светодиод "гаснет").
А так как, в рабочем подрежиме сценария включенной защиты, измерения
производятся постоянно и через каждые 250 мкс. (в этом подрежиме прерывания
постоянно разрешены), то максимальная инерционность срабатывания защиты, в
течение всего времени отработки рабочего подрежима, не будет хуже 250 мкс.
В дальнейшем, этот показатель можно улучшить.
В части касающейся влияния на инерционность срабатывания защиты, все "дела,
вершащиеся" в "основном теле" программы, в течение всего времени отработки
рабочего подрежима сценария включенной защиты - "по барабану", так как эти "дела"
никак не влияют на период ухода в прерывания.
7
В частности, именно этим прерывания и хороши.
Так бы их и расцеловал. Если бы была возможность.
При всем этом "прерывательноскоростном великолепии", "основное тело может ползти
как черепаха".
По "микросекундным меркам", это "черепаха" и даже "улитка", а по "житейским
меркам", это "курьерский поезд".
Даже "тормозить" его приходится. Так как слишком "прыткий".
А теперь, после этих слов, оцените красоту/ляпоту стратегического замысла ("и волки
сыты, и овцы целы").

Режим включенной защиты

Рабочий подрежим режима включенной защиты

Если включен режим защиты, то рабочая точка программы входит в рабочий подрежим
этого режима.
А если она войдет в него из режима выключенной защиты?
Будет конфуз, так как установлены максимальные пороги.
Значит, нужно "идти" в EEPROM-память данных ПИКа и считывать из нее те значения
порогов, которые в ней хранятся.
Что и имеет место быть.
Примечание: на время отработки процедуры записи в EEPROM-память данных ПИКа,
прерывания должны быть запрещены.
После этого, можно смело входить в циклическую ПП слежения, что тоже имеет место
быть.
Первым делом, нужно разрешить прерывания.
А как же иначе?
Прерывания нужно разрешить на все время отработки этого цикла (это и есть), а
иначе, все мое предыдущее "тарахтенье", по поводу минимальной инерционности
защиты, "и гроша ломаного не стоит".
После разрешения прерываний, следует фиксированная задержка.
Она обеспечивает заданную скорость смены показаний.
Именно во время ее отработки происходит бОльшая часть уходов в прерывания.

8
Далее следует проверка на превышение порогов.
Вернее, сами эти проверки (по U и по I) производятся в ПП прерывания, а в
"проверке на превышение порогов", анализируются только состояния соответствующих
флагов, которые "жестко привязаны" к результатам этих проверок.
Стратегия работы процедуры проверки превышения порогов будет "расписана" ниже, а
пока предполагаю, что превышений порогов защиты не обнаружено.
В этом случае, можно вывести на индикацию результаты измерения напряжения и
тока, а также и сопровождающие их надписи.
Поэтому, сначала отрабатывается "сдвоенная" ПП 2/10 преобразования, после чего,
результаты ее отработки выводятся на индикацию во 2-ю строку ЖК-модуля.
При этом, они "укомплектовываются" соответствующими надписями.
Теперь, для того чтобы "из поля зрения не выпадала" кнопка "Переключение
режимов" (если "выпадет", то нельзя будет переключить режим), необходимо опросить
состояние этой кнопки.
Если она отжата, то эта проверка просто "проскакивается транзитом".
Если она нажата, то происходит переход на начало ПП опроса клавиатуры, а затем
(после отжатия) и переход в режим выключенной защиты.
Предположим, что эта проверка "проскочена"/"проскокнута"/"про… (о великий и могучий
русский язык!).
После этого, транзистор открывается, и нагрузка подключается к блоку питания.
Далее, "при наличии отсутствия бяк", открытие транзистора будет периодически
подтверждаться.
Но если "вражина поднимет голову выше установленной планки хотя бы на
миллиметр", то в процессе первой же отработки ПП прерывания, нагрузка будет
"сверхоперативненько" отключена от блока питания.
Еще раз обращаю внимание на то, что включение транзистора происходит в самом
конце цикла.
Это означает, что после включения блока питания с ранее установленным Uвых.,
которое превышает порог защиты по напряжению, транзистор будет гарантированно
закрыт (на выходе БП будет "полный штиль". Даже наносекундного "всплеска" не
будет), так как рабочая точка программы "железобетонно закольцуется" в аварийном
цикле (большущий "недолет").
Причем, в течение всего времени отработки аварийного подрежима, на индикацию, в
динамике, будет выведен числовой результат превышения порога по напряжению.
После этого, нужно просто покрутить регулятор напряжения блока питания ("глядучи"
на дисплей. На нем отображается все необходимое) и добиться тем самым перехода
(производится автоматически) в рабочий подрежим.
При этом, нагрузка автоматически подключится к выходу блока питания.
И не нужно делать никаких лишних "телодвижений".
Естественно, что это относится к режиму включенной защиты.
В режиме выключенной защиты, такого нет, что вполне естественно.

Аварийный подрежим режима включенной защиты

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


цикле рабочего подрежима.
Для того чтобы обеспечить выход из аварийного цикла с разрешенными прерываниями,
в начале аварийного цикла, они разрешаются.
Хотя, далее, они и запрещаются (см. рис. 5), но в "зону" разрешения прерываний
попадает небольшая группа команд анализа состояний флагов срабатывания/не
срабатывания защиты, а также и команда возврата из аварийного подрежима в
рабочий подрежим.
Эти команды обеспечивают малый цикл (несколько м.ц.) проверки на превышение
порогов.
Он отрабатывается в том случае, если "бяк" нет (оба флага опущены), причем, "с
реактивным свистом".
Примечание: ради этого и затеян соответствующий, "флаговый сыр-бор" в ПП
прерывания.

9
Но как только появляется "бяка" (обнаружено поднятие какого-нибудь из флагов), так
рабочая точка программы "отфутболивается" в большой цикл проверки на превышение
порогов.
А проще говоря, полномасштабно начинает отрабатываться весь аварийный цикл.
В ходе его отработки, хоть как-то воздействовать на состояние транзистора не нужно.
Ведь "бяка" же в наличии! Зачем воздействовать?
Вот не будет "бяки", так сразу же и "милости просим".
Только не в аварийный, а в рабочий подрежим.
После "закольцовки" в аварийном цикле, можно/нужно сделать что-нибудь полезное.
Например, вычислить величину превышения порога и вывести на индикацию результат
этого вычисления. Причем, в динамике.
Что и имеет место быть.
Для обеспечения "добывания" результатов измерения и приемлемой скорости смены
показаний (в комплексе), в "зону" разрешения прерываний "врезана" фиксированная
задержка.
После ее отработки, прерывания запрещаются.
А зачем, далее, их разрешать, ведь защита сработала.
Если устранить "бяку" и соответственно, автоматически вернуться в рабочий подрежим,
то прерывания, также автоматически, будут разрешены.
Причем, заранее ("зер гут"!).
Далее, следует, уже ставшее надоедливым, "индикаторное на колу мочало".
Только надпись другая и отображается результат специфической функциональности
(превышение порогов). Третий раз повторять не буду.
После завершения "индикаторных дел" à "закольцовка" на начало аварийного
подрежима, и все повторяется снова. До устранения "бяки".
Как только "бяка" будет устранена, оба флага срабатывания/не срабатывания защиты
будут опущены, что есть "свисток", по которому происходит переход в рабочий
подрежим.
Вот и вся текущая "свистопляска".
"Глобальный" вывод: прежде чем "падать" на текст программы, нужно как следует (с
пристрастием) отработать ее стратегию на уровне блок-схем и всяческих, умных
мыслей/рассуждений.
И юмор в этом деле очень помогает.
Ну и знания/опыт совсем не помешают.
А если трагически воспринимать свои неудачи (без
них, в нашем деле, никак не обойдешься), то и
будет неудачник-"комплексер".
Кнопку "Переключение режимов" нужно подключить
так, как показано на картине слева.
Пока, я ограничился той функциональностью, о
которой рассказал.
И это "только цветочки, ягодки будут впереди". Всему свое время.
Не исключено, что что-то "подрихтую", если в этом есть здравый смысл.
А пока, для того чтобы Вы четко представили себе, что речь идет не о "толчении
воды в ступе", а о вполне конкретной "железяке", посмотрите на это:

10
Кстати, сия "железяка" работает очень даже прилично.
Критерий - радость души.
Не знаю у кого как, а у меня, радость души есть объективно/субъективный признак
качества проделанной работы.
Пока замеряю количество "далеких от жизни" квантовок.
В дальнейшем, доберусь и до "приближенного к жизни".
В следующем подразделе, в полном соответствии с тем, что я называю
"методологией", будут неизбежные "разборки" с программой, составленной под
сказанное/показанное выше.

"Практикум по конструированию устройств на PIC контроллерах"      http://ikarab.narod.ru       E-mail: karabea@lipetsk.ru

11