[SapegoAL 0]

Пожалуйста - аппаратное зависание TWI. Исходный код - возьмите прямо из даташита.

Уважаемый. Если бы я не работал с AVR, то наверное я бы вам поверил. Слышал какие-то легенды на эту тему, но мне как-то сложно в это поверить и я не вдавался в подробности. Причина проста:

Только в одном из последних изделий у меня применена связка m640+m48. Связка работает по общей шине I2C на которой, в том числе, сидят 2 at24c512. m640 является мастером, а m48 слэйвом, который эмулирует 24с01. Там часы, температура и другие датчики. Инфу с m48 я читаю 1 раз в минуту. Чтение с 24с512 идёт непрерывно. Самое древнее изделие работает с короткими остановками 2.5 года. Изделий таких несколько десятков. Были ошибки программного характера. Сейчас устранили и никаких проблем просто нет. Ни с какими висами вообще не сталкивался. Кстати очень похожий по структуре контроллер в LPC2106.

[artemkad 62]

Прерывание, вызываемое генератором собаки. Оказывается, оно может не срабатывать. Решение, предлагаемое Атмелами - это разрешать это прерываение перед его срабатыванием. Просто писк.

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

Да и насколько я помню эта проблема была лишь на первых чипах (A).

ЗЫ. А тебе что, остальных таймеров в M48 не хватает?

Изменено 14 июля, 2008 пользователем ArtemKAD

[defunct 0]

Третье - эта ошибка описана в еррате, но предложение по ее решению мне очень нравится. МЕГА48/88/168. Прерывание, вызываемое генератором собаки. Оказывается, оно может не срабатывать. Решение, предлагаемое Атмелами - это разрешать это прерываение перед его срабатыванием. Просто писк.

Обождите, причем тут разрешение перед его срабатыванием? Особливо если учесть, что этот режим WatchDog'a используется для пробуджения МК из глубокого сна.

 

2. Watchdog Timer Interrupt disabled

If the watchdog timer interrupt flag is not cleared before a new timeout occurs, the watchdog will

be disabled, and the interrupt flag will automatically be cleared. This is only applicable in interrupt

only mode. If the Watchdog is configured to reset the device in the watchdog time-out

following an interrupt, the device works correctly.

Problem fix / Workaround

Make sure there is enough time to always service the first timeout event before a new watchdog

timeout occurs. This is done by selecting a long enough time-out period.

 

Если туго с переводом, поможем:

Главное успеть попасть в обработчик прерывания WDT до того как произойдет следующий таймаут. Что обеспечивается выбором WDT интервала достаточной длительности.

[a_electronic 0]

Только в одном из последних изделий у меня применена связка m640+m48. Связка работает по общей шине I2C на которой, в том числе, сидят 2 at24c512. m640 является мастером, а m48 слэйвом, который эмулирует 24с01. Там часы, температура и другие датчики. Инфу с m48 я читаю 1 раз в минуту. Чтение с 24с512 идёт непрерывно. Самое древнее изделие работает с короткими остановками 2.5 года. Изделий таких несколько десятков. Были ошибки программного характера. Сейчас устранили и никаких проблем просто нет. Ни с какими висами вообще не сталкивался. Кстати очень похожий по структуре контроллер в LPC2106.

Читайте внимательно - если возвращается ошибка, повторный запрос сразу с возвратом ошибки завешивает узел. У нас тоже такие связки работали, пока не понадобился контроль ошибок. Потом пришлось в весь софт встраивать патчи.

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

Да и насколько я помню эта проблема была лишь на первых чипах (A).

ЗЫ. А тебе что, остальных таймеров в M48 не хватает?

Обождите, причем тут разрешение перед его срабатыванием? Особливо если учесть, что этот режим WatchDog'a используется для пробуджения МК из глубокого сна.

....

Если туго с переводом, поможем:

Главное успеть попасть в обработчик прерывания WDT до того как произойдет следующий таймаут. Что обеспечивается выбором WDT интервала достаточной длительности.

Сорри - немного некорректно выразился ввиду некоторой давности попытки разрешить этот глюк. В общем, преложенное решение не работало и непонятно - сколько конкретно времени надо дать до срабатывания прерывания? Системы была следующая - таймер собаки использовался ввиду его маложручести. Устройство должно было отсчитывать таймаут, работая на конденсаторе при пропадании питания. Интервал собаки - 2 секунды - то есть - нереально не попасть в обработчик. Прикол заключался в том, что хотя флаг прерывания и сбрасывался (проверено), но прерывание наступало далеко не каждый раз. То есть - из 10 прерываний могли сработать все 10, а могло и не одного не сработать. После первого же несрабатывания прерывание зависает где то во внутренней логике. Кристалл был точно не А. Я, кстати постил эту проблему - безрезультатно.

Вообще, что я хочу всем этим сказать - что политика фирмы Атмел в основном ориентирована на объем продаж, а не на получение качественного изделия, в результате мы получаем даташит в котором на первой странице жирным шрифтом написано количество powerful команд, часть из которых на поверку оказывается виртуальными и указанием наличия узлов, которые на самом деле ни фига не работают или рабоотают настолько коряво. что лучше забыть о том, что они есть.

[VCucumber 0]

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

Видимо, атмеловскую собаку дрессировали сразу кусать, а Вы ее тяффкать заставляете. -Бобик, фас! -aф, аф(с)

 

 

Вспомнил еще один приятный момент.

Номенклатура AVR сейчас просто бешеная, так вот, с х-мега, похоже, ситуация улучшается - будет несколько корпусов и несколько вариантов памяти _одного_ камня.

[artemkad 62]

Прикол заключался в том, что хотя флаг прерывания и сбрасывался (проверено), но прерывание наступало далеко не каждый раз. То есть - из 10 прерываний могли сработать все 10, а могло и не одного не сработать. После первого же несрабатывания прерывание зависает где то во внутренней логике. Кристалл был точно не А. Я, кстати постил эту проблему - безрезультатно.

Наверное потому и безрезультатно, что никто воспроизвести не смог ;) .

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

[defunct 0]

преложенное решение не работало и непонятно - сколько конкретно времени надо дать до срабатывания прерывания?

Время пробуждения + C,

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

 

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

...

То есть - из 10 прерываний могли сработать все 10, а могло и не одного не сработать. После первого же несрабатывания прерывание зависает где то во внутренней логике. Кристалл был точно не А. Я, кстати постил эту проблему - безрезультатно.

Ну может быть. Уж извините все проблемы отследить сложно...

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

 

указанием наличия узлов, которые на самом деле ни фига не работают или рабоотают настолько коряво. что лучше забыть о том, что они есть.

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

[SapegoAL 0]

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, я просто объективно смотрю на вещи.

[a_electronic 0]

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

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

Честно - отключил дебаггер и флаги на порт выводил. насчет выполняет - согласен. Здесь не поспоришь. Ну по этому поводу хорошо сказал

Видимо, атмеловскую собаку дрессировали сразу кусать, а Вы ее тяффкать заставляете. -Бобик, фас! -aф, аф(с)

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

В Пентиуме, как известно, была обнаружена ошибка математики ч/з 2.5 года. И это при миллионных тиражах.

....

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

Да. И заставить их, чтобы они выпаяли их из собранных плат, причем непременно китайским паяльником. Шоб знали. Эти кристаллы тоже отзывают иногда, только не с уровня конечных потребителей. Майкрочипы так точно отзывали какие то - ПИКи16 еще.

[SapegoAL 0]

Да. И заставить их, чтобы они выпаяли их из собранных плат, причем непременно китайским паяльником. Шоб знали. Эти кристаллы тоже отзывают иногда, только не с уровня конечных потребителей. Майкрочипы так точно отзывали какие то - ПИКи16 еще.

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

 

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

[Alex B._ 0]

Что бы Вам написали, что если на TWI устройство даст ошибку и после этого сразу обратится на шину и получить ещё одну ошибку, то шина зависнет? Причём не произвольную ошибку, а ошибку при конкретной структуре обращения.

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

 

или что при команде сложения процессор может некорректно установить бит переноса? (В errate на PIC, что я уже прилагал).

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

 

перетранслировать проверенную программу!

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

 

Или вот такая шляпа (Обратите внимание не в режиме ошибки, а в режиме работы!!!)

6. Module: MSSP (All I2C™ and SPI Modes)

Тож самое, ошибка старинная и обходится компилером.

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

 

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

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

 

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

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

 

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

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

[IgorKossak 0]

Давайте к теме вернёмся, а именно к XMEGA.

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

[Serjio 0]

Узнал в Rainbow 128Xmega при 100шт ~ 101руб.

Уже доступны для заказа.

[zltigo 1]

Узнал в Rainbow 128Xmega при 100шт ~ 101руб.

Это все фигня, вот тут http://efind.ru/icsearch/?search=ATxmega128 и по одному евро обещают. Верите?

А 101руб почему-то верите :( ну бог с ним ru - например http://www.mouser.com/Search/Refine.aspx?N...ouser_Wildcards

И что характерно сроков поставки не называют. Скоро уже осень...

[rezident 0]

Это все фигня, вот тут http://efind.ru/icsearch/?search=ATxmega128 и по одному евро обещают. Верите?

А 101руб почему-то верите :( ну бог с ним ru - например http://www.mouser.com/Search/Refine.aspx?N...ouser_Wildcards

И что характерно сроков поставки не называют. Скоро уже осень...

А это типичная ситуация из анекдота

Сорри :bb-offtopic: анекдот в тему.

Приходит мужик в винную лавку.

- А чёй-то у вас водка по 3 рубля?

- Такая цена. Будете брать?

- Не-а. Вон там за углом по рублю предлагают.

- Ну так идите и купите там за углом.

- Так у них нету в наличии.

- Вот когда у меня закончится, то я тоже по рублю предлагать буду.