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