Мистика какая-то :(

Привет Andrey!

AA> У меня недавно на каком-то AVR была проблема со слетанием EEPROM,... AA> по моим "разборкам" получилось, что при "дребезге питания" AA> (не до нуля естественно, а так), чуть ниже ресета... AA> ресет ещё не проходит, а питание в какой-то момент оказывается AA> "дерьмовое". (Я так и не понял, что там виной - сам уровень или таки AA> перепады питания). Вообщем на будующее я сделал для себя вывод, что AA> "питание на ресет" нужно брать не от питания МС, а по возможности от AA> каскадов питания расположенных до этого питания, где процессы плохого AA> питания "зарождаются".

Вообще-то для таких случаев существуют супервизоры питания. В современных AVR'ках даже встроены в кристалл (BOD).

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Чудо-йогурт Био. Чемпион среди какао.

Привет Andrey!

AA> Я не знаю, как там у ИАРа, а вот у WinAVR пока до выполнения AA> первой команды явно написанного С-кода дойдёт (инициализация того же AA> прерывания, к примеру) столько воды может утечь, что об AA> описанных эффектах можно забыть.

AA> (В одном из реальных проектов, верхний софт для которого писал не я, AA> от Ресета до первой С-команды - 6,5мс...

Только WinAVR тут ни при чем. Что в стартапе написали, то процессор после сброса и выполняет. Пролог же функции main, генерируемый самим gcc, ничего "лишнего" не содержит, может быть даже вообще пустым.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Дареному письму в клуджи не смотрят.

Здоpовья тебе Michael и долгих лет жизни!

MB> Я pаньше, ещё до AVR, пользовался сyпеpвизоpом ADM705, MB> y него есть вход контpоля внешнего питания, я тyда подавал MB> с "электpолита" фильтpа, pазyмеется, поделив тpебyемый MB> ypовень до 1.25 вольт. Так что контpоллеp впадал в отpyб MB> ещё задолго до того, как 5 вольт начинало падать.

Вот BTW насчет АДМ. Использyю именно этy микpyшкy, и на некотоpых платах имею пpоблемy: генеpиpyет сбpос пpи ноpмальном питании. Вход контpоля 1,25 в не использyется. Вочдог, отpезал - не он. Остаются только внyтpенние пpичины? Кyда лyчше ставить этy микpyшкy? К втоpичномy источникy? или наобоpот к пpоцессоpy?

Don't worry, be happy Michael. Еадpес: Mitya1698<Собака>mail<Точка>ru Обязательно "no spam" в теме письма! ... @T:\Golded\tagline.lst

Здравствуй, Andrey!

SB>> сброс с дребезгом, либо в самом пике при такой комбинации питания и SB>> сброса что-то происходит, что он потом и на нормальный сброс не SB>> реагирует.

AA> Hе знаю как у пиков, а у авр сделать ресет обыкновенным входом, AA> или там его отключить - это штатная возможность.

Мне при работе с AVR всегда хватало типовых вариантов сброса. Примерно таких-же, как и в пиках. Правда я с этим пиком все же супервизор MCP100 в схемы ставил. Hо особо настораживает в данном случае совпадение: при определенной комбинации включения и варианта компиляции проекта (программном!) процессор перестает реагировать на сброс. Тут уж действительно пахнет сабжем или инопланетянами :)) Микрочип пишет, что медленное нарастание питания недопустимо. Hо к чему это приводит - хто знает?

Успехов! До свидания. Sergey.

Hi Andrey!

AA> У меня недавно на каком-то AVR была пpоблема со слетанием EEPROM,... AA> по моим "pазбоpкам" полyчилось, что пpи "дpебезге питания" AA> (не до нyля естественно, а так), чyть ниже pесета... AA> pесет ещё не пpоходит, а питание в какой-то момент оказывается AA> "деpьмовое". (Я так и не понял, что там виной - сам ypовень или таки AA> пеpепады питания). Вообщем на бyдyющее я сделал для себя вывод, что AA> "питание на pесет" нyжно бpать не от питания МС, а по возможности от AA> каскадов питания pасположенных до этого питания, где пpоцессы плохого AA> питания "заpождаются".

У AVR для этого встpоенный BOD есть.

Best regard, Roman Gubaev! [Team Beer - rulez forever!] е-мыло: rgubaevyandexru (что кyда вставить - сами догадаетесь :-))

... РАО "ЕЭС России", Хакасэнеpго, гpyппа связи

Пpивет, Mitya.

Вот что Mitya Gladyshev wrote to Michael Belousoff:

MB>> Я pаньше, ещё до AVR, пользовался сyпеpвизоpом ADM705, MB>> y него есть вход контpоля внешнего питания, я тyда подавал MB>> с "электpолита" фильтpа, pазyмеется, поделив тpебyемый MB>> ypовень до 1.25 вольт. Так что контpоллеp впадал в отpyб MB>> ещё задолго до того, как 5 вольт начинало падать.

MG> Вот BTW насчет АДМ. Использyю именно этy микpyшкy, и на некотоpых MG> платах имею пpоблемy: генеpиpyет сбpос пpи ноpмальном питании. Вход MG> контpоля 1,25 в не использyется. Вочдог, отpезал - не он. Остаются MG> только внyтpенние пpичины? Кyда лyчше ставить этy микpyшкy? К MG> втоpичномy источникy? или наобоpот к пpоцессоpy? 5В делается из 24 на MG> этой же плате. Пpоцессоp mb90f497g

У них поpог, когда генеpиpyется сбpос - 4.75 вольт, если склеpоз не вpёт. Так что если на линии имеются пpовальчики в виде иголок ниже этого значения, то он вполне может на них возбyдиться и сгенеpиpовать сбpос.

MG> -+- GoldED+/W32 Модеpатоp - деpевянная палка с пpокладкой из сyкна, MG> слyжащая для пpиглyшения звyка y пианино (Больш Энц Словаpь)

Этот модеpатоp y меня давно сломанный валяется. :-)))

--Michael G. Belousoff-- Yekaterinburg city mickbell(dog)mail(dot)ru

Alex,

You wrote to Andrey Arnold:

AA>> У меня недавно на каком-то AVR была проблема со слетанием AA>> EEPROM,... по моим "разборкам" получилось, что при "дребезге AA>> питания" (не до нуля естественно, а так), чуть ниже AA>> ресета... ресет ещё не проходит, а питание в какой-то момент AA>> оказывается "дерьмовое". (Я так и не понял, что там виной - сам AA>> уровень или таки перепады питания). Вообщем на будующее я сделал AA>> для себя вывод, что "питание на ресет" нужно брать не от питания AA>> МС, а по возможности от каскадов питания расположенных до этого AA>> питания, где процессы плохого питания "зарождаются". AM> Вообще-то для таких случаев существуют супервизоры питания. В AM> современных AVR'ках даже встроены в кристалл (BOD).

Тем не менее... без внешнего супервизора избавиться от ошибок в контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не удалось. Шоттки диод параллельно резистору я тоже ставил, уровень ресет выставил верхний, что-то там ещё, имеющее отношение к делу (уже не помню)... Так что ИМХО все идеи я исчерпал... :)

Andrey

Alex,

You wrote to Andrey Arnold:

AA>> Я не знаю, как там у ИАРа, а вот у WinAVR пока до выполнения AA>> первой команды явно написанного С-кода дойдёт (инициализация того AA>> же прерывания, к примеру) столько воды может утечь, что AA>> об описанных эффектах можно забыть. AM>

AA>> (В одном из реальных проектов, верхний софт для которого писал не AA>> я, от Ресета до первой С-команды - 6,5мс... AM> Только WinAVR тут ни при чем. Что в стартапе написали, то AM> процессор после сброса и выполняет. Пролог же функции main, AM> генерируемый самим gcc, ничего "лишнего" не содержит, может быть даже AM> вообще пустым.

А вот это я не понял... как это пустым...

Вот я написал программку:

=== Begin of for.c === #include <avr/io.h>

#include <iom128.h>

int main(void) { char i; char j; PORTC = PORTC & ~0x01 | 0x80; for (i=0;i<8;i++) { // j = j +i; }

for (i=7;i<0;i--) { // j = j +i; } } === End of for.c =====

=== Begin of for.lss ===

for.elf: file format elf32-avr

Sections: Idx Name Size VMA LMA File off Algn 0 .data 00000000 00800100 0000010a 0000019e 2**0 CONTENTS, ALLOC, LOAD, DATA 1 .text 0000010a 00000000 00000000 00000094 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .bss 00000000 00800100 0000010a 0000019e 2**0 ALLOC 3 .noinit 00000000 00800100 00800100 0000019e 2**0 CONTENTS 4 .eeprom 00000000 00810000 00810000 0000019e 2**0 CONTENTS 5 .debug_aranges 00000014 00000000 00000000 0000019e 2**0 CONTENTS, READONLY, DEBUGGING 6 .debug_pubnames 0000001b 00000000 00000000 000001b2 2**0 CONTENTS, READONLY, DEBUGGING 7 .debug_info 00000107 00000000 00000000 000001cd 2**0 CONTENTS, READONLY, DEBUGGING 8 .debug_abbrev 00000047 00000000 00000000 000002d4 2**0 CONTENTS, READONLY, DEBUGGING 9 .debug_line 000000af 00000000 00000000 0000031b 2**0 CONTENTS, READONLY, DEBUGGING Disassembly of section .text:

0000008c <__ctors_end>: 8c: 11 24 eor r1, r1 8e: 1f be out 0x3f, r1 ; 63 90: cf ef ldi r28, 0xFF ; 255 92: d0 e1 ldi r29, 0x10 ; 16 94: de bf out 0x3e, r29 ; 62 96: cd bf out 0x3d, r28 ; 61

000000a8 <.__do_copy_data_loop>: a8: 07 90 elpm r0, Z+ aa: 0d 92 st X+, r0

000000b2 <__do_clear_bss>: b2: 11 e0 ldi r17, 0x01 ; 1 b4: a0 e0 ldi r26, 0x00 ; 0 b6: b1 e0 ldi r27, 0x01 ; 1 b8: 01 c0 rjmp .+2 ; 0xbc

000000bc <.do_clear_bss_start>: bc: a0 30 cpi r26, 0x00 ; 0 be: b1 07 cpc r27, r17 c0: e1 f7 brne .-8 ; 0xba c2: 0c 94 65 00 jmp 0xca

------------------------------ И как избавиться тут от

__do_copy_data

Другое дело, что в данном случае объём копирования нулевой ...

------------------------------

#include <iom128.h>

int main(void) { ca: cd ef ldi r28, 0xFD ; 253 cc: d0 e1 ldi r29, 0x10 ; 16 ce: de bf out 0x3e, r29 ; 62 d0: cd bf out 0x3d, r28 ; 61 char i; char j; PORTC = PORTC & ~0x01 | 0x80; d2: 80 91 35 00 lds r24, 0x0035 d6: 98 2f mov r25, r24 d8: 9e 7f andi r25, 0xFE ; 254 da: 80 e8 ldi r24, 0x80 ; 128 dc: 89 2b or r24, r25 de: 80 93 35 00 sts 0x0035, r24 for (i=0;i<8;i++) e2: 19 82 std Y+1, r1 ; 0x01 e4: 89 81 ldd r24, Y+1 ; 0x01 e6: 88 30 cpi r24, 0x08 ; 8 e8: 24 f4 brge .+8 ; 0xf2 ea: 89 81 ldd r24, Y+1 ; 0x01 ec: 8f 5f subi r24, 0xFF ; 255 ee: 89 83 std Y+1, r24 ; 0x01 f0: f9 cf rjmp .-14 ; 0xe4 { // j = j +i; }

for (i=7;i<0;i--) f2: 87 e0 ldi r24, 0x07 ; 7 f4: 89 83 std Y+1, r24 ; 0x01 f6: 89 81 ldd r24, Y+1 ; 0x01 f8: 88 23 and r24, r24 fa: 24 f4 brge .+8 ; 0x104 fc: 89 81 ldd r24, Y+1 ; 0x01 fe: 81 50 subi r24, 0x01 ; 1 100: 89 83 std Y+1, r24 ; 0x01 102: f9 cf rjmp .-14 ; 0xf6 104: 0c 94 84 00 jmp 0x108

=== End of for.lss =====

Andrey

Hello, Andrey! You wrote to Sergey Brylew on Sun, 08 Apr 2007 21:51:50 +0400:

AA> Hе знаю как у пиков, а у авр сделать ресет обыкновенным входом, AA> или там его отключить - это штатная возможность.

У пиков тоже, но не у всех. Только у тех, что имеют внутренний тактовый генератор. У новых - практически у всех. Но в сабже используется 876-й, который довольно старый. Это же не АВРы, где приходится каждые несколько лет на новый чип переходить из-за снятия с производства старого.

With best regards, Alexander Torres. 2:461/28, E-mail: snipped-for-privacy@yahoo.com [а ночью мы снова, уйдем эскадроном..]

Hello, Sergey! You wrote to Andrey Arnold on Mon, 09 Apr 2007 07:04:37 +0400:

SB> Здравствуй, Andrey!

SB>>> сброс с дребезгом, либо в самом пике при такой комбинации питания и SB>>> сброса что-то происходит, что он потом и на нормальный сброс не SB>>> реагирует.

AA>> Hе знаю как у пиков, а у авр сделать ресет обыкновенным входом, AA>> или там его отключить - это штатная возможность.

SB> Мне при работе с AVR всегда хватало типовых вариантов сброса. SB> Примерно таких-же, как и в пиках. Правда я с этим пиком все же SB> супервизор MCP100 в схемы ставил. Hо особо настораживает в данном SB> случае совпадение: при определенной комбинации включения и варианта SB> компиляции проекта (программном!) процессор перестает реагировать на SB> сброс. Тут уж действительно пахнет сабжем или инопланетянами :))

Нет, немного не так. На сброс он реагирует, в смывсле - сбрасывается. Только это не помогает - программа после этого все равно работает с глюком.

SB> Микрочип пишет, что медленное нарастание питания недопустимо. SB> Hо к чему это приводит - хто знает?

При использовании бронаута - в общем, ни к чему.

Я работю с ПИКами примерно 14 лет, и описанных в этом треде глюков - никогда не наблюдал.

With best regards, Alexander Torres. 2:461/28, E-mail: snipped-for-privacy@yahoo.com [а ночью мы снова, уйдем эскадроном..]

Vladislav,

You wrote to Andrey Arnold:

AA>>>> У меня недавно на каком-то AVR была проблема со слетанием AA>>>> EEPROM,... по моим "разборкам" получилось, что при "дребезге AM>>> Вообще-то для таких случаев существуют супервизоры питания. AM>>> В современных AVR'ках даже встроены в кристалл (BOD). AA>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>> удалось. Шоттки диод параллельно резистору я тоже ставил, уровень AA>> ресет выставил верхний, что-то там ещё, имеющее отношение к делу AA>> (уже не помню)... Так что ИМХО все идеи я исчерпал... :) VB> Ты бы вспомнил, на каком именно AVR наблюдалось ?

ATmega8L с кварцем на 8 МГц.

Andrey

Пpивет, Andrey!

AA>>> У меня недавно на каком-то AVR была проблема со слетанием AA>>> EEPROM,... по моим "разборкам" получилось, что при "дребезге

AM>> Вообще-то для таких случаев существуют супервизоры питания. В AM>> современных AVR'ках даже встроены в кристалл (BOD).

AA> Тем не менее... без внешнего супервизора избавиться от ошибок в AA> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не удалось. AA> Шоттки диод параллельно резистору я тоже ставил, уровень ресет AA> выставил верхний, что-то там ещё, имеющее отношение к делу (уже не AA> помню)... Так что ИМХО все идеи я исчерпал... :)

Ты бы вспомнил, на каком именно AVR наблюдалось ?

с уважением Владислав

Alex,

You wrote to Andrey Arnold:

AA>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>> удалось. AM> Уточни, пожалуйста, речь идет о современных ATMEGA'х, или о AM> старинных AT90? А то в старых EEPROM действительно работала ненадежно, AM> сами атмеловцы это признали и что-то там переделывали...

Что в доке заложено я только что сообщил, а что там реально стояло, может и ATMega8, ибо питание там от BP5221A, то бишь пятивольтовое, я смогу уточнить только завтра. Hо думаю, это вопрос второстепенный.

AA>> Шоттки диод параллельно резистору я тоже ставил, уровень ресет AA>> выставил верхний, что-то там ещё, имеющее отношение к делу (уже AA>> не помню)... Так что ИМХО все идеи я исчерпал... :) AM> Издевательства производились в момент записи в EEPROM, или порча AM> данных наблюдалась даже когда ничего не записывалось?

Данные считывались с ошибкой, когда я стартовал одновременно непрерывно издеваясь над напряжением питания. Причём последующие старты с нормальным питающим напряжением повторяли ошибку считывания. То бишь, что-то менялось именно в содержимом ЕЕПРОМ, хотя в этот момент туда по тексту программы ничего не писалось, только считывалось.

ЗЫ. В принципе, где-нибудь в четверг (вторник и среда уже заняты другими делами) я могу ещё какие-нибудь опыты провести. Плата у меня есть.

ЗЗЫ. Hулевая ячейка ЕЕПРОМ не используется. Просто... чтобы не заморачиваться и этой проблемой.

Andrey

Alex,

You wrote to Andrey Arnold:

AA>> 00000098 <__do_copy_data>: AA>> И как избавиться тут от __do_copy_data? AM> А чем она тебе мешает? У тебя программа не влезает в ПЗУ?

Тут я очевидно погорячился со словом "избавиться".

Я хочу "избавиться" от неё в этом месте, точнее я хочу предварительно выполнить некие нужные мне инструкции по установке железа, а уже потом пусть долго и нудно (6,5 мс) выполняется __do_copy_data

ЗЫ. А насчёт размеров памяти вопрос в данном случае вообще не стоит.

Andrey

Привет Andrey!

AA> Тем не менее... без внешнего супервизора избавиться от ошибок в AA> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не удалось.

Уточни, пожалуйста, речь идет о современных ATMEGA'х, или о старинных AT90? А то в старых EEPROM действительно работала ненадежно, сами атмеловцы это признали и что-то там переделывали...

AA> Шоттки диод параллельно резистору я тоже ставил, уровень ресет AA> выставил верхний, что-то там ещё, имеющее отношение к делу (уже не AA> помню)... Так что ИМХО все идеи я исчерпал... :)

Издевательства производились в момент записи в EEPROM, или порча данных наблюдалась даже когда ничего не записывалось?

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Я удалю твою жажду. Без возможности восстановления.

Привет Andrey!

AM>> Пролог же функции main, AM>> генерируемый самим gcc, ничего "лишнего" не содержит, может быть AM>> даже вообще пустым.

AA> А вот это я не понял... как это пустым...

======= test.c ========= void do_smthng(void);

int main(void) { do_smthng(); return 0; } ======================== ======= test.s ========= .file "test.c" .arch avr2 __SREG__ = 0x3f __SP_H__ = 0x3e __SP_L__ = 0x3d __tmp_reg__ = 0 __zero_reg__ = 1 .global __do_copy_data .global __do_clear_bss .text .global main .type main, @function main: /* prologue: frame size=0 */ /* prologue end (size=0) */ rcall do_smthng ldi r24,lo8(0) ldi r25,hi8(0) /* epilogue: frame size=0 */ ret /* epilogue end (size=1) */ /* function main size 4 (3) */ .size main, .-main /* File "test.c": code 4 = 0x0004 ( 3), prologues 0, epilogues 1 */ ========================

Обрати внимание, что первая же сгенеренная компилятором инструкция - вызов do_smthng.

AA> Вот я написал программку:

AA> === Begin of for.c === поскипано AA> === End of for.c =====

AA> === Begin of for.lss ===

AA> 00000000 <__vectors>: AA> 0: 0c 94 46 00 jmp 0x8c AA> 4: 0c 94 63 00 jmp 0xc6

Если заведомо известно, что main не использует ни .data, ни .bss, ни прерывания, что мешает разместить ее код сразу с адреса 0?

AA> 00000098 <__do_copy_data>:

AA> ------------------------------ AA> И как избавиться тут от __do_copy_data?

А чем она тебе мешает? У тебя программа не влезает в ПЗУ?

Линкер хочет видеть (прилинковать) эти символы из-за того что компилятор вставляет в каждом файле вот это:

.global __do_copy_data .global __do_clear_bss

Это фича у него такая. Самое простое - смириться с тем, что в ПЗУ будет лежать несколько десятков ненужных инструкций. Выполнять-то их никто не заставляет! Если все-таки жалко ПЗУ, скажи -nostdlib. Если не хочешь -nostdlib, просто определи где-нибудь эти символы, например в самом хвосте твоего стартапа:

.global __do_copy_data .global __do_clear_bss __do_copy_data: __do_clear_bss:

Линкер увидит, что они определены, и будет счастлив. И ничего лишнего из библиотек тянуть уже не будет. Можно и в сишном файле определить функцию, не содержащую ни одной машинной команды, хотя это уже похоже на извращение. :) Еще у линкера есть опция, с помощью которой можно заставить его считать символ определенным. Во-можно, ей в данном случае можно возпользоваться (но я не уверен, поможет ли, не пробовал).

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Смотрю куда глаза глядят...

Пpивет, Andrey!

AA>>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>>> удалось. Шоттки диод параллельно резистору я тоже ставил, AA>>> уровень ресет выставил верхний, что-то там ещё, имеющее AA>>> отношение к делу (уже не помню)... Так что ИМХО все идеи я AA>>> исчерпал... :) VB>> Ты бы вспомнил, на каком именно AVR наблюдалось ?

AA> ATmega8L с кварцем на 8 МГц.

А что происходило, не уточнял ? Я вот помню, что на 90S2313 при плавном падении питания затиралась ячейка, на которую в этот момент указывал EEARL, а когда я стал после всех операций с EEPROM принудительно обнулять адрес и отказался от использования нулевой ячейки, эффект почему-то вообще исчез и ее содержимое перестало искажаться. С мегами до сих пор я не видел таких чудес. Стоило бы посмотреть, что же там такое происходит - что на что искажается, в какой именно момент, и куда при этом указывали регистры адреса. Если, конечно, это не самопроизвольный вход в программу записи или, что маловероятно, но возможно (наблюдалось на 90S) - вход в режим программирования.

с уважением Владислав

Vladislav,

You wrote to Andrey Arnold:

AA>>>> Тем не менее... без внешнего супервизора избавиться от ошибок в AA>>>> контрольной сумме ЕЕПРОМ издеваясь над питанием мне так и не AA>>>> удалось. Шоттки диод параллельно резистору я тоже ставил, AA>>>> уровень ресет выставил верхний, что-то там ещё, имеющее AA>>>> отношение к делу (уже не помню)... Так что ИМХО все идеи я AA>>>> исчерпал... :) VB>>> Ты бы вспомнил, на каком именно AVR наблюдалось ? AA>> ATmega8L с кварцем на 8 МГц. VB> А что происходило, не уточнял ?

Я занимался в основном проблемами железа, но со слов программиста, системы он не заметил.

VB> Я вот помню, что на 90S2313 при плавном падении питания затиралась VB> ячейка, на которую в этот момент указывал EEARL,

А как такое можно выловить? Пока железячный дебагер стартует, или там, сделает шаг, проходит вечность, и тут ИМХО он не помощник.

VB> а когда я стал после всех операций с EEPROM принудительно обнулять VB> адрес и отказался от использования нулевой ячейки, эффект почему-то VB> вообще исчез и ее содержимое перестало искажаться.

Про это и я и он знал с самого начала (уж извини, откуда не помню) и в софте это реализовано было опять же с самого начала.

А ты "достаточно издевался" над напряжением питания?

VB> С мегами до сих пор я не видел таких чудес. Стоило бы посмотреть, VB> что же там такое происходит - что на что искажается, в какой именно VB> момент, и куда при этом указывали регистры адреса.

Это всё хорошо, вот только как такое можно практически отследить?

VB> Если, конечно, это не самопроизвольный вход в программу записи или, VB> что маловероятно, но возможно (наблюдалось на 90S) - вход в режим VB> программирования.

К сожалению ничего добавить к преждесказанному не могу.

Andrey

Хоpошее Кино это вино. Выпьем, Andrey? Воскpесенье Апpель 08 2007 10:21, Andrey Arnold wrote to Sergey Brylew:

SB>> 7805 пpи включении. А заменить 7805 на что-нибyдь посовpеменнее? AA> Я не знаю, как там y ИАРа, а вот y WinAVR пока до выполнения AA> пеpвой команды явно написанного С-кода дойдёт (инициализация того же AA> пpеpывания, к пpимеpy) столько воды может yтечь, что об AA> описанных эффектах можно забыть.

Детсад какой-то, ей-богy. Сишный стаpтап подменить необpазованность не позволяет?

Майкл