3-Sep-03 09:39 Alexey V Bugrov wrote to Oleksandr Redchuk:
OR>> Я не верю, что при работе методом, отличающимся от "метода тыка" OR>> можно в течении _всего_ времени работы над проектом _каждый_ день OR>> перешивать кристалл по 20 раз и выбрать его ресурс таким образом OR>> за два месяца.
AB> Есть такие случаи - когда производятся "косметические" доработки Так это "случаи" ("дни", как в письме Алексея Бойко) или "норма"?
AB> кода, т.е. на этапе тестирования/вылизования. AB> Особенно если в программе есть UI. 20 раз его AB> можно прошить за час легко. :) Дык я не говорю, что 20-30 раз в день невозмоджно! Я не представляю, как всю тысячу выбрать за два месяца!
wbr, Кстати, о привычках :-) Кусок из реальных проектов на тему отладки.
=== util.h enum { MAIN_C = 1, UTIL_C, METER_C, CONFIG_C, MODEMIO_C и т.д.
#ifdef USE_ASSERT #define assert(p) { if( !(p) ) AssertHalt( CURFILE, __LINE__ ); } void AssertHalt(u8 fil, u16 line); #else #define assert(p) #endif
=== util.h #ifdef USE_ASSERT void AssertHalt(u8 fil, u16 line) { //... тут было немного приведения всего в "безопасное" // состояние pbuf[0] = SEGS_A; pbuf[1] = SEGS_F; Word2segs(pbuf + 5, 4, line); BlankSegs0(pbuf + 5, 3); Byte2segs(pbuf + 2, 3, fil); BlankSegs0(pbuf + 2, 2); // выводим на 7-сегментный индикатор memcpy(dispSegBuf, pbuf, 9); // и пишшим (блин, не выучил я в детстве морзянку :-( ) beepmask = 0x55; for (;;) { TickServWDT(); } } #endif ==== somefile.c #define CURFILE SOMEFILE_C
#include ... ...
Кроме прочего помогло выявить один очень странный и редко проявляющийся глюк. Насовал везде, где счёл нужным assert-ов, один раз зашил и через пару дней тестирования "у полi" мне сообщили два числа. Как часто в таких случаях -- кривой параметр одной процедуры кое-что рушил, это сказывалось совсем в другой процедуре....
Попытки поймать перешивкой - да хоть 10000 раз - врядли помогли бы. Впрочем, анализ исходников до получения чего-то в духе AF 2 890 -- тоже. Разве что очень уж глобальный анализ.