Модульное тестирование AVR на ассемблере

Как вы тестируете свой ассемблерный код?

Я работаю над последовательным сервоконтроллером как часть проекта робота hexapod, и код дошел до того, что он становится сложным;) В любом случае, я привык использовать модульные тесты в своей повседневной работе в качестве разработчика сервера C ++ и поэтому я пытался применить те же виды тестирования к моему ассемблерному коду AVR. Я разработал способ, который работает хорошо для меня (см. Здесь ), но мне интересно, есть ли какие-либо стандартные инструменты или методы, которые мне не хватает.

Обновлено: для тех из вас, кто интересуется полным исходным кодом сервоконтроллера и модульными тестами, теперь можно ознакомиться здесь .

Я бы также назвал это элегантным, но хотел бы добавить проблему, если вы простите мое вторжение.

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

Разработка через тестирование (TDD) - одна из лучших систем, о которых я слышал для разработки, и мне это нравится, но проблемы, которые занимают мое время, обычно вызваны сложными прерываниями и аппаратными событиями, которые многие называют сбоями. Кажется незначительным иметь проблему каждые 2 часа, когда звезды выравниваются, но если ваш телефон просто зависает раз в неделю, вы бы проклинали имя инженера. В нашем случае нам приходится переходить на кормушку, когда вещи действительно ломаются, чего, как вы можете себе представить, я бы хотел избежать.

Я видел очень интеллектуальные решения для проверки функциональности подсистем, которые, при правильной реализации, вероятно, сэкономили бы мне 3 часа из 50-часовой рабочей недели, но если бы был разумный способ найти ситуации с ошибками, это сэкономило бы мне недели работы. ищите «ошибку», которая иногда случается в поле под большой нагрузкой.

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

Интересный. После Рождества я планировал заняться сборкой ассемблера с фотографиями, когда у меня будет немного больше времени, и я буду хорошо смотреть на вашу систему.

Один из способов, который я мог бы увидеть, - это написать какой-то фреймворк на другом языке, чтобы создавать и разрушать фиктивные объекты и т. Д., Но как вы будете связывать это с чипом / симуляцией, будет проблемой.

Если это станет слишком обременительным, тогда это перевесит преимущества модульного тестирования, а также сделает вас менее заинтересованным в его использовании.