Встроенное программное обеспечение поблочного тестирования [закрывается]

Есть так много способов сделать это. Вот что я сделал:

Генерирует шесть случайных шестнадцатеричных цифр (0-F)

function randColor() {
    for (var i=0, col=''; i<6; i++) {
        col += (Math.random()*16|0).toString(16);
    }
    return '#'+col;
}

Чрезвычайно короткая однострочная

'#'+Math.random().toString(16).slice(-6)

Создает отдельные компоненты RGB (00-FF)

function randColor2() {
    var r = ('0'+(Math.random()*256|0).toString(16)).slice(-2),
        g = ('0'+(Math.random()*256|0).toString(16)).slice(-2),
        b = ('0'+(Math.random()*256|0).toString(16)).slice(-2);
    return '#' +r+g+b;
}

Переработанная шестнадцатеричная строка (XOR 3 выводят вместе, чтобы сформировать цвет)

function randColor3() {
    var str = Math.random().toString(16) + Math.random().toString(16),
    sg = str.replace(/0./g,'').match(/.{1,6}/g),
    col = parseInt(sg[0], 16) ^ 
          parseInt(sg[1], 16) ^ 
          parseInt(sg[2], 16);
    return '#' + ("000000" + col.toString(16)).slice(-6);
}
61
задан a_m0d 30 June 2009 в 04:12
поделиться

8 ответов

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

  • для алгоритмов, которые не зависели от целевого оборудования, мы просто проводили модульные тесты которые были построены и протестированы на невстроенной платформе.
  • для вещей, требующих оборудования, модульные тесты были условно скомпилированы в код для использования любого доступного оборудования. В нашем случае это был последовательный порт на целевом объекте, передающий результаты на другой, более мощный компьютер, на котором тесты проверялись на правильность.
  • В зависимости от аппаратного обеспечения, иногда можно было подставить «виртуальное» устройство на компьютер. невстроенная платформа. Обычно это заключалось в том, что другой поток выполнения (или сигнальная функция) изменял память, используемую программой. Полезно для ввода-вывода с отображением в память, но не для прерываний прерывания и т.п.
  • обычно вы можете проводить модульное тестирование только небольшого подмножества полного кода за раз (из-за ограничений памяти).
  • для тестирования чувствительных ко времени вещей мы этого не делали. Легко и просто. Используемое нами оборудование (8051 и 68302) не всегда работало, если работало слишком медленно. Такого рода отладку нужно было сначала сделать с помощью CRO (осциллографа) и (когда у нас было немного денег) ICE (внутрисхемного эмулятора).

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

Такого рода отладку нужно было сначала сделать с помощью CRO (осциллографа) и (когда у нас было немного денег) ICE (внутрисхемного эмулятора).

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

Такого рода отладку нужно было сначала сделать с помощью CRO (осциллографа) и (когда у нас было немного денег) ICE (внутрисхемного эмулятора).

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

51
ответ дан 24 November 2019 в 17:16
поделиться

Модульное тестирование в среде ПК (компиляция кода с помощью компилятора C ПК и запуск кода в среде модульного тестирования ПК) может принести много пользы с несколькими оговорками:

  1. Это не относится к тестированию вашего низкоуровневого кода, включая код запуска, тесты RAM, драйверы оборудования. Вам придется использовать их более прямое модульное тестирование.
  2. Компилятор вашей встроенной системы должен быть надежным, чтобы вы не охотились за ошибками, создаваемыми компилятором.
  3. Ваш код должен иметь многоуровневую архитектуру с аппаратная абстракция. Возможно, вам потребуется написать имитаторы аппаратных драйверов для среды модульного тестирования вашего ПК.
  4. Вы всегда должны использовать типы stdint.h , такие как uint16_t , а не простые unsigned int и т. Д.

Мы следовали этим правилам,

20
ответ дан 24 November 2019 в 17:16
поделиться

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

  • По возможности абстрагируйтесь от аппаратных зависимостей. Таким образом, вы можете запускать свои модульные тесты на имитируемом «оборудовании», а также тестировать различные редкие / исключительные случаи, которые будет сложнее протестировать на целевом объекте. Чтобы избежать затрат на абстракцию, вы можете использовать, например, условную компиляцию.

  • Как можно меньше зависеть от оборудования.

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

13
ответ дан 24 November 2019 в 17:16
поделиться

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

0
ответ дан 24 November 2019 в 17:16
поделиться

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

A) Напишите как можно больше аппаратно-независимого кода приложения в среде ПК, прежде чем писать его на целевом компьютере, и одновременно с этим напишите свои модульные тесты. времени (выполнение этого сначала на ПК должно помочь вам разделить аппаратно-независимые вещи). Таким образом, вы можете использовать выбранные вами тестеры модулей, а затем тестировать аппаратно-зависимые компоненты старомодным способом - с помощью RS-232 и / или осциллографов и контактов ввода / вывода, передающих данные, зависящие от времени, в зависимости от того, насколько быстро он должен работать. .

B) Запишите все это на целевом оборудовании, но есть цель make для условной компиляции сборки модульного теста, которая будет запускать модульные тесты и выводить результаты (или данные, которые могут быть проанализированы на предмет результатов) через RS-232 или каким-либо другим способом. Если у вас мало памяти, это может быть сложно.

Редактировать 03.07.2009 У меня просто возникла еще одна мысль о том, как проводить модульное тестирование оборудования, зависящего от оборудования. Если ваши аппаратные события происходят слишком быстро для записи с помощью RS-232, но вы не хотите вручную просматривать тонны данных осциллографа, проверяя, поднимаются или опускаются ли флаги контактов ввода / вывода, как ожидалось, вы можете использовать ПК карта со встроенным DIO (например, линейка карт сбора данных National Instruments) для автоматической оценки синхронизации этих сигналов. Тогда вам просто нужно будет написать программное обеспечение на вашем ПК для управления картой сбора данных для синхронизации с текущим выполняемым модульным тестом.

6
ответ дан 24 November 2019 в 17:16
поделиться

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

Если вы пишете интерфейс связи, извините.

0
ответ дан 24 November 2019 в 17:16
поделиться

Здесь много хороших ответов, некоторые вещи, о которых не упоминалось, - это запуск диагностического кода, чтобы:

    Регистрировать события HAL (прерывания, сообщения шины и т. Д.)
    Имейте код для отслеживания ваших ресурсов (все активные семафоры, активность потоков)
    Имейте механизм захвата оперативной памяти для копирования содержимого кучи и памяти в постоянное хранилище (жесткий диск или эквивалент) для обнаружения и отладки взаимоблокировок, живых блокировок , утечки памяти, переполнение буфера и т. д.
3
ответ дан 24 November 2019 в 17:16
поделиться

Возможно, вы захотите ознакомиться с Test Driven Development for Embedded C Джеймса В. Греннинга. Выход книги запланирован на август 2010 года, но бета-версия книги доступна уже сейчас на The Pragmatic Bookshelf.

13
ответ дан 24 November 2019 в 17:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: