Блог

• поделиться

Этой записью мы начинаем цикл постов, посвященных выпуску новой версии САПР печатных плат Delta Design 1.0 (DD 1.0).  Версия 1.0 – это полностью промышленная коммерческая версия. Уже сейчас для понимания  устройства системы доступна версия 0.9

• поделиться

Замысел
В ходе работ по созданию нашего симулятора в целях проверки его возможностей и сравнения с другими системами моделирования был реализован проект симуляции работы операционной системы FX-RTOS на модели микроконтроллера PIC32. Для тестирования предполагалось написать простейшую программу, которая должна мигать светодиодами. В случае модели светодиодами были просто выходы портов общего назначения. Переключение светодиодов осуществлялось по программному прерыванию и прерыванию от таймера. Данный тест позволял нам полностью охватить заявленную возможность совместного моделирования HDL-моделей и встраиваемых систем. В таком варианте применения собираемая из исходников на C прошивка играет роль "тестбенча", обеспечивая управление внешними воздействиями на модель железа. Она формирует память инструкций и данных, с которыми работает процессорное ядро и/или периферия. Кроме всего прочего, подобный тест полезен своим охватом функционала языка. Т.к. в начале, перед выполнением даже самой примитивной программы, осуществляется инициализация ОС. Также осуществляются определённые действия с памятью и теневым набором регистров при обработке прерываний. Все эти операции задействуют выполнение множества команд процессора, а следовательно различных арифметических и логических операций с объектами различных типов языка описания аппаратуры (в данном случае VHDL). И, если в ходе выполнения последовательности таких операций попадаем на баг симулятора, то симуляция, естественно, валится. Исправная же работа означает:
- симулятор достаточно работоспособен для разработки цифровой аппаратуры
- совместное моделирование "железа" и "прошивки" поддерживается

• поделиться

В моей первой статье я рассказал об использовании препроцессора для организации модульности на уровне исходных текстов в языках С/C++. Вкратце этот способ сводится к написанию специфических метаданных внутри исходников, которые анализируются внешним инструментом и используются для генерации glue-исходников, позволяющих реализовать модульность. Детали реализации описаны в упомянутой статье, поэтому не буду здесь повторяться. В данной статье я пойду чуть дальше и попытаюсь показать, что с помощью метаданных или аннотаций можно реализовать не только модульность, но и некоторые другие полезные фичи. Должно получиться что-то вроде Google Guice или Spring для С (той его части, которая связана с модульностью и аспектами). Отдельно подчеркиваю, что эта статья — дополнение и улучшение первой, поэтому тут я буду говорить не столько технических деталях реализации, сколько о том, как это все выглядит для пользователя. Если эта тема вызовет интерес, то я напишу продолжение с пояснениями о том, как устроено внутри само приложение-конфигуратор.

• поделиться

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

• поделиться

Beta-tester:

Вы писали: - добавлена возможность настройки маски и пасты для контактных площадок на плате. Не нашел как это сделать.

• поделиться

Beta-tester:
Не понятно как собственно использовать Топор для трассировки платы вместо нового встроенного редактора платы?

• поделиться

Beta-tester:

Как при создании компонента сделать верхнее подчеркивание над конкретным альтернативным именем порта а не над всем текстом в имени порта. В Альтиуме это делается установкой / в Pcad ~.

• поделиться

Прошу обратить внимание на примитивный пример - ECAD.758745.001 (нижний правый узел на схеме). Видим диодный мост с диодом защиты V2 и элементами фильтрации C5-C8

• поделиться

- Перемещение содержимого - зажатая левая кнопка и перемещение мыши.
- Масштаб - нажатый "Ctrl" + колёсико мыши
- Выделение строчки - клик левой кнопки мыши

• поделиться

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