Это так. Но есть и еще одно "но". Стоимость масок для "дебаггинга" rev. A -> rev. G для технологии 0.18 и 0.35 сильно разные. Настолько, что для 0.35 Атмел может позволить себе оплатить этот процесс сам. А вот для 0.18 его оплачивать вынуждены мы.

Для тестирования, например, протокольчика SS7 http://en.wikipedia.org/wiki/Signaling_System_7 потребуется в буквальном смысле гора железа c соответствующей стоимостью. К горе железа еще и специалисты по этой горе железа не помешают... Причем все вместе при сертификационных испытаниях проверит далеко даже не на 90%. Оставшихся десять хватит для полного облома...

Почитайте PDF в корневом посте топика и поищите мои старые посты по теме. А чего там отлаживать, если ядро совместимое? Вроде как обычный AVR код должен исполняться. Хидеры написать - так вроде Атмел нам уже помог.

Не хочу никого убежать, но на блэкфине для сжатия цветной картинки 320*240 требуется примерно 5 MIPS'ов..

IMHO, список преимуществ исчерпывающий и впечатляющий. Действительно, есть простые проекты, в которых это не надо. Но лично у меня таких становится все меньше.

Да я ж не спорю. Можно попробовать асилить на FPGA еще быстрее.

Идем к первоистокам http://www.ijg.org и смотрим, что плавучка может быть, а может и не быть. IMHO, очень хорошая либа (да и стиль С программизма там шикарный, хотя с непривычки и несколько тяжеловесный), если ее не использовать "в лоб", то можно использовать как пособие по разработке своего варианта кодека.

В лоб на маленьких камнях ее очень тяжело использовать - например, нужен менеджер кучи. При переработке всего этого дела (особый зачот там людям за быстрый целочисленный DCT 8*8) с отбрасыванием лишнего все вполне хорошо раскладывается - 2килобайта кода, 1.5 килобайта таблиц во флеше, 400 байт данных, 20 байт CSTACK.

Железо разное бывает. Ядро проца, память, таймер в простейшем режиме как правило, достаточно хорошо поддаются симуляции. А вот какой-нибудь таймер с PWM, IMHO, я и не мечтаю увидеть работающим в симуляторе.

Можно конечно, запустить на симуляцию HDL код периферии, но так JPEG можно до пенсии отлаживать

Тут наверное НАДО помнить о том, что и BF и FPGA уже находятся в одной ценовой категории с атмеловскими средне-старшими восьмибитовиками. Вот такая жизнь настала, пока "будущее, которое ждали" все не наступало и не наступало.

Сертификационные испытания служат для тестирования на соотвествие стандартам (полного тестирования никто не сделал для сложных вещей, это факт).

Испытания разработчиков - они из другой области.

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

Такие тестовые испытания на синтетических портах проводить гораздо удобнее. Например, многие вещи можно тупо проверять на дуракоупорность методом монте-карло. Поставил синтетический порт на сервак - и пусть они недельку-другую почитает из симулятора канала сигнал с помехами, причем статистика помех разная. Например, помехи "случайно" повреждают sync word в двух подряд идущих пакетах и пр. - на реальном железе такое делать точно устанете

Во-первых, там Mega16, ну два бакса в розницу. Кроме нее - статическая озушка и ацп. И кроме того, мне скорость особо не нужна, я просунуть через канал быстрее не смогу. Когда надо будет сделать 10-20-50-100 кадров в секунду - будет FPGA (BF - врядли), а пока - перефразируя цитату - "каждый патрон стоит всего два доллара"

Чего не скажешь про стоимость средств разработки для BF (JTAG вроде там менее 1 k$ никак не стоит), а также стомость труда программиста для BF и *HDL ("дропанием мышкой классов в проект" там много не сделаешь).

Я не каких-то конкретных вариантах - я о тенденции.



Это Вы меня уговариваете? Не перепутали с кем-то случайно ?

А если в пересчете на MIPS'ы, то вообще весело, - 30 MIPS'ов блэкфина стоят 1$.

!уговаривал, но раскрывал Вашу мысль. Ибо согласен с ней.Токо плата под BF с внешней памятью стоит достаточно взрослых денег (тщательно разведенная 4-х слойка с учетом 100 Мгц шины; конечно, есть фанаты, которые "и на двух слоях работает" - но это "китайский подход"). FLASH внешний нужен - пусть и SPI, недорогой. Так что там всего набежит никак на 1$/30MIPS.

Вопроса нет - BF - замечательный камень, вне конкуренции по цене 1 MIPS.

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

Что-то Вас носит от "синтетических портов" к сильно конкретным JTAG. Вы уж определитесь

Ну при достаточно большом запасе в попугаях на "чистом C/C++" тоже вполне терпимо выходит.

Ну тут действительно несколько другая жизнь, однако от нее никуда не дется. Иначе получится сидеть на AVR8, писать на его ASM и ждать очередной реинкарнации AVR8 - YMEGA, пытатся убедить себя, что "другого и не надо" и естественно расплачиваясь за все это из своего кармана.

Одно дополняет другое. Дрова на железо, разборки с хитрыми контроллерами прерываний - тут без JTAG тоска.Иес! ZMEGA - это будет означать конец эры 8-битников.

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

Я же сказал, что


Сейчас хватит и меги, код аккуратненький, достаточно легко переносится на ARM.

Я другого не пойму, ну зачем мы в подфоруме по AVR8 флудим о том, что ARM/BF/FPGA - лучше. Давайте к черту вообще его (этот подфорум) закроем.

Малость OFF, но раз уж упомянулив суе. Какова ситуация с RTOS на BF сейчас? Вездесущий uCOS есть - куда же без него http://www.micrium.com/analog/index.html , а вот что там с альтернативами? RTEMS вроде как есть, но статус непонятен.

Всё познаётся в сравнении

Я в этой ветке вот что понял, если даже кодер JPEG легко ложится на AVR, то AVR тоже имеет право на жизнь

Ну LPC2103 тоже продаётся по 1$ за 30 MIPS.

Ага, MIPS'ы только ну очень разные.

Я не говорил, что легко. Четыре дня работал, с утра до вечера. Вопрос в том, что на тот же LPC2103 не ляжет jpeglib без переделок - слишком громоздка.

Дак а что? Вы предлагаете рассматривать MT-System как эталон? MT-System как я понял не есть прямым поставщиком Atmel продукции, отсюда и завышенные цены.

Но вот то что можно взять процессор от Atmel за $4 в розницу с DMA всей периферии это факт. А вот у аналогичных по цене - мелких NXP DMA прото нет.

Тем более, что никого тут уговаривать похоже не надо. Все уже в курсе что такое и ARM и MSP и т.д. Интернет вроде у всех работает. Некоторые к тому же уже попробовали это всё пощупать, так что сравнивать есть с чем.

Не вижу по какому поводу очередная истерика. Ну появился новый камень. Большой респект за это Atmelу. Возможно попробуем. Если задача подвернётся. Заодно оценим новые возможности. Выпустит новый камень NXP тоже радоваться будем. К счастью задачи у всех разные (на том и живём). Применить какой-нибудь BF может быть и хотелось бы - да совершенно некуда (я о себе естественно). Не придумывать же задачу под него. И на оборот также. Вот есть у меня сейчас две задачи с которыми на ATMEGA работать будет сложно. Не будет развития. И XMEGA здесь уже не поможет. Так там и обсуждать нечего.

2 zltigo. Очень давно уже отказался от ATTiny2313. Везде ставлю atmega8 (отлаживаю на 88). Места на плате занимает меньше, стоит дешевле, ресурсов больше.

С подачи AlexandrY еще раз почитал доку на STM32 и убедился, что там народ тоже не дремлет. Если допустить точность выработке прерывания от RTC 1/8192 сек вместо 1/32768, потребление под 15 мка в спящем режиме (при спящем стабилизаторе) и 20 мка при включенном стабилизаторе, то по всем остальным параметрам STM32 смотрится выигрышно по сравнению с ATxmega (на первый взгляд). DMA, ADC, скорость обработки, 32 бита...

Единственное но - PLL стартует за 200 мкс. Т.е. если нам после просыпания хватит 8 Мгц - все стартует за 50 мкс. Если надо быстрее - 250 мкс.

Это нестрашно - обещаю, когда слегка затихнет отсортировать и разделить. Ну началось с того, что вдруг появилось "давно долгожданное будущее" ... ну пришлось обсуждать , что собственно ждали-то.



Я в курсе, просто где-то за бугром были куплены складские остатки почти на развес.




Да, как эталон NXP в России. В качестве поставщиков Atmel лично я их не упоминал вообще.




smRTOS - почти местный проект



Есть STM32 да и NXP LPC1000 серию должен вскоре выкатить.

IMHO отлаживать лучше на 168-й, по объему флеш хватит на отладку без оптимизации, иногда актуально. В остальном один в один с 88-й.

Тонкость одна выяснилась при прочтении доки на ATxmega. Стартует она всегда на 2 Мгц, а через какое время после старта заведется генератор 32 мгц - нигде в доке не указано.

STM32 тоже содержит немало "фич". caxapa::she указал, что встроенный стабилизатор напряжения начинает нехило жрать при разогреве хотя бы до 50 град, что является штатной температурой.

В обсчем, надобно буде еще MSP430F5xxx глянуть (информация от caxapa::General), вроде как 25MIPS и куча памяти обещана, но непонятно за какие бабки.

Обещаю сильно не восторгаться

А чего спорим -то ? Выйдет - купим - пощупаем - обсудим.

Вот, что пока прислал Atmel

Datasheet - ATxmega64A1/128A1/192A1/256A1 Preliminary - Rev. B - 2008-05-09 -
http://www.atmel.com/dyn/general/tech_doc....p;family_id=607
Кому интересно будет

Ссылка на этот шит была в корневом посте топика.

Если пришлют ещё чего нить - выложу ссылку , но пока ничего больше не было.

И пока тема идёт как OFF - вопросик модераторам.
Atmel ( после регистрации на их сайте) присылает всевозможные DОСи на всё, что только выпустили выпускали и будут выпускать , и естествеено схемные и программные решения . Могу эти ссылки выкладывть и сюда - скажите только куда.
Кстати MEGA164P теперича только до 16 Мгц - из DATA SHEET убрали 20 Mгц

Это может говорить о чем угодно. Например, что не тянет. Или что не стоит создавать конкуренцию ATxmega


IAR ATxmega уже поддерживает, что неудивительно
http://www.iar.com/website1/1.0.1.0/107/1/index.php

caxapa::diper сообщил о замолоди от TI (вот вот должно выйти)

МSР430F5436 192KB+512B, 16KB
МSР430F5438 256KB+512B, 16KB
встроенный LDO для ядра чтоб оптимизировать питание
LPM5 без сохранения RAM
32битный умножитель
модуль RTC
модуль CRC16

caxapa::jorikdima

Так что ATxmega не останется в одиночестве

Ну наконец-то догадались что RAM нужен.
А то ихние (ti) 2kb ram / 64k флеш просто издевательство.

Вообще-то, с 10к рамы уже давно есть.

Только цена на них, если мне память не изменяет, была неразумная. Да и были они из семейства F1хх, т.е. не 16 мгц и т.д.

Да Вы правы, есть
аж один (MSP430F1611), с неадекватной ценой ~$17

TI всегда был и остаётся TI. С ним даже никто не равняется.
Ценники атомные. Ну а изделия - достойные. AVR в общем-то из другой ценовой ниши.

ATxmega однозначно эффективнее по всем параметрам MSP430F1xx. С F2xx все сложнее, интересно, как оно будет на практике с 5XХ.

Здорово! Устаревшее не разумное к использованиванию в новых разработках семейство F1 менее эффективно, нежели еще не появившееся. Было-бы безмерно странно, если было-бы наоборот . А вот с текущим F2 заменившими F1 уже "все сложнее". С учетом того, что даташит XMEGA испещрен пометками "подлежит определению", даже в части очень интересных параметров, как потребление периферии, в области энергопотребления все может оказаться "просто" не эффективно.

хмега интересный кристалл. Но мне кто то может сказать, у нее SPI только 8 битный что ли?

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

Несложно также заметить, что Atmel сейчас пускается в авантюру за авантюрой. Пытается в борьбе за рынок воевать на всех фронтах. Анонсирован целый ряд приборов, которые толком не увидели свет. Это и на рынке ARM, и преславутая AVR32, и таже pico и вот теперь объявлена XMEGA, как снег на голову где написано технология picopower 2! Так ещё picopower 1 свет толком не увидели. atmega48p пока недоступна.

Но всётаки, zltigo, я также вижу, что они движутся вперёд! И это важно. Коллектив разработчиков у них очень амбициозен. Это совершенно очевидно. И пусть, возможно, они не достигнут всех своих целей и воплотят все свои задумки, пусть они ошибаются, но они двигаются сами и двигают вперёд прогресс.


Давайте посмотрим правде в глаза. На рынке 8-ми битников стандартом на сегодняшний день является отсутствие контроллера приоритетов прерываний. Исключение только x51. И вот первый шаг на встречу разработчикам. Контроллер ПДП. Система программирования событий - тоже весьма интересная штука. И прочие фичи - как будто читали мысли разработчиков. Например всё то, что реализовано по RTC и микропотреблению, всё до единого уже назрело. И, совершенно очевидно, что этот локомотив потянет за собой остальные конторы. Например того же Microchip. Так почему бы им не сказать спасибо? Даже если их поделками и не будешь пользоваться. За что я их буду ругать? Наоборот, я с уважением отношусь к этой команде разработчиков.

Ещё раз повторюсь. Взращивание одного монстра, которое привёдёт к созданию другого монстра в области ПО, что в свою очередь приведёт к этой липовой совместимости, и соответственно будет потом являться тормозом дальнейшего развития железа - вы за такой путь? Или живая конкуренция, которая порождает достаточно быстрое развитие железа, но, несколько усложняет жизнь разработчикам ПО (То есть даёт нам хлеб). То же путь.

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

беда хавр в том что систему команд не дополняли. про 5ои серии уже с 2002 г года говорят, в 2006 семинары с подробностяи были но вот мк пока нет, ( как и хмега). неизвестно, не приоритетныи продукт или это "немецкая точность" ( разработка мк ТИ в германии происходит).
некоторые моменты сравнения ф5 и хавр:
- адресное пространство разширен в
хавр страницами ( RAMP regs).
в ф5 20битными рeгистрами
- ф5 выполняет за одну команду несколько операции с стеком ( за сколько такт - не знаю),
хавр нет , в коде авр слишком много места/времени занимают операции стеком.
- косвенная адресация в авр краине ограниченныи

20 битные регистры появились еще в 430Х архитектуре.

сравнивать команды\циклы не надо. мсп проигрывает в разы. Особенно по работе с портами.

Я бы в виде примера фирмы, учитывающей, предугадывающей и реализующей чаяния и причуды разработчиков, привел не Atmel, а Maxim. С давних пор не перестаю удивляться разнообразию и функциональности их продукции. В части всяких стыков, интерфейсов и драйверов, например. Ну не нужно в MAX232 четыре канала - у Maxim есть м/с с 1TX + 1 RX в uSOP. Нужен еще один UART в МК, а в наличии только SPI - у Maxim есть мост SPI-UART. Надо добавить USB-device в малоногий MCU не имеющий внешней шины - у Maxim есть USB-device с интерфейсом SPI. Ну и всякие там дела с RTC, супервизорами, питаниями и т.п. Очень много потенциальных желаний разработчиков фирмой Maxim предугадано и реализовано. Вот с кого надо пример брать

Но на рынке микроконтроллеров у макса как-то не сложилось. Они делают зачечательную кучку мелких девайсиков, и... пусть делают! Каждый рожден для чего-то своего. Maxim - явно не для MCU ATmega88P использована в нескольких сотнях устройств. Имено в очень маложрущем режиме. Полет нормальный (после наложения патча на ДНК разработчика), в режиме полного сна с работающим RTC единицы мка, хотя передельных цифр не старались достичь (еще есть потреблящие цепи кроме CPU).