Мне нравится отделять задачи. Например, когда я создал круговой буфер для своего Atmel AVR, я написал все это в Code :: Blocks и скомпилировал его с помощью обычного компилятора GCC вместо компилятора AVR GCC, затем создаю для него единичный тест. Я использовал специальный файл заголовка, чтобы обеспечить соответствующие типы данных, с которыми я хотел работать (например, uint8_t). Я обнаружил ошибки с модульными тестами, исправил их, затем перевел фиксированный код в AVR Studio и интегрировал его. После этого я использовал написанные функции поддержки и ISR, чтобы поместить буфер в полезный код (т. Е. Вытащить один байт из буфера, вставить его в регистр вывода данных UART, добавить строчную константу в буфер для функции printf и т. Д.). Затем я использовал симулятор AVR, чтобы убедиться, что мои ISR и функции вызываются и что правильные данные появляются в регистрах. После этого я запрограммировал его на чип, и он работал отлично.
Я очень предпочитаю возможности отладки Code :: Blocks по сравнению с AVR Studio, поэтому я использую вышеуказанный подход, когда могу. Когда я не могу, я обычно имею дело только с оборудованием. Например, у меня есть таймер, который автоматически создает прямоугольную волну. Лучшее, что я мог сделать, это увидеть, что в симуляторе сбивается штыревой бит. После этого мне просто нужно было поднять прицел и убедиться.
Мне нравится использовать многоуровневый подход при отладке проблем. Например, с часами первый слой: «Поместите зонд на булавку и посмотрите, есть ли там сигнал». Если нет, проконтролируйте штырь на uC и ищите сигнал. Затем я закодировал интерфейс отладки в одном из моих UART, где я могу посмотреть конкретные значения регистра и убедиться, что они такие, какими они должны быть. Поэтому, если это не сработает, следующим шагом будет «вызвать значение регистра и убедиться, что оно правильно».
Попробуйте подумать вперед четыре шага или около того, когда вы планируете свою отладку. Здесь должно быть + 5В, но что, если нет? Запишите в интерфейс отладки способ переключения булавки и посмотреть, не изменит ли она ее. Что делать, если это не сработает? Сделайте что-нибудь еще и т. Д. И т. Д. Вы дойдете до точки, в которой вы столкнетесь: «У меня нет ИДЕИ, ПОЧЕМУ ЭТОТ ОПАСНО, ЧТО НЕ РАБОТАЕТ !!!!» но, надеюсь, вы поймете причину заранее.
SRoe, я также настоятельно рекомендую вам абстрагироваться от более высокоуровневой логики, алгоритмов, функциональности и т. Д. Стремитесь изолировать действительно аппаратное или конкретное устройство в небольшом числе модулей. Это облегчит вам руководство Аарона. Это также улучшит тестируемость аппаратно-незаписанных бит. –
После запуска на хосте вы должны выполнить единичные тесты на реальном целевом оборудовании, но выбивать доступ к внешнему оборудованию. Это улавливает компилятор и аппаратные ошибки на целевой платформе. Это может потребоваться даже для более высоких уровней SIL. – starblue