Тестирование и отладка кода для МК

Прочитал на лоре недавно как человек тестирует свое устройство на AVR даже не имея самого устройства. Использует simulavr для моделирования самого МК и собственную модель внешней периферии (двигатели, светодиоды, датчики, последовательные интерфейсы и т.п.). Собирается делать автоматические тесты. После этого захотелось улучшить свои методы тестирования и отладки.

У меня все несколько хуже. Тестируется только управляющий код, он включается в состав модели внешних устройств (у меня только двигатели), собирается под x86. Получаю программу которая из входных сигналов и каких-то заданных констант выдает много телеметрии, которую можно смотреть на графиках или пытаться делать автоматический анализ. Но остается много кода который не покрыт тестами, например все обработчики команд CLI. Их приходится отлаживать на живом МК.


Почему сдално именно так? Вчера я использовал AVR, сегодня хочу cortex-m4, завтра захочу dsp. Делать симулятор для всего этого тяжело и неинтересно, и для МК-шной периферии особенно. Готовых думаю не найти. Выход только в том, чтобы тестировать код до hal. А то, что после только на живом.

Но каким образом протянуть границу hal для переключатель контекстов например? По ту сторону прерывание pendsv сохраняющее контекст и вызывающее shedule() по эту сторону. Портировать это под x86 мне кажется плохой идеей. Завтра мне надо будет поработать на ARM-буке а просто пересобрать модель под него не получится.

Отказываться от переключателя задач, значит надо переписывать весь код задач в кооперативном стиле специально для моделирования. Тоже не привлекательное занятие.

Да и отладка проблем реального времени не удалась в обоих случаях. Но есть ещё и просто какой-то код, в том же обработчике CLI который использует какую-то синхронизацию или назовем это даже IPC (ITC). Там может быть функция чтения и вывода в терминал значения часто обновляемого из другой задачи параметра. Этот код хочется отладить насколько возможно.

Ну и главное, что код перед hal тоже надо переписывать для модели. Это явный непорядок. Но что-то хороших идей не приходит.
  • 0
  • 18 августа 2013, 18:52
  • amaora

Комментарии (11)

RSS свернуть / развернуть
Я не совсем понял, это вопрос или что?
Прочитал на лоре недавно как человек тестирует свое устройство на AVR даже не имея самого устройства.
Ты линк забыл. Хотя, кажется, neiver здесь тоже писал что-то подобное.
+1
  • avatar
  • Vga
  • 18 августа 2013, 19:15
Да, похоже на вопрос. Линк.

www.linux.org.ru/gallery/screenshots/9449688
0
Почитал пост-ссылку neiver-а. Возникает вопрос, есть ли в pthreads возможность менять контекст треда.
0
Ничего не понял…
А можно как-то популяризировать?
+2
Моделирование может быть очень сильно нужно например в случае когда надо управлять чем-то сложным, а любая ошибка приводит к повреждению оборудования, механически или электрически. Здесь делается программная имитация этой сложной системы. Добавляется код управления и вместе отлаживается. Когда все работает хорошо, можно собрать прошив и попробовать на реальной системе.

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

А автоматические тесты без этого скорее всего вовсе не будут возможны.
0
Честно говоря, коллега, не совсем понял суть вашего вопроса. Как-то (ИМХО) непонятно вы описали задачу.

Я так понимаю, Вы пишите код для МК, и этот код использует вытесняемую многозадачность. И Вы хотите запускать этот код (для автоматизации тестирования) в некой тестовой среде на ПК. Переносимость обеспечивается за счет HAL, но возникает проблема с эмуляцией многозадачности. Я Вас правильно понял?

Если я правильно понял, то почему бы не поступить как это сдано в эмуляторе FreeRTOS для Posix?
0
  • avatar
  • e_mc2
  • 18 августа 2013, 21:07
Да, но я не ставлю такой узкий вопрос как мне эмулировать многозадачность, может быть это и не надо делать. Вопрос где будет проходить hal, что с какой стороны расположить. Да и здесь же не место для вопросов, можете сказать как сами тестируете.

Про FreeRTOS посмотрю. По тексту по ссылке пишут, что делается suspend/resume, сам не подумал, что можно так просто.
0
Да и здесь же не место для вопросов, можете сказать как сами тестируете.

Я для автоматизированного тестирования emedded девайсов применял 2 метода.

Первый — просто пишем HAL и запускаем код на ПК, максимально покрывая его unit-текстами. Вообщем, обычное unit — тестирование, и покрытие получается небольшим.

Второй — тестируем на девайсе, но управляем девайсом из тестового скрипта через GDB. Тобишь тестовый скрипт через GDB заливает прошивку, ставит точки останова, читает значения переменных, сверяет значение с «эталонными значениями» заложенными в скрипте. Иногда, наоборот, модифицируем память МК из скрипта, чтобы сэмулировать некоторое «внешние действие». Скрипт не может сам нажать на клавишу на устройстве, зато можно «смухлевать», постановить точку останова в функции чтения клавиатуры, и принудительно вернуть код «нажатой» клавиши. Это тоже не 100% покрытие, но лучше чем первый вариант.

 делается suspend/resume

Да. Но управляет этим шедулер FreeRTOS, благодаря чему поведение системы в эмуляторе максимально похоже на «четный» FreeRTOS. Хотя, естественно, о реальном времени и полной аутентичности речь не идет.
+1
Второй — тестируем на девайсе, но управляем девайсом из тестового скрипта через GDB.
Интересно, а как генерить скрипт такой? Заливать — ещё ладно, а вот делать программу теста со всякими подменами и перестановкой точек =)
0
Тестовые скрипты писали тестеры вручную. Хотя была возможность полуавтоматической генерации тестовых сценариев. Для этого прямо в комментариях в коде писались «хинты» для тестового фреймворка.
типа
// Test1 checkpoint1 set a = 0
// Test1 checkpoint2 check b = 0
0
Чем не устраивает протеус? Он позволяет и датчики эмулировать и исполнительные механизмы и «реальный код мк» с многозадачностями и тд. Сам пользуюсь иногда.

Единственным недостатком вижу отсутствие возможностей написания скриптов для автоматизации. В Микрокапе с этим намного проще, но оно с МК не дружит.
0
  • avatar
  • kest
  • 18 августа 2013, 22:12
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.