Digitrode

У вас есть 3D принтер, и вам надоело распечатывать модели из интернета и хотите создать что-то свое? Замечательно! Сегодня существует ряд программ, позволяющих рисовать свои 3D модели. Одной из таких программ является OpenSCAD. Ее особенность заключается в том, что моделирование здесь скорее представляется программированием, нежели рисованием. Большое количество полезных моделей, в том числе детали для 3D принтеров RepRap, были спроектированы с помощью OpenSCAD.

Этот материал не является полным руководством OpenSCAD, но прочитав его вы сможете создавать несложные детали самостоятельно.

Хотя использование AVR-ассемблера позволяет легко писать компактные по размеру кода программы, все же использование языка C и AVR Libc дает больше удобств. В этой статье будет показано, как написать код на C, который avr-gcc скомпилирует с минимальным размером. Существует ряд руководств по написанию компактного кода для AVR, но ни одно из них не рассматривает вопрос сокращения оверхеда в start-up библиотеке avr-gcc (gcrt1).

Многие все еще применяют avr-gcc 4.3.3, поскольку он дает более плотный код по сравнению с версиями 4.5.3 и 4.7, но для ниже приведенного примера avr-gcc 4.8.2 дал еще более компактный код, нежели 4.3.3.

Тестовая программа работает со встроенным температурным датчиком ATtiny85 и мигает светодиодом. После компиляции с оптимизацией –Os получаем программу размером 274 байта:

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

Основы принципа встраивания функций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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