Встроенный дизайн прошивки

Embedded Motherboard

Embedded Motherboard

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

Больше
Thermal Printer

Thermal Printer

Jarltech имеет большой опыт в разработке высоконадежных термопринтеров. Включите 2-дюймовый и 3-дюймовый термопринтер.

Больше

Более 30 лет разработчик и производитель встроенных микропрограмм | Ярлтех

Базируется в Тайване, Jarltech International Inc., с 1987 года, предоставляет дизайн встроенного микропрограммного обеспечения | интеграция электронных продуктов и оборудования, чтобы помочь клиентам от идеи до реального продукта. Основной продукт, включая проектирование схем, разработку электроники, сборку печатных плат, промышленный дизайн, разработку оборудования, мелкосерийное производство, DIP печатных плат, решение EMS, сборочное производство, изготовление печатных плат и так далее.

Также предоставляются электронные продукты Jarltech по индивидуальному заказу, а также инженерные разработки, такие как схемы, программное обеспечение, корпуса и образцы, инструменты и формование, промышленное производство, сертификация и маркетинговые услуги. Идея + Дизайн + Производство + Сервис = Ярлтех.

Jarltech предлагает клиентам высококачественные POS-системы и периферийные устройства, обладая глубокими инженерными знаниями и 29-летним опытом, Jarltech обеспечивает удовлетворение требований каждого клиента.

Встроенный дизайн прошивки

Предложите системные тесты, чтобы убедиться, что продукт превышает заявленные требования.

Встроенный дизайн прошивки
Встроенный дизайн прошивки

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

Проектируем прошивку за пять шагов

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

Шаг 1. Определите требования

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

Каждое утверждение требования также должно быть еще двумя вещами: однозначным и проверяемым. Однозначное утверждение не требует дополнительных пояснений. Он максимально ясен и лаконичен. Проверяемость - ключ к успеху. Если требование написано правильно, можно легко построить набор тестов, чтобы убедиться, что требование выполняется. Правильный набор требований - это письменный список утверждений, каждое из которых содержит ключевую фразу «[продукт] должен ...» и ничего не говорит о том, как это реализовано, однозначно и проверяемо. Таким образом, хорошая архитектура зависит от хороших требований.

Шаг 2. Отличите архитектуру от дизайна

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

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

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

Шаг 3. Управляйте временем

В некоторых требованиях к продукту будет указано явное количество времени. Большинство продуктов содержат сочетание требований не реального времени, программного и жесткого реального времени. Мягкие дедлайны обычно сложнее всего однозначно определить, протестировать и реализовать. После определения крайних сроков первый шаг в архитектуре - выдвинуть как можно больше требований своевременности из программного обеспечения в аппаратное обеспечение.

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

Шаг 4. Дизайн для тестирования

Каждую встроенную систему необходимо протестировать. Как правило, также полезно или обязательно, чтобы тестирование проводилось на нескольких уровнях. Наиболее распространенные уровни тестирования:
1. Системные тесты проверяют, соответствует ли продукт в целом установленным требованиям или превышает их. Системные тесты, как правило, лучше всего разрабатывать вне инженерного отдела, хотя они могут вписаться в тестовую систему, разработанную инженерами.
2. Интеграционные тесты проверяют, что подмножество подсистем, идентифицированных на схемах архитектуры, взаимодействует, как ожидалось, и дает разумные результаты. Интеграционные тесты, как правило, лучше всего разрабатываются группой тестирования или специалистом в области разработки программного обеспечения.
3. Модульные тесты проверяют, что отдельные программные компоненты, идентифицированные на промежуточном уровне проектирования, работают так, как ожидают их разработчики. То есть они тестируют на уровне общедоступного API (интерфейса прикладного программирования), который компонент представляет другим компонентам. Модульные тесты обычно лучше всего разрабатывают те же люди, которые пишут тестируемый код.

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

Шаг 5. Планируйте изменения

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


Новость