Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
УП МПУ-13.doc
Скачиваний:
10
Добавлен:
01.04.2025
Размер:
6 Мб
Скачать
☆

Часть 2. Процесс проектирования устройств на мк (л4, л5)

2.1. Этапы процесса проектирования устройств на мк

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

1. Разработка технического задания (ТЗ) выполняется разработчиком по требованиям пользователя и согласовывается с последним. Описывается назначение устройства, перечень функций, основные технические характеристики, связи и взаимодействие устройства с другими элементами системы управления или автоматизируемого комплекса, при необходимости – взаимодействие с оператором (человеко-машинный интерфейс), требования к конструкции.

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

2. Разработка алгоритма работы устройства – слабо формализуемый этап. Состоит в одновременном выборе способа решения (организация циклической последовательности действий) и средств решения (выбор МК и других основных электронных компонент).

Как и в любом другом процессе проектирования, важно соблюдать баланс между принципами проектирования «сверху – вниз» и «снизу – верх». Первый требует понимания принципов системного подхода, а второй – знания конкретных приемов реализации простейших алгоритмов (последнее и есть основная задача этого курса).

Как правило, заканчивается разработкой структурных схем аппаратной и программной части.

Степень детализации в этих схемах зависит как от выбора средств проектирования, так и от уровня подготовленности разработчиков. Например, использование в качестве языка программирования Ассемблера требует использования языка блок-схем с проработкой алгоритма программы почти до уровня машинных команд. При использовании языка высокого уровня (типа С/С++) структурно-модульные средства последнего в сочетании с «хорошим стилем программирования» снижают потребность в представлении алгоритма на языке блок-схем. Однако совместное использование программных и аппаратных решений требуют поиска новых удобных и компактных средств представления алгоритма.

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

Далее процесс проектирования формально может идти параллельно – разработка программной и аппаратной частей, до начала их совместной отладки.

3.1. Разработка программной части.

3.1.1. Написание текста программы на выбранном языке (ассемблер/С/С++) – необходим текстовый редактор. Здесь весьма важен, так называемый, «хороший стиль программирования» (см. Подвал).

3.1.2. Трансляция исходного текста и сборка загрузочного модуля. При работе с проектом из нескольких файлов исходного текста и использовании объектных библиотек готовых подпрограмм требуется объединение объектных модулей в один загрузочный. Необходимы программы транслятора (компилятора) и редактора связей.

На этом этапе выявляются синтаксические ошибки [Error] и предупреждения [Warning]. Последние не препятствуют созданию загрузочного модуля, но желательно добиваться их отсутствия – это способствует правильному стилю программирования и уменьшает вероятность логических ошибок.

Загрузочный модуль может иметь несколько форматов. Для загрузки в память программ целевого МК требуется только двоичный код команд и данных (констант). Для загрузки в моделирующую программу (симулятор) в дополнению к машинному коду требуется связь с исходным текстом для поддержки процесса отладки в символьном виде.

3.1.3. Отладка программы [Debug] заключается в выявлении вычислительных и логических ошибок в программе: корректной работы вычислительных функций, правильного использования адресов, последовательности действий, времени выполнения критических частей программы и пр.

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

Сравнительно недавно появился новый класс симуляторов, включающих кроме логической модели МК схемотехнические модели всех узлов ввода/вывода и наборы моделей типовых электронных и др. компонент. Как правило, такие пакеты строятся на базе широко распространенного математического пакета моделирования цифровых и аналоговых устройств PSPICE (например, Proteus VSM). Такие симуляторы позволяют проверить работоспособность не только программной, но и аппаратной частей.

Рассмотрим перечисленные выше этапы подробнее, чтобы обсудить выбор готовых аппаратных и программных средств для их исполнения.