Модули тестирования модулей для кода микроконтроллера C

Ответ 1

Вы пишете:

"Большая часть кода, написанного для микроконтроллеров, вращается вокруг записи параметров конфигурации и данных в регистры, чтения входящих данных из регистров и ответа на события прерывания".

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

Возможно, потому, что программисты-микроконтроллеры могут протянуть руку и прикоснуться к аппаратным средствам в любое удобное для них время, многие (большинство?) из них привыкли делать именно это, на протяжении всего своего кода. Часто эта привычка следует безоговорочно, может быть, потому, что так много людей, занимающихся подобной работой, являются ЭО, а не компьютерными учеными по обучению и склонности. Я знаю, я сам начал сам.

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

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

[http://discuss.joelonsoftware.com/default.asp?joel.3.530964.12][1]

Ответ 2

Одним из подходов к этому может быть использование эмулятора. Я работаю над эмулятором AVR, и одна из идей его использования - это действительно код unit test. Эмулятор реализует CPU и регистры, прерывания и различные периферийные устройства, а в моем случае байты, записанные на эмулируемый UART, переходят в обычный stdout эмулятора. Таким образом, код unit test может запускаться в эмуляторе и записывать результаты его тестирования на консоль.

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

Ответ 3

Напишите макетные версии функций/макросов доступа к регистру. Обратите внимание, что это предполагает, что ваш код использует общий набор функций доступа к регистру, а не ad hoc, например, *(volatile int*)0xDEADBEEF = 0xBADF00D.

Вызовите обработчиков прерываний непосредственно из вашего тестового кода (может быть проблематичным на некоторых архитектурах и sup1;), "программном прерывании", если оно доступно, или от обработчика прерываний таймера, если вам нужно, чтобы они выполнялись асинхронно. Это может потребовать обертывания кода включения/выключения прерывания в функциях/макросах, которые вы можете макетировать.

& ПОД1; 8051: во всяком случае с компилятором Keil 8051 вы не можете напрямую вызвать функции прерывания. Однако это можно было бы разработать с помощью препроцессора C.

Ответ 4

Существует ли какой-либо режим петлевой проверки, чтобы вы могли использовать сам контроллер для генерации событий, которые вы можете протестировать?