VladimirYU

Была похожая ситуация, попались бракованные кварцы. По умолчанию МК работает от внутреннего RC генератора, как только перешивали фузы на работу с внешним кварцем происходил кирдык, так как кварц не запускался.

Повлияет, если есть инициализируемые переменные в ЕЕПРОМ, тогда на выходе будет два HEX файла. Прошивка для флэш и для ЕЕПРОМ. Например: int __eeprom val = 0x1234;

В опциях проекта выходной формат Intel-extended не забыть поставить.

Нет, к сожалению, ничего вечного. С Ксенией полностью согласен

Приммер инициализации USART1 для м128 на 1МГц, работает без ошибок, кварц 16МГц //------------ Инициализация USART1 ----------------------- void MonitorUART :: InitUSART1 (ULONG baudrate, char frame, char stopbits ) { UCSR1B = (1<<RXEN1)|(1<<TXEN1); // Количество стоп битов if ( stopbits == 1) UCSR1C &= ~(1<<USBS1); // 1 bit else UCSR1C |= (1<<USBS1); //2 bit //Устанавливаем фрэйм UCSR1B &= ~(1<<UCSZ12); char tmp = 0; switch (frame) { case 5: tmp = ~(1<<UCSZ10); tmp &= ~(1<<UCSZ11); UCSR1C = tmp; break; case 6: tmp |= (1<<UCSZ10); tmp &= ~(1<<UCSZ11); UCSR1C = tmp; break; case 7: tmp |= (1<<UCSZ11); tmp &= ~(1<<UCSZ10); UCSR1C = tmp; break; case 8: UCSR1C |= (1<<UCSZ10)|(1<<UCSZ11); break; default: UCSR1C |= (1<<UCSZ10)|(1<<UCSZ11); break; } // Скорость обмена UINT ubrr = CPU_F_Hz/ ( 16UL*baudrate) -1; UBRR1L = (char) ubrr; UBRR1H = ubrr>>8; // Разрешаем прерывания RxcIntEnable (); TxcIntEnable (); }

В папке firmware лежат исходные тексты проекта, состоящего из нескольких файлов на ассемблере, для Вашей тиньки и загружаемый файл ldp.hex. Прошивать следует именно его.

Начнем с того, что тем способом, о котором Вы писали, Вы измеряете не частоту, а период. А относительно того, как действовать дальше Вам достаточно подробно ответили. Ибо других подробностей Вашей задачи нам неизвестно.

Кстати тема "магических" чисел уже, кажется, звучала на сахаре. Может автору топика будет полезно там покопаться

В общем это и ожидалось, совет defunct единственный в Вашем случае выход.

Попробуйте из отладчика EWAVR IAR только врсия должна поддерживать м644.

Из флэш тоже должно из чистого кристалла 0xFF читаться. А почему на Olimex потянуло, отлаживать все равно не сможете? Любой AVR-программатор решит Ваши проблемы. Второе, не залочен ли случаем Ваш МК?

Странно, что нули, а не 0xFF. У меня а м64 проблем не было.

nullakilla Так как все же разрешилась Ваша проблема?

Если не нужна высокая точность, можно измеряемые сигналы проШИМить далее оптопары фильтр и АЦП.

Или наоборот вставь в цикл сброс собаки.

Спасибо всем, проблема была в том что цепь питания 5В на STK200 была реализована через самовостанавливающийся предохранитель, который через определенное время подогревался у увеличивал сопроттивление. Этого хватало чтобы режим программирования сбивался. Закоротил его и все стало на место.

Вроде да, но еще осциллом посмотрю.

Сталкивался кто-нибудь с таким эффектом. Имеется прибор на основе меги 128. Включаю питание пытаюсь зашить фузы и рабочую программу. Нескоько секунд мега откликается на программатор, а потом отькликаться перестает. Выключаю питание, вклаю снова то же самое. Программатор STK200 программа PONYPROG и Avreal эффект один и тот же. Прибор отлаженный, серийный.

Сейчас не видно а апноуты все же посмотрите, там был вариант лоадера под мегу 16, если память мне не изменяет.

struct TItem { .......... }; const TItem Item { ................... };

Но почему то на них все экономят, а потом преодолевают возникающие проблемы.

n+1) понятие обратной связи и устойчивости.

Могу предположить, что проблема с ресетом по питанию. При записи/чтении программатором ресет формируется программатором и все работает. При включении питания ресет собственный и имеем проблемы. Включите фузы отвечающие за BOD или/и поставьте внешний супервизор.

Только это придется делать при каждом измерении, т.к. если я правильно понял смещение плавает.

А что Вы вкладываете в понятие синхронный, какой ток? Постоянный или переменный, какой диапазон величин. Слишком эмоционально, но конкретики не достаточно.