Наверное потому и безрезультатно, что никто воспроизвести не смог .
А вообще, мог бы использовать WDT по той-же схеме, но по прямому назначению - через каждые пару секунд проходя через Reset (когда-то в AtTiny13 так и сделал).

Время пробуждения + C,
где C определяется как время выполнения максимально длинной цепочки более высокоприоритетных прерываний. Если грубо - это сумма времени выполнения всех разрешенных более приоритетных обработчиков.


Ну может быть. Уж извините все проблемы отследить сложно...
Кстати проверяли Вы с честным Sleep или все-таки под отладкой (когда все sleep'ы эмулируются).


Вы преувеличиваете. Даже если взять ваш пример насчет WDT, то все-таки давайте вспомним, что основную свою функцию (сброс МК) этот узел выполняет!

2 oran-be. Ваши наезды на Atmel просто бредовые. В Пентиуме, как известно, была обнаружена ошибка математики ч/з 2.5 года. И это при миллионных тиражах. Проблема не в самой ошибке, а в её диагностике. Что вы бы хотели? Что бы Вам написали, что если на TWI устройство даст ошибку и после этого сразу обратится на шину и получить ещё одну ошибку, то шина зависнет? Причём не произвольную ошибку, а ошибку при конкретной структуре обращения. Такие вещи продиагностировать сложно. Такие ситуации вот у меня не встречались к примеру. Я на ходу обрывал и подключал устройство. Пробовал работать без подпорки и т.д. У меня это просто приводит к сбоям, но никак не висам. Кроме всего прочего I2C шина не предназначена для коммутации устр-в на горячую. Я, к примеру, даже не вижу смысла обрабатывать такие ошибки. Всё равно моё изделие будет функционировать неправильно, если чтение 24с неверным. Как известно, что если делать изделие с защитой от дурака, то только дурак им и воспользуется.
Иными словами такие хомуты можно найти в любом МК любого производителя.

Скажите что смешнее, что при определённых ошибках на шине I2C (собственно при некоректной работе слэйва) можно подвесить шину (выход из этого есть), что при нестандартном использовании WDT можно отлавить @опу (тоже выход есть) ..... или что при команде сложения процессор может некорректно установить бит переноса? (В errate на PIC, что я уже прилагал). То есть 1 команда из выстраданных 39 работает .... ммм ... не совсем корректно. Настолько "несовсем" что надо править компилятор или перетранслировать проверенную программу!

Или вот такая шляпа (Обратите внимание не в режиме ошибки, а в режиме работы!!!)
6. Module: MSSP (All I2C™ and SPI Modes)
The Buffer Full (BF) flag bit of the SSPSTAT register
(SSPSTAT<0>) may be inadvertently cleared even
when the SSPBUF register has not been read. This
will occur only when the following two conditions
occur simultaneously:
• The four Least Significant bits of the BSR
register are equal to 0Fh (BSR<3:0> = 1111);
and
• Any instruction that contains C9h in its 8 Least
Significant bits (i.e., register file addresses,
literal data, address offsets, etc.) is executed.


Так что лучше недокументированная шляпа в I2C, с которой я, к примеру ни разу не сталкивался (и не только я)? Или документированный хомут ядра?

Я например считаю, что при ошибках которые в той errata описаны - солидная фирма должна была бы камни свои просто назад забрать. Как это интел сделал.

Я не защищаю Atmel, я просто объективно смотрю на вещи.

Честно - отключил дебаггер и флаги на порт выводил. насчет выполняет - согласен. Здесь не поспоришь. Ну по этому поводу хорошо сказал
Проблему решил - влепил кварц часовой и увеличили раза в 2 электролит. Эти Меги48/88/168, как я понимаю, сделали в пику пикам нановаттным. Пока их отладят - а судя по семейству до Меги 8/16, то как раз года 2.5 - лучше считать их Мегами8 и не рыпаться сильно далеко. ИМХО- этот подход экономит кучу времени и нервов. Так же и ХМЕГИ.
Да. И заставить их, чтобы они выпаяли их из собранных плат, причем непременно китайским паяльником. Шоб знали. Эти кристаллы тоже отзывают иногда, только не с уровня конечных потребителей. Майкрочипы так точно отзывали какие то - ПИКи16 еще.

Так я про микрочипы и писал. Это же выдержка из микрочиповской ерраты. Вчера с официального сайта скачал.

Ошибок в ядре AVR-ки даже на заре становления не припомню. Такое только микрочип отмочить может.

Да хотелось бы. Если вы на эту ошибку не натыкались, это не значит, что нет смысла о ней заявлять. Ситуация вполне жизненная - несколько устройств на шине (емкость, соответственно затягиваются фронты) + высокая скорость + относительно высокоомные подтяжки (энергопотребление). Основной критерий потребление - отсюда желание увеличить скорость и подтяжки. Фиг с ним, что ACK в каких-то очень редких ситуациях (сильные помехи) опуститься не успеет, переспросим (интегральное потребление будет все равно ниже). Но не тут-то было...


Начнем с того, что это не команда сложения. Это инструкция приведения к BCD. Ни один компилятор ее использовать не будет. Объяснять почему? Про дремучих (в хорошем смысле этого слова) асматиков промолчу.


эта ошибка известна с незапамятных времен, чуть ли не с первых PIC18


Тож самое, ошибка старинная и обходится компилером.
И вообще, крайне неудачный вы контроллер выбрали для примера. =) Его конечно не сняли с производства и не скоро снимут, но для новых разработок он не рекомендуется. Его даже в табличке нету.


Бред какой-то. Вы хотите сказать, что недокументированая, но мелкая ошибка в кристалле лучше чем документированная, но посложней? =)) гениально - вы наверное никогда просто не сталкивались с не внесенными в еррату багами.


Забрать, закопать и надпись написать. В следующий раз когда будете приводить контраргумент, постарайтесь разобраться в теме. Приводите хотя бы адекватные примеры.


Постарайтесь не начинать холивар. Разнесу в пух и прах, надоело, чес слово. Рождайте легенды у себя в голове, отделе, на предприятии, но не на форуме - это не профессионально, легенды рождать. А до кучи вспомним STM, NXP и иже с ними. Для начала поищите по форуму на тему еррат в STR91 производства уважаемой конторы STMicroelecronics.

Давайте к теме вернёмся, а именно к XMEGA.
Если тема исчерпала себя, могу закрыть по желанию трудящихся.

Узнал в Rainbow 128Xmega при 100шт ~ 101руб.
Уже доступны для заказа.

Это все фигня, вот тут http://efind.ru/icsearch/?search=ATxmega128 и по одному евро обещают. Верите?
А 101руб почему-то верите ну бог с ним ru - например http://www.mouser.com/Search/Refine.aspx?N...ouser_Wildcards
И что характерно сроков поставки не называют. Скоро уже осень...

А это типичная ситуация из анекдота
Сорри анекдот в тему.
Приходит мужик в винную лавку.
- А чёй-то у вас водка по 3 рубля?
- Такая цена. Будете брать?
- Не-а. Вон там за углом по рублю предлагают.
- Ну так идите и купите там за углом.
- Так у них нету в наличии.
- Вот когда у меня закончится, то я тоже по рублю предлагать буду.

появились и в ценнике Digikey, цена деиствительно низкая для AVR, поставки с конца августа, но трудно поверить в этот срок.
http://search.digikey.com/scripts/DkSearch...p;x=24&y=16

AVR ISP mkII fix:
AVRISP mkII programmers manufactured from 20071012 to 20080130 has a missing parameter in the firmware. This causes the AVRISP mkII to not be able to communicate with the target AVR. The AVRISP mkII can be fixed by upgrading the firmware For procedure details see AVRISP mkII fix note.

Download upgrade package at http://www.atmel.no/beta_ware/as4/AVRISPmkIIUpgrade.exe.

Хотел обновить, а не загружает. Удалили что ли. Может у кого есть.

Так это ж бета вроде как! Обновление прошивки JTAGICE mkII идет автоматом при загрузке нового релиза AvrStudio, еxe-шник и файл прошивки сидят в распакованной Студии. А с AVRISP не так же?

Да, Студия умеет апгрейдить и AVRISP.

AVRISP и AVRISP mkII не одно и то же

Да вроде все в курсе.
Поправляюсь - Студия умеет апгрейдить то, что нужно спрашивающему