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

2-1/10.

"Разборки" с инициализацией графического модуля (с целью


обеспечения "безглючной" инициализации, осуществляемой по 3-му варианту).
Флаги статуса графического модуля и работа с ними
(чтение-анализ-"оргвыводы").

Начну с творческого наследия Михаила Задорного (бъет не в бровь, а в глаз. Талант).


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

По ходу работы, была замечена одна пренеприятнейшая "бяка", связанная с


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

1
А с третьей стороны, импульсы "дребезга", попавшие в "зону" неустойчивой работы
графического модуля (в "зону" его "агонии". По Uпит.), вполне могут привести, и
реально приводят, к "глюку" инициализации.
Особенно с учетом того, что по 3-му варианту инициализации, который имеет место
быть, вывод RES постоянно соединен с +Uпит.
Вероятнее всего, речь идет о комплексном, негативном воздействии, на процесс
инициализации, "смеси из двух бяк": низкой скорости нарастания Uпит. (а у меня
именно такой БП. С электролитами по 20 000 мкф.) и "пачки дребезга", которой
сопровождается каждое включение питания.
Чем медленнее скорость нарастания Uпит., тем большее количество импульсов
"дребезга" попадает в "зону" неустойчивой работы графического модуля.
В зависимости от степени разряда электролитов блока питания (на момент включения
питания), текущая "пачка дребезга", на оси напряжений (в диапазоне от 0 до 5 вольт),
может занимать различные положения.
Если питание включается после глубокого разряда электролитов БП, то создается
самая неблагоприятная ситуация (вероятность "глюка" инициализации графического
модуля максимальна).
Само по себе, наличие серии импульсов на выводе RES не есть причина
"катастрофы", так как они "воспринимаются" графическим модулем как серия
последовательных, внешних сбросов.
"Катастрофа" наступает тогда, когда интервалы времени между этими сбросами
становятся меньше какой-то величины.
Какой?
В рабочем состоянии, это 8 мкс., но с полной уверенностью можно сказать, что при
значениях Uпит., меньших, чем 5 вольт, это значение будет превышать 8 мкс.
Чем меньше Uпит., тем это превышение будет блее значительным.
Вот и получается, что на начальной стадии заряда глубоко разряженных электролитов
блока питания (прежде всего это относится к электролиту, подключенному к выходу
стабилизатора БП), по совокупности указанных выше причин, создаются самые
благоприятные условия для "глюка" инициализации.
Если "клацанье тумблером" происходит тогда, когда электролиты БП не полностью
разряжены, то вероятность "глюка" инициализации гораздо меньше.
А правее "зоны" неустойчивой работы графического модуля, эта вероятность резко
снижается.
"Зона" неустойчивой работы графического модуля - понятие достаточно "скользкое", но
лучше "привязаться" хоть к какому-то более-менее понятному критерию, чем вообще
его не иметь.
Изложенная выше "концепция", на мой взгляд, достаточно внятно объясняет те факты,
которые имеют место быть.
Откуда взялась эта самая "пачка дребезга"?
Электролиты (электролитические конденсаторы) это такая "хитрая штуковина", которая
хорошо "гладит" на низкой частоте, но просто отвратительно "гладит" на высокой.
После включения блока питания, имеет место быть "пачка дребезга", высокочастотные
составляющие спектра которого не "давятся" электролитами.
А графический модуль-то совсем не "заторможен". "Шустёр", каналья.
Таким образом, по высокой частоте, наблюдается форменное безобразие.
И "судиться" бесполезно. "Такими их мать родила".
Именно по этой причине, цепи питания устройств желательно блокировать
конденсаторами (не электролитическими).
Лучше всего высококачественными. Например, КМ (бедные КМ. "Драгметальщики" житья
им не дают).
Это может "сработать"?
Может. Частично.
Но в "глобальном" смысле, это не есть решение вопроса.
В некоторых случаях, "такой номер может пройти", а в некоторых случаях - нет.
Почему?
В основном потому, что спектры "пачек дребезга" могут быть совершенно
разнообразными, и по этой причине, нельзя гарантировать полное отсутствие "бяк", о
которых идет речь.
2
В данном случае, по большому счету, такой способ решения проблемы есть халтура.
Вывод: блокировочные конденсаторы, конечно же, можно и нужно использовать, но
"собака глобально порылась" совсем в другом.
Может возникнуть версия о том, что подобного рода "глюк" может возникнуть за счет
ПИКа (программа начинает отрабатываться до того, как графический модуль переходит
в "рабочее" состояние), но эта версия не верна.
Хотя бы по той причине, что включен PWRT (а это задержка аж в 72 мс.), плюс, 1024
такта OSC.
Этот интервал времени с запасом "перекрывает" практически любой интервал времени
нарастания Uпит. (с расчетом на это и "ваялось"), за исключением "маразматических"
случаев, когда, при прочих, равных условиях, в блоке питания, применяется уж очень
"слабосильный" (по току) силовой трансформатор или на регулирующем транзисторе
стабилизатора падает какое-то "совершенно могучее" напряжение (он сильно
призакрыт).
Такого нет. В моем БП стоит такой мощный и увесистый "транс", что им убить можно,
а падение напряжения на регулирующем транзисторе - порядка 8...10 вольт.
Вывод: "ПИКовая составляющая" отпадает.
Ответственно это заявляю, так как это не голые слова, а утверждение,
"программножелезячно" проверенное "засылкой на территорию врага разнообразнейших
шпионов" (просто не хочется Вас этим "КГБизмом" утомлять).
Итак, "корень текущего зла" находится в графическом модуле.
Возникает закономерный вопрос: "Как бороться с этим бунтом"?
Думы по поводу кардинального решения этой проблемы, неизбежно "упираются" в
необходимость реализации общеизвестного принципа "пережидания пачки дребезга".
Это означает то, что питание на графический модуль должно быть подано с задержкой
(относительно момента времени включения БП), величина которой обеспечивает это
"пережидание".
Такую задержку выгодно сделать как можно большей, но ее величина не должна
превышать 72 мс. (время задержки PWRT), плюс 1024 такта OSC, плюс время
отработки первых команд ПП START (тех, которые исполняются до начала процедуры
инициализации графического модуля), а иначе программная инициализация начнется до
того, как графический модуль будет к ней готов ("глюк").
Естественно, что в этом случае, PWRT нужно включить.
Есть два приемлемых варианта реализации этого принципа.
1. Вариант включения Uпит. графического модуля при помощи времязадающей
RC-цепочки.
2. Вариант включения Uпит. графического модуля при помощи ПИКа.

1. Вариант включения Uпит. графического модуля при помощи времязадающей


RC-цепочки.

В этом случае, дополнительный вывод порта не задействуется.


В простейшем случае, в качестве коммутатора Uпит., можно применить транзистор.
Принципиальную схему этого "наворота" Вы видите на
рисунке слева.
Проще всего коммутировать "корпус" (GND), что и имеет
место быть (вывод 2 графического модуля и есть GND).
Примечание: типовое значение тока, потребляемого
графическим модулем, равно 4 ма.
Эта "штуковина" работает так.
После включения питания, конденсатор начнет заряжаться
через резистор.
Напряжение на базу транзистора подается через кремниевый диод (можно поставить
любой кремниевый диод).
Кремниевый диод начинает "пропускать через себя" ток только при приложенном к
нему напряжении величиной около 0,7 (в среднем) вольт и выше.
Примечание: для германиевых диодов, этот "порог" = 0,3 вольта (в среднем).

3
То есть, проще говоря, до тех пор, пока напряжение на конденсаторе не достигнет 0,7
вольт, транзистор будет гарантированно закрыт и тот "дребезг", который имел место
быть "до того", будет полностью блокирован за счет того, что графический модуль
просто не запитывается ("корпус" не подключен).
После того, как диод начнет проводить ток (U на конденсаторе более 0,7 вольт),
уровень напряжения на базе транзистора, по мере заряда конденсатора, будет
нарастать до тех пор, пока он не перейдет из режима линейного усиления в ключевой
режим (полное открытие. Падение напряжения на участке "коллектор-эмиттер" порядка
0,12…0,14 вольт. Зависит от конкретного транзистора).
Естественно, что параметры времязадающей цепочки можно изменить.
Но у этого способа коммутации Uпит. есть недостаток: уровень Uпит. плавно
нарастает, а не коммутируется "резким скачком".
Причем, время этого "плавного нарастания" зависит от коэффициента усиления
транзистора по току.
В принципе, если подобрать транзистор с коэффициентом усиления по току от 300…
400 и выше, то можно достигнуть хорошего результата, но ведь это "геморрой".
К тому же, при любом "раскладе", положа руку на сердце, нужно признать, что сие не
есть кардинальное решение проблемы.
В идеале, Uпит. должно коммутироваться "резким, бездребезговым скачком", а
транзисторы, даже с самым большим коэффициентом усиления по току, это дело
качественно "не потянут".
Это дело качественно "потянут" либо триггер Шмидта, собранный на элементах
аналоговой техники, либо м/схема аналогового компаратора, либо цифровая м/схема, в
состав которой входит тот же триггер Шмидта.
Но в любом из этих случаев, имеет место быть усложнение принципиальной схемы,
что, как Вы сами понимаете, вовсе не есть "зер гут".
Кроме того, нужно "заморачиваться" оптимальным подбором номиналов элементов
времязадающей RC-цепочки.
Причем, "на глазок" (опытным путем), так как в этом случае, точно проконтролировать
временные параметры проблематично.
Да и "гулять" они будут.
Не знаю кому как, но лично меня это как-то не прельщает.
Хочется иного "счастья". "Счастья, не омраченного геморроем".
Примечание: я не хаю этот способ. Просто он мне не нравится своей "аналоговостью"
(сердцу не прикажешь).

2. Вариант включения Uпит. графического модуля при помощи ПИКа.

То есть, транзистором управляет ПИК.


Только вот "загвоздка" в том, что на стадии отработки задержки PWRT, а заодно и
1024-х тактов OSC, ПИК не в состоянии ничем "разумно" управлять ("смертельный
номер"!).
Проще говоря, пока ПИК "занимается своей инициализацией, его лучше не беспокоить".
В имеющейся у меня документации, я не нашел даже и полунамека на динамику
состояний выводов портов, которая имеет место быть в процессе "свершения этого
интимного таинства".
Короче, "человек не в себе" (вообще "неадекватен").
А раз это так, то и нечего "нарываться на грубость".
Что мы, нехристи что-ли? Соображение нужно иметь…
Пусть "оклемается" и "примет человеческий облик". Вот тогда и поговорим.
Вопрос: "А каков должен быть предмет разговора"?
Вопрос конечно интересный.
Если подключить "вышележащий" транзистор к какому-нибудь свободному выводу порта,
то по окончании инициализации ПИКа, на момент начала исполнения программы, в
конечном итоге, транзистор будет закрыт, так как, в результате инициализации ПИКа
(по умолчанию) все порты будут работать "на вход".
Это означает то, что база транзистора будет, образно выражаясь, "висеть в воздухе",
и соответственно, напряжение на базе будет равно нулю (или очень близко к нему).
Вот Вам и обоснование того, что транзистор будет закрыт.
4
Остается только (в ПП START) перестроиться на работу "на выход" (после этого,
транзистор все-равно будет закрыт нулем, имеющим место быть, по умолчанию, на
выходе соответствующей защелки порта), а затем программно "выставить" единицу на
том выводе порта, который управляет транзистором ("скачкообразная и бездребезговая"
подача питания на графический модуль), и все дела!
С учетом того что есть, это всего одна дополнительная команда.
При таком "раскладе", и время нарастания Uпит., и "пачка дребезга" - "по барабану"
("дела давно минувших дней").
И еще получается то, что надежно зафиксировавшееся Uпит., подается на графический
модуль строго перед началом "боевых действий" (непосредственно, перед началом
исполнения программной процедуры инициализации графического модуля).
По-моему, в случае использования 3-го варианта инициализации, это наилучший, по
качеству, вариант подачи Uпит. на графический модуль.
Его "цена" - один вывод порта, один транзистор, один резистор и одна
дополнительная команда.
В "железе", это выглядит так:

В светло-желтом секторе показан вариант включения Uпит. графического модуля при


помощи времязадающей RC-цепочки.
В данном случае, для управления транзистором, задействован вывод RB6, но можно
назначить и другой.
Что касается соединения вывода R/W с выводом порта RB7, то речь об этом пойдет
ниже.
А пока, имейте сказанное ввиду. В конце подраздела "соберу все до кучи".

Работа с битами статуса


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

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

Таблица 1. Инструкции, используемые при чтении данных.


Инструкции Ao R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 Описание команды
Read Чтение текущего байта данных из
Data from 1 1 Байт данных, который считывается из ОЗУ выбранного столбца активной
RAM графического модуля страницы.
В конце чтения – автоинкремент.
ON/OFF
BUSY

RESET

Чтение статуса состояния:


1 модуль не готов к
BUSY работе с М/К
Status 0 1 0 0 0 0 0 0 модуль готов к работе с
М/К
Read
ON/OFF 1 ЖКИ выключен
0 ЖКИ включен
RESET 1 состояние сброса
0 рабочее состояние

"За компанию" с текущей "нужностью", имеет место быть инструкция чтения байта
данных Read Data from Ram.
Пока не обращайте на нее внимания (всему свое время).
Сейчас нужно обратить внимание на инструкцию Status Read (чтение битов/флагов
статуса или чтение статуса состояния).
Имеется 3 флага (бита) статуса.

1. Флаг RESET сбрасывается в 0 в случае успешного сброса аппаратной "начинки"


графического модуля (с этого сброса начинается его инициализация).
2. Флаг ON/OFF сбрасывается в 0 в случае успешной отработки инструкции
Display ON (включение дисплея).
3. Флаг BUSY сбрасывается в 0 в случае успешной отработки любой текущей
инструкции.

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

6
Если "обратить орлиный взор" на все то, что не связано с процедурой инициализации
графического модуля (на остальную часть программы), то возникает вполне
закономерный, простой вопрос: "А зачем вообще нужна проверка состояния флага
BUSY, с дальнейшим результатом ее анализа и соответствующими оргвыводами"?
И в самом деле, интервал времени отработки полного цикла вывода байта данных на
индикацию, в разы превышает интервал времени, необходимый для завершения
"всяческих аппаратных дел", инициируемых текущим стробом.
Это означает то, что текущая, аппаратная процедура, инициируемая предыдущим
стробом, гарантированно будет отработана до момента "прохождения" последующего
строба.
Проще говоря, реально отрабатываемая, программная задержка (ее можно считать
фиксированной), гораздо больше той задержки, которая требуется.
Конечно же, даже и в этом случае, теоретически, существует вероятность аппаратного
"глюка" при выводе на индикацию текущего байта данных, но реально, она на столько
мала, что просто не имеет смысла довольно-таки существенно "затягивать" время
полного цикла вывода байта данных на индикацию, а соответственно и делать всю
процедуру вывода байтов данных на индикацию "тормозной".
Она и без этого "довеска" достаточно "тормозная".
Вывод: я не утверждаю, что работа с флагом BUSY вредна (совсем наоборот!), но на
достаточно низких скоростях работы тактового генератора ПИКа (как в данном случае),
при организации программной процедуры вывода байтов данных на индикацию, работа
с флагом BUSY, на мой взгляд, нецелесообразна (больше потеряешь, чем выиграешь).
Она может быть целесообразна на высоких скоростях работы тактового генератора
ПИКа (например, при F кв.= 20 Мгц.), при условии, что объем памяти программ
применяемого ПИКа позволяет эту "роскошь".
Короче, рад бы применить, да здравый смысл взбунтовался.
Так и порешим.
Итак, остается только процедура инициализации.
А вот это уже другое дело.
Она исполняется только на 1-м "витке" полного цикла программы, и поэтому вполне
можно позволить себе "затянуть" этот цикл работой со всеми тремя флагами статуса.
В этом случае, больше выиграешь, чем потеряешь. Однозначно.
Это выглядит так:
............................
............................
;********************************************************************************
; НАЧАЛО ПРОГРАММЫ.
;********************************************************************************
; Подготовительные операции.
;================================================================================
START bsf Status,RP0 ; Переход в 1-й банк.
clrf TrisB ; Все выводы портов В и С
clrf TrisC ; работают на выход.
bcf Status,RP0 ; Переход в 0-й банк.

bsf PortB,6 ; Включение питания графического модуля.


bcf PortB,A0 ; Подготовка к исполнению команд.
bsf PortB,E1 ; Включение обеих
bsf PortB,E2 ; кристаллов.
;================================================================================
; Инициализация графического модуля.
;================================================================================
movlw b'00111110' ; Инструкция "Display OFF"
movwf PortC ; (выключение дисплея).
call STROB ; Строб ("запуск в работу").
;---> Возврат по стеку из ПП STROB
movlw b'00111111' ; Инструкция "Display ON"
movwf PortC ; (включение дисплея).
call STROB ; Строб ("запуск в работу").
;---> Возврат по стеку из ПП STROB
;-----------------------------------------
; Подготовка к чтению статуса состояния.
7
;-----------------------------------------
bsf Status,RP0 ; Переход в 1-й банк.
movlw b'11111111' ; Все выводы порта С
movwf TrisC ; работают на вход.
bcf Status,RP0 ; Переход в 0-й банк.

bsf PortB,R_W ; Установка режима чтения (R/W=1).


NO_INIT call STROB ; Строб ("запуск в работу инструкции
; "Status Read"").
;---> Возврат по стеку из ПП STROB
;----------------------------------------------
; Анализ состояний флагов ON/OFF, BUSY и RESET.
;----------------------------------------------
nop ; "Перестраховочная" задержка в 1 м.ц.
btfsc PortC,5 ; Флаг ON/OFF поднят (1) или опущен (0) ?
goto NO_INIT ; Если ON/OFF=1 (ЖКИ не включился),
; то состояние ON/OFF опрашивается еще раз.
; Если ON/OFF=0 (ЖКИ включился),
; то переход на анализ состояния флага BUSY.
btfsc PortC,7 ; Флаг BUSY поднят (1) или опущен (0) ?
goto NO_INIT ; Если BUSY=1 (модуль не готов к работе с
; М/К),то состояние BUSY опрашивается еще раз
; Если BUSY=0 (модуль готов к работе с М/К),
; то переход на анализ состояния флага RESET.
btfsc PortC,4 ; Флаг RESET поднят (1) или опущен (0) ?
goto START ; Если RESET=1 (сброс не было), то переход
; на начало исполнения программы.
; Если RESET=0 (сброс был), то программа
; исполняется далее.
;-----------------------------------------
; Подготовка к работе в режиме записи.
;-----------------------------------------
bsf Status,RP0 ; Переход в 1-й банк.
clrf TrisC ; Все выводы порта С работают на выход.
bcf Status,RP0 ; Переход в 0-й банк.
bcf PortB,R_W ; Установка режима записи (R/W=0).
call STROB ; Строб ("запуск в работу").
;---> Возврат по стеку из ПП STROB
;-------------------------------------
; Установка 1-й (самой верхней) строки
; обеих кристаллов (адрес 00h).
;-------------------------------------
............................
............................
Так как, на момент начала исполнения ПП START и вплоть до окончания смены
направлений работы выводов портов, питание графического модуля выключено, то его
нужно включить (bsf PortB,6).
В комплексе с транзистором, это обеспечивает подачу Uпит., на графический модуль, в
то время, когда значение Uпит. установилось и зафиксировалось на уровне 5 вольт, а
"пачка дребезга" исполнила свою "гнусную функцию" в совершенно "безобидном месте"
(там, где отрабатывалась задержка PWRT).
Не правда ли, как просто!
Это и есть итог "вышележащих словоблудий" (в части касающейся включения Uпит.
графического модуля).
Не смотря на то, что по умолчанию, на выводе Ao устанавливается 0, я посчитал
целесообразным программно подтвердить этот 0 командой (bcf PortB,A0).
Причина - "суперважняк".
После этой "перестраховки", как-то на душе спокойнее. Хуже не будет, а в случае чего
- поможет.
Перехожу к работе с флагами статуса.
Естественно, что этими "делами" нужно заниматься после отработки инструкций
Displau OFF и Display ON, что и имеет место быть.

8
Сначала, стандартно перестраиваются направления работы выводов порта С (с работы
"на выход", на работу "на вход").
Далее нужно озаботиться обеспечением условий выполнения инструкции Status Read
(см. таблицу 1).
Ao = 0 устанавливать не нужно, так как это было сделано ранее.
Остается только выставить R/W = 1, что и имеет место быть (bsf PortB,R_W).
Далее, инструкция Status Read "запускается в работу штатным стробом" (call STROB).
После этого, на выводах порта С, устанавливаются текущие уровни битов байта
статуса.
Из числа битов этого байта, в данном случае, интерес представляют только биты с №
№ 4 (RESET), 5 (ON/OFF) и 7 (BUSY).
Первым анализируется состояние флага ON/OFF.
Если флаг ON/OFF не сбросился (0), то происходит "закольцовка" на начало ПП
стробирования, после чего текущее состояние флага ON/OFF снова считывается и
анализируется на предмет "опущения"/поднятия флага ON/OFF.
Если этого "опущения" нет, то имеет место быть дальнейшее "на колу мочало",
причем, до "победного конца" (типичная, "плавающая" задержка).
"Победный конец" наступит тогда, когда произойдет "опущение" флага ON/OFF.
После свершения этого отрадного события, происходит "линейный" переход на
проверку "опущения" (или нет) флага BUSY.
Она полностью аналогична предшествующей проверке, только проверяется состояние
не бита № 5, а бита № 7.
Следующим проверяется состояние флага RESET.
К моменту начала его проверки, он будет опущен (0), так как перед этим было
отработано аж две "плавающие" задержки (флаг RESET гарантированно должен
опуститься).
То есть, если со сбросом все ОК, то будет один-разъединственный цикл проверки
состояния флага RESET, после чего рабочая точка программы быстренько "побежит
делать свои дела дальше".
Если вдруг что-то пошло "на перекосяк", и флаг RESET не опустился, то разговор
короткий - переход на начало программы и полномасштабное "на колу мочало".
После "засечения опущения" всех трех флагов - обратная перестройка направлений
работы выводов порта С, переход в режим записи и "выход на широкий оперативный
простор".
Обращаю Ваше внимание на то, что интервал времени между двумя соседними
стробами должен быть больше, чем 8 мкс.
Именно для гарантированного обеспечения этого необходимого условия, в процедуру
анализа состояний флагов статуса, введена "перестраховочная" задержка (nop).
Сказанное реализовано в программе 12864_12.asm (прилагается).
Я ее гонял долго и упорно. "Клацал тумблером" на все лады (и быстро, и с оттяжкой,
и еще черт знает как).
С великой радостью сообщаю, что не смотря на все эти "издевательства", не было
замечено ни одного "глюка" инициализации.
Если учесть то, что программа 12864_12.asm является одноцикловой (с "мертвяком"), а
также и то, что я работал со своим "тормозным" блоком питания, то это совсем не
плохо.

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

Оценить