Совершенно согласен с предыдущим оратором

И более того - очень часто программы для МК пишу так, чтобы они компилились и запускались на компе. Для этого делается простенький HAL (Hardware Abstraction Layer) на макросах. Например:
Код:
#define hal_led1_on() (PORTC &= ~0x08)
#define hal_led1_off() (PORTC |= 0x08)
#define hal_is_btn1_pressed() (PINB & 0x04)
И потом в проге везде пишем конструкции вида:
Код:
if (hal_is_btn1_pressed())
hal_led1_on()
else
hal_led1_off()
Ну в общем думаю смысл понятен. Макросы выносим в hal.h, а для винды пишем свой hal.h, в котором вписываем нужные действия - в зависимости от того что за прога, сообщения там на консоль валим или к каким-то кнопочкам-лампочкам в ГУИ привязываем. Для гуи кстати наша прога должна работать в отдельном потоке, чтоб не тормозило.
И все. Отладка на железе упрощается на порядок, потому что при достаточной сложности софта большая часть багов - чисто софтовые и на эмуляции вылезают и фиксятся. А перекомпилировать и запустить прогу на компе занимает несколько секунд, в отличие от перепрошивки контролера. Плюс иногда удобно работать не в реальном времени, тогда пятиминутный тест проги (какого-нить ПИ-регулятора) можно уложить в секунды. Но для таких задач одними кнопочками в гуях не обойдешься, надо писать эмуляцию регулируемой системы...
Мда, это я уже полез в материи, полезные для тех, кто программировать уже умеет
Добавлено спустя 3 минуты 30 секунд:А - самую главную полезность забыл - на компе есть ОТЛАДЧИК!!! Можно точки останова ставить и переменные смотреть. На атмеге8 это намного сложнее
