Основы проектирования систем на микроконтроллерах и ПЛИС

Разработка систем на БИС программируемых цифровых устройств

Системы управления на основе микропроцессоров и микроконтроллеров быстро получили массовое применение, поскольку были сформулированы ясные правила их проектирования. Создание аппаратной компоненты велось на основе магистрально-модульной структуры, прикладные программы вначале были несложными и разрабатывались известными методами. Идея совместной работы нескольких микропроцессорных БИС на одну магистраль в области систем управления не получила развития. При необходимости увеличить производительность системы разработчики шли по пути увеличения разрядности – переходили от 8- к 16- или 32-разрядной микропроцессорной БИС. До середины 90-х годов увеличение разрядности означало также переход в другой класс качества микропроцессорных БИС. Многоразрядныемикропроцессорные БИС имели архитектурные и структурные решения, которых в дешевых 8-разрядных изделиях быть не могло. Заметным явлением в конце 80-х годов стало использование в разрядных системах управления преимущественно микроконтроллеров. Микропроцессоры 8- и 16- разрядности продолжают выпускаться для поддержки серийных изделий. Основной областью применения микропроцессоров стала 32- и 64- разрядная обработка данных в компьютерах, сигнальных и коммуникационных процессорах.

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

Во второй половине 90-х годов существенно изменилась топология микропроцессорных систем управления. В прежней магистрально- модульной структуре схемы обслуживания отдельных узлов были драйверами без интеллекта. Они выполняли функции преобразования протоколов, служили усилителями мощности, но не имели возможности обрабатывать свою информацию. Функцию обработки выполнял ведущий микроконтроллер, к которому от периферийных схем тянулись жгуты проводов. Автомобили на этом этапе[7] содержали до трех миль проводов весом более 100 кг. Удешевление микроконтроллеров привело к целесообразности замены ими многих периферийных схем. Появилась возможность предобработки локальных данных и пересылки ведущему микроконтроллеру только результатов. Это привело к широкому внедрению последовательных интерфейсов (RS-232, I²C, SPI) и разработке новых (CAN, MicroLan). Топология систем управления приобрела характер сети локальных ведомых микроконтроллеров, связанных между собой и с ведущим микроконтроллером через последовательные интерфейсы. Значительное улучшение характеристик собственно микроконтроллеров связано с внедрением RISC-архитектур, flash-памяти программ и EEPROM-памяти данных, прецизионных блоков АЦП и ЦАП. Гарвардская архитектура микроконтроллеров (с раздельными матрицами памяти программ и данных) позволила оптимизировать формат команд и обеспечить выборку и выполнение большинства из них за один машинный цикл или даже такт. Производительность, например, микроконтроллеров AVR (Atmel) достигла значения 10 MIPS на частоте 10 МГц.

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

Совершенствование микроэлектронной технологии позволило объединить на одном кристалле ядро микроконтроллеров MCS-51 с прецизионными 12-разрядными модулями АЦП и ЦАП. Микроконтроллер ADm812 (Analog Devices) является, по существу, однокристальной измерительно - управляющей микропроцессорной системой. В настоящее время передовые структурные решения применяются в классе 8-разрядных микроконтроллеров. Рост степени интеграции 8- разрядных МК направляется на реализацию новых функциональных модулей и структурных решений.

Качественные изменения в области применения БИС программируемой логики наступили, когда в качестве средств описания проектов стали применяться языки высокого уровня типа HDL (Hardware Description Language). Производители ПЛИС путем постепенного согласованного усложнения элементной базы и средств проектирования решили задачу автоматического синтеза устройства на основе текстового описания. Таким образом, появилась возможность значительно сократить сроки разработки проектов на ПЛИС и сделать процесс проектирования доступным широкому кругу инженеров. В настоящее время ПЛИС имеют степень интеграции до нескольких миллионов эквивалентных вентилей, а их быстродействие (ввода/вывода) достигло рубежа 400 МГц. Из наиболее известных производителей ПЛИС следует отметить фирму Altera. Ее микросхемы и системы проектирования дают возможность быстро реализовать нужную функцию на кристалле, используя автоматическую компиляцию графического или текстового описания проекта. Качество и стоимость такого метода проектирования вполне соответствуют требованиям интеграции разрабатываемой схемы в структуру системы управления на основе микроконтроллеров.

Микроконтроллеры и ПЛИС удачно дополняют друг друга, и несколько фирм приступили к выпуску БИС, интегрирующих на одном кристалле как микроконтроллер, так и матрицу программируемой логики. Так старшая модель семейства Е5 фирмы Triscend объединяет на кристалле ядро микроконтроллера 8051, ОЗУ объемом до 64 Кбайт и матрицу программируемой логики объемом до 3200 ячеек. Другим примером может служить семейство FPSLIC фирмы Atmel. БИС семейства включают ядро RISC-микроконтроллера AVR, статическую память SRAM и матрицу FPGA типа АТ40К. Память разделена на ОЗУ программ, память данных и память общего назначения. Производительность микроконтроллера достигает значения 40 MIPS на частоте 40 МГц. Кроме того, к ядру AVR-микроконтроллера добавлен 8-разрядный умножитель.

В устройствах управления объектами (контроллерах) на основе МК аппаратурные средства и программное обеспечение существует в форме неделимого аппаратурно-программного комплекса. При проектировании контроллеров приходиться решать одну из самых сложных задач разработки, а именно задачу оптимального распределения функций контроллера между аппаратурными средствами и программным обеспечением. Решение этой задачи осложняется тем, что взаимосвязь и взаимовлияние аппаратурных средств и программного обеспечения в микропроцессорной технике претерпевают динамические изменения. Если в начале развития микропроцессорной техники определяющим было правило, в соответствии с которым аппаратурные средства обеспечивают производительность, а программное обеспечение – дешевизну изделия, то в настоящее время это правило нуждается в серьезной корректировке. Так как МК представляет собой стандартный массовый (относительно недорогой) логический блок, конкретное назначение которого определяет пользователь с помощью программного обеспечения, то с ростом степени интеграции и, следовательно, функционально-логических возможностей МК резко понижается стоимость изделия в пересчете на выполняемую функцию, что в конечном итоге и обеспечивает достижение высоких технико-экономических показателей изделий на МК. При этом затраты на разработку программного обеспечения изделия в 2 – 10 раз превышают затраты на приобретение и изготовление аппаратурных средств.

В настоящее время наибольшее распространение получил методологический прием, при котором весь цикл разработки контроллеров рассматривается как последовательность трех фаз проектирования:

1. анализа задачи и выбора (и/или разработки) аппаратурных средств контроллера;

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

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

Фаза разработки программного обеспечения, т.е. фаза получения прикладных программ, в свою очередь, разбивается на два существенно различных этапа:

1. «от постановки задачи к исходной программе»;

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

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

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

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

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

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

После получения объектного кода программы неизбежно наступает этап отладки, т.е. установления факта ее работоспособности, а также выявления и устранения ошибок. Без этого этапа разработки никакое программное обеспечение вообще не имеет права на существование.

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

автономную отладку каждой процедуры в статическом режиме, позволяющую проверить правильность проводимых вычислений, правильность последовательности переходов внутри процедуры (отсутствие «зацикливания») и т.п.;

комплексную отладку программного обеспечения в статическом режиме, позволяющую проверить правильность алгоритма управления (по последовательности формирования управляющих воздействий);

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

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

С использованием разрабатываемого устройства можно будет выполнять рассмотренные этапы отладки уже непосредственно на «живом» МК, подключая к нему реальные физические объекты. Эти этапы отладки можно будет объединить со следующими этапами разработки устройства – отладка отдельных фрагментов программного обеспечения на отладочном модуле в режиме реального времени. Можно будет исключить этап комплексной отладки прикладного программного обеспечения на инструментальной микроЭВМ с внутрисхемным эмулятором.

Разрабатываемое устройство должно обеспечить все необходимые возможности, доступные в кросс системах:

доступ к любому ресурсу МК;

пошаговое исполнение программ.

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

Можно будет моделировать среду обитания МК, т.е. различного рода объекты и датчики, подключаемые к нему.

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