Проблемные моменты в организации программного обеспечения при воздействии мощных помех.
Обусловлены возможными отклонениями в устойчивости отдельных ячеек ОЗУ к внешним электромагнитным помехам «при некотором стечении обстоятельств» когда уровень воздействия недостаточен для обработки аппаратными системами POR и/или BOD.
Для АВР наличие программно-управляемого предделителя тактовой частоты (не биты конфигурации, а содержимое CLKPR ! ) единственно радость – наличие автоустановки их содержимого при аппаратном сбросе ( он же сброс по POR ).
Для МК имеющих конвеер предвыборки команд – собственно сам конвеер.
Для МК имеющих режим обмена с портами (для определенной части команд) основанный на системе «чтение-модификация-запись» необходимость применения страховочной загрузки защелок константой в соответствии с текущими требованиями программы.
Причем у PICов и у MCS51 под таковым режимом подразумеваются достаточно серьёзно отличающиеся процедуры:
У PIC чтение выводов - модификация в АЛУ – запись в защелки
У MCS51 чтение защелок - модификация в АЛУ – запись в защелки
Посему необходимо особо внимательно отнестись к проработке процедуры ввода/вывода в порты с «совмещенными» режимами ввода и вывода на разных выводах у одного и того же порта.
Наиболее развитая система управления портами ввода/вывода имеется у АВР… Однако…
У всех МК имеются регистры направления портов – а они также могут быть подвержены «потере памяти» как и любой из регистров ОЗУ.
Следующее место преткновения – использование сколь-нибудь «долгохранящейся» информации в регистрах ОЗУ.
Поскольку никоим образом нельзя обойти хотя - бы программно организованный «длинный таймер» на двух-трех регистрах ОЗУ. Да и система фильтр - контроля входного сигнала также требует или весьма значительного места в ПЗУ или наличия регистра – накопителя промежуточного результата. От применения прерываний и подпрограмм использующих стек а также аппаратных средств основанных на конфигурации с помощью программно – загружаемых регистров конфигурации (тех же аппаратных таймеров) на участках программы, где предполагается воздействие помехи, предпочтительно вообще отказаться.
Участки анализа событий предпочтительно оформлять в виде древовидной структуры с фиксированными переходами вида GOTO/JMP (при соответствующей потере объёма памяти программ) а часто повторяемые фрагменты описывать макросами. Использование флагов пользователя, создаваемых программой, запрещено (опасность сбоя ячеек ОЗУ при «относительно длительном хранении»).
Вобщем…
Основываясь на вышеуказанном был нашкарябан следующий алгоритм обработчика условного объекта «газовая зажигалка»:
http://img.radiokot.ru/files/20529/zmdkhfmor.GIFОсновное допущение алгоритма – при обнаружении внешнего воздействия на выводе датчика ионной проводимости выполняем отключение искрогенератора и проводим контрольный замер на стабильность показаний с интервалом нечувствительности на время «бороды» из более низкоуровневых выбросов, следующих за началом импульса разряда.
Хотя… Данный алгоритм более из области «теоретизирования» - за отсутствием возможности реальной проверки результатов на макете.
Содержимое макроса таймера обработчика интервала контроля поджига таково, что по исчерпании таймера (в каком бы участке исполняемой программы он не находился) вызовет выход на участок полного останова работы, сохраняемый до снятия напряжения питания. Начальные участки настроек/инициализации и система индикации аварийных ситуаций на графике алгоритма не указаны, также как и детализация макросов аппаратно зависимых от типа применяемого семейства МК.