как тестировать программу микроконтроллера Опции

[nckkm]

Собственно вопрос - пишу программу для микроконтроллера STM32, но как проверить все ли правильно работает?
Как автоматизировать и симулировать проверку всех заявленных функций контроллера?

Я почему спрашиваю, я долго работал с ПЛИСами и там с этим делом было более менее все понятно.

В ПЛИС сам проект описывается на Verilog, потом к нему дописывается Testbench - это вторая программа на том же Verilog, которая симулирует все внешние воздействия / сигналы на микросхему. Так же, Testbench контролирует, что разрабатываемая микросхема выдает правильные отклики и вообще правильные последовательности сигналов.
Таким образом, с помощью Verilog можно абсолютно точно посмотреть что и как происходит внутри любого блока проекта.
Я так даже симулировал от начала до конца запуск ядра Linux в ПЛИС и просматривал сигналы обращения к SDRAM, и прочие..

А как все это делается с микроконтроллерами? И делается ли вообще?
В принципе, я понимаю, можно использовать статический анализ с инструментами типа cppcheck, или писать Unit Test, но кажется мне это все не совсем то, что нужно.. Ну вот какой unit test можно написать для обработчика прерываний или функции ининциализации контроллера DMA?

А если у меня контроллер управляет медленными процессами типа включил вентилятор, выждал 10 секунд, включил печку.. Как тестировать такие функции устройства?

Возможно тема обсуждалась, извините если так, не нашел поиском.

[lekintr]

Ну не знаю, у меня вопрос в отладке микроконтроллеров всегда решался довольно просто и топорно.
Берем подпрограмму, запускаем ее по циклу на длительное время и долбим снаружи всеми возможными данными, которая она обязана сожрать. Если зависла, вылетела, отожрала память, порушился стек, разбираемся. Не вылетела, идем к следующему модулю.
Отличие от ПЛИС, у микроконтроллеров в том, на мой взгляд, что они с одной стороны более "тянучие" на баги, то есть влетает он в баг легко, но и вылетает также легко. А вот ПЛИС, влетае в баг тяжело, благодаря жесткой симуляции, но уж если влетела, вытащить очень трудно.
ТС могу повторить то, что тут уже озвучил сам ТС. Отлаживайте по кускам. Если подпрограмма не зависает от данных в тестовом модуле, она не зависнет и в связке с остальными устройствами. Микроконтроллеры скорее страдают от аппаратных чудес, которые устраивают им разработчики. Кривые клоки, плохое питание, порушенные входные сигналы, испорченные уровни и так далее. Соответственно микропроцессор зависает в 99% случаев не то того, что программа плохо написана, а от того, например, что разработчики забыли подтянуть выводы JTAG и вообще бросили их как попало, ну и там кондесаторы на питанию поставили не те и не там. Вот и начинается поле чудес...

Про ОСь, как необходимый инструмент в отладке на мой взгляд чушь конкретная. Имеет смысл только в пределах данной конкретной темы.
Ось отдельно, отладка отдельно. На мой взгляд опять же, ось как существо жрущее несравнимо больше ресурсов менее надежна, чем более простая самописная программа. Но это уже другая тема...

Сообщение отредактировал lekintr - Nov 27 2013, 13:06

[AlexandrY]

Если подпрограмма не зависает от данных в тестовом модуле, она не зависнет и в связке с остальными устройствами.

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

Глючная программа в 99% случаев изменяет свое поведение при переносе на целевую платформу, целевой компилятор и целевую область памяти.

Про ОСь, как необходимый инструмент в отладке на мой взгляд чушь конкретная. Имеет смысл только в пределах данной конкретной темы.
Ось отдельно, отладка отдельно. На мой взгляд опять же, ось как существо жрущее несравнимо больше ресурсов менее надежна, чем более простая самописная программа. Но это уже другая тема...

Здесь искажен смысл первоначальной мысли.
Ось (вернее RTOS) предлагалась как единственный надежный носитель таких сервисов как логи, сохранение логов, апгрейда, перехвата исключений, контроля загруженности процессора и проч.