Digitrode

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

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

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

Инженер Фабьен ле Ментек (Fabien le Mentec) привел небольшое исследование, позволяющее лучше оптимизировать работу 8-разрядных контроллеров. Он работал над регулятором напряжения на основе 8-разрядного микроконтроллера ATMEGA328P фирмы ATMEL. Основная логика контроллера была реализована в главной функции main() и зависела от периодического таймера, функционирующего с фиксированной частотой. В обработчике прерывания по таймеру инкрементировалась переменная-счетчик, которая затем использовалась в основной программе для правильной в плане синхронизации работы контроллера напряжения.

Посмотрев на код Фабьена, один интересующийся человек отметил, что в этом коде для счетчиков используется тип uint8_t вместо unsigned int, и сказал, что с этим могут возникнуть трудности в рамках данного проекта. Но Фабьен пояснил причины и последствия такого решения.

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

Получение оптимального кода

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

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

Любая часть системы управления, будь то регулятор, объект или датчик, имеет вход и выход. С помощью входов и выходов они взаимодействуют с другими элементами системы и с внешней средой. При воздействии входного сигнала на элемент системы, в этом элементе происходят какие-то внутренние изменения состояния, которые приводят к изменению выходного сигнала. То есть элемент системы представляет собой некоторую функцию зависимости y от x. Это можно изобразить на рисунке 1.

Определение функции F(x) и есть, по сути, основная задача, решаемая в рамках теории автоматического управления. Знание F(x) объекта поможет составить правильный алгоритм управления им, F(x) датчика определит характер обратной связи, а синтез F(x) сделает систему по-настоящему работоспособной. Саму F также иногда называют оператором, поскольку она оперирует входным сигналом.

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

Совет 1 — не используйте goto

Примерно пару десятилетий назад, когда компьютерное программирование, каким мы его знаем сегодня, пребывало в состоянии младенчества, последовательность выполнения программ в первую очередь определялась командой goto. Она позволяет перепрыгнуть с одной части кода к другой. Вот как это выглядит:

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

• Постарайтесь делать обработчик прерываний как можно короче. В идеале он должен быть не более полстраницы кода на языке C. Если пишите на ассемблере, то постарайтесь уместить код максимум на одной странице. Длинные обработчики, могут нарушить время работы программы.
  

• Время выполнения кода в обработчике также должно быть сведено к минимуму. 100-200 тактовых циклов хватит вполне, хотя насчет точного количества можно подискутировать. Если вам нужно много чего обработать, то лучше сгрести данные в буфер ожидания и позволить основному циклу или подпрограмме не-обработчика сделать все остальное.
  

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

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

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

Мы все знаем, что существуют 2 подхода к написанию программы – процедурно-ориентированное программирование (ПОП) и объектно-ориентированное программирование (ООП). Вы можете написать программу, используя любой из этих способов, но между ними есть заметные различия. Эти 2 подхода являются результатом эволюции разработки программного обеспечения, длившейся многие десятилетия. С момента изобретения компьютера было опробовано множество подходов и методов написания программ. Сюда можно отнести такие методы, как программирование сверху вниз (Top-Down programming), программирование снизу вверх (Bottom-Up programming), модульное программирование (Modular programming), структурное программирование (Structured programming) и другие. Основной целью всех этих методов было одно — сделать процесс программирования эффективнее. Это означает, сделать процесс написания сложных программ менее трудным, легко понимаемым, легко расширяемым/модифицируемым и имеющим как можно меньшую вероятность появления ошибок.