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

[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 - чтобы программно симулировать все возможные ситуации...

[AlexandrY]

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

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

Инструмент есть и называется он RTOS. Но не любая, а с надежным отладочным движком + микроконтроллер с продуманными отладочными средствами.

Как понимаю вы перешли с Amber на STM32. И видимо потому, что у Amber нет отладочных средств кроме как симуляции на VHDL
А uLinux не та вещь чтобы на поиск одного испорченного указателя тратить дни. Там тогда на всю жизнь хватит отладки.

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

Нынче принято сразу брать микроконтроллер со всей отладочной инфраструктурой. Чтобы была ОСь, в ней уже реализованные логи и удаленный апгрейд, отладочный канал (лучше несколько) через SWD/JTAG, поддержка просмотра всех объектов оси в IDE, полный и отлаженный BSP (лучше даже генерируемый), профайлер, трассер событий и проч. и чтобы все это загружалось и работало максимально быстро.
Такую инфраструктуру мало кто имеет. Я знаю только серию Kinetis от Freescele у которой все это есть.

[Golikov A.]

Нынче принято сразу брать микроконтроллер со всей отладочной инфраструктурой. Чтобы была ОСь, в ней уже реализованные логи и удаленный апгрейд, отладочный канал (лучше несколько) через SWD/JTAG, поддержка просмотра всех объектов оси в IDE, полный и отлаженный BSP (лучше даже генерируемый), профайлер, трассер событий и проч. и чтобы все это загружалось и работало максимально быстро.
Такую инфраструктуру мало кто имеет. Я знаю только серию Kinetis от Freescele у которой все это есть.

этим абзацем вы перечеркнули жизнь всех проектов с LPC, STM, и огромной армией других АРМов, также в топку пошли все без операционные проекты.

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

[AlexandrY]

также в топку пошли все без операционные проекты.

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

Так, не отходим от контекста.

Уважаемый TC начал с того, что отлаживал uLinux с помощью симулятора аппаратной части. С тем же успехом он мог бы отлаживать uLinux скажем в Micro-Cap (модели только будет найти труднее )

Вот альтернативы этому абсурду и рассматриваем.