PIC-микроконтроллеры. Все, что вам необходимо знать

Глава 6 Подпрограммы и модули

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

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

Прочитав эту главу, вы:

• Убедитесь в необходимости применения модульного принципа программирования.

• Поймете структуру стека и его использование в механизме вызова подпрограмм и возврата из них.•

• Поймете термин «вложенная подпрограмма».

• Узнаете, как можно передать параметры в подпрограмму и возвратить результат в вызывающую программу.

• Сможете писать подпрограммы, оказывающие минимальное влияние на свое окружение.

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

Давайте заглянем внутрь вашего персонального компьютера. Скорее всего он будет похож на тот, фотография которого приведена на Рис. 6.1. На материнской плате типичного компьютера размещаются микропроцессор, различного рода память и другие сопутствующие ИС, а также некоторое количество слотов расширения. К этим слотам можно подключить плату дискового контроллера и видеокарту. Существуют и другие платы, например звуковая плата, модем, сетевой контроллер. Каждая из этих плат выполняет собственные и совершенно независимые задачи, но все они взаимодействуют через сервисы, предоставляемые главной платой — материнской.

Рис. 6.1.Модульная конструкция на примере ПК

Преимущества такой модульной конструкции очевидны:

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

• Возможность повторного использования компонентов от предыдущей системы.

• Возможность покупки стандартных плат или разработки собственных специализированных плат.

• Легкость обслуживания.

Разумеется, у такого подхода есть и некоторые недостатки. Материнская плата, в которую интегрированы все устройства, имеет меньший размер и, теоретически, меньшую стоимость, чем эквивалентная совокупность простой материнской платы и карт расширения. Скорее всего она даже будет более надежной, поскольку входные и выходные сигналы не проходят через разъемы. Однако, если в такой плате возникнут какие-либо неполадки, их, как правило, гораздо труднее отследить и исправить.

В модульном программировании используется тот же самый принцип построения «программных узлов», т. е. программ. Вот формальное определение принципа модульного программирования, которое дается в научно-технической литературе:

Способ разработки программ, при котором программа разбивается на логически завершенные единицы — модули. При этом каждый модуль может разрабатываться, программироваться, транслироваться и тестироваться независимо от других[89].

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

Преимущества модульного программирования аналогичны преимуществам модульного проектирования, но еще более убедительны:

• Модули можно тестировать, отлаживать и поддерживать по отдельности; это обеспечивает общую надежность.

• Можно повторно использовать модули из других проектов или купить их у сторонних производителей.

• Легче модернизировать программу (простой заменой модулей).

Решение о том, каким образом следует разбить программу на отдельные независимые задачи, принимается на основе опыта. Собственно кодирование этих задач в виде подпрограмм ничем не отличается от написания примеров, которые мы рассматривали в предыдущих главах (см., например, Программу 5.9 на стр. 162). Для реализации указанных подпрограмм имеется несколько дополнительных команд, которые перечислены в Табл. 6.1. Далее в настоящей главе мы рассмотрим эти команды, а также некоторые методики, применяемые при разработке программного обеспечения.