Файл: Самоучитель по программированию PIC контроллеров для начинающих (Е.А. Корабельников,2008).pdf

Вывод: "шаг" изменения константы младшего разряда составляет 123 мкс.

Cледовательно, полный цикл счета счетчика младшего разряда составляет

256х123=31488 мкс.

Это означает, что через каждые 31488 мкс., содержимое счетчика среднего разряда будет изменяться на единицу.

Следовательно, полный цикл счета счетчика среднего разряда составит

256х31488=8,060928 сек.

Это означает, что через каждые 8,060928 сек., содержимое счетчика старшего разряда будет изменяться на единицу.

Следовательно, полный цикл счета счетчика старшего разряда составит

256х8,060928=2063,5975 сек.

Это есть максимальное время задержки ("грубая прикидка").

Например, требуется сделать "грубую прикидку" значений констант для вычитающего, трехразрядного счетчика, формирующего интервал времени 20 сек.

Встаршем разряде, тройку назначать нельзя, так как будет "перебор", а двойка будет в самый раз: 2х8,060928=16,121856 сек.

Остаток: 20-16,121856=3,878144 сек.

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

.123.

123х31488=3873024 мкс.=3,873024 сек.

Остаток: 3,878144 сек.- 3,873024 сек.=0,00512 сек.=5120 мкс.

Для младшего разряда счетчика, назначаем константу .41 (с "недобором"): 41х123=5043 мкс. То, что сейчас проделано, называется разложением.

Итак, "грубая прикидка" значений констант, для формирования интервала времени величиной 20 сек., дала следующие результаты:

- для старшего разряда: .02 (H), - для среднего разряда: .123 (M), - для младшего разряда: .41 (L).

Обращаю Ваше внимание на то, что это именно "грубая прикидка".

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

То есть, речь идет о сумме фактического времени отработки задержки и времени отработки этих команд.

Именно поэтому, в младшем разряде должен быть "недобор".

Вернемся к рассмотренному выше примеру: при значении константы младшего разряда счетчика .10 и шаге в 123 мкс., счетчик должен показать 1230 мкс., но он показывает 1250 мкс. (это пример того, что часто встречается).

Вчем дело?

Дело в том, что кроме ПП задержки, еще отрабатывается (в течение 20 мкс.) и группа команд, которая не входит в ее полный цикл.

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

Это позволяет достаточно точно "выйти в числовой сектор обстрела".

Внашем случае, если имеются такие "линейные вкрапления", реальная величина калиброванного интервала времени может оказаться более чем 20 сек.

А может и не оказаться.

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

Во многих случаях, достаточно только скорректировать числовое значение константы младшего разряда.

Вслучае значительных расхождений между фактической и расчетной величинами, нужно замерить "шаги" констант среднего и/или старшего разряда и внести в расчеты соответствующие коррективы.

Просто нужна "тренировка".

118

Когда Вы "набьете на этом деле руку", все это будет происходить без "напряга", хотя и будет занимать определенное время.

Главное - понимать смысл производимых действий. Ну и "технологию" тоже. Потренироваться можно, используя все ту же программу cus.

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

Большее время задавать не нужно (будете долго ждать конца счета). Попробуйте сами назначить точки остановки.

Не забудьте про "уловку".

Разбираем следующий случай: в тексте программы имеется ошибка.

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

Вэтом случае, после ассемблировании текста программы, Вы получите сообщения о всех допущенных ошибках, с указанием строк программы, в которых они допущены.

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

Эти ошибки нужно устранить и добиться безошибочного ассемблирования.

При этом, вовсе не обязательно, за один "присест", устранять все ошибки (если их много). Можно, не спеша и по очереди, разобраться с каждым сообщением об ошибке, производя ассемблирование после каждой такой "разборки" или после неудачной ее попытки, вплоть до устранения ошибки.

Пока все ошибки не будут устранены, дальнейшая работа с текстом программы просто не имеет смысла (MPLAB "уйдет в отказ" и о создании HEX файла можно даже и не мечтать). Советую Вам попробовать внести в текст программы cus какие-нибудь ошибки, из списка тех, что указаны выше, и посмотреть, что из этого получится после ассемблирования. Предположим, что все ошибки подобного рода устранены и получено сообщение о безошибочном ассемблировании.

После этого, "хлопать в ладоши", вообще-то, рановато, так как далее предстоит "борьба" с ошибками функционального характера (естественно, при их наличии), что будет посерьезнее, чем ошибки в оформлении текста программы.

По той причине, что в этом случае, MPLAB не поможет (ошибок функционального характера "он не видит").

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

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

Вслучае отсутствии такого соответствия, выявляется причина несоответствия и принимаются меры для его устранения.

Анализ текста программы на наличие или отсутствие ошибок функционального характера целесообразно начать с "прогонки" рабочей точки по всему полному циклу программы.

В этом случае, работа происходит по принципу "следопыта".

Первичная задача: нужно "протащить" рабочую точку программы по полному циклу программы, начиная с первой ее команды, при настройках MPLAB по умолчанию.

119

До возникновения первого затруднения.

Далее работа мозга и радость победы (в идеале).

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

И так далее. До конца полного цикла программы (вернее, до "выхода на новый виток" полного цикла программы).

Факт такого "протаскивания" рабочей точки программы по полному циклу односценарной программы, соответствует проверке работоспособности программы типа "грубо" и говорит о том, что программа "жизнеспособна".

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

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

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

Обращаю Ваше внимание на то, что употребленное мной слово "затруднение", вовсе не свидетельствует о наличии ошибки функционального характера.

Затруднение может быть связано с ней, но оно может быть также связано и с "уходом" рабочей точки программы в нежелательный сценарий работы программы.

Вспомните про то, как при отладке программы cus, рабочая точка программы "ушла в вечное кольцо" ПП PRD, и из-за этого нельзя было осуществить замер значений полупериодов.

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

Это вовсе не говорит о том, что этот нежелательный сценарий нежелателен вообще. Проверить нужно и его, но только в ходе "прогонки", осуществляемой именно для проверки этого сценария.

Взависимости от сложности программы (от количества сценариев ее исполнения), таких

"прогонок" может быть достаточно большое количество, так что освоение их "технологии" (свободная "рулёжка" сценариями программы) насущная необходимость.

Чем больше способов имитации внешних, управляющих сигналов знает программист, тем в меньшее количество "тупиков" он будет попадать.

Вот Вам и ответ на вопрос: "Зачем нужны функции стимула и/или уловки"?

На мой взгляд, эффективнее сконцентрировать внимание не на функциях стимула, а на "уловках".

Лично я, так и делаю.

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

В следующем разделе, тема "рулёжки" сценариями будет продолжена.

"Самоучитель по программированию PIC контроллеров для начинающих" http://ikarab.narod.ru E-mail: karabea@lipetsk.ru

120