Блог

• поделиться

Beta-tester:

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

• поделиться

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

• поделиться

Beta-tester:

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

• поделиться

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

• поделиться

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

• поделиться

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

• поделиться

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

• поделиться

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

• поделиться

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

• поделиться

В программировании довольно часто возникает ситуация, когда требуется привязать к коду некоторые утверждения «о коде», которые сами по себе выполняемым кодом не являются. Высокоуровневые языки, C# или Java, содержат концепцию т.н. метаданных, атрибутов или аннотаций, которые и являются встроенным средством, для записи подобного рода информации внутри файлов исходных текстов. Широко используемые сегодня в системном программировании языки С/C++ имеют ограниченные возможности для описания аннотаций или метаданных, хотя нуждаются в них не менее, а может быть даже и более, чем вышеупомянутые высокоуровневые языки, главным образом потому, что при программировании следует учитывать особенности нижележащей аппаратуры. Например, иногда возникает необходимость в явном указании выравнивания структур, особенностей их расположения в памяти, ограничения при использовании функций и многое другое. В настоящее время, большинство из этих проблем решаются нестандартными методами (с помощью нестандартных расширений компилятора) либо хранятся отдельно от кода в каких-то внешних файлах настроек или файлах сборки (например, явное задание каких-то параметров в виде ключей компилятора, которые записываются для определенных файлов внутри makefile). В некоторых случаях, подобная метаинформация, которая логически неразрывно связана с содержимым файла, и вовсе в явном виде нигде не присутствует, а просто записывается в readme.txt (примеры – требуемые внешние константы, требования к расположению определенных функций по определенному адресу и т.п.).Обсуждаемый сейчас новый стандарт С++14 предполагает введение новых синтаксических конструкций для атрибутов, однако это не сможет решить вышеописанные проблемы, поскольку набор самих атрибутов остается фиксированным и определенным в самом языке (то есть пользователь не может определять свои собственные атрибуты, как это можно делать в Java/C#).В настоящей статье предлагаются методы, основанные на открытых форматах и стандартах, позволяющие ввести пользовательские метаданные или атрибуты в текст программ на С/C++, также рассмотрен тесно связанный с этим вопрос модульности на уровне исходных текстов в языке С. Созданные таким образом модули могут быть повторно использованы без внесения в них каких-либо изменений. При этом используется стандартный инструментарий для компиляции.