Шаблоны модульного тестирования для кода микроконтроллера C

Question

Хотя существует множество платформ модульных тестов, поддерживающих C, я немного озадачен тем, как писать модульные тесты для кода микроконтроллера (PIC в моем случае, но я думаю, что вопрос более общий, чем этот).

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

Answer 1

Вы пишете;

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

& ПОД1; На ум приходит 8051: по крайней мере, с компилятором Keil 8051 нельзя напрямую вызывать функции прерывания. Это может быть решено с препроцессором C, хотя.

Answer 4

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