Блог

• поделиться

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

• поделиться

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

• поделиться

Beta-tester:

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

• поделиться

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

• поделиться

Beta-tester:

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

• поделиться

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

• поделиться

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

• поделиться

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

• поделиться

С операционными системами реального времени связано много мифов. Эта ситуация дополнительно усугубляется маркетингом, так как если рассуждать формально, то под определение ОСРВ можно подвести почти все что угодно, исходя из того, что ресурсы любого компьютера ограничены, а следовательно объем входных данных для любого алгоритма также ограничен, следовательно и время выполнения этого алгоритма также ограничено сверху некоторой константой. Поэтому для любого конкретного приложения можно задать такие временные характеристики, что абсолютно любая ОС будет способна их выполнить. Поэтому в настоящее время ярлык "ОСРВ" вешается на все продукты, где этот ярлык может помочь продажам. Кроме того, возникает путаница между понятиями "система реального времени" и ОСРВ. Система реального времени - это конечный продукт (устройство), которое имеет заданные временные характеристики, имеющий аппаратное обеспечение, операционную систему и прикладное ПО, где каждый из этих компонентов способен работать в реальном времени. Стандарт POSIX 1003.1 определяет ОСРВ как ОС, которая обеспечивает требуемый уровень сервиса в определенный промежуток времени. Это определение достаточно расплывчато, так как ничего не говорится о том, насколько жёсткими должны быть требования к этому уровню сервиса. В качестве примера можно привести аудио- или видеовоспроизводящую систему. Ее разработчика может вполне устраивать, что раз в день или в неделю ПО, входящее в состав устройства, может спровоцировать даже видимые пользователю, но кратковременные задержки. Иначе обстоит дело с промышленными или транспортными системами, где выход за определенные заранее задержки может спровоцировать катастрофические последствия. Различия между этими требованиями привели к разделению ОСРВ на ОС мягкого и жёсткого реального времени. Первые обеспечивают работу системы "в целом", но не обязаны гарантированно укладываться в заранее определенные временные рамки; вторые, напротив, должны гарантировать, что временные характеристики будут соблюдены даже при наихудшем стечении обстоятельств. Поскольку путем смягчения требований к "уровню сервиса" любую ОС можно рассматривать как ОСРВ, следует признать что удовлетворительное определение ОСРВ, которые позволило бы чётко разделять классы ОС между собой до сих пор отсутствует. Поэтому попытаемся вывести его из теоретических изысканий в области планирования процессов, а также из практических соображений.

• поделиться

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