Ревич, Ю.В. Программирование микроконтроллеров AVR: от Arduino к ассемблеру

1 70 Часть 11. Программирование микроконтроллеров АVR на ассемблере Разумеется, сохранение заодно и рабочей переменной temp необязательно, и здесь приводится лишь в качестве примера. Просто в операциях сравнения нередко уча­ ствует и рабочая переменная, а она также может быть испорчена в процессе обра­ ботки «вклинившегося» прерывания . ЗАМЕТКИ НА ПОЛЯХ Отметим , что во многих случаях такой прием с сохранением регистра SREG можно все же обойти , чтобы не загромождать код и не удлинять процедуры , хоть с точки зрения программистов это выглядит и неграмотно (и я вам этого не советовал ! ) . Все дело в вероятности наихудшего стечения обстоятельств, которую всегда желательно прики­ нуть (это называется инженерным подходом) . Пусть , например, программа в основном цикле ожидает приема некоей команды по UART, игнорируя любые другие пришедшие байты : G_cykle : rcall in_com ; вызов процедуры приема байта - см . главу 1 5 cpi temp, Command_A ; определяем, та ли команда breq proc_A ; если та, то на процедуру обработки команды rjmp G_cykle ; иначе все сначала Как вы увидите в главе 15, внутри процедуры in_сот возникновение прерываний нам не страшно. Так что неприятность случится только, если прерывание возникнет между командами cpi и ьreq, т. е. если оно появится за время выполнения команды cpi (и то, напомним, только, когда в прерывании есть команда , модифицирующая значение, - в рассматриваемом случае - флага нуля z) . Процедура in_com для приема байта по UART при скорости 9600 бит/с может длиться порядка одной миллисекунды (и весь цикл займет примерно столько же) , тогда , при типовом времени выполнения команды cpi порядка долей микросекунды , вероятность неблагоприятного стечения обстоя­ тельств составит всего несколько случаев на 1 О ООО поданных команд. Если предпо­ ложить , что внешний компьютер непрерывно «бомбардирует» МК командами по UART, то вероятность сбоев достаточно велика, если же подача команды осуществ­ ляется пользователем вручную раз в сутки (в месяц, в год) , то, скорее всего, на такую возможность можно не обращать внимания. Гораздо удобнее выстроить «правиль­ ный» протокол взаимодействия, подразумевающий контроль обмена командами (о чем мы также будем говорить в главе 15) , - в критичных случаях это все равно по­ требуется , потому что сбои могут происходить и по иным причинам . Но если требует­ ся абсолютная надежность, конечно, лучше вдвойне застраховать себя от всех воз­ можных ситуаций . И еще заметим «до кучи», что команды, заведомо не модифицирующие значение соответствующего флага в регистре SREG, можно «вклинивать» между командами, его изменяющими, и командами условного перехода, его проверяющими. Так, между проверкой «на нолы> и ветвлением по этому условию (например, парой dec . . . brne ) можно вставить сколько угодно команд пересылки данных или, к примеру, извлечения/сохранения регистра в стеке . Сам переход по командам семейства ьrхх также не модифицирует содержимого SREG, и возможны конструк­ ции, когда ставятся подряд две и более команды перехода по одному условию. К оманды проверки -пропуска Это чрезвычайно распространенная группа команд, которые осуществляют пропуск следующей по порядку команды в зависимости от состояния отдельного бита