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

[nckkm]

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

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

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

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

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

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

[mempfis_]

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

Проверять работоспособность переферии контроллера нет смысла. Это делают за Вас производители контроллера, а всякие разные баги переферии описывают в эрратах, которые тоже стоит иногда листать.
Что касается проверки работоспособности программы, то сдесь всё зависит только от Вас. Если программа простая, то достаточно один раз её отладить с помощью отладчика/симулятора/светодиода/LCD-индикатора. Убрать отладочную информацию, проверить что с функционалом всё в порядке и принять решение о завершении отладки.
Если программа сложная, то не стоит скупиться и выделить один UART только для отладочных целей и выводить в него всю важную информацию.
Программу разделять на осмысленные задачи, каждую из которых можно отладить независимо от других, и обеспечить их максимальную независимость от других задач - задача опроса АЦП, задача контроля GPRS, задача обслуживания LCD-индикатора и т.п. Если есть зависимые задачи, то предусмотреть чтобы крах одной задачи не влиял на другие, зависящие от неё задачи.
Каждая задача должна при выполнении некоторых действий отправляет в debug-порт сообщения.
Например условный лог:

TASK LCD: PRINT MSG: HELLO
TASK GPRS: TRY CONNECT: APN: internet
TASK SERVER: WAITE GPRS
TASK GPRS: CONNECT OK: IP: 10.9.8.7
TASK LCD: LCD LOST
TASK SERVER: SEND DATA: BYTES: 245 TYPE: GPS FIFO
.............................
.............................
TASK LCD: LCD INIT OK
.............................

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

Другой вариант косвенной борьбы с глюками программы - наличие возможности дистанционного обновления прошивки. Если в устройстве есть ETHERNET или GPRS, или любой порт, по которому можно связаться с устройством (RS232, RS485, голый UART), то после завершения написания условно "рабочей и отлаженной прошивки" в первую очередь следует ввести и отладить возможность её обновления дистанционно. Перимущества дистанционной перепрошивки нет смысла описывать.

[nckkm]

Проверять работоспособность переферии контроллера нет смысла. Это делают за Вас производители контроллера, а всякие разные баги переферии описывают в эрратах, которые тоже стоит иногда листать.

нет, проверять работоспособность переферии не собирался.. только проверка своей собственной программы..

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

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

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

Может какой инструмент есть вроде тестбенча для Verilog - чтобы программно симулировать все возможные ситуации...