ПОСЛЕ ИЗУЧЕНИЯ ГЛАВЫ ВЫ СМОЖЕТЕ:
• Провести сравнительный анализ языка ассемблер и языков программирования высокого уровня для разработки программного обеспечения встраиваемых систем.
• Рассказать об особенностях языка Си, которые позволили выбрать его в качестве основного языка высокого уровня для кодирования управляющих программ встраиваемых систем.
• Рассказать об основных положениях метода структурного проектирования и применить этот метод на практике в области встраиваемых систем.
• Понять важность документирования в процессе разработки.
• Перечислить правила ведения инженером рабочей тетради.
• Применить методы универсального языка моделирования к описанию функционирования встраиваемых систем.
Предлагаемая Вашему вниманию глава, быть может, самая главная в этой книге. Она предлагает Вам несколько шире взглянуть на процесс проектирования встраиваемых систем, нежели Вы делали это до настоящего времени. Мы покажем в этой главе, почему язык Си стал основным языком высокого уровня для проектирования управляющих программ встраиваемых систем. Далее мы сравним технологии программирования встраиваемых систем на Си и на ассемблере и покажем, что оптимальным является сочетание этих двух языков. Следующим предметом нашего изучения будет метод структурного проектирования в приложении к встраиваемым системам. Мы рассмотрим основные положения этого метода и приведем примеры его использования. Мы также рассмотрим способы описания программного продукта с использованием универсального языка моделирования.
На протяжении всей этой книги для написания фрагментов программ управления мы используем язык Си. Мы выбрали Си для программирования встраиваемых микропроцессорных систем по многим причинам, которые, мы надеемся, станут Вам ясны по мере знакомства с материалом этой главы.
В предисловии мы адресовали данную книгу подготовленным читателям, которые знакомы с основами цифровой и микропроцессорной техники, имеют опыт программирования на языке ассемблера для какого либо типа МК. Не пугайтесь, если Вы чувствуете себя недостаточно образованным в перечисленных областях знаний. Мы постарались преподнести материал данной книги так, чтобы он легко усваивался учащимися. Для того чтобы восполнить недостающие знания в области цифровой техники, рекомендуем обратиться к книге [9] или к иным подобным изданиям. Для предварительного знакомства с архитектурой и системой команд микроконтроллеров 68HC12 Вы можете использовать книгу [6].
В следующих параграфах данной главы мы познакомим Вас с технологиями создания программного обеспечения для встраиваемых систем. Мы проведем сравнительный анализ преимуществ и недостатков технологий программирования встроенных систем на Си и на ассемблере. Мы также постараемся разъяснить Вам, почему язык Си стал стандартом программирования для встроенных систем.
Многие разработчики встраиваемых систем используют для программирования микроконтроллеров только язык ассемблера. И существует много убедительных доводов в пользу такого решения. В общем, хорошо написанная на языке ассемблера программа исполняется за меньшее время и занимает в памяти меньший объем, нежели та же программа, написанная на языке высокого уровня. Именно эти характеристики: время выполнения и размер программного кода, — являются критическими для приложения, где элементная база обладает относительно невысоким быстродействием, а память программ ограниченна в объеме.
В одном из курсов по микропроцессорной технике, мы попросили студентов во время лабораторных работ запрограммировать одну и ту же задачу на ассемблере и на языке Си. Пример был следующий: в массиве 16 разрядных чисел без знака необходимо было подсчитать число чисел, равных заданному значению. Поскольку компилятор Си сначала преобразует исходный текст программы в программу на языке ассемблер и только потом превращает ассемблерный текст в коды инструкций микроконтроллера, студенты смогли сравнить собственные ассемблерные программы с аналогичными программами, сгенерированными компилятором. И студенты могли убедиться, что их программы оказались компактнее и более логично написанными, чем ассемблерная программа на выходе компилятора.
В дополнение к уже отмеченным преимуществам, язык ассемблера предоставляет разработчику прямой доступ ко всем без исключения аппаратным средствам МК. Такой доступ возможен и в Си, но с меньшими возможностями, т.е. в ограниченном объеме. Однако это преимущество в полной мере может быть реализовано только высококлассным специалистом. Программист, успешно решающий задачи на ассемблере, должен детально разбираться в алгоритмах преобразования кодов и очень хорошо знать аппаратные возможности МК.
Если Вы программировали на ассемблере, то Вы должны были изучить массу приемов, которые и позволят Вам стать профессионалом высокого уровня. Вы должны были познакомиться не только с деталями архитектуры МК, но и с особенностями его системы команд. Однако при переходе к другому типу МК, Вам придется потратить не так мало времени, чтобы адаптировать свои программы к МК с другой системой команд ассемблера. Такую ситуацию называют несовместимостью кодов.
Недавно один из авторов этой книги должен был выполнить разработку, в которой заказчик определил использование МК компании Atmel. Он никогда ранее не использовал 8-разрядные МК от компании Atmel, но был не прочь их освоить. Поэтому автор решил выполнять проект на Си. Это позволило ему быстрее завершить исполнение заказа. Если бы он решил выполнять проект на ассемблере, то ему потребовалось значительно больше времени не только для изучения архитектуры и алгоритмов работы периферийных модулей, но и системы команд, поскольку МК Atmel существенно отличаются от знакомых автору МК Motorola/Freescale Semiconductor. Кроме того, область применения устройства была такой, что он мог не беспокоиться о размере программы и времени ее выполнения. Поэтому в приведенных условиях выбор языка Си для проекта был логичным и естественным.
В общем, языки высокого уровня позволяют создать такой исходный текст программы, который будет обладать свойством переносимости, его сможет прочесть и понять не только разработчик программы (свойство читабельности), и, наконец, на его основе будет сгенерирован компактный исполняемый машинный код. Кроме того, языки высокого уровня располагают библиотеками математических действий над числами, представленными в различных форматах, в том числе и в формате с плавающей запятой. Структура программы на языке высокого уровня хорошо соотносится с методами структурного проектирования программного обеспечения. Виртуозный программист на языке ассемблера может опровергнуть наши обоснования преимуществ программирования на языках высокого уровня, однако наши выводы основываются на опыте коллег разного возраста, и, соответственно, разной квалификации, а также на собственном опыте.
Поскольку программы на языке высокого уровня обладают более высокой степенью абстракции, эффективность программирования возрастает. Поэтому программист может завершить проект за меньшее время, чем он выполнял бы этот проект на ассемблере. Кроме того, если один и тот же ранее отлаженный код используется в следующих проектах, то эффективность программирования значительно повышается (концепция многократного использования программного кода для типовых функций управления).
Языки высокого уровня обладают важным свойством переносимости программного кода. Это означает, что программа, написанная на языке высокого уровня для одного МК, затем может быть скомпилирована другим компилятором для МК с другим процессорным ядром. И эта программа тоже окажется работоспособной. Для того, чтобы программа обладала свойством переносимости, синтаксис языка высокого уровня для разных компиляторов должен быть абсолютно одинаков. В частности, таким свойством обладает язык Си стандарта ANSI (American National Standards Institute). Разработчики называют его просто «ANSI C». Основная цель стандартизации состоит в том, чтобы обеспечить разработчику возможность написания типовых функций управления один раз с последующим их многократным использованием в разных проектах и для разных микроконтроллеров.
Языки высокого уровня также обеспечивают очень хорошую читабельность кода. Если программа хорошо написана, другой программист, не ее разработчик, может прочесть исходный текст и понять, какой алгоритм реализован и как программа работает. Мы специально не определили, что означает термин «хорошо написана». Мы оставим этот весьма важный аспект до параграфа 2.5, в котором обсудим структурное проектирование.
Еще одним преимуществом языков высокого уровня является простота реализации различных математических вычислений. Например, операции умножения и деления чисел в формате представления с плавающей точкой достаточно сложно реализуются на ассемблере. Строго говоря, имеются специальные библиотеки функций на ассемблере, которые, впрочем, сейчас уже достаточно трудно достать. В тоже время с математическими вычислениями прекрасно справляются языки высокого уровня. Так в главе 4 мы покажем, как на Си записать выражение для вычисления длительности импульса, используя значения моментов времени, полученные с таймера:
TIMP = (216×n) + (Stop_count − Start_count)
Вычисление этого уравнения достаточно сложно выполнить на ассемблере, однако для языка высокого уровня это рутинная задача. Однако не следует забывать, что мы должны включить эти математические операции в код программы, а это увеличит затраты памяти МК на проект.
Подведем итоги нашему короткому сравнению языка ассемблер с языками высокого уровня. Мы можем сделать вывод, что языки высокого уровня пригодны и весьма полезны для программирования встраиваемых систем.
Проведя обзор в Internet, Вы обнаружите достаточно большое число разнообразных компиляторов различных языков высокого уровня для встраиваемых систем. Вы без труда найдете компиляторы Си, С++, Java. Ada, Fortran и некоторые другие. Каждый из этих языков имеет свои преимущества и недостатки. Часто выбор языка программирования может определяться специфическими особенностями задачи или просто пожеланиями заказчика. Детальное сравнение всех перечисленных языков выходит за рамки этой книги и вряд ли возможно.
Для этой книги мы выбрали язык Си, потому что именно он сейчас используется в организациях разработчиков, и он обеспечивает хороший доступ к аппаратным ресурсам микроконтроллеров. Язык Си известен как некоторый промежуточный язык, который объединяет в себе свойства языка высокого уровня и одновременно обеспечивает легкий доступ к регистрам и ячейкам памяти МК. Именно это свойство отмечал один из разработчиков Си господин Ричи (Ritchie).
Язык Си был изобретен в середине 60-ых годов прошлого столетия. Несмотря на почтенный возраст, он так и остался одним из простых и компактных языков высокого уровня. Изначально язык Си был разработан для создания операционной системы Unix, поэтому его характеризуют как «инструмент для создания более сложных инструментов». Язык Си покрывает основные потребности программистов встраиваемых систем без отягощения редко используемыми конструкциями. Более того, программист может достаточно быстро освоить навыки программирования на Си и создавать приложения, которые по быстродействию и затратам памяти близки к ассемблерным. В завершение отметим, что основные конструкции языка Си делают их крайне удобными для реализации принципов структурного программирования.
Наш разговор о Си был бы неполным, если бы мы кратко не остановились на происхождении этого языка. Для более полного погружения в эту тему советуем обратиться к книге [8]. Ниже по тексту параграфа мы даем краткое изложение одного из разделов этой книги.
Первая версия языка Си была разработана в середине 60 ых годов для разработки операционной системы Unix в лаборатории Bell. Один из самых первых разработчиков этого языка, Кен Томсон (Ken Thompson), решил, что требуется язык для создания более сложных языков программирования. Он создал такой язык и назвал его «B». В процессе развития своего творения Томсон постоянно боролся с ограничением ресурсов памяти, что теперь очень похоже на встраиваемые системы. Деннис Ричи (Dennis Ritchie) решил расширить язык «B» свойством генерировать малый по объему код, который сможет соперничать с кодом, написанным на ассемблере. В 1973 году важнейшие свойства этого нового языка «C» были получены.
Возрастающая популярность Си заложена в его переносимости. Компиляторы Си были созданы для многих платформ (так в сообществе разработчиков называют процессорное ядро МК), отчего его популярность еще больше выросла. Наиболее бурно Си стал использоваться в 80 годах, когда стал основным языком для создания программ персональных компьютеров.
Американский национальный институт стандартизации (American National Standards Institute — ANSI) в 1982 году учредил комитет X3J11 для разработки стандарта языка Си. В 1989 доклад комитета был передан в Международную организации стандартизации (International Organization for Standardization — ISO) и международную электротехническую комиссию (International Electrotechnical Commission — IEC) и был утвержден в качестве стандарта ISO/IEC 9899-1990. За этим стандартом последовало неизбежное развитие языка, которое было узаконено в 1999 стандартом ISO/IEC 9899. И Си стал языком, который наиболее часто используется в компьютерной индустрии.
Итак, мы установили, что предпочтительно программировать встраиваемые системы на языке высокого уровня. И в качестве такого языка мы обоснованно выбрали язык Си. Но и ассемблер имеет свои преимущества. Так на каком языке мы все таки будем программировать встраиваемые системы?
Практика применения языка Си и ассемблера показывает, что оптимальный результат, как с точки зрения экономии времени на разработку, так и по времени исполнения программы, можно получить, используя в одном проекте сразу два языка программировании: и Си, и ассемблер. Основная часть прикладной программы, в которой производятся преобразования данных, будет написана на СИ, в то время, как критичные по времени реализации фрагменты алгоритма, следует оформить на ассемблере. Кроме того, ассемблер иногда используют для программной поддержки некоторых внешних по отношению к МК периферийных ИС. Драйверы обмена с такими ИС обычно требуют многократного переключения отдельных линий портов МК, что в компиляторах Си для некоторых МК удобнее выполнить на ассемблере. Еще один случай обязательного включения ассемблерного фрагмента в текст основной программы на Си мы продемонстрируем на примере использования команд ассемблера 68HC12/HCS12 для преобразования данных по правилам нечеткой логики (см. гл. 7).
Ранее мы упомянули, что конструкции языка Си как нельзя лучше сочетаются с методом структурного проектирования. Настало время познакомиться с этим методом.
Несколько следующих параграфов мы посвятим изложению основных идей метода структурного проектирования. Для создания этого раздела мы использовали материалы, изложенные в [1, 7], а также опыт собственных разработок. Метод структурного проектирования не гарантирует обязательного успешного завершения проекта. Однако этот метод значительно увеличивает вероятность создания за ограниченное время качественной системы, полностью совместимой с управляемым объектом.
Теория. Метод структурного проектирования — это регламентированная последовательность действий, которая позволяет разработать структуру аппаратных и программных средств встраиваемой системы, удовлетворяющих техническим требованиям к проектируемому устройству.
Первым шагом этой последовательности действия является как можно более полное описание технических требований к будущей системе. В подавляющем большинстве случаев технические требования формулирует не тот, кто потом реализует систему. Поэтому технические требования должны быть как можно более точно доведены до исполнителя. Исполнитель обязан подробно исследовать предложенные ему технические требования, понять их обоснованность и согласованность. Представьте себе трагедию разработчика, который выполнил систему, работающую правильно, но по неправильному техническому заданию! Разработчик потратил время и деньги на проект, но он не нужен заказчику! Кто виноват? Вывод: структурное проектирование использует определение проблемы как путь к определению решения этой проблемы.
Применение. На протяжении всего этого параграфа мы будем иллюстрировать применение выдвинутых концепций на примере разработки системы управления стереоусилителем. Прототип нашего примера контроллер стереоусилителя, был разработан доктором Паррисом Нилом (Parris Neal) из Аэрокосмической Академии в Колорадо. Парис — превосходный инженер, разрабатывает стереоусилители мирового уровня. Любой из его проектов — это произведение искусства. Паррис разработал стереоусилитель, который может принимать звуковые сигналы от шести различных источников. Пользователь должен выбрать сигнал либо с помощью переключателей на передней панели корпуса усилителя (рис. 2.1), либо с дистанционного пульта управления, связанного со стереоусилителем по инфракрасному каналу. Паррис попросил первого автора этой книги разработать микропроцессорный контроллер для этого усилителя, используя 8 разрядный RISC МК компании Atmel. Ему было интересно на практике исследовать возможности МК Atmel в качестве низкостоимостного МК для следующих проектов.
а) Вид спереди
б) Плата с микроконтроллером
в) Вид сзади
Рис. 2.1. Внешний вид стереоусилителя с дистанционным управлением
После первого обсуждения были выявлены следующие технические требования к проекту:
• Необходимо разработать микропроцессорный контроллер для управления стереоусилителем;
• Контроллер должен обеспечить подключение ко входу стереоусилителя одного их шести источников звукового сигнала. Выбор источника сигнала может осуществляться оператором с пульта управления или с дистанционного пульта управления, связанного с основным устройством по инфракрасному каналу.
• При разработке устройства управления необходимо использовать МК компании Atmel.
После знакомства с этими первыми техническими требованиями был создан список вопросов, который должен был бы помочь разработчику более полно понять все особенности данного проекта:
• Что конкретно должен делать контроллер в ответ на выбор номера канала воспроизведения?
• Кто несет ответственность за интерфейс сопряжения между контроллером и стереоусилителем?
• Каковы электрические характеристики сигналов с передней панели усилителя и с удаленного пульта управления?
• Какие сигналы должен формировать контроллер для управления переключением каналов усилителя?
В ответ на эти вопросы заказчик (доктор Паррис Нил) выдал детальное словесное описание желаемых режимов работы своего устройства на четырех страницах. Он также нарисовал обобщенную блок схему алгоритма процесса управления. На основе этого описания нами совместно в процессе непрерывного обсуждения были созданы структурная схема контроллера и более подробная блок схема алгоритма. Далее мы два месяца переписывались по электронной почте, чтобы уточнить все детали устройства. Заметьте, в течение этих двух месяцев ни одной строки кодов программы не было написано!
Теория. Тщательный детальный анализ требований заказчика должен предшествовать собственно процессу проектирования. Эти требования затем превращаются в детальное описание технических характеристик будущего устройства. Технические характеристики содержат полное описание режимов функционирования устройства, включая реакцию устройства на каждое входное воздействие, а также алгоритмы обработки данных и обработки ошибок. Все пункты описания технических характеристик устройства, которые могут толковаться двояко, должны быть совместно обсуждены заказчиком и исполнителем с целью устранения разногласия по каждому пункту. Когда формулирование порядка работы устройства закончено, можно задуматься о способах воплощения этого устройства.
Вторым шагом структурного проектирования является разбиение поставленной задачи (системы) на несколько иерархически взаимосвязанных более мелких задач (подсистем). Что это все означает? Мы разобьем систему на несколько функционально законченных подсистем, и определим взаимосвязи между ними. Поскольку для каждой такой подсистемы определены функции, но техническая реализация этих функций пока еще не ясна, разработчики именуют их «черными ящиками».
Каждый такой «черный ящик» — это хорошо описанный блок, который выполняет некоторую законченную функцию. Мы знаем его входы и выходы, но пока не знаем все детали функционирования. Мы продолжаем делить систему на такие «черные ящики» до тех пор, пока функция каждого выделенного блока не станет полностью ясной для понимания. Кроме того, в процессе разделения на блоки и создания из них иерархической структуры проектируемой системы мы показываем связи между блоками.
Третий шаг структурного проектирования — это создание графического образа работы системы, который способствует более полному пониманию внутренних связей между блоками в процессе функционирования устройства. Для создания графического образа системы применяются структурные схемы и диаграммы работы. Применение. Как было ранее упомянуто, мы использовали детальные структурные схемы и блок схемы алгоритмов для обсуждения с заказчиком технических характеристик проектируемой системы. Было бы чрезвычайно трудно превратить 4 страницы текста с описанием требований к устройству во взаимосвязанную картину без использования этих графических образов.
Теория. Структурная схема алгоритма функционирования системы (или ее аппаратного обеспечения, или программы управления) — это основной результат структурного проектирования, который иллюстрирует, каким образом большая система (или электрическая схема, или программа управления) состоит из модулей, которые изображены блокам на рисунке. Стрелки используются для того, чтобы показать, что один из модулей системы формирует сигналы для другого модуля. В случае структурной схемы программного обеспечения один модуль вызывает другой, к которому направлена стрелка. Стрелка с кружком показывает, что один программный модуль передает данные другому модулю. Блок-схема алгоритма тоже очень полезный инструмент, который позволяет проследить процесс преобразования данных на протяжении исполнения всей программы. Однако блок-схемы алгоритма читабельны только для относительно небольших алгоритмов, когда эти схемы умещаются на одной или двух страницах. В универсальном языке моделировании блок схемы алгоритмов заменены на диаграммы работы. Мы вернемся к этому вопросу в 2.7.
Применение. Структура программного обеспечения контроллера управления стереоусилителем показана на рис. 2.2. Блок схема алгоритма — на рис. 2.3. Проанализировав эти рисунки, можно увидеть, что структура программы управления показывает взаимосвязь отдельных модулей программы, в то время, как блок схема алгоритма является графическим описанием порядка функционирования этой программы. В этот момент, Вы можете подумать: «Наконец-то! Теперь можно кодировать программу!». Но нет, существует еще несколько обязательных этапов структурного проектирования, которые должны предшествовать написанию текста программы.
Рис. 2.2. Структура программы управления стереоусилителем
Рис. 2.3. Блок-схема алгоритма управления стереоусилителем
Теория. Следующий шаг структурного проектирования — детальное определение функций каждого блока. Для каждого выделенного на предыдущих этапах «черного ящика» определяются функции входов и выходов. В случае программного обеспечения определяются данные, которые передаются программным функциям и возвращаются ими. Для описания связей между входами и выходами блоков используют псевдокодирование.
Этап псевдокодирования определить принципы программной реализации отдельных блоков структурной схемы. После завершения этого этапа разработчик будет иметь полную структурную схему, которая описывает поставленную задачу в целом, и множество детализированных блоков, которые описывают отдельные функции проектируемого устройства.
Применение. В проекте контроллера стереоусилителя мы разместили псевдокод непосредственно в графические образы блок схемы алгоритма (рис. 2.4). Вы можете убедиться, что теперь для каждого блока мы имеем полное перечисление его функций, после которого можно приступить к непосредственному написанию текста программы.
Рис. 2.4. Псевдокод программы управления стереоусилителем
Теория. Следующий шаг структурного проектирования — написание исходного текста программы на Си, в редких случаях на ассемблере. Причем под написанием программы понимается не только создание исходного текста программы, но и его поэтапная отладка. Отладка может производиться с использованием трех стратегий.
Первая стратегия соответствует методу проектирования сверху вниз. Сначала пишется и отлаживается основная функция (main.c) программы управления. При этом все вызываемые функции симулируются пустыми программными модулями. По мере продвижения сверху вниз, все большее число функций наполняется содержанием, и для них записывается исходный текст программы.
Вторая стратегия соответствует методу проектирования снизу вверх. В соответствие с этим методом сначала пишутся и отлаживаются пока несвязанные функции нижнего уровня. Постепенно разработчик переходит к функциям более высокого уровня, выстраивая иерархические связи в соответствие со структурной схемой.
Третья стратегия сочетает в себе две предыдущие. Попеременно пишутся и отлаживаются функции сверху и снизу структурной схемы. Объединение проекта в целом осуществляется на каком то из средних уровней.
До настоящего времени мы рассматривали все шаги метода структурного проектирования преимущественно в приложении к разработке программного обеспечения встраиваемой системы. Однако эти же этапы в полной мере применимы также к проектированию аппаратного обеспечения системы.
Применение. В проекте контроллера стереоусилителя мы специально разработали аппаратный симулятор, который использовался на этапе отладки программного обеспечения. Этот симулятор состоял из некоторого количества переключателей для имитации органов управления на передней панели стереоусилителя, и светодиодов, которые отображали состояние сгенерированных контроллером сигналов управления. Функциональная схема симулятора приведена на рис. 2.5. С помощью этого симулятора мы провели отладку, а затем поэтапно проверили функционирование разработанной программы. Доктор Парис Нил настоятельно попросил нас проверить программное обеспечение в автоматическом режиме, т.е. без применения программных средств отладки, по каждому из возможных сценариев работы. И только затем мы разместили контроллер в корпусе стереоусилителя и приступили к комплексным испытаниям законченного изделия.
Рис. 2.5. Функциональная схема имитатора для тестирования программы стереоусилителя
Теория. Заключительным этапом метода структурного проектирования является определение критериев, по которым можно будет сделать вывод, что устройство удовлетворяет поставленным техническим требованиям. Это предполагает разработку стратегии верификации, отладки и тестирования разработанного устройства. Программа верификации — это не одно и тоже, что программа тестирования. Тем не менее, тестирование — это значительная часть процесса верификации. Для того, чтобы правильно испытать систему, разрабатывается специальная программа тестирования, которая позволяет полностью проверить режимы работы прибора и их соответствие техническим требованиям. Основной задачей является выявить и зафиксировать имеющиеся ошибки, и очень важно убедиться, что проект соответствует планируемому поведению.
Ошибки в проекте могут быть различной породы. Мы кратко рассмотрим их в порядке возрастания неприятностей от них.
Самыми простыми для устранения являются синтаксические ошибки. Эти ошибки выявляет компилятор в процессе обработки исходного текста программы. Компилятор выдает сообщения двух типов: предупреждения («Warning») и ошибки («Error»). Предупреждения выдаются компилятором в тех случаях, когда компилятору «кажется», что некоторые конструкции программы неудачны. При этих ошибках код на выходе компилятора получается. Несмотря на то, что код будет образован, Вы должны будете принять решение по поводу исправления или нет этих мест в программе. Ошибки с сообщением «Error» не позволят Вам создать файл загрузочного модуля, поэтому Вам придется заняться их немедленным устранением. При этом следует знать, что всего лишь одна синтаксическая ошибка может вызвать генерацию сразу нескольких сообщений об ошибках.
Ошибки исполнения в реальном времени можно выявить только в процессе выполнения программы. Они обычно приводят к разрушению алгоритма управления. Например, если Вы при написании текста программы для выполнения задержки на 3 мс неправильно посчитали число отсчетов внутреннего генератора тактирования, то программа будет успешно исполняться, но задержка будет не соответствовать 3 мс. Ошибки исполнения в реальном времени достаточно сложно выявляются. Составление специальной методики тестирования поможет Вам выявить подобные неисправности.
Наиболее неприятный тип ошибок — это неправильные начальные условия для составления программы. В этом случае может получиться, что программа полностью удовлетворяет требованиям, но сами технические требования неправильные. Никакие маленькие коррекции не исправят положения дел. Вот почему мы обязательно должны затратить так много времени на разбор и выработку всех условий работы устройства.
Всеобъемлющее тестирование может использовать технику сверху вниз, когда сначала исследуется общее поведение системы, а затем детали поведения в отдельных режимах. А может наоборот, снизу вверх, когда тестирование начинается с проверки правильного функционирования драйверов периферии. Иногда используется смешанная техника. В любом случае, методика тестирования определяется конкретным проектом. Хороший тест проверяет также живучесть (робастность) программного обеспечения. Под живучестью понимают ситуацию. При которой на вход системы могут поступить не предполагаемые комбинации сигналов, и при этом программное обеспечение должно оставаться работоспособным и формировать сигналы управления, по крайней мере, не создающие аварийной ситуации для исполнительных устройств.
Применение. В процессе тестирования контроллера стереоусилителя были выявлены ситуации, которые не были предусмотрены начальными установками на проектирование программы. Например, если пользователь выбрал устройство для воспроизведения, то предыдущее устройство отключается от входа усилителя, а следующее выбранное подключается. При этом не подумали, а что следует делать контроллеру, если пользователь с пульта управления выбрал то же устройство, которое уже подключено. Контроллер в соответствие со сценарием сначала отсоединял устройство, а затем его же коммутировал опять. Это вызывало неприятные для слуха шумы. Только при тестировании устройства на реальном объекте мы смогли выявить эту неисправность и достаточно просто исправили программу.
Следует заметить, что процесс тестирования занимает много времени, поскольку он многоступенчатый. Если какие либо ошибки обнаружены, то вносятся исправления в исходный текст программы, и все тесты должны быть проведены заново.
Итак, мы закончили свое первое знакомство с методом структурного проектирования. В следующем разделе мы остановимся на вопросах документирования процесса разработки.
Теория. Многие начинающие программисты уверены, что документирование программного обеспечения проекта — это добавление некоторого количества коротких комментариев к работающей версии программы. Однако хорошее документирование программы значительно важнее самого программного обеспечения. Хорошая документация содержит все разработанные на предыдущих этапах структуры, которые были обсуждены нами в предыдущем разделе. Все эти структуры помогают нам не только закодировать программу, но и содержат информацию о том, как программа работает.
Полная документация на программное обеспечение содержит комментарии, письменное описание принципов построения программы, технические условия на написание программы, исходный текст программы, руководство пользователя, историю разработки программы и ее модификаций. Весь этот набор документов может быть разделен на внешнюю и внутреннюю документацию. Внешняя документация состоит из специально написанного текста, который поясняет, как работает программа. Внутренняя документация включает полный набор читаемых и понимаемых документов, который необходим для легкого исправления кода. Внутренняя документация состоит из комментариев, исходного текста программы, структуры и специальных записей.
Комментарии помогают читателю определить, что программист хотел сделать в любой точке программы. В нашем контроллере стереоусилителя мы имели 4 страницы комментариев, предшествующих программе, которые со всей полнотой описывали работу системы. Мы также написали дополнительные комментарии по алгоритму работы программы, а также описание каждой отдельной функции. Более того, мы комментировали каждую строку исходного текста программы. Это может показаться избыточным. Но чем больше времени затрачено на составление комментариев, тем меньше времени понадобится для поддержания этого кода.
Самодокументирующий код означает, что имена переменных констант и функций выбираются такими, чтобы было интуитивно понятно ее назначение. Например, если функция называется «delay_3ms», то сразу понятно, что функция формирует задержку 3 мс.
Аккуратное форматирование исходного текста программы с помощью скобок и отступов позволяет показать структуру программы. Например, выполняемые в цикле команды записываются с отступом, позволяя легко идентифицировать набор выполняемых в цикле операций.
Применение. Несколько месяцев спустя после завершения разработки, заказчик (доктор Парис Нил) попросил меня внести изменения в алгоритм управления стереоусилителем. Благодаря хорошим комментариям автор быстро восстановил в памяти ход вычислительного процесса и внес изменения в исходный текст программы за 20 мин. Важно, что после этого определенное количество времени было затрачено на внесение дополнительных комментариев. Если бы мы не документировали программу качественно сразу, мы не смогли бы произвести необходимые доработки быстро.
Язык Си как нельзя лучше сочетается со структурным проектированием. Программа на языке Си состоит из основной программы (main.c), которая описывает всю задачу. Основная программа вызывает программы функции, которые выполняют определенные действия. Программы функции можно рассматривать как реализацию модулей, которые мы обсуждали на этапе структурной декомпозиции проекта. Программы функции могут, в свою очередь, вызывать другие функции, в соответствие с иерархической структурой проекта.
Метод проектирования сверху вниз может быть легко реализован на Си. Основная программа показывает общий ход реализации алгоритма управления. Чем дальше Вы погружаетесь в функции все более низкого уровня, тем более детально Вы знакомитесь с особенностями алгоритма управления.
С темой составления качественной документации проекта тесно связаны вопросы ведения рабочих тетрадей. В этом параграфе мы рассмотрим, зачем и почему нужны рабочие тетради. Представленный Вам материал в сокращенном виде является изложением статьи наших коллег, которая была написана в 1990 г. [5].
Рабочие тетради предназначены для регистрации процесса научного поиска, обдумывания различных решений для проектов, сравнения и анализа предложенных решений, для записи результатов испытания собственных устройств. В инженерной практике одной из основных причин ведения рабочих тетрадей является накопление положительных результатов своей деятельности, которые потом, даже по прошествии нескольких лет, могут быть использованы в новом проекте, для подачи заявки на изобретение, могут быть включены в работу для присвоения научной степени.
Поскольку во многих организациях рабочая тетрадь является официальным документом, то ее ведение регламентируется жесткими правилами:
1. Листы тетради должны быть хорошо скреплены, так, чтобы страницы не могли быть из нее удалены свободным образом. Если же какие то страницы вырываются, то для этого должны быть веские причины.
2. Все записи должны делаться последовательно несмываемыми чернилами.
3. Страницы тетради должны быть последовательно пронумерованы.
4. Каждая запись должна сопровождаться датой. При этом дата не должна быть двояко трактуемой. Запись «09 мая 2004 г.» лучше, чем «9/5/2004».
5. Если в предшествующие записи вносятся изменения, то эти изменения должны сопровождаться простановкой даты.
6. Нельзя стирать кажущиеся Вам ошибочными сведения. Их необходимо подчеркнуть или выделить маркером.
7. Законченный материал должен быть помечен символами «X» или «Z» для уверенности, что ничего не было добавлено позже.
Когда специалиста патентного отдела спрашивают, что должно быть включено в рабочие тетради, от отвечает «Все!». Для того, чтобы не заниматься излишним правописанием, но все таки выполнить требования по заполнению рабочих тетрадей, последовательно ответьте себе на следующие вопросы: что, кто, когда, где, почему и как? Когда Вы подготовите ответы на эти вопросы, выберите подходящий стиль изложения. Помните, что при необходимости, другой специалист должен понять проект и продолжить его.
Рабочие тетради, когда они ведутся должным образом, представляют собой прекрасный документ о содержании проекта. В следующем параграфе мы рассмотрим технику документирования алгоритмов с помощью блок схемы алгоритма.
Теория. Универсальный язык моделирования (Unified Modeling Language — UML) — это язык для определения, представления, проектирования и документирования программных систем. Основными составляющими языка UML являются элементы, связи, механизмы расширения и диаграммы. Универсальный язык моделирования предоставляет разработчику метод графической иллюстрации и имитационного моделирования системы, которая основана на программном принципе управления. Этот язык позволяет стандартизировать графическое изображение операций в системе с целью моделирования ее алгоритма работы в общем виде, без составления исходного текста управляющей программы. Универсальному языку моделирования посвящены более 100 научных монографий. Мы рассмотрим лишь малую часть сведений об этом языке, которые будут использованы нами для проектирования встраиваемых систем на протяжении всей этой книги. Если Вас будет интересовать получение более широких сведений по этой теме, обратитесь к литературе, рекомендованной в конце главы.
Свою историю универсальный язык моделирования ведет с начала 90х годов. В 1994 году Грэйди Буч (Grady Booch), Джеймс Рэмбо (James Rambaugh) и Ивар Якобсон (Ivar Jacobson) начали объединять несколько методов объектно ориентированного моделирования в фирме Rational Software. Их целью была разработка методов сокращения времени реализации программных продуктов для промышленности. И уже в 1995 году была представлена спецификация метода, названного «Unified Method». Первая версия универсального языка моделирования была принята консорциумом OMG (Object Management Group) в январе 1997 года. Утвержденная же в сентябре того же года версия UML 1.1 была принята на вооружение основными компаниями — производителями программного обеспечения, такими, как Microsoft, IBM, Hewlett Packard.
Визуальные модели универсального языка моделирования широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. В практике эксплуатации программных информационных систем постоянно приходится решать такие задачи как перераспределение вычислений и данных, обеспечение проведения параллельных вычислений, обеспечение безопасности доступа к информационным системам, оптимизация балансировки нагрузки систем, устойчивость к сбоям и многое другое. Основные виды визуальных моделей UML (универсального языка моделирования): диаграммы сценариев, диаграммы взаимодействия объектов, диаграммы классов, диаграммы состояний, диаграммы модулей и компонентов, диаграммы действий [2,3]. Графические средства представления алгоритмов позволяют переводить модели UML в исходный код объектно-ориентированных языков программирования, что значительно ускоряет процесс разработки. Поэтому универсальный язык моделирования прекрасно зарекомендовал себя на множестве успешных программных проектов. Мы не будем касаться объектно ориентированного программирования в нашей книге. Поэтому мы используем лишь малую часть возможностей универсального языка моделирования для иллюстрации последовательности действий в проектируемых нами программ для встраиваемых систем.
Синтаксис языка универсального моделирования — условные графические обозначения различных типов операторов, которые позволяют составить блок схему алгоритма. Блок схема алгоритма — графическое изображение логической структуры алгоритма. Каждое действие алгоритма представляется в виде геометрической фигуры — условного графического обозначения оператора UML.
Основные типы операторов представлены на рис. 2.6. Программа начинается с оператора начального запуска и заканчивается оператором останова. Множество различных действий совершается под управлением программы в процессе ее выполнения. Каждое действие отображается оператором процесса, который производит изменение значения, формы представления или расположения данных. Оператор процесса может иметь любое количество входов, но только один выход. Переход от одного оператора к другому обозначается стрелкой. Если в процессе выполнения очередного действия производится анализ некоторого внешнего сигнала или внутреннего состояния программы с последующим выбором, по какому пути продолжить исполнения программы, то такое действие отображается условным оператором (другое название — оператор решения). Условный оператор имеет один вход и несколько выходов. После выполнения действий условного оператора программа может «избрать» только один путь. Поэтому условия, по которым определяется направление выхода из оператора решения, должны быть взаимоисключающими. Оператор слияния (поглощения), в соответствие со своим названием, позволяет соединить несколько отдельных ветвей алгоритма в одну. В завершение мы включили два оператора, которые характерны для структурного программирования. Это операторы ветвления и объединения, которые предназначены для отображения работы систем с параллельными вычислителями [2,3]. В качестве первого примера использования условных графических обозначений UML мы представили средствами универсального языка моделирования процесс структурного проектирования, блок схема алгоритма которого приведена на рис. 2.7. На рис. 2.8 тот же процесс представлен с большей степенью подробности, что немедленно привело к усложнению блок схемы алгоритма.
Рис. 2.6. Условные графические обозначения операторов универсального языка моделирования UML
Рис. 2.7. Блок схема алгоритма структурного проектирования
Рис. 2.8. Блок схема алгоритма разработки и тестирования программного обеспечения встраиваемой системы
Основная идея, которую мы стремились развить на протяжении всей этой главы, состоит в том, что подлежащая реализации большая задача должна быть разбита на ряд малых взаимосвязанных задач. Идея декомпозиции задач лежит в основе метода структурного проектирования, который в равной степени применим к проектированию, как аппаратных, так и программных средств, что делает его особенно полезным при разработке встраиваемых систем. Более того, этот метод может быть использован на этапе постановки задачи, который предшествует структурному проектированию аппаратных и программных средств системы.
В качестве темы дипломного проектирования одному из авторов этой книги было предложено разработать систему управления медицинским лазером для лечения различных расстройств зрения. Около шести месяцев он провел в библиотеке, изучая технологии лазерной глазной хирургии. В итоге, его представления о функциях контроллера управления хирургическим лазером изменились коренным образом в сторону их увеличения. Результаты своего исследования автор воплотил в структурной схеме рис. 2.9, которая отражает все возможные функции системы автоматизированного управления хирургическим лазером и их взаимосвязь в проекте. Обратите внимание, что в данном случае метод структурного проектирования использован для систематизации функций системы управления, когда задачи проектирования аппаратного и программного обеспечения системы еще не поставлены.
Рис. 2.9. Структура функций медицинского лазера
В этой главе мы провели сравнительный анализ преимуществ и недостатков языка ассемблер и языков программирования высокого уровня для разработки программного обеспечения встраиваемых систем. Среди языков высокого уровня мы сделали выбор в пользу языка Си, способного генерировать программный код, сравнимый по быстродействию и затратам памяти с кодом языка ассемблер. Мы установили, что оптимальный результат может быть получен при программировании встраиваемых систем одновременно на Си и на ассемблере. Мы кратко познакомились с методом структурного проектирования и универсальным языком моделирования UML. Мы также познакомились с применениями метода структурного проектирования для определения функций управления медицинским лазером и для разработки структуры программного обеспечения контроллера стереоусилителя. Мы кратко рассмотрели условные графические обозначения операторов UML и познакомились с примерами описания алгоритмов посредством составления блок схемы алгоритма из операторов UML.
1. Dale, Nell, and Susan С. Lilly. Pascal Plus Data Structures. 4th ed. Englewood Cliffs, NJ: Jones and Bartlett, 1995.
2. Douglass, Bruce Powel. Real Time UML Developing Efficient Objects for Embedded Systems. 2nd ed. Boston: Addison Wesley, 2000.
3. Fowler, Martin, with Kendall Scott. «UML Distilled A Brief Guide to the Standard Object Modeling Language. 2nd ed. Boston: Addison Wesley, 2000.
4. Kobryn, Chris. «UML 2001.» Communications of the ACM 42, no. 10, (October 1999): 29–37.
5. МсСоnnасk, J. В., R. K. Morrow, H. F. Bare, R. J. Bums, and R. L. Rasmussen «The Complementary Roles of Laboratory Notebooks and Laboratory Reports.» Paper presented at the annual meeting of the American Society for Engineering Educators Toronto, Canada, 1990.
6. Pack, Daniel, and Steven Barrett. 68HC12: Theory and Applications. Upper Saddle River, NJ: Prentice Hall, 2002.
7. Page Jones, Meilir. The Practical Guide to Structured Systems Design. 2nd ed. Upper Saddle River, NJ: Yourdon Press, 1988.
8. Ritchie, Dennis M. «The Development of the С Language.» Paper presented at а meeting of the Association for Computing Machinery, Second History of Programming Languages Conference, Cambridge, МА, 1993.
9. Wakerly, John F. Digital Design Principles and Practices. 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2000.
1. Проведите сравнение достоинств и недостатков применения языка Си и языка ассемблер для программирования встраиваемых микропроцессорных систем.
2. Опишите следующие свойства метода структурного проектирования: переносимость, устойчивость, читабельность.
3. Какие другие компиляторы с языков высокого уровня, кроме компиляторов Си, Вы знаете? Укажите их источники в Internet.
4. Каковы основные причины быстрого распространения языка Си для программирования встраиваемых систем?
5. Что такое «черный ящик»?
6. Каково различие между структурой и блок схемой алгоритма?
1. Преобразуйте блок схему алгоритма рис. 2.3 в диаграмму действия UML.
2. Что называют псевдокодированием?
3. Объясните различия между методами проектирования сверху вниз и снизу вверх?
4. Каковы различия между внешней и внутренней документацией?
5. Поясните необходимость ведения рабочей тетради.
1. Программно аппаратный дуализм встраиваемой микропроцессорной системы?
2. Представьте себе, что Вас попросили разработать портативную метеостанцию, которая может быть установлена в некотором удалении от центрального поста и будет сообщать этому посту состояние окружающей среды на месте размещения. Метеостанция оснащена следующими приборами:
• Анемометром — прибором для измерения скорости ветра. Анемометр представляет собой колесо с лопастями, которое вращается со скоростью, пропорциональной скорости ветра. Будем считать, что электронная схема анемометра выдает один импульс амплитудой 5 В на один оборот колеса.
• Барометром — прибором для измерения атмосферного давления. На аналоговом выходе электронного преобразователя сигнала барометра формируется напряжение в диапазоне 0…5,0 В. Давлению в 640 мм рт. ст. соответствует напряжение 0 В, давлению 810 мм рт. ст. — напряжение 5,0 В. Преобразователь обладает линейной передаточной характеристикой.
• Гигрометром — прибором для измерения влажности воздуха. Гигрометр также оснащен электронным преобразователем сигнала с линейной передаточной характеристикой. Относительной влажности 0% соответствует напряжение 0 В, влажности 100% — напряжение 5,0 В.
• Термометром — прибором для измерения температуры воздуха. Температуре 50°C соответствует напряжение 0 В, температуре +120°C — напряжение 5,0 В. Передаточная характеристика преобразователя сигнала — линейная.
• Флюгером — прибором для определения направления ветра. Напряжение на выходе электронного преобразователя прямо пропорционально углу поворота флюгера. Напряжение 0 В формируется при положении стрелки «север», далее напряжение линейно возрастает, при положении стрелки «юг» напряжение равно 2,5 В, и на повороте в 180 град. эл. продолжает линейно возрастать до 5,0 В.
Проектируемая система должна уметь делать следующее:
• Станция должна периодически, один раз в 15 мин. передавать по радиоканалу информацию об измеренных значениях величин с выхода датчиков. Если скорость ветра превышает установленное значение, защитная панель станции должна автоматически закрывать окно солнечной батареи (рис. 2.10).
Рис. 2.10. Портативная метеостанция
• Измеритель уровня осадков должен периодически очищаться.
• Кроме передачи информации об измеренных значениях с выхода датчиков, аналогичная информация должна отображаться на местном жидкокристаллическом индикаторе.
Разработайте структуру функций для управления такой станцией. Разработка передатчика не является Вашей задачей, Вы должны лишь подготовить собранные данные для передачи по радиоканалу.
3. Выберите один из домашних приборов, которые управляются встроенным контроллером. Разработайте структуру функций управления для одного из этих приложений. Выберите прибор из списка: микроволновая печь, холодильник, музыкальный центр.
4. Разработайте диаграмму действий UML для выбранного домашнего прибора.