Самоучитель по программированию PIC контроллеров для начинающих (Е.А. Корабельников,2008). Самоучитель по программированию PIC контроллеров для начинающих. Система команд pic16F84A 26 Что такое программа иправила ее составленияПример создания программы автоколебательного мультивибратораДирективы.
 Скачать 3.49 Mb.
|
|
movwf W_Temp ) и далее будет "скакать " по командам ПП прерывания (она будет исполняться. После исполнения первых 3- х команд , содержимое регистров и должно скопироваться в регистры Stat_Temp и W_Temp соответственно В данном случае, копироваться будут значения по умолчанию 152 В регистре W , по умолчанию, установлено число 00h. Так как в регистре W_Temp , по умолчанию, также установлено число 00h, то, при сохранении содержимого регистра в регистре W_Temp , в окне RAM , никаких изменений не произойдет ( кроме PC ). В регистре Status , по умолчанию, установлено число 18h. Проследите (в окнах Watch и RAM ), как это число, сначала, запишется в регистр W ( movf Status,W ), а затем , скопируется из регистра W в регистр Stat_Temp Пошли дальше Перед исполнением команды ветвления PortB,0 , необходимо посмотреть на состояние нулевого бита регистра PortB По умолчанию, он установлен в 0, следовательно, в соответствии с алгоритмом работы команды, рабочая точка программы "уйдет " сценарий "программа исполняется далее ", То есть, "встанет " на команду Так оно и есть Далее , исполняем все команды записи констант в регистры SecH_2 и Убеждаемся, что в регистры SecH_2 и из регистра, скопировались числа .250 и соответственно Переходим на "врезку " в ПП задержки PAUSE_2 ( clrwdt ). Далее, отслеживание работы программы происходит аналогично отслеживанию работы ПП PAUSE или PAUSE_D Собственно говоря, работу ПП PAUSE_2 можно и не отслеживать, а "пройти ее в автомате ", поставив точку остановки на первую команду ПП CYCLE ( btfsc PortB,0 ). Таки делаемВыставляем точку остановки, щелкаем по кнопке с зеленым светофором и убеждаемся , что рабочая точка программы "встала " на команду Это свидетельствует о том , что внутренний цикл подпрограммы прерывания успешно пройден (" глюков / мин " нет. Для того чтобы в этом окончательно убедиться (ну ив обучающих целях тоже, не снимая установленную точку остановки, можно еще раз (да и сколько угодно раз) щелкнуть по кнопке с зеленым светофором и капитально удостовериться в том , что после отработки "автомата ", рабочая точка программы снова окажется на команде PortB,0. Это свидетельствует о том , что при наличии несущей, рабочая точка программы " железобетонно уйдет в вечное кольцо " ПП CYCLE ), в чем и требовалось радостно убедиться Один сценарий отслежен Отслеживаем следующий "Встаем " все на туже команду Применяем "уловку ", заменив эту команду на команду Производим ассемблирование и устанавливаем программу на начало Так как должен произойти безусловный переход на первую команду ПП EndInt , то устанавливаем точку остановки на команде Запускаем "автомат " и ждем окончания его отработки Рабочая точка программы "встала " на команду Исполняем ее и убеждаемся , что 1- й бит регистра IntCon установился в 0 (флаг прерывания INT программно сброшен. Далее, исполняем, рекомендованный разработчиками, стандартный "набор " из 4- х команд восстановления содержимого регистров Status и W (результат можно проконтролировать. Рабочая точка программы "встала " на команду retfie Исполняем команду retfie и получаем предупреждение ( MPLAB "в панике ") о том , что стек пусти соответственно, извлекать из него нечего Хоть "шаром покати ". Но паниковать ненужно Вконце- концов, мы кто Гомо сапиенсы или мартышки Щелкнув по ОК , спокойно закрываем окно предупреждения, после чего рабочая точка программы устанавливается на начало (в данном случае, на команде в "шапке " программы. Поза мыслителя Вопрос : " В чем дело Почему стек пустой "? Ответ : переход в ПП прерывания был осуществлен не из "зоны " разрешения прерываний "основного тела " программы, а при помощи "уловки ", то есть, проще говоря, условного перехода (см. виртуальный" call) не было, а следовательно ив стек ничего не записалось " С другого бока ": так как, походу отслеживания, никаких команд условных переходов не 153 исполнялось, а стек , по умолчанию, пуст, значит и на момент исполнения команды retfie, он также будет пусто чем мы и получили добросовестное предупреждение А раз это так, то при щелчке по ОК , MPLAB "принудительно " устанавливает рабочую точку программы на начало, как бы предлагая найти и устранить ошибку, а затем попробовать повторить отслеживание еще раз Таким образом, для "полноценного " отслеживания данного сценария работы ПП прерывания , необходимо "уйти " в прерывание из "зоны " разрешения прерываний "основного тела " программы Проще всего это сделать, не задействуя функции стимула, а при помощи очередной "уловки ", смысл которой заключается в следующем В списке команд, Вы не обнаружите команды условного перехода в ПП прерывания , в нем имеется только команда возврата из ПП прерывания ( retfie ). Но это вовсе не означает, что "уход " в ПП прерывания происходит по какому- то "таинственному указанию святого духа ". Эта команда вполне конкретна и называется она call выше, я ее называл виртуальный" call). Просто она исполняется не программно, а аппаратно По факту возникновения события прерывания любого типа Таким образом, чтобы проверить / сымитировать уход в прерывание из "зоны " разрешения прерываний "основного тела " программы, необходимо просто- напросто "врезать " в нее команду Для того чтобы быстро "добраться " до этой команды (не ждать окончания отработки счетчика, ее лучше "врезать " между командами clrwdt и decfsz Для работы в "основном телепрограммы, также необходимо заблокировать команду и разблокировать команду Делаем это Производим ассемблирование , и после получения сообщения о безошибочном ассемблировании , устанавливаем программу на начало ( goto START ), назначаем точку остановки на команде и запускаем "автомат ". Ждем его отработки, после чего рабочая точка программы устанавливается на команде INT (то есть, таким образом, мы "добрались " до этой команды. А теперь разбираемся со стеком Сначала нужно открыть специальное окно, в котором мы будем наблюдать содержимое стека Это делается так в главном меню MPLAB, щелкаем по слову Window и в выпадающем списке, щелкаем по строке Stack Откроется окно Window В нем пока ничего нет (т к команд условных переходов не было. Расположите это окно в любом удобном для Вас месте обычным, для " Виндов ", способом Исполняем команду Рабочая точка программы "уйдет " в ПП прерывания и "встанет " на первую ее команду W_Temp ). А теперь посмотрите в окно стека В нем появилась строка с адресом той команды, на которую, после возврата рабочей точки программы из ПП прерываний , она "встанет " (с адресом возврата. Этот адрес - 003Bh. Откройте окно ROM и убедитесь в том , что команда с этим адресом ( decfsz SecL,F ) является следующей, после команды При переходе в ПП прерывания по активному перепаду на входе, по сути, происходит тоже самое Разница только в том , что положение команды в тексте программы, фиксировано, а " виртуальный " call может сформироваться сразу же после отработки любой из команд "зоны " разрешения прерываний Напоминаю Вам , что ранее мы отслеживали исполнение 2- го сценария работы ПП прерываний Еще раз "прогоним " по нему рабочую точку программы, нона этот раз, мы "вошли " в ПП прерываний "как положено ", то есть, из "зоны " разрешения прерываний "основного тела " программы (в вершину стека "заложен " адрес возврата. 154 Так как при первом "прогоне ", мы уже отследили работу этого сценария и убедились , что все в порядке , то назначаем точкой остановки команду retfie и запускаем "автомат ". После его отработки, рабочая точка программы "встала " на команду retfie Исполняем ее Вершина стека очистится (стек станет опять пустым, рабочая точка программы "вернется " в "основное тело " программы и установится на команде SecL,F , в чем и требовалось убедиться Итак , мы разобрались со всеми сценариями работы программы и убедились в отсутствии ошибок функционального характера, а заодно и "заглянули " в стек Программа отслежена После всех этих "катаклизмов ", нужно "навестив программе порядок ", вернув ее к исходному состоянию (убрать все "уловки "). Отладка программы В результате отслеживания работы программы, мы убедились в том , что программа работает в соответствии с задуманным алгоритмом ее работы При этом, внимания на ее временнЫе характеристики не обращалось Так как в большинстве программ, имеются калиброванные, повремени (стой или иной точностью, это зависит от специфики разрабатываемого устройства, задержки, тов первую очередь, именно к коррекции величин этих задержек (под задуманные) и сводится процесс отладки программы Обращаю Ваше внимание на то, что отлаживаться может как "локальная " ПП задержки , таки более "навороченная " ПП задержки , имеющая внутри своего цикла несколько "локальных " ПП задержек Примером "локальной " ПП задержки может послужить, например, ПП PAUSE_2 , а примером "навороченной " ПП задержки может послужить ПП CYCLE см текст программы. И ту , и другую можно отладить, то есть, изменить времязадающие константы (а при необходимости, добавить или удалить калибровочные NOP ы ) таким образом, чтобы время отработки задержек было равно расчетным значениям Для того чтобы это сделать без ошибок, нужно знать, как программа работает В процессе отладки, программист должен уметь "вычленять ", из текста программы, оба типа ПП задержек (см выше) и четко представлять себе функции этих задержек в "контексте " всей программы Только после этого имеется гарантия того, что он поставит точки остановок точно и без ошибок Разбираемся с задержками программы Retr_1.asm Ранее , было сформулировано требование к величине защитного интервала времени он должен быть равен примерно 60 мс Определяемся с "границами " защитного интервала времени Он начинает формироваться после исполнения команды PortB таких команд две, как для 1- го, таки для 2- го сценария работы программы в "основном телепрограммы Сразу "настораживаемся ": два сценария могут исполняться заразное время, а нам , предположим, нужно сделать так, чтобы оба сценария выполнялись за одинаковое время В учебно - тренировочных целях, производим оценку этой разницы По вполне понятным причинам, общие команды этих 2- х сценариев в расчет не берутся Остаются те части этих сценариев, которые не являются общими В них , рабочая точка программы, в зависимости от сценария ее исполнения, "движется " по- разному Соответственно , интервалы времени их отработки тоже могут быть разными Вот Вам и разница во времени Давайте разбираться После команды Trigg,0 , происходит "разветвление " сценариев, а "слияние " сценариев происходит на команде .197 (на это намекалось выше. Для того чтобы выровнять время исполнения этих сценариев, необходимо подсчитать количество машинных циклов, за которые они исполняются Если при этом выявятся различия, то необходимо произвести их выравнивание калибровочными NOP ами В данном случае, практической необходимости в "выравнивании " сценариев нет, но 155 существуют и программы , необходимым условием "полноценной " работы которых является одинаковое время исполнения двух или более ее "локальных " сценариев, "расходящихся из одной точки ", а затем "сходящихся в одну точку " (например, программы, созданные под точные, измерительные приборы. Раз уж "подвернулся такой повод ", то, как говорится, "грех его упускать ". Поэтому, в учебно - тренировочных целях, ниже, будет произведено выравнивание "локальных " сценариев Итак , "расхождение сценариев из одной точки " происходит от команды Схождение сценариев в одну точку " происходит на команде Выставляем точку остановки на команде Сбрасываем программу на начало и "доходим ", до этой точки остановки, в "автомате ". Проблем при этом не будет, так как установки MPLAB по умолчанию, позволяют это сделать ( в противном случае, пришлось бы применять "уловку "). Выставляем точку остановки на команде Сбрасываем программу на начало, вызываем секундомер, сбрасываем секундомер в ноль , жмем на кнопку с зеленым светофором Секундомер показал 6 м . ц . Чтобы отработать 2- й сценарий , нужно применить "уловку ", в виде замены команды Trigg,0 на команду Trigg,0 Ассемблируем , выставляем те же точки остановки и т д. (те же действия. Секундомер показал 5 м . ц . Разнобой " в 1 м . ц . Для его устранения, нужно "врезать " один nop после команды PortB (той, которая следует за командой .255 ). Выравнивание сценариев произведено (оба будут исполняться за 6 м . ц .). В тексте программы, этого NOP а нет по причине того, что "разнобой " в 1 м ц никакой "погоды не делает " но, при желании, Вы его можете "врезать ". Если Вы добавили в текст программы, то нужно произвести ассемблирование Этот пример простейшего выравнивания времени исполнения сценариев приведен для того, чтобы было понятно, о чем идет речь В других программах, такое выравнивание может быть архинеобходимым (об этом пойдет речь водном из следующих разделов, так что обратите на это внимание Например , если в частотомере не выровнять сценарии, то его показания не будут стабильными даже при абсолютно стабильной, измеряемой частоте После того, как мы убедились, что оба сценария будут исполняться заодно и то же время ( если имеется такая необходимость, можно заняться калибровкой (ноне наоборот. Сбросьте программу Retr_1.asm на начало (на) ив пошаговом режиме (а можно ив "автомате "), "встаньте " на команду PortB (на ту, которая находится после команды .251 ). Вызовите секундомер и сбросьте его на ноль Назначьте точку остановки на команде .245 (конец формирования защитного интервала времени) и запустите "автомат ". После того, как он отработает, секундомер покажет ровно 60 мс Естественно, что в этом случае, числовые значения констант защитного интервала времени уже подобраны (.197 и .121). Можете, для тренировки, поизменять их и посмотреть (по секундомеру, что из этого получится Процесс отладки подобного рода ПП задержки уже был подробно расписан выше, так что повторяться не буду Замечание : фактически, формирование защитного интервала времени заканчивается не после выхода рабочей точки программы из ПП PAUSE_D , а после исполнения команды IntCon , то есть, величина защитного интервала времени окажется на 6 мкс. (6 команд по одному м ц .) больше (60 006 мкс, что с учетом допуска в "плюс- минус 2 лаптя ", вполне приемлемо Отладка остальных ПП задержек - аналогична "Пройдитесь " по этим ПП задержек самостоятельно После этого Вы , должны получить следующие результаты 1. "Ширина зоны " разрешения прерываний 11,28 мс (границы ": верхняя - movwf IntCon , нижняя - clrf IntCon ). 156 2. В ПП прерывания , интервал времени отработки одного цикла задержки 5,62 мс (точка остановки одна btfsc PortB,0 (от этой точки остановки, и через один "виток ", до нее же. Примечание собственно говоря, отладки, как таковой, и не было (константы не менялись, а была просто проверка величин задержек, которые уже были отлажены ранее Чтобы процесс отладки был "полноценным ", для тренировки, можете изменить исходные требования к этим величинами руководствуясь принципом отладки, описанным при отладке программы, произвести отладку программы Retr_1.asm Итак , отладка закончена, и HEX- файл программы Retr_1.asm можно открывать в программе , обслуживающей Ваш программатор, после чего можно "прошить " ПИК При этом, вероятность того, что устройство будет работать именно так, как задумано, велика А теперь о программе , выполняющей тоже самое, но без уходов в прерывания Файл текста программы называется (находится в папке " Тексты программ. Программа выглядит так ;******************************************************************************** ; Retr_3.asm ВАРИАНТ БЕЗ ПРЕРЫВАНИЙ ; Сканер для ретранслятора VERTEX-7000VXR. ; Автор Корабельников Евгений Александрович г . Липецк декабрь г. ; E-mail: karabea@lipetsk.ru http://ikarab.narod.ru ;******************************************************************************** ; Позволяет перевести VERTEX-7000VXR и другие подобные ретрансляторы из режима односторонней ретрансляции в режим двухсторонней ретрансляции без потери качества работы. |