На сайте Atmel появились даташиты на Xmega с USB-интерфейсом:
ATxmega16A4U/32A4U/64A4U/128A4U
ATxmega64A3U/128A3U/192A3U/256A3U

Все семество AU:
http://atmel.com/dyn/resources/prod_docume...p;family_id=607

ATxmega16A4U/32A4U/64A4U/128A4U
http://atmel.com/dyn/resources/prod_docume...p;family_id=607

ATxmega64A3U/128A3U/192A3U/256A3U
http://atmel.com/dyn/resources/prod_docume...p;family_id=607

Радует малый размер errata и ее отсутствие в части USB.

Ксения, извините, но раз ужВы посмотрели DS - их можно по USB программировать?

Я поняла так, что нельзя. Среди бутлоадеров USB не упоминается:

Жаль, если так...

Да, жаль

Вообще-то USB-загрузчик - вещь исключительно программная, а не аппаратная. Это SPI- или JTAG-загрузчики должны поддерживаться аппаратно, а USB-загрузчик всегда может быть написан для МК, способного к самопрограммированию (т.е. к записи в свой flash). На худой случай можно было бы легко адаптировать USB-загрузчики от серии AT90USB. Другое дело, что фирма-производитель должна была бы поставлять такой бутлоадер сразу в фабричном изделии. Странно, если такая возможность не была использована - никаких препятствий на этом пути я в упор не вижу.

Не переживайте, появится. Не все сразу.

Обязательно появится в следующих модификациях изделия. У ATMEL выбора нет: либо выпускаешь свои вкусные булочки -- с изюмом, как у других производителей
(других архитектур), либо без изюма, и тогда твой товар постепенно теряет интерес у потребителей.

Вопрос в другом -- "когда?" Наличие ДШ на МК и доступность самих МК -- это несколько разные вещи.

Да ну что в нем хорошего ? Для серии совершенно не годится, пока компом он увидится, потом в программаторе нужно сконектится, уходит уйма времени… Например в at90usb162 есть этот загрузчик… По моему по spi проще и быстрей….

Думаю, что ждать осталось немного. У Атмеля, как известно, был посткризисный затык, когда его продуция почти совсем пропала с прилавков магазинов. Производство пришлось разворачивать, фактически, с нуля в совершенно другом месте. Но сейчас дело уже на мази - от былого дефицита практически не осталось и следа. Ныне уже ничто не мешает Атмелю выпускать новьё, т.к. с накопившимися "долгами" он расквитался.

Однако не исключено, что Атмел более реалистически взглянул на ситуацию и понял, что направление AVR32 так и не перехватило эстафету популярности у AVR8, как на это ранее рассчитывали. Т.е. несмотря на все вкусности платформы AVR32, народ не спешит на нее перебираться. А кому на AVR8 становится тесно, предпочитают перебираться не на AVR32, а на ARM. В этой ситуации далее торомозить включение USB-интерфейса на Xmege стало нецелесообразно.

Ранее предполагалось включить USB-интерфейс лишь в состав старших Xmega: ATxmega128A1U и ATXmega-128B1 (на них до сих пор не выложены даташиты). И вот вдруг такой резкий поворот - вето на USB преодолено сразу на широкий спектр девайсов.


Мне прошивка через SPI тоже больше нравится, однако Xmega эту возможность не поддерживает. А в этом случае прошивка через USB составляет сильную конкуренцию JTAG, т.к. не требует дорогого программатора.

PDI как альтернатива рулит... Теоретически.

PDI это тоже самое что и JTAG/SPI - железный автомат, требующий внешнего программатора. USB загрузчик совсем другое.

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

Что за кризис-то? Атмел что, разве обратно купил фабрики? Где?



это -- да.


Народ как раз подается в сторону на Кортексов, а не АВР32. По крайней мере в моем окружении именно такая ситуация. Более того, я даже знаю людей, которые мигрировали с АВР32 на Кортексы.


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

Я не фанат Атмела, хотя очень близок к этому статусу. Мои основные "поделки" базируются именно на АВР-ках. На STM8 а не пересел только потому, что в моем арсенале числится еще и MSP430 и ARM7/Cortex от NXP. От этого зоопарка архитектур и без того рвет крышу. В последнее время я чаще стал задумываться о сокращении количества поддерживаемых архитектур. Ну, в самом деле, сложно успевать за всеми новинками и вкусностями в современном динамичном мире! И я прихожу к выводу, что самый лучший вариант для моих изделий -- это будет Кортекс. Конкретно Cortex-M0 и Cortex-M3. И очень похоже, что я этими пунктами закрываю все свои направления. Мне самому печально это произносить, но это факт. Атмел уходит из моей жизни. Точно так же как ушло 51-е ядро. Навсегда.

Как Вы думаете -- что может предложить мне Атмел взамен LPC11xx/LPC17xx ?

(Боюсь, что так думаю не только один я.)

Не то чтобы купил, а типа арендовал. Где-то на Филиппинах. Т.е. Атмел, как и намеревался, все-таки ушел от "натурального хозяйства", когда всё приходилось делать своими руками на собственных фабриках. Сейчас он просто заказывает нужное ему на чужих фабриках, подобно тому, как отечественные электронщики уже не травят платы сами, а заказывают их производство на поточных линиях. А порой и с впаиванием деталей. Таково веление времени - предельная специализация: одни фирмы специализируются на разработке микросхем, а другие на их производстве. Самим же строить фабрики невыгодно - пока построишь, глядишь, а техпроцесс уже шагнул на меньшие нанометры.


Возможно это и так. ARM нынче в моде. Но лично я просто балдею от AVR32, и в частнсти от серии AT32UC3C.


Да именно так. Полагали, что за неимением USB народ подастся на AVR32. Боялись, что "продвинув" серии AT90USB и ATmega, тем самым создадут конкуренцию серии AVR32, на которую очень рассчитывали. Серия AVR32 действительно получилась замечательная, но законы конкуренции неумолимы - там правят свои законы, основанные на популярности. Сейчас в моде ARM, хотя он этого не вполне заслуживает.


Понимаю вас, но ... не разделяю ваших предпочтений. Сама лично фанатка Атмеля и ничего не могу с этим поделать.


Ничего не могу ответить на этот вопрос, т.к. с LPC11xx/LPC17xx дела никогда не имела.

Что значит "взамен"? Тут и два АРМ-а от разных производителей взамен не сильно идут, а как рассматривать взамен полностью разные камни?

Я имел ввиду "взамен семейства LPC11xx/LPC17xx", а не "замену одного камня на другой эквивалентный ему и желательно с совпадающий по ногам".
Понятно, что у Атмела есть серия Кортексов, но... по совокупности все параметров... Почти шило на мыло. Смысла нет.

Вот тут:


и тут:


Ксения, скажите, а что Вас так сильно привлекает в AT32UC3C? Почему Вы от него "балдеете"?
И второй вопрос.
Скажите, почему, по Вашему мнению, ARM не заслуживает внимания, что в нем такого, что Вы предпочитаете ему AVR32?

Спасибо.

Дык с таким подходом вы не сможете привести что предлагает NXP взамен AVR. Т.к. по совокупности параметров ...
У нас сейчас к примеру двигается проект на STM32 (двигает коллега - и нам польза и ему опыт) и тут-же я уже вижу всю ту кучу проблем которая свалится в обозримом будущем. Начиная с банальнейшей - чем записывать программу на производстве т.к. с компа заливать софт никто не позволит.
PS. Совокупность параметров бывает разной. Я к примеру LPC11 в своих задачах не буду использовать просто из-за отсутствия встроенной EEPROM. Это для меня более чем определяющий параметр.

Ну не знаю что за кучу проблем Вы смогли разглядеть... Я сейчас работаю с STM32 и вижу лишь одни плюсы.
1. Шить можно по уарту через заводской бутлоадер - не нужен программатор для производства.
2. EEPROM эмулируется посредством IAP.
3. Для отладки и разработки есть SWD - реально лишь 4 провода вместе с питанием (у AVR8 6 проводов).
И т.д. и т.п. куда не копни.

Еще раз для тех, кто не читает. Прибор для программирования обязан иметь один разъем, одну кнопку и свисток обозначающий завершение записи. И никаких ПК, юартов и заводских бутлоадеров которые все равно надо прописывать. Разъем вставил, нажал - прописал. Все что сложнее - пользуйтесь сами при программировании, но на производстве такого не надо.

Эмуляция это как-бы не одно и то-же. Когда надо писать 10 байт - еще куда не шло. А когда хоть пол сотни с контролем и восстановлением корректности каждого байта/слова - тут эмуляция вылазит боком.

И вроде бы - да, я на эту тему хотел услышать мнения. И вроде бы -- нет, что-то куда-то не туда соскользнула мысль.

Давайте-как я уточню и еще раз подвешу свой вопрос.

Как Вы думаете -- что может предложить (мне) Атмел взамен линеек LPC11xx и LPC17xx, которыми я планирую зарыть почти все свои направления?
Разницу в питании +3.3В и +5.0В, а так же наличие/отсутствие корпусов DIP можно не упоминать. Почти не принципиально. Я даже не хотел бы поднимать проблему наличия/отсутствия EEPROM "на борту". По нынешним временам, подвесить внешнюю 24LCxx не такая уж и большая проблема.

Я свой вопрос задаю исходя вот из каких соображений. Просто я старею, а мир настолько быстро изменяется, и ... я уже начинаю это замечать... что я просто физически не успеваю отслеживать направления AVR, MSP430, Cortex. Я хотел бы произвести "сокращение штатов". Кого-нибудь "уволить" из этого набора.

АВР -- подкупает свое "народностью" и доступностью.
MSP430 -- это бывший лидер по энергопотреблению. Равных ему реально нет. Сейчас это уже не так.
Cortex -- молодой и преспективный. Многообещающий.

Из недостатков:

AVR -- дорогой, собака! При интенсивном использовании констант (константные строки, avr/progmem.h) в программе, Си-ный код программы становится "неуклюжим", теряет прозрачность и красоту. Потом становится тяжело его сопровождать. Противоречие Гарвардская архитектуры проца и изначальной ориентации Си на Фон-Нейманоскую архитектуру.
MSP430 -- какой-то он ватный. Ни то, ни се! Ни жуткой скорости как у Cortex-M3, ни насыщенной периферии на малых кристаллах, как у AVR.
Cortex -- личная моя не освоенность его на платформе Linux. Но это временно. Неопределенность в вопросе -- можно-ли вообще изготовить репликатор для массового программирования изделий на базе Кортексов. (Репликатор -- это программатор, у которого целевая прошивка находится внутри. Т.е. можно реплицировать код без компа.)

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

Я не знаю... мне кажется, если оставить рядом только LPC11xx и LPC17xx, то я закрою очень широкую панораму, начиная от мелких девайсов, котрые должны только мигать ЛЭД-ом и ничего более не делать, до девайсов, которые должны общаться с компами (через Ethernet, через USB), поддерживать LCD (в том числе графические до 320х240), даталогеры, ну и т.д. Единственный момент, который я тераю отказавшись от AVR -- удобные для быстрого макетирования DIP-кузова.

И да! Я принципиально не изучаю ни PIC-и, ни STM8, ни XMega по этой же причине -- катастрофическая нехватка времени! Меня не устраивают поверхностные знания и юзание "библиотек на все случаи жизни" (камень в огород STM8). Я предпочитаю копать глубоко.

Извините! Я сказал очень много. Я хотел бы услышать мнение народа.

Если я начну с вами бодаться на тему, что лучше, AVR32 или ARM, то начнется холивар . Обращаю ваше внимание то, что сейчас вы находитесь на территории раздела AVR, а потому здесь активная критика AVR/AVR32 в пользу других платформ условно наказуема. Лично я нечего не имею против священных войн, но положение модератора ftp обязывает меня соблюдать негласные правила куда строже, чем остальных участников форума.

Однако совсем кратко я могу намекнуть на причину своих предпочтений. Дело в том, что платформа AVR (и отчасти AVR32) куда более соответствует контроллерам, тогда как архитектура ARM более соответствует процессорам. Резкой границы между контроллерами и процессорами нет, но интуитивно она ощущается. Например, очевидно, что архитектура Intel x86 предназначена именно для процессоров, а AVR8 для контроллеров. Так и здесь. AVR32 много больше контроллер, чем ARM. Архитектура ARM не была рассчитана на контроллеры, но контроллеры на этой архитектуре сделали через ж... ухо . В то время как архитектуру AVR32 специально разрабатывали для контроллеров.


Не уверена, что ваш LPC11xx переплюнет любой из AVR32. Последние предельно экономичны.

Хорошо, Ксения, я понял, но вопросы остались.
Холливары и подростковые "бодания" никому не нужны.
Где бы мы могли с Вами поговорить на эту тему, чтобы не нарушать правила. (Или вырезать и перенести часть темы в другую? Вы можете это сделать?)
И мои извинения -- это я свернул тему в совершенно другом направлении.

Так вроде "ОБЩЕНИЕ" открыто

avr32, пардон за продолжение, вкусен, но плохо пахнет. Будет стабильность, - будет(?) и успех.
И pic32(йето холливар) - тоже интересен. Остальное как-то теряет вес, имхо.

Неправда в каждом предложении. Расуждения свидетельствующие п полном незнании других архитектур. Особенно показательно в этом смысле сваливание в одну кучу всех столь разнообразных ARM - этакий собирательный образ врага.

На бумаге по отдельно выпяченным параметрам. На комплексное, включая периферию, решение проблемы энергопотребления Atmel в отличие от MSP так и не осилил. Среди малых контроллеров за исключением MSP хорошо смотрится STM8.

Все определяется целесообразностью. Вот вроде хотели отказаться от АВР, но весной выиграли тендер на 8 килоустройств, посчитали, посмотрели - Мега88 полностью перекрывает все потребности и АРМ вроде как и не при делах при таком раскладе, а СТМ8 еще не освоен в должной мере.

Между строк: я знаю как минимум несколько весьма крупны производств где зашивка происходит путём кликания на батничек и вывода сообщений на экран о результате программирования, юстировки или калибровки. И нет никаких проблем. Не лишне ещё раз поблагодарить AVReal'а. При этом на производствах работают совершенно разные люди от студентов до женщин преклонного возраста. Но если для Вас это принципиально - так потратьте неделю и сделайте свой автономный программатор с интерфейсом uart - чем плохо?

Каким это? Эмуляция на то и эмуляция что Вы вольны добиться любого перфоманса от хранилища и даже сильно лучшего нежели работа напрямую с eeprom встроенным в AVR или внешним AT24. Я говорю об этом потому что лично пробовал и имею положительный опыт. А Вы на мой взгляд лишь теоретизируете на эту тему и пытаетесь убеждать в чём-то окружающих. Странно это... Для себя можете настроить целый замок из страшилок о современных ширпотребных армах и так и продолжать жить в мире и согласии с AVR, но не стоит строить посылы в массы основанные только на глубоко субъективных индивидуальных фобиях.

Подвесить - никогда не проблема. Вот только это - ноги, место на плате, деньги, контакты пайки, доступность содержимого снаружи....

Он никогда не был лидером. Они с Atmel и Microchip шли практически нос-в-нос. На самом деле там все зависело от метода измерения. Тем более, что отсутствие EEPROM убирает из тестовой программы потребления один из самых потребляющих элементов.


ГДЕ? Особенно после того, как добавить стоимость 24LCxx с которой "не такая уж и большая проблема"

Ну ни за что бы не сказал... Я конечно progmem.h никогда не пользовался, но больших проблем с константными строками не замечал. Была как-то проблема константного массива константных строк, но это скорее проблема Cи т.к. в АСМ-е там вообще не проблема.

А это то тут причем? Причем тут разделение кода и данных с ориентацией Си? Есть желание тягать лишние байты при обращении к памяти ради непрерывного адресного пространства?

Может быть. А как к примеру использование перспективного CC430. Или уже есть дешевые транссиверы плюс Cortex в одном флаконе?

XMega это практически тот-же AVR плюс новая периферия... Из минусов - убрали SPI-программирование.



И что он будет делать с голым камнем на котором бутлоадером и не пахнет?

Да уж... Сильно лучше когда в любой момент можно или потерять все содержимое страницы или выделять на каждый элемент раз в сто больше чем надо...

В 3 метрах от меня валяется автомобильная магнитола в которой китайцы решили сэкономить на EEPROM-ке и начали писать текущие настройки во ФЛЕШ... Проблем небыло ... первые два месяца. А вот потом это стало регулярным геморроем для отдела гарантийного обслуживания. Сперва платы просто списывали, но после второго десятка пришли ко мне с вопросом - КАКОГО они помирают. Основной способ ремонта оказался - переписать ФЛЕШ. И это не одна модель и даже не один производитель...
Напомнить еще какова гарантия сохранения текущих настроек в GSM-модулях? Там так-же решили не заморачиваться...

Чип выходит с завода-производителя уже прошитым загрузчиком изначально (применительно STM32 и наверное подавляющему большинству ширпотребных ARMов). И действительно не пахнет.Это не аргумент, а лишь домыслы и продолжающиеся попытки притянуть кота за уши...
Всё зависит от кривизны рук программиста. Написали так что может слететь - будет слетать. И ничего более.

+1.

Это скорее всего плюс а не минус. Связь программатора (в широком для Вас смысле) с программируемым МК более надежная. Скорость быстрее. Проводов меньше. Габариты разъема программирования меньше.

Был и остается, естественно, среди равных по производительности.

Ага . У MSP430 в реале, а Atmel именно оно это самое "все зависит от метода измерения" . Уже писал, все выдают всякие зависящие от метода измерения данные по ядру, но совершенно "забывают" о периферии, ресурсах ядра уходящих на ее обслуживание и возможности автономной работы периферии.

Типичный ток потребления первой попавшейся EEPROM будет на уровне 1-2uA, что, конечно, заметно, но отнюдь не "из самых потребляющих".

Стоимость в хоть каких-то заметных количествах на уровне 10..15 евроцентов.

На самом деле вопрос использования или неиспользования внешней EEPROM намного более широк, чем Вам кажется.

Любопытно как Вы эту равную производительность считаете? По производительности арифметических операций? Да, 16 битник тут может выигрывать... Но арифметика в программах это не самые распространенные операции, а значит их вклад в общее время не сильно заметный. Наиболее частые - различные проверки и переходы. А вот тут как раз преимуществ нет.

Ну если Вы так считали ток потребление МК - я тогда не удивлен выводам. Возьмите еще раз в руки доку на "первую попавшуюся EEPROM" и найдите ток потребления в режимах чтения и записи, а не во время простоя. Вы там найдетеп 1-2мА при чтении и 3-5мА при записи. Это для черепашных i2c. Для более шустрых SPI до 10-20ма на 10МГц.
Открой доку на твой любимый MSP и найди такой периферийный модуль который при работе потребляет такие токи.

Плюс монтаж, плюс монтаж обвески, плюс цена места на плате и того центов 25 можно смело добавлять...

Причем тут "преимущества" в производительности, если я говорю про потребление при равной производительности обеспечивающей получение одинакового результата. Кроме того, еще раз обращаю внимание на роль в энергопотреблении правильно спроектированной периферии. Например, даже супер-пупер-пико потребляющее ядро вынужденно работающее на более высокой тактовой из-за того, что для тактирования периферии, например, на PWM банально нет возможности давать частоты выше частоты ядра, проиграет тому контроллеру, чья периферия может гибко тактироваься. И уж совсем со свистом проиграет контроллеру, который будет иметь на борту DAC и способным генерировать даже более лучшего качества гармонические сигналы работая на тактовых частотах в десятки килогерц, вместо мегагерц.

Разумеется. А я мог сравнивать токи потребления в рабочих режимах? Тогда теперь ВОЗЬМИТЕ документацию на AVR8 и попробуйте найти там токи потребления при при работе с EEPROM. Сравним. Но там их вообще НЕТ. Нет, как и массы других данных необходимых для оценки энергопотребления при реальной работе. Но тем не менее Вы считаете возможным почему-то рассуждать о якобы малом энергопотреблении. Может Вы еще думаете, что на борту AVR какой-то совершенно волшебные технологии EEPROM совсем не такие, как тот-же Atmel использует в своих EEPROM чипах?

Мне ничего не кажется, поскольку я просто использую внешнюю EEPRОМ. Причем достаточно широко. При этом я не имею ни ограничений по размеру EEPROM заложенных производителем, ни жестких ограничений по скорости обмена (и заодно связанным с этим потреблением), ни рабской привязанности к чипам с набортным EEPROM. Для длительного хранения данных кроме EEPROM получают распространение и набортные блоки RAM связанные с RTC - скорости и энергетика другого порядка.

http://www.rlocman.ru/news/new.html?di=107100

Вот чем мне "нравятся" фанатки, так это тем, что согласны питаться рекламной информацией из гламурных журналов . Берем PDF на первый в Вашей ссылке ATxmega16A4U
и читаем. Ой, а где мои 100nA ? Нету Даже в глубоком сне c тактированием от 1024Hz ( ой, а котроллер-то 32 МЕГАгерцовый вообще-то ) типичное значении 500nA а воообще-то и 2000nA может быть. А что у него на 32MHz - да, на 32MHz у него 12000000nA. Кстати о недавно обсуждаемом здесь EEPROM - для этого чипа указали потребление при записи EEPROM/Flash - 3,6mA ( 3600000nA) причем "типичное". При этом максимальное потребление внешних I2C EEPROM сопоставимого объема от ST на 400KHz тактовой 1mA. Да здравствуют "микроконтроллеры семейства AVR XMEGA, имеющих самое низкое энергопотребление в отрасли – 100 нА." Урааа!?????

P.S.
Что бы была понятна моя ирония, сообщаю, что ядро использованного мною уже прошлым летом ST8L101 на 16MHz со всей дури потребляет не более 3,5mA (типичное 2.7). При записи во Flash типичное 0.7mA. Причем в том, что касается энергопотребления у него все четко описано. По поводу супер специальной AVR архитектруры - ST8 (и MSP430) в отличии от супер AVR8 позволяет запускать программы из RAM, например для того, что-бы еще больше снизить энергопотребление - до 1.6mA на 16MHz.

P.P.S.
ST8L была использована вместо еще новенькой на тот момент ATmega с буковками 'PA' , 2.5mA на всего-то 4MHz и дурацки тактируемой периферией. Заказчик очень хотел ATmega - типа у него есть "специалисты" которые будут потом сопровождать а наилучший на тот момент вариант на ST8L не хотел. В требования по питанию я честно уложился, со скрипом, но уложился. Потом, когда заказчик захотел еще уменьшить потребление все было переведено на ST8L. За работу, естественно, было заплачено повторно, причем в двойном размере - дабы не повадно было настаивать на выборе любимого контроллера а не на оптимальном решении задачи .

Дык, вы про слип-мод забыли!
А инфа вовсе не гламурная. Ссылку привела на русский текст только для того, чтобы вам понятнее было . А в оригинале на сайте Atmel выглядит так:

Из чего, впрочем, не совсем ясно, в sleep-моде измеряли этот ток или нет. По смыслу это все-таки sleep-мод, но при переводе получилось гораздо гламурнее .

Самое печальное, что НЕТ - уже писал - в реальной, а не рекламной документации там 500nA . Чистая деза в этих ссылках. 100nA разве только от внешнего генератора гипотетически может быть намеряли. Для любого варианта внутреннего хоть RC, хоть с внешним часовым кварцем уже минимальное число 500nA.
Конечно, тот-же STM8L более 1000nA кушает когда ничего не делает, но у него НОРМИРОВАНЫ времена переходов между режимами. И они достаточно малы. Ну а когда надо РАБОТАТЬ тут уж ядро STM8L и уделывает новейший бумажный X флагман от Atmel по полной. Я не испытываю от этого факта никакой радости - просто констатация факта.

Вот с этим делом как раз нет проблем. 1 кнопка и "3 зеленых свистка"...
http://www.starterkit.ru/html/index.php?na...=view&id=51

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




Как это нет?!
По ссылке выше. Страница 65. Типовой ток потребления при работе RTC вызываемого с частотой 1,024kHz от таймерного генератора
32,768kHz (делитель 32) при температуре T = 25°C. Естественно все остальное отключено или спит.


Это не тактирование 1024Гц, это частота вызова RTC. Причем достаточно частая. Я к примеру RTC обычно вызываю раза 4-8 в секунду.

Никак НЕТ. Совсем нет в указанной Вами таблице тока потребления в 100nA. В указанном Вами режиме там 500nA а не 100nA. На что я и указал.
Документ 8387A–AVR–07/11 скачивал прямо с Atmel позавчера. Если только вдруг ночью тайно поменяли на 100uA

Что Вы решили назвать "частотой вызова RTC" мне неведомо, но бог с Вами - к делу отношения это не имеет.

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


Еще как есть - Вы просто недостаточно внимательно смотрите. Открывай страницу 64. Смотри типовое потребление в полном слипе при 25гр. цельсия. Ток 0,1мкА...


Ровно то, что написано в доке:

Только качественно спать у Mega умеет ПЛОХО - в ожидании прерывания, например, таймера PWM спится плохо и высокая тактовая ядра ядра ведет к проигрышу в потреблении относительно контроллеров имеющих более развитую систему тактирования.

Именно по этой причине более производительный 16bit MSP430 имеет дополнительное преимущество, особенно когда еще уделено особое внимание переходным режимам из сна и обратно.

Совсем недавно Вы говорили о другом режиме:
Сколько в нем? Совсем полный слип есть и у MSP430 с теми-же 100nA.


Документацию вижу. Почему Вы эту строчку трактуете, как "Это не тактирование 1024Гц, это частота вызова RTC." не понимаю. Я не настаиваю на том, что Вы что-то понимаете не правильно, а я правильно - просто не разбирался пока за ненадобностью. Я просто действительно не понимаю, что такое означают Ваши слова "Это не тактирование 1024Гц, это частота вызова RTC.". Объяснить Вы похоже не можете? Ну, как уже писал, ладно.

С чего вдруг более производительный?


Есть другие варианты "RTC on" кроме как "включение RTC"?

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

Нет. RTC Включен. Он, естесвенно, тактируется от 32HKz, а ядро от клоков RTC подеденных на 32. Там-же есть такой-же режим, когда для ядра используются 32KHz - кушает побольше. Итак RTC on это RTC включен. Вопрос ведь был в том, что Вы поведали миру о том, что "RTC on" это какой-то "вызов RTC" с частотой 1024Hz. Этого я не понял. Никаких вразумительных толкований что такое "вызов RTC" я пока не увидел.
P.S.
Я тут сейчас на пару дней в Питер отъеду, так что не обессудьте за последующее молчание.

C чего вдруг? Тем более что так потребление будет выше.

Я ничего миру не поведал. Я всего лишь перевел фразу "RTC on 1.024kHz low power 32.768kHz TOSC," без фантазий на тему тактирования ядра "от RTC подеденных на 32".

В 2008 году я выбирал проц, на базе которого нужно было создать одно малопотребляющее устройство. На тот момент я уже много работал с AVR, а MSP430 почти не знал. Мне было бы проще, быстрее и дешевле создать девайс на базе AVR. Но я решил проверить и и тот, и другой проц. Я взял TINY48P и MSP430F2001. Немножко не эквивалент, но мне не нужно было много памяти. (Устройство крайне простое.)

Сейчас уже точно не помню, но при напряжении 3.3 В AVR потреблял тока примерно на 20-50% больше, чем MSP430 при примерно одинаковых тактовых частотах (1 МГц и 1.1 МГц соответственно). Про снижении Vcc до 2 В микроконтроллеры потребляли примерно одинаковый ток. Но при дальнейшем снижении, MSP430 начинал проигрывать AVR-ке. Потребление измерялось в активном режиме МК, т.е. никакие режимы снижения мощности не включались.

Казалось бы -- ага!

Но следует заметить, что при напряжении даже 3.3 В у меня возникали проблемы с открытием полевых транзисторов (2N7002). А при питании 2 В, задача вообще не решалась -- транзисторы работали в активной области, что недопустимо для ключей.

Мало того, при максимальном энергосбережении -- PowerDown для AVR и LPM4 для MSP430 -- AVR нельзя разбудить перепадом напряжения на ножке порта. Т.е. тактирование периферии отключать нельзя. С другой стороны, MSP430 просыпался по заданному перепаду на любой ноге.

Поэтому, мне пришлось отказаться от AVR и принять решение в пользу MSP430.

Спать можно по разному. Можно уснуть и не проснуться. Все зависит от задачи. В моем случае MSP430 по совокупности параметров выиграл. Хотя мне лично удобнее было бы работать с AVR. Просто я с ними работал несоизмеримо дольше и намного лучше их знаю. Если бы не жесткие требования энергопотребления, то выбор был бы однозначно за AVR.

Я уже вообще перестал Вас понимать - это самый малый по току потребления режим. В том, который без поминания 1024Hz а просто с тактировкой от RTC, контроллер кушает больше.
Совершенно неправильный перевод, как минимум по причине полного отсутствия в первоисточнике сколь-нибудь вменяемого эквивалента использованного Вами словосочетания "частота вызова RTC" и самое главное для меня непонятно само действие "вызов RTC" тем более в контексте энергопотребления. Как я воспринял эту фразу я объяснил. Вы объяснить свой "перевод" даже не смогли ссылаясь на то, что просто перевели. Впрочем, уже третий раз говорю, что на данный момент это меня слабо волнует. Все. Побежал....

С чего вдруг? Pin Change вроде всегда был асинхронным и вполне честно будит из PowerDown .

Я тоже так думал, пока не попробовал.

Мне не удалось вывести МК из PowerDown (при отключенном тактировании портов CLK_io) по PCIx. Только через INT0 или INT1.

В документации об этом явно не сказано. Поэтому создается ложное впечатление, что не смотря на отключение тактировниа, возможны прерывания INTx, следовательно, возможны и прерывания PCIx. Но это не так! У них разные механизмы. Попадалово для тех, кто не знает.

А это тогда можно не принимать во внимание



И далее по тексту

Да. Спасибо.
Только мне кажется, что я это тоже видел и пробовал. Мне сейчас сложно сказать, что я тогда делал. Возможно, где-то и накосячил.
Сейчас проверить нечем. Вполне может быть, что тогда меня не устроило, что прерывания возникают по любому перепаду -- нужно экономить питалово, а проц генерит два прерывания на один импульс. Не помню я.

А за поправки -- огромное спасибо!