Программирование контроллеров
При использовании микропроцессорных управляющих устройств (МП-контроллеров) необходимо программировать следующие позиции управления: опрос состояния датчиков, ожидание событий в объекте, формирование временных датчиков, ожидание событий в объекте, формирование временных задержек, формирование статических и импульсных управляющих сигналов, индикация состояния объекта и т.д. Программная реализация некоторых позиций оказывается сложной, но даже для относительно простых функций программная реализация сопряжена с необходимостью поиска нетривиальных решений, направленных на устранение ограничений, которые накладываются архитектурой МП, в том числе системой команд. Эти технические сложности - один из факторов, сдерживающих широкое применение МП в устройствах и системах автоматики.
Весь цикл разработки МП-контроллеров рассматривается как последовательность трех относительно независимых фаз проектирования:
- анализ задач и выбор аппаратных средств изделия;
- разработка программного обеспечения изделия;
- компенсирование аппаратных средств и программного обеспечения в прототипе изделия и его отладка.
Фазу разработки ПО, т.е. получение ППП, разделяют на два этапа:
первый – это переход от постановки задачи к исходной программе;
второй – переход от исходной программы к объектному модулю.
На втором этапе организуются машинные коды прикладных программ, работающих в МП-контроллерах. Разработка ПО легко поддается формализации и поддержана системным ПО микропроцессора, направленным на автоматизацию получения ППП.
В состав средств системного ПО входят трансляторы с различных алгоритмических языков высокого уровня, ассемблеры, редакторы текстов, программы-отладчики, программы-документаторы и т.д. Наличие таких системных средств на этом этапе характеризуется отсутствием инженерной творческой мысли.
Инженерный труд на первом этапе разработки ПО при переходе от постановки задачи к исходной программе практически не поддается формализациии, следовательно, не может быть автоматизирован. Проектная работа носит творческий характер, изобилует решениями, определяемыми опытом, квалификацией и интуицией разработчика МП-контроллера, в процессе работы возникает огромное количество трудностей. Качество полученного программного продукта всецело зависит от уровня проектных решений, принятых на этапе перехода от постановки задачи к исходной программе.
Опыт разработки МП-контроллеров позволяет утверждать, что многие процессы, реализуемые аппаратными средствами, могут быть преобразованы в эквивалентные процессы, реализуемые программой. В МП-контроллерах аппаратные средства и ПО существуют в форме неделимого аппаратно-программного комплекса, в котором имеются ПУ аппаратными средствами и аппаратура, на которой реализуются программы.
Ресурсы, затрачиваемые собственно на программирование, т.е. на получение машинных кодов, столь незначительны по сравнению с ресурсами, затрачиваемыми в процессе формализации прикладной задачи и разработки алгоритма, что следует говорить не о проблеме разработки прикладного ПО контроллеров, а о проблеме формализации профессиональных знаний конечного пользователя МП.
Сложившаяся структура трудозатрат в разработке МП-контроллеров позволяет выделить три основные стадии проектирования прикладного ПО:
- анализ предметной области в целях определения задач, автоматизация решения которых на основе МП-контроллеров обещает наибольший эффект;
- разработка алгоритма решения поставленной задачи;
- собственно программирование, или точнее: сопровождение программного продукта системными средствами поддержки проектирования.
Если задача поставлена, то для ее решения, т.е. для получения текста исходной программы, необходимо выполнить ряд последовательных действий:
- подробное описание задачи;
- анализ задачи;
- инженерная интерпретация задачи с привлечением того или иного аппарата формализации (граф автомата, сети Петри, матрицы состояний и т.п.);
- разработка общей блок-схемы алгоритмов работы МП-контроллера;
- разработка детальных блок-схем алгоритмов отдельных процедур, выделенных на основе модульного принципа составления программы;
- детальная проработка интерфейса МП-контроллера и внесение исправлений в общую и детальные БСА;
- распределение рабочих регистров МП и памяти МП-контроллера;
- формирование текста исходной программы.
В результате работы по трем первым пунктам получают так называемую функциональную спецификацию прикладной программы МП-контроллера, в которой основное внимание уделяется детализации способов формирования входной и выходной информации МП-контроллера. Затем на языке БСА разработчик описывает метод, выбранный для решения поставленной задачи. Разработка БСА очень похожа на разработку аппаратных средств систем автоматики и обработки данных, где в основу положена та же самая процедура структурного проектирования, которая традиционно используется разработчиками аппаратных средств.
Отличие состоит в том, что при разработке аппаратных средств используются логические схемы, триггеры, регистры и другие элементы, а при создании ПО разработчик оперирует командами, подпрограммами, таблицами, другими программными объектами из арсенала средств обработки данных. Если алгоритм - это точно определенная процедура, предписывающая МП-контроллеру однозначно определенные действия по преобразованию исходных данных в выходные, то разработка БСА требует предельной точности и однозначности используемой атрибутики: символических имен переменных, констант установок, подпрограмм (модулей), адресов символических таблиц, портов ввода-вывода и т.п.
Основное внимание при разработке БСА следует уделить тому разделу функциональной спецификации прикладной программы, в котором приводится описание аппаратуры сопряжения МП-контроллера с объектом управления. Это описание для успешной разработки ПО детализируется вплоть до характеристик каждого входного и выходного сигналов или устройства.
Разработка прикладной программы МП-контроллера заключается в использовании метода декомпозиции, при котором вся задача последовательно разделяется на меньшие функциональные модули. Каждый из них можно анализировать, разрабатывать и отлаживать отдельно от других. Схемы связности этих функциональных модулей, каждый из которых реализует некоторую процедуру, образует общую или системную БСА прикладной программы. Это разделение задачи на модули и субмодули выполняется последовательно до такого уровня, когда разработка БСА модуля упрощена. Последовательная декомпозиция обладает достаточной гибкостью, что позволяет привести в соответствие степень детализации БСА модуля со сложностью соответствующей процедуры. Язык графических образов БСА используется на любом уровне подробности описания модулей по принципу -каждому оператору БСА соответствует единственная команда МП.
Разработка БСА функционального модуля программы имеет выраженный интерактивный характер, т.е. требует многократных проб для проверки правильности алгоритма. Вне зависимости от функционального назначения процедуры при разработке ее БСА рекомендуется придерживаться следующей очередности работы.
1. Определить, что должен делать модуль. (Это уже было сделано при разработке системной БСА, но теперь рассматривается не программа в целом, а ее отдельный фрагмент и, следовательно, может потребоваться доопределение и уточнение целевого назначения процедуры).
2. Определить способы получения модулем исходных данных (от датчиков через порты ввода, из таблиц и памяти, через рабочие регистры). Для реализации ввода исходных данных в модуль всего БСА надо включить соответствующие операторы.
3. Определить необходимость какой-либо предварительной обработки введенных исходных данных (маскирование, сдвиг, масштабирование, перекодировка) и, если необходимо, включить соответствующие операторы.
4. Определить способ преобразования входных данных в требуемые выходные. Используя операторы процедур и условные операторы принятия решений, отобразить на языке БСА выбранный метод содержательной обработки исходных данных.
5. Определить способы выдачи из модуля обработанных данных (передать в память, в вызываемую программу, в порты вывода информации). Необходимые действия отразить в БСА.
6. Определить необходимость какой-либо дополнительной обработки выводимых данных (изменение формата, перекодирование, масштабирование, маскирование) и ввести в БСА операторы подготовки данных для вывода из модуля.
7. Вернуться к пункту 1 настоящего перечня работ и проанализировать полученный результат. Выполнить интерактивную корректировку БСА, чтобы придать ей логичность, стройность, четкий графический образ.
8. Проверить работоспособность алгоритма на бумаге путем подстановки в него действительных данных. Убедиться в его сходимости и результативности.
9. Рассмотреть предельные случаи и попытаться определить граничные значения параметров, с которыми оперирует алгоритм, за пределами которых он теряет свойства конечности, сходимости или результативности. Особое внимание при этом следует уделить анализу возможных ситуаций переполнения разрядной сетки МП, изменения знака результата операции, деления на переменную, которая может принять нулевое значение.
10. Провести мысленный эксперимент по определению работоспособности алгоритма в реальном масштабе времени, когда стохастические события, происходящие в объекте управления, могут оказать влияние на работу алгоритма. Параллельно самому тщательному анализу следует подвергнуть проверке реакцию алгоритма на возможные прерывания в целях определения критических операторов, которые необходимо защитить от прерываний. Кроме того, в ходе проверки следует проанализировать логику алгоритма в целях определения таких последовательностей операторов, при выполнении которых МП-контроллер может «не заметить» кратковременных событий в объекте управления. При обнаружении таких ситуаций в логику БСА следует внести коррективы.
Практика разработки ПО для МП-контроллеров показала, что последовательное использование описанной поэтапной процедуры проектирования алгоритмов, составляющей основу метода структурного программирования, обеспечивает получение работоспособных прикладных программ. Дисциплинированное следование этой поэтапной процедуре проектирования ПО целесообразно не только для сложных, но даже для самых простых задач.
Преобразование разработанного алгоритма в исходный текст программы - дело несложное. Но, прежде чем приступить к написанию программы, необходимо специфицировать память и выбрать язык программирования.
Спецификация памяти (и рабочих регистров) заключается в определении: адреса первой команды прикладной программы, действительных начальных адресов стека, таблиц данных, буферных зон передачи параметров между процедурами, подпрограмм обслуживания прерываний и т.д. При этом следует исходить из того, что в МП-контроллере память программ и память данных чаще всего физически и логически разделены: программа и константа хранятся в блоке ППЗУ (или ПЗУ), а переменные - в блоке ОЗУ. Перечень языков написания исходного текста прикладной программы достаточно велик и начинается от машинного кода до почти естественного языка. В машинном коде или на языке ассемблера программировать сложнее „ временные затраты больше, чем на алгоритмическом языке высокого уровня, но в первом случае код программы получается более копоткий, требуется меньший объем памяти и отрабатывается такая программа быстрее. Объектные коды, полученные путем трансляции исходных программ, написанных на алгоритмическом языке высокого уровня, занимают в памяти МП-контроллера много больше места и требуют большего времени на исполнение.
Большинство прикладных задач управления объектами решается в реальном масштабе времени, и поэтому к средствам МП-техники предъявляются столь высокие требования по быстродействию, что для решения этих задач основным языковым средством написания прикладных программ является язык ассемблера.
Дата добавления: 2019-02-07; просмотров: 834;