Вышло уйма Xmega c USB-интерфейсом!, серии A3AU и A4AU Опции

[Xenia]

На сайте 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.

[ArtemKAD]

Понятно, что у Атмела есть серия Кортексов, но... по совокупности все параметров... Почти шило на мыло. Смысла нет.

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

[zhevak]

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

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

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

Как Вы думаете -- что может предложить (мне) Атмел взамен линеек 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). Я предпочитаю копать глубоко.

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

[ArtemKAD]

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

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

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

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

AVR -- дорогой, собака!

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

При интенсивном использовании констант (константные строки, avr/progmem.h) в программе, Си-ный код программы становится "неуклюжим", теряет прозрачность и красоту. Потом становится тяжело его сопровождать.

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

Противоречие Гарвардская архитектуры проца и изначальной ориентации Си на Фон-Нейманоскую архитектуру.

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

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

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

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

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

Но если для Вас это принципиально - так потратьте неделю и сделайте свой автономный программатор с интерфейсом uart - чем плохо?

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

Каким это? Эмуляция на то и эмуляция что Вы вольны добиться любого перфоманса от хранилища и даже сильно лучшего нежели работа напрямую с eeprom встроенным в AVR или внешним AT24.

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

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

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

[zltigo]

Он никогда не был лидером. Они с Atmel и Microchip шли практически нос-в-нос.

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

На самом деле там все зависело от метода измерения.

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

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

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

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

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

[ArtemKAD]

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

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

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

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

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

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

[zltigo]

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

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

Ну если Вы так считали ток потребление МК - я тогда не удивлен выводам. Возьмите еще раз в руки доку на "первую попавшуюся EEPROM" и найдите ток потребления в режимах чтения и записи, а не во время простоя. Вы там найдетеп 1-2мА при чтении и 3-5мА при записи.

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

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

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