Шаблоны модульного тестирования для кода C микроконтроллера
-
12-09-2019 - |
Вопрос
Хотя существует множество платформ модульного тестирования, поддерживающих C, я немного озадачен тем, как писать модульные тесты для кода микроконтроллера (в моем случае PIC, но я думаю, что вопрос более общий).
Большая часть кода, написанного для микроконтроллеров, вращается вокруг записи конфигурации и значений данных в регистры, чтения входящих данных из регистров и реагирования на события прерываний.Мне интересно, может ли кто-нибудь дать несколько советов о наиболее эффективном способе этого.
Решение
Ты пишешь;
«Большая часть кода, написанного для микроконтроллеров, вращается вокруг записи конфигурации и значений данных в регистры, чтения входящих данных из регистров и реагирования на события прерывания».
Я согласен, что на практике это часто бывает, но на самом деле я не думаю, что это хорошо, и я думаю, что небольшое переосмысление поможет вам достичь целей тестирования.
Возможно потому, что программисты микроконтроллеров может протягивать руку и прикасаться к оборудованию в любое время, многие (большинство?) из них привыкли делать именно это в своем коде.Часто этой привычке следуют беспрекословно, возможно, потому, что многие люди, выполняющие такого рода работу, являются EE, а не учеными-компьютерщиками по образованию и наклонностям.Я знаю, я сам так начинал.
Я пытаюсь подчеркнуть, что проекты микроконтроллеров могут и должны быть хорошо спроектированы, как и любой другой программный проект.Действительно важная часть хорошего дизайна — ограничить доступ оборудования к драйверам оборудования!Выделите весь код, который записывает регистры, отвечает на прерывания и т. д.на модули, которые обеспечивают остальному вашему программному обеспечению удобный, понятный и абстрактный доступ к оборудованию.Протестируйте эти модули драйверов на объекте, используя логические анализаторы, осциллографы, специальные испытательные стенды или что-то еще, что имеет смысл.
Действительно важным моментом является то, что теперь остальная часть вашего программного обеспечения, надеюсь, большая его часть, теперь представляет собой просто код C, который вы можете запускать и тестировать на хост-системе.В хост-системе аппаратные модули изолированы таким образом, чтобы обеспечить видимость того, что делает тестируемый код.В этом коде вы можете использовать основные подходы модульного тестирования.Это требует некоторой подготовки и работы, но если вы хорошо организованы, вы можете создать многоразовую систему, которая может применяться ко всем вашим проектам.Потенциальные выгоды огромны.Я написал немного больше об этих идеях здесь;
[http://discuss.joelonsoftware.com/default.asp?joel.3.530964.12][1]
Другие советы
Одним из подходов к этому может быть использование эмулятора.Я работал над эмулятором AVR, и одна из идей его использования действительно заключается в модульном тестировании кода.Эмулятор реализует ЦП и регистры, прерывания и различную периферию, а (в моем случае) байты, записанные в эмулируемый UART, идут в штатный. stdout
эмулятора.Таким образом, код модульного теста можно запустить в эмуляторе и записать результаты теста на консоль.
Конечно, необходимо также убедиться, что эмулятор правильно реализует поведение реального процессора, иначе нельзя доверять поверхностным модульным тестам.
Напишите макетные версии функций/макросов доступа к регистру.Обратите внимание, что это предполагает, что ваш код использует общий набор функций доступа к регистрам, а не специальные вещи, такие как *(volatile int*)0xDEADBEEF = 0xBADF00D
повсюду.
Вызывайте обработчики прерываний непосредственно из тестового кода (может быть проблематично на некоторых архитектурах¹), «программного прерывания», если оно доступно, или из обработчика прерываний таймера, если вам нужно, чтобы они выполнялись асинхронно.Для этого может потребоваться обернуть код включения/выключения прерывания в функции/макросы, которые вы можете смоделировать.
На ум приходит № 8051:по крайней мере, с помощью компилятора Keil 8051 вы не можете напрямую вызывать функции прерывания.Однако это можно решить с помощью препроцессора C.
Возможно, существует какой-либо режим обратной связи, чтобы вы могли использовать сам контроллер для генерации событий, которые вы можете протестировать?