MATLAB.Exponenta
–Û·Ë͇ Matlab&Toolboxes

Simulink Blocksets\Fixed-Point Blockset

К.Г.Жуков,"Справочное руководство пользователя Fixed-Point Blockset"

В оглавление

ПРИМЕНЕНИЕ ПАКЕТА FIXED - POINTBLOCKSET В РАЗРАБОТКЕ УСТРОЙСТВ РЕАЛЬНОГО ВРЕМЕНИ

1. Введение

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

В статье рассматривается специфика задач разработки и отладки устройств на гибридных микропроцессорах DSP 56800 фирмы Motorola. Описываются методы их решения и применяемые для этих целей технические и программные средства, которые собирательно можно назвать инструментальными средствами разработки и отладки.

2. Выбор средств для реализации МПС

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

Ни аппаратные средства, ни программное обеспечение не существуют независимо, поэтому указанное преобразование никогда не может быть завершено полностью. Всегда существуют программы управления аппаратными средствами и аппаратура, при помощи которой реализуются программные алгоритмы. Это утверждение основано на опыте, и его принимают как аксиому.

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

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

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

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

3. Методология объектно-ориентированного анализа и проектирования

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

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

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

Разделение процесса разработки на отдельные этапы способствовало становлению концепции жизненного цикла про-граммы. Под жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. Стандарт ISO/IEC 12207, хотя и опи-сывает общую структуру ЖЦ программы, не конкретизирует детали выполнения тех или иных этапов. Согласно принятым взгля-дам ЖЦ проекта состоит из следующих фаз (этапов):

  • Анализа предметной области и формулировки требований
  • Разработки структуры
  • Реализации проекта (программно-аппаратной/программной)
  • Внедрения
  • Сопровождения
  • Отказа от использования

На этапе анализа предметной области и формулировки требований осуществляется определение функций, которые должна выполнять разрабатываемая система (устройство), а также концептуализация предметной области. Результатом данного этапа должна явиться некоторая концептуальная схема, содержащая описание основных компонентов и тех функций, которые они должны выполнять.

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

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

Этап программирования выполняется в инструментальной среде быстрой разработки приложений (Rapid Application De-velopment, RAD). Появление RAD - инструментариев позволило существенно сократить сроки и затраты на выполнение этого этапа. Результатом данной фазы является прикладное обеспечение, которое обладает требуемой функциональностью для решения необходимых задач в конкретной предметной области.

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

Для создания проекта обычно используется спиральная модель ЖЦ (рис.1).


Рис.1 Спиральный процесс проектирования

На начальных этапах ЖЦ реализуемость технических решений проверяется путем создания прототипов.

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

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения/систем (Computer Aided Sofware/System Engineering, CASE) CASE - средства позволяют проектировать практически любые системы на компьютере.

Инструментальные CASE - средства и диапазон их практического применения в большей степени зависят от удачного определения семантики и нотации соответствующего языка моделирования. Специфика унифицированного языка моделирования (Unified Modeling Language, UML) заключается в том, что он определяет семантическую метамодель, а не способы представления или реализации компонентов с конкретным интерфейсом.

Из более чем 800 компаний и организаций, входящих в настоящее время в состав консорциума OMG (Object Management Group) особую роль продолжает играть Ration Software Corporation, которая стояла у истоков разработки языка UML. Эта компания разработала и выпустила в продажу одно их первых инструментальных CASE - средств Ration Ruse 98, в котором был реализован язык UML [2, 3, 4, 5].

Встраиваемые системы реального времени, изначально описываемые языком моделирования ROOM (Real - Time Object - Oriented Modeling - объектно-ориентированное моделирование систем реального времени), в настоящий момент специфицирова-ны с использованием стандарта UML. Это достигается путем использования мощных механизмов расширения UML.

4. Преимущества технологий MathWorks

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

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

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

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

Выбор CASE- средств для разработки устройств (систем) реального времени представляет еще более сложную проблему. Инструментальные пакеты MathWorks используют интуитивно понятный интерфейс и дают возможность профилирующему спе-циалисту, надеясь только на свои силы, наиболее полно реализовать свои замыслы. Пакеты расширения MathWorks, включая Simulink, Fixed-Point Blockset и Real-Time Workshop, новое поколение средств автоматизированной разработки систем на базе МП.

Simulink использует язык программирования сверхвысокого уровня (VHLL). Он является языком программирования следующего поколения [6], удовлетворяющим требованиям ООП.

Real-Time Workshop (RTW) автоматически генерирует C- код из S - модели проектируемого цифрового устройства и практически не требует его дальнейшей коррекции.

Основные преимущества использования технологий MathWorks можно охарактеризовать следующими доминирующими положениями:

  • Инструментальные средства используют методологию ООАП
  • Являются высокоэффективной CASE- средой для разработки инженерных и научно-технических приложений реального времени
  • Обеспечивают интерактивный, графический процесс разработки устройств реального времени
  • Имеют уровень абстракции для описания устройств наиболее понятный разработчику по сравнению с много-численными диаграммами UML
  • Строятся по принципу открытой архитектуры, что гарантирует поддержку аппаратных средств большинства ведущих производителей DSP
  • Обеспечивают полный спиральный цикл (рис.1) разработки устройств реального времени
  • Функциональные возможности могут быть расширены в соответствии с требованиями конкретной разработки
  • Большинство разработанных новшеств, как правило, повторяются конкурентами с естественным значитель-ным отставанием

5. Практические результаты

На кафедре "Прикладной математики и информатики" разработан для учебных и научных целей пилотный вариант инст-рументального комплекса (ИКРВ). Структурная схема ИКВР представлена на рис.2.


Рис.2. Структурная схема инструментального комплекса

В состав комплекса входят следующие аппаратные и программные средства:

  • ПК
  • Оценочный модуль с целевым процессором(56F800 Demo Board)
  • MatLab 6.5 R13 с пакетами расширения (Simulink, Fixed-Point Blockset, Real-Time Workshop)
  • Среда разработки сигнальных процессоров (CodeWarrior Development Studio for Motorola 56800/E Hybrid V6.1) фирмы Metrowerks

Оценочный модуль и ПК соединяются двумя стандартными интерфейсными кабелями (LPT, COM). Через параллельный LPT - порт осуществляется загрузка исполняемого кода в целевой процессор. Обмен данными производится через стандартный интерфейс RS232. Структурная схема процесса разработки устройств реального времени показана на рис.3.


Рис.3. Схема процесса разработки устройства

Функциональные возможности ИКРВ позволяют осуществлять процесс проектирования по этой схеме. В настоящее вре-мя с помощью комплекса разработаны два устройства. Первое из устройств является цифровым настраиваемым интегратором. Принципы построения интегратора и оценка его методической погрешности рассмотрены в работе [7].

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

Основная часть проектирования устройств выполнялась в Fixed-Point Blockset. Система команд целевого процессора ориентирована на представление данных в форме с фиксированной точкой. Было произведено совместное тестирование двух уст-ройств и доказана их работоспособность.

В дальнейшем предполагается оценить возможности ИКРВ при проектировании многопроцессорных устройств.

Литература

1. Мясников В.А., Игнатьев М.Б. и др. Микропроцессоры: системы программирования и отладки. М.: Энергоатомиздат, 1985.- 272 с.
2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд. Пер. с англ. М.: "Изда-тельство Бином", СПб.: "Невский диалект", 1998.- 560 с.
3. Фаулер М., Скотп К. UML в кратком изложении. Применение стандартного языка объектного моделирования. Пер. с англ. М.: Мир, 1999. -191 с.
4. Трофимов С.А. CASE - технологии: практическая работа с Rational Rose. М.: ЗАО "Издательство Бином", 2001.- 272 с.
5. Леоненков А.В. Самоучитель UML. СПб.: БХВ - Петербург, 2001.-304 с.
6. The MathWorks, Inc. Product & Documentation CDs. The Real-Time Workshop Development Process. -p.D2-p.D34.
7. Жуков К.Г. Анализ погрешности цифровых интеграторов в Simulink.Тезисы докладов Всероссийской научной конференции "Проектирование научных и инженерных приложений в среде MATLAB"(28-29 мая 2002 г.). М.: ИПУ РАН.2002.-207 с.

В оглавление


Поиск по сайту:

Система Orphus

Яндекс.Метрика