Программирование контроллеров

При использовании микропроцессорных управляющих уст­ройств (МП-контроллеров) необходимо программировать следующие позиции управления: опрос состояния датчиков, ожидание событий в объекте, формирование временных датчиков, ожидание событий в объекте, формирование временных задержек, формирование статиче­ских и импульсных управляющих сигналов, индикация состояния объекта и т.д. Программная реализация некоторых позиций оказыва­ется сложной, но даже для относительно простых функций программ­ная реализация сопряжена с необходимостью поиска нетривиальных решений, направленных на устранение ограничений, которые накла­дываются архитектурой МП, в том числе системой команд. Эти тех­нические сложности - один из факторов, сдерживающих широкое применение МП в устройствах и системах автоматики.

Весь цикл разработки МП-контроллеров рассматривается как последовательность трех относительно независимых фаз проектиро­вания:

- анализ задач и выбор аппаратных средств изделия;

- разработка программного обеспечения изделия;

- компенсирование аппаратных средств и программного обеспе­чения в прототипе изделия и его отладка.

Фазу разработки ПО, т.е. получение ППП, разделяют на два этапа:

первый – это переход от постановки задачи к исходной программе;

второй – переход от исходной программы к объектному модулю.

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

В состав средств системного ПО входят трансляторы с различ­ных алгоритмических языков высокого уровня, ассемблеры, редакто­ры текстов, программы-отладчики, программы-документаторы и т.д. Наличие таких системных средств на этом этапе характеризуется от­сутствием инженерной творческой мысли.

Инженерный труд на первом этапе разработки ПО при перехо­де от постановки задачи к исходной программе практически не подда­ется формализациии, следовательно, не может быть автоматизиро­ван. Проектная работа носит творческий характер, изобилует реше­ниями, определяемыми опытом, квалификацией и интуицией разра­ботчика МП-контроллера, в процессе работы возникает огромное ко­личество трудностей. Качество полученного программного продукта всецело зависит от уровня проектных решений, принятых на этапе перехода от постановки задачи к исходной программе.

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

Ресурсы, затрачиваемые собственно на программирование, т.е. на получение машинных кодов, столь незначительны по сравнению с ресурсами, затрачиваемыми в процессе формализации прикладной задачи и разработки алгоритма, что следует говорить не о проблеме разработки прикладного ПО контроллеров, а о проблеме формализа­ции профессиональных знаний конечного пользователя МП.

Сложившаяся структура трудозатрат в разработке МП-контроллеров позволяет выделить три основные стадии проектирования прикладного ПО:

- анализ предметной области в целях определения задач, авто­матизация решения которых на основе МП-контроллеров обещает наибольший эффект;

- разработка алгоритма решения поставленной задачи;

- собственно программирование, или точнее: сопровождение программного продукта системными средствами поддержки проекти­рования.

Если задача поставлена, то для ее решения, т.е. для получения текста исходной программы, необходимо выполнить ряд последова­тельных действий:

- подробное описание задачи;

- анализ задачи;

- инженерная интерпретация задачи с привлечением того или иного аппарата формализации (граф автомата, сети Петри, матрицы состояний и т.п.);

- разработка общей блок-схемы алгоритмов работы МП-контроллера;

- разработка детальных блок-схем алгоритмов отдельных про­цедур, выделенных на основе модульного принципа составления про­граммы;

- детальная проработка интерфейса МП-контроллера и внесе­ние исправлений в общую и детальные БСА;

- распределение рабочих регистров МП и памяти МП-контроллера;

- формирование текста исходной программы.

В результате работы по трем первым пунктам получают так на­зываемую функциональную спецификацию прикладной программы МП-контроллера, в которой основное внимание уделяется детализа­ции способов формирования входной и выходной информации МП-контроллера. Затем на языке БСА разработчик описывает метод, вы­бранный для решения поставленной задачи. Разработка БСА очень похожа на разработку аппаратных средств систем автоматики и обра­ботки данных, где в основу положена та же самая процедура струк­турного проектирования, которая традиционно используется разра­ботчиками аппаратных средств.

Отличие состоит в том, что при разработке аппаратных средств используются логические схемы, триггеры, регистры и другие эле­менты, а при создании ПО разработчик оперирует командами, под­программами, таблицами, другими программными объектами из арсе­нала средств обработки данных. Если алгоритм - это точно опреде­ленная процедура, предписывающая МП-контроллеру однозначно оп­ределенные действия по преобразованию исходных данных в выход­ные, то разработка БСА требует предельной точности и однозначно­сти используемой атрибутики: символических имен переменных, кон­стант установок, подпрограмм (модулей), адресов символических таб­лиц, портов ввода-вывода и т.п.

Основное внимание при разработке БСА следует уделить тому разделу функциональной спецификации прикладной программы, в котором приводится описание аппаратуры сопряжения МП-контроллера с объектом управления. Это описание для успешной раз­работки ПО детализируется вплоть до характеристик каждого вход­ного и выходного сигналов или устройства.

Разработка прикладной программы МП-контроллера заключа­ется в использовании метода декомпозиции, при котором вся задача последовательно разделяется на меньшие функциональные модули. Каждый из них можно анализировать, разрабатывать и отлаживать отдельно от других. Схемы связности этих функциональных модулей, каждый из которых реализует некоторую процедуру, образует общую или системную БСА прикладной программы. Это разделение задачи на модули и субмодули выполняется последовательно до такого уров­ня, когда разработка БСА модуля упрощена. Последовательная де­композиция обладает достаточной гибкостью, что позволяет привести в соответствие степень детализации БСА модуля со сложностью соот­ветствующей процедуры. Язык графических образов БСА использу­ется на любом уровне подробности описания модулей по принципу -каждому оператору БСА соответствует единственная команда МП.

Разработка БСА функционального модуля программы имеет выраженный интерактивный характер, т.е. требует многократных проб для проверки правильности алгоритма. Вне зависимости от функционального назначения процедуры при разработке ее БСА ре­комендуется придерживаться следующей очередности работы.

1. Определить, что должен делать модуль. (Это уже было сдела­но при разработке системной БСА, но теперь рассматривается не программа в целом, а ее отдельный фрагмент и, следовательно, может потребоваться доопределение и уточнение целевого назначения про­цедуры).

2. Определить способы получения модулем исходных данных (от датчиков через порты ввода, из таблиц и памяти, через рабочие реги­стры). Для реализации ввода исходных данных в модуль всего БСА надо включить соответствующие операторы.

3. Определить необходимость какой-либо предварительной об­работки введенных исходных данных (маскирование, сдвиг, масшта­бирование, перекодировка) и, если необходимо, включить соответствующие операторы.

4. Определить способ преобразования входных данных в тре­буемые выходные. Используя операторы процедур и условные опера­торы принятия решений, отобразить на языке БСА выбранный метод содержательной обработки исходных данных.

5. Определить способы выдачи из модуля обработанных данных (передать в память, в вызываемую программу, в порты вывода ин­формации). Необходимые действия отразить в БСА.

6. Определить необходимость какой-либо дополнительной обра­ботки выводимых данных (изменение формата, перекодирование, масштабирование, маскирование) и ввести в БСА операторы подготовки данных для вывода из модуля.

7. Вернуться к пункту 1 настоящего перечня работ и проанали­зировать полученный результат. Выполнить интерактивную корректировку БСА, чтобы придать ей логичность, стройность, четкий графический образ.

8. Проверить работоспособность алгоритма на бумаге путем под­становки в него действительных данных. Убедиться в его сходимости и результативности.

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

10. Провести мысленный эксперимент по определению работо­способности алгоритма в реальном масштабе времени, когда стохасти­ческие события, происходящие в объекте управления, могут оказать влияние на работу алгоритма. Параллельно самому тщательному ана­лизу следует подвергнуть проверке реакцию алгоритма на возможные прерывания в целях определения критических операторов, которые необходимо защитить от прерываний. Кроме того, в ходе проверки следует проанализировать логику алгоритма в целях определения таких последовательностей операторов, при выполнении которых МП-контроллер может «не заметить» кратковременных событий в объекте управления. При обнаружении таких ситуаций в логику БСА следует внести коррективы.

Практика разработки ПО для МП-контроллеров показала, что последовательное использование описанной поэтапной процедуры проектирования алгоритмов, составляющей основу метода структур­ного программирования, обеспечивает получение работоспособных прикладных программ. Дисциплинированное следование этой поэтап­ной процедуре проектирования ПО целесообразно не только для сложных, но даже для самых простых задач.

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

Спецификация памяти (и рабочих регистров) заключается в оп­ределении: адреса первой команды прикладной программы, действи­тельных начальных адресов стека, таблиц данных, буферных зон пе­редачи параметров между процедурами, подпрограмм обслуживания прерываний и т.д. При этом следует исходить из того, что в МП-контроллере память программ и память данных чаще всего физически и логически разделены: программа и константа хранятся в блоке ППЗУ (или ПЗУ), а переменные - в блоке ОЗУ. Перечень язы­ков написания исходного текста прикладной программы достаточно велик и начинается от машинного кода до почти естественного языка. В машинном коде или на языке ассемблера программировать сложнее „ временные затраты больше, чем на алгоритмическом языке высо­кого уровня, но в первом случае код программы получается более ко­поткий, требуется меньший объем памяти и отрабатывается такая программа быстрее. Объектные коды, полученные путем трансляции исходных программ, написанных на алгоритмическом языке высокого уровня, занимают в памяти МП-контроллера много больше места и требуют большего времени на исполнение.

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