begin

OR>> Hекогда думать, "сейчас мы быcтренько-быстренько перекомпилируем OR>> и зашьём новый вариант". И уже 1000 перешивок флеша мало (это же OR>> на 2-3 месяца!),

AB> Что правда что ли? Это из одного разговора. Я что-то в духе "по сравнению с 25-ю штатными перешивками D87c51FA AVR-ские 1000 -- это вечность", а мне "да я раз 20-30 в день перешиваю, что там той тысячи..." Тут напрашивается классический вопрос - "Вы так много работаете -- когда же Вы думаете?"

AB> Я вот хоть и предложил счетчик перезаписей в avreal, а AB> реально им не пользуюсь. Еще ни разу не доходило до 1000, хотя я именно AB> так и пишу, как ты описал. Как? "Некогда думать", и в случае затыка ты практически не анализируешь код и поведение, а почти наугад меняешь/добавляешь кусок и перезашиваешь? Я не могу представить -- как при другом подходе (НЕ методом Монте-Карло) можно перешивать по 20-30 раз в день в течении многих дней подряд (в течении всей работы над проектом). Разве что заготовки для всех частей были написаны до получения в руки платы и потом в течении пары недель они поэтапно подключались к загружаемому модулю и зашивались. Иначе зашивку раз в 20 минут в течении многих дней подряд я объяснить не могу.

Кстати, если ни разу не доходило до 1000, значит не так :-) Так как по тому разговору выходило, что этой тысячи - так, на отладку пары программ.

wbr, Хотя... Старая шутка про два способа разработки электроники: Немецкий: год всё рассчитывается, за день паяется, включается, работает. Американский: за день паяется со всеми подстроечниками и потом год эти подстроечники крутятся.

Может я просто не верю в то, что второй способ существует где-либо, кроме анекдота?

OR>> Я не могу представить -- как при другом подходе (HЕ методом OR>> Монте-Карло) можно перешивать по 20-30 раз в день в течении OR>> многих дней подряд (в течении всей работы над проектом). Разве OR>> что заготовки для всех частей были написаны до получения в руки OR>> платы и потом в течении пары недель они поэтапно подключались к OR>> загружаемому модулю и зашивались. Иначе зашивку раз в 20 минут в OR>> течении многих дней подряд я объяснить не могу.

AB> Что-то ты так слова намешал, что я так и не понял во что ты веришь, AB> а во что нет.

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

wbr,

OR>> Я не верю, что при работе методом, отличающимся от "метода тыка" OR>> можно в течении _всего_ времени работы над проектом _каждый_ день OR>> перешивать кристалл по 20 раз и выбрать его ресурс таким образом OR>> за два месяца.

AB> Согласан. Каждый день так нельзя. Hо вполне могут попадаться дни AB> когда и побольше бывает. Ну так _попадаться_ и _дни_! А по тому разговору выходило, что 1000/(пусть 25) = 40, это для двух месяцев -- почти каждый рабочий день. Такие _дни_ и у меня бывают, но довольно редко, раз 1k перезаписей считаю достаточно большим числом, чтобы о нём не задумываться.

wbr,

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 -- тоже. Разве что очень уж глобальный анализ.

OR>> Я не верю, что при работе методом, отличающимся от "метода тыка" OR>> можно в течении _всего_ времени работы над проектом _каждый_ день OR>> перешивать кристалл по 20 раз и выбрать его ресурс таким образом OR>> за два месяца.

RA> Можешь не верить дальше - но именно так мне пришлось работать - дело RA> было не в RA> кривости моих способностей, а в сопряжении пика с совершенно глюкавым RA> устройством - GSM модемом. В том случае умозрительно (посидев и подумав) RA> выловить полный спектр его (модема) особенностей не получалось. Работа с :-( Я так не залетал, повезло. В самом "запущенном" в смысле документации случае хватило дней пяти и сотни-полутора перешивок.

Но таки это была работа "методом тыка", хоть и вынужденная и не по вине разработчика. Так что моя вера не поколеблена :-)

Wbr, === Женщина должна быть непокобелима.