XMEGA: будущее, которого мы так долго ждали, наступило., XMEGA - лучший 8 битный микроконтроллер. Опции

[Evgeny_CD]

XMEGA: будущее, которого мы так долго ждали, наступило.

Итак, на сайте Atmel появились полноценные доки по семейству. Само семейство пока еще недоступно в виде чипов на складах дистрибуторов, но такая позиция уже есть в прайсах. Совсем скоро можно будет запаивать.

Далее все рассматривается на примере ATxmega128A1

Что обращает на себя внимание.

1. ATxmega64A1/128A1/192A1/256A1 Preliminary (75 pages, revision B, updated 5/08)
http://www.atmel.com/dyn/resources/prod_do...nts/doc8067.pdf

Смотрим секцию errata и видим - ATxmega128A1 rev. G. Т.е. предыдущие версии A-F сгинули в Atmel, так и не выйдя в свет. Вызывает уважение по сравнению с ситуацией на рынке ARM - там erratы к современным чипам просто вызывают депрессию.

Сама errata вполне терпимая. Видно, что в предыдущих errata'х народ дожимал цифровые глюки, а теперь осталось некоторое количество аналоговых - нелинейности по напряжению и пр.

То, что нет errat в части DMA, арбитража шин и т.д., и то, что это rev. G, дает некоторую надежду на вылеченность системных багов.

2. Накристальная периферия. То, ради чего все затевалось

* RC генераторы - аж целых 4 штуки: 32 kHz Int. ULP; 32 kHz Int. Osc.; 2 MHz Int. Osc.; 32 MHz Int. Osc. Просто праздник какой-то.

* 8 UART - это уже обсуждали

* 16 битный RTC с прескалером (с коэф. от 1(!) до 1024), у которого есть Compare Match регистр - это просто праздник какой-то для всех, кто, например, делает коммуникационные протоколы

* Event system - пока еще мною не познанная замолодь, но из описаний следует, что это эффективная шняга для обработки событий.
AVR1001: Getting Started With the XMEGA Event System (8 pages, revision A, updated 2/08)
http://www.atmel.com/dyn/resources/prod_do...nts/doc8071.pdf

* DMA
• The DMA Controller allows high-speed transfers with minimal CPU intervention
– from one memory area to another
– from memory area to peripheral
– from peripheral to memory area
– from peripheral to another peripheral

Заметим, что DMA во всяких там SAM - "жалкое подобие левой руки" DMA XMEGA. И меговское DMA работает на всей SRAM - привет dsPIC.

* 12 бит DAC (1 Мгц) и ADC (2 Мгц). Хоть в реальности они и получились 10 битными, все равно очень даже!

* AWeX – Advanced Waveform Extension. Внушительный блок для всяких PWM приложений.

* External Bus Interface for up to 128M bit SDRAM - токо в описании я что-то ничего про SDRAM не нашел

3. Жручесть. В варианте ULP, RTC,WDT, BOD Enabled обещают не более 2 мка при 3.3В.

Типовой CR2016 имеет емкость 90 mAh, CR2032 - 230 mAh. 0,002*24*365*5=87.6 ма*ч энергии на 5 лет. 5 лет от CR2016 - большего на практике нафиг не надо. Т.е. дальнейшее уменьшение тока потребления суть маркетинговый развод, по технике это будет эффективно только для очень специфичных применений.

To ensure safe operation it is always recommended to have a brown-out detector (BOD) enabled. This has to be either internal in the microcontroller or an external device. The
brown-out detector will ensure that the microcontroller is held in reset if VCC is lower than minimum. The XMEGA BOD has a new and innovative sampling mode. In sampling mode,
the BOD is turned on only once per ms to check status of VCC. If everything is OK, the BOD is turned off and remains off until next checkpoint. This gives XMEGA a max power
consumption of 2 мкA in Power Save mode with a 32 kHz crystal running, Real Time Counter operating, Watchdog Timer enabled and BOD operative with max 1 ms reaction
time. To achieve the same performance, TI MSP430 devices need to enable the System Voltage Supervisor that consumes up to 15 мкA.

Тута все подробно расписано.
Introducing a New Breed of Microcontrollers for 8/16-bit Applications (White Paper, 15 pages, revision A, updated 02/08)
http://www.atmel.com/dyn/resources/prod_do...nts/doc7926.pdf

"На ходу" жручесть тоже очень даже хороша: 2 MHz VCC = 1.8V All PRR Set Internal RC 720 мкА. Или в терминах CR2032 (230 mAh) 13 суток непрерывной работы! Для CR123A (1600 mAh) это 92 дня работы.

По моему опыту - ATmega на 3.68 Мгц - это прием POCSAG 1200 бит/сек, включая 8 кратный oversampling, DPLL, БЧХ декодер и пр (C код без asm вставок! Но C код продуманный, конечно). Причем это без DMA. Так что 2 Мгц для XMEGA - это весьма немало.

При питании 1.8В - до 12 Мгц, 32 Мгц - от 2.7В. Так что процык получился весьма зажигательный. MSP430 нервно курит (понятно, что 32Мгц XMEGA будет быстрее 16 Мгц MSP430, разве только что умножитель 16х16 спасет MSP430).

4. Цены - ABN Universal,Inc., например, дает для ATXMEGA128A1-AU 9,97 $ в розницу - достаточно обнадеживающе. Это на проц с 8К RAM, 4K EEPROM, 128K FLASH, 78 IO пинов.
Для примера - MSP430F2618TPNR - FLASH 116K x 8 + 256B, SRAM 8Kx8, A/D 8x12b; D/A 2x12b, 64 IO пинов имеет в розницу цены $13.16 на www.digikey.com

Выводы:

Atmel таки сделал лучший 8 бит контроллер. И, уверен, будет заслуженно снимать с него сливки ближайшие лет 5. Конечно, будет ламье, которое с криками "32 лучше 16 лучше 8" убежит применять всякое многобитное барахло, но найдутся серьезные юзера, которые смогут выжать все из этого кристалла (а в серии 10к, я уверен, этот кристальчик даст фору по цене очень и очень многим)

http://www.atmel.com/dyn/corporate/view_de...EC_NAME=Product
Availability and Pricing.
The first devices, ATxmega128A1 and ATxmega64A1 are both offered in 100-pin TQFP and BGA packages and are available now. Volume prices for 10k units are US$3.75 and US$3.50, respectively. Other XMEGA devices will be available during 2Q or 3Q of 2008.

Что касается перспектив, то тут все просто замечательно!
AVR XMEGA 8/16-bit High Performance Low Power Flash Microcontrollers (Flyer, 4 pages, revision B, updated 03/08)
http://www.atmel.com/dyn/resources/prod_do...nts/doc7925.pdf
ATxmega384A1 384k FLASH, 4k EERPOM, 32k SRAM (!).

Основной кайф от XMEGA следующий. В общем, по своим основным параметрам, он умеренно чемпионский - MSP430 уверенно дышит в спину. Кроме одного - соотношение цены и объема памяти. 64К команд (при очень эффективной системе команд, которая хорошо ложится под С) и 8 К ОЗУ - этого вполне достаточно, чтобы использовать вполне взрослую ОСьку типа uCOS. И комфортно писать очень сложные приложения, которые будут годами работать от CR2032.

Наличие ОСьки позволяет по полной программе использовать технологию синтетических портов. Т.е., например, при разработе ZigBee девайса, можно взять платку с CPU + RF, один SPI канал, например, выделить на связь с "большим процессором", на втором XMEGA сделать конвертер SPI<->USB (FTDI), и вести разработку в Win32, при этом имея виртуальные драйвера периферии, полностью эквивалентные "боевой" периферии. При такой технологии отпадает необходимость в аццком симуляторе периферии XMEGA (такие симуляторы, как показывает практика, до конца отдебажить невозможно), а разрабатывать под Win32 (или под Linux - если профи, то без разницы), все таки куда приятнее, чем дебажить кристалл при помощи самого продвинутого джЫтага. В приведенной выше схеме за счет DMA в XMEGA можно организовать дуплексный канал связи порядка 1 Мбайт/сек (2 чипа FTDI на раные USB порты, дрова D2XX drivers дают 1 Megabyte / second ) с "большим процессором".

В упомянутом выше документе
http://www.atmel.com/dyn/resources/prod_do...nts/doc7926.pdf
на 7 странице есть чудная табличка о загрузке проца.
XMEGA UART communication with and without DMA. При 3500 бит/сек мы имеем 5.17% CPU load (непонятно, на какой тактовой, симплекс или дуплекс). Т.е. при организации 1 Мбайт/сек дуплексного канала можно ожидать загруки проца порядка 25% при тактовой 32 Мгц. Т.е. если внешняя периферия порождает поток данных не более 1 мбайт/сек, то у проца будет возможность "отогнать" его на "большой" процессор, принять обработанные данные, и потратить 75% своего времени на дополнительную обработку данных - приписать к блоку отсчетов ADC время, когда эти отсчеты были взяты, поймать время по таймеру и выплюнуть синхронного блок выходных отсчетов и т.д.

В общем, читаем pdf моих старых постов по синтетическим портам и виртуальной разработке, и можно приступать к созданию конкурентов автономных радиоканальных девайсов типа ZigBee

Сообщение отредактировал Evgeny_CD - May 18 2008, 15:37

Прикрепленные файлы

 Deram_Platform.pdf ( 78.53 килобайт ) Кол-во скачиваний: 141
 Development_Universe_y2007m08d05.pdf ( 220.15 килобайт ) Кол-во скачиваний: 114
 Hibrid_Systems_y2007m06d11.pdf ( 230.72 килобайт ) Кол-во скачиваний: 171
 Visio_cosimulating.pdf ( 58.57 килобайт ) Кол-во скачиваний: 113
 Visio_Hibrid_Systems_1_y2007m06d11.pdf ( 86.58 килобайт ) Кол-во скачиваний: 138

 

[zltigo]

Итак..

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

Сама errata вполне терпимая.

Пока их особо еще никто не трогал

Заметим, что DMA во всяких там SAM - "жалкое подобие левой руки" DMA XMEGA. И меговское DMA работает на всей SRAM - прЭвЭд dsPIC.

Не устаю замечать, что DMA на контроллерах без кэша или каких-либо специализированных архитектурных наворотов штука малоэффективная. А то, что сделано у помянутого всуе ARM7 LPC, это как раз и есть эффективное использование DMA, поскольку он работает НА ОТДЕЛЬНОЙ ШИНЕ с ОТДЕЛЬНЫМ банком. Что позволяет не тормозить контролер "контроллером DMA"

* 12 бит DAC (1 Мгц) и ADC (2 Мгц). Хоть в реальности они и получились 10 битными, все равно очень даже!

Что в реальности расскажете после работы с живым кристаллом.

MSP430 нервно курит (понятно, что 32Мгц XMEGA будет быстрее 16 Мгц MSP430, разве только что умножитель 16х16 спасет MSP430).

Кто там будет курить покажет жручесть и способность к автономной работе ПЕРИФЕРИИ, коея у MSP430 под это по жизни делалась.

Выводы:

Выводы преждевременны. Тем более, что по такой цене он в обычных применения он нахрен не нужен, а в маложрущих это еще надо сильно посмотреть по отношению к MSP430

Конечно, будет ламье, которое с криками "32 лучше 16 лучше 8" убежит применять всякое многобитное барахло, но найдутся серьезные юзера..

Несомненно одно, на звание лучшего 8-бит общего назначения от Atmel он может явно претендавать. Только вот.. кто-нибудь сможет назвать лучший в мире 4-бит процессор??? Набежало, похоже, понимешь ламерье и с воплями "8 лучше 4" затоптало

Извините за прямоту - лично Вы хоть что-то за последние годы сделали???

Сообщение отредактировал zltigo - May 18 2008, 15:47

[Evgeny_CD]

Извините за прямоту - лично Вы хоть что-то за последние годы сделали???

Работаю в основном головой (руковожу коллективом), иногда руками. Пока отношусь к категории "ламья" - AVL терминал на LPC2129, специализированная фотокамера на LPC2468 ну и всякая мелочь на LPC2103.

Сообщение отредактировал Evgeny_CD - May 18 2008, 15:36

[SasaVitebsk]

Не устаю замечать, что DMA на контроллерах без кэша или каких-либо специализированных архитектурных наворотов штука малоэффективная. А то, что сделано у помянутого всуе ARM7 LPC, это как раз и есть эффективное использование DMA, поскольку он работает НА ОТДЕЛЬНОЙ ШИНЕ с ОТДЕЛЬНЫМ банком. Что позволяет не тормозить контролер "контроллером DMA"

Естественно, сам пока не пробовал, поэтому утверждать что-либо глупо, но согласно статье DMA в xMega не будет тормозить процессор. И речь там идёт о нескольких шинах. Хотя, естественно, поживём увидим.

Несомненно одно, на звание лучшего 8-бит общего назначения от Atmel smile.gif он может явно претендавать. Только вот.. кто-нибудь сможет назвать лучший в мире 4-бит процессор??? Набежало, похоже, понимешь ламерье и с воплями "8 лучше 4" затоптало

В общем то всё правильно, но согласитесь изделия нонче всё сложнее и интелектуальнее. А процессоры дешевеют (как в прямом смысле, так и за счёт обесценивания зелёного). Поэтому применение нескольких процов - очень удобный подход. Я, например с удовольствием применяю. Если рассматривать под этим углом, то применение синхронного, статического процессора часто бывает весьма привлекательно. И в этой нише 32-ух битные конкуренцию пока не составляют. Выпуск мелких армов с частотой 45МГц похоже имеет меньше шансов на выживание, чем тех же AVR с частотой 32 и значительной переферией.


Совершенно понятно, что они врят ли подвинут те же АРМы, они просто укрепляют звои позиции в своём сегменте. И это отнюдь не агония.

[zltigo]

..согласно статье DMA в xMega не будет тормозить процессор. И речь там идёт о нескольких шинах.

Как водится недоговорки. Либо несколько шин/банков и тут уж речь не идет о "работает по всей памяти", либо нет.

...применение синхронного, статического процессора часто бывает весьма привлекательно. И в этой нише 32-ух битные конкуренцию пока не составляют.

Зато составляют конкуренцию те-же MSP430, да и 51 с много более разнообразной периферией.
Evgeny_CD что-то про прицепить RF и конкурировать с ZigBee говорил? Так тот-же TI прикупил Chipcon с массой RF устройств в том числе и интегрированных с 51 (32 мегагерца, кстати и один такт на команду) на борту и начинает прикручивать к ним и свои MSP430 - CC2430/1 первая ласточка. А тут рассказы о прикручивании каких-нибудь RF к XMEGA в смутной надежде что-то сделать ДЕШЕВЛЕ? КРУЧЕ?

Выпуск мелких армов с частотой 45МГц похоже имеет меньше шансов на выживание, чем тех же AVR с частотой 32 и значительной переферией.

Да оба будут соcуществовать. Достаточно долгое время.

Совершенно понятно, что они врят ли подвинут те же АРМы, они просто укрепляют звои позиции в своём сегменте. И это отнюдь не агония.

Подвинут . Просто цепляются за сокращающийся в результате передела рынок - более 90 штук только ARM-ов (в том числе и Atmel-ом) в секунду выпускаюся. Для 8-бит это совсем не агония, но уже далеко и не процветание. В принципе все определяет цена - для средних и выше AVR8 она просто неадекватна текущему состоянию дел на рынке. Во многих случах можно было-бы и спокойно AVR8 использовать, но лично мне уже просто не хочется чувствовать себя лохом и спонсировать Atmel, ибо за те-же и МЕНЬШИЕ деньги можно выбрать другой конроллер.

[GetSmart]

Работаю в основном головой (руковожу коллективом), иногда руками. Пока отношусь к категории "ламья" - AVL терминал на LPC2129, специализированная фотокамера на LPC2468 ну и всякая мелочь на LPC2103.

Все мы тут ламьё Я по крайней мере готов гордиться этим

[zltigo]

Поэтому применение нескольких процов - очень удобный подход. Я, например с удовольствием применяю.

Если говорить не о "халтурах", то в основных моих изделиях одного процессора просто не бывает в принципе . Только вот причем здесь XMEGA?

[Evgeny_CD]

Совершенно понятно, что они врят ли подвинут те же АРМы, они просто укрепляют звои позиции в своём сегменте. И это отнюдь не агония.

Полностью согласен! Они и не пытаются подвинуть ARM, dsPIC из своих ниш. Они просто пытаются сделать "новое прочтение" 8 битных процессоров.

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

Думаю, когда ATxmega16A4 и ATxmega32A4 выйдут на рынок, они приятно удивят нас ценой.

Evgeny_CD что-то про прицепить RF и конкурировать с ZigBee говорил? Так тот-же TI прикупил Chipcon с массой RF устройств в том числе и интегрированных с 51 (32 мегагерца, кстати и один такт на команду) на борту и начинает прикручивать к ним и свои MSP430 - CC2430/1 первая ласточка. А тут рассказы о прикручивании каких-нибудь RF к XMEGA в смутной надежде что-то сделать ДЕШЕВЛЕ? КРУЧЕ?

Все не так однозначно.

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

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

Так вот, для среднетиражных проектов - сотни в мес - снижение приведенной стоимости труда программистов куда важнее, чем экономия нескольких $ за счет засовывания всего на свете на один кристалл. И вообще, RF Silicon и Digital Silicon - это все-таки разные технологии. Иначе "в среднем на всадника и лошадь приходится по три ноги".

[zltigo]

Они просто пытаются сделать "новое прочтение" 8 битных процессоров.

Новое прочтение _AVR8_ контролеров. Процесс естественный и обязательный для любой фирмы.
Посему м стоит воспринимать сие спокойно, а отнюдь не как Заботу Партии и Правительства о Советском человеке .

Кучка мелких сопроцессоров вокруг большого процессора - это очень перспективная технология.

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

ATxmega очень хорошо подходит на роль периферийного сопроцессора для сложных и основного процессора для простых и средних систем.

Не лучше, чем многие другие контроллеры, если вдруг, случайно не будет попадание в 10 с какими-нибудь 8шт UART. У меня, например, мелкие LPC живут и STM32 наверное будут. В старом примитивном оборудовании ATTiny живут - хватало.

Думаю, когда ATxmega16A4 и ATxmega32A4 выйдут на рынок, они приятно удивят нас ценой.

Или Да или Нет . Поймите меня правильно - я никоми образом не завязываюсь на конкретные архитектуры/производителей, я двумя руками за то, что-бы меня удивили, но ....

Универсальность (на что метит ZigBee) - это хорошо, но для специализированных задач

Я не о ZigBee - что-то там не то не то кривовато. Некоторые, типа NXP и производить уже перестали и из Альянса вышли.. Я просто о массовом железе на котором можно делать любые протоколы.

И вообще, RF Silicon и Digital Silicon - это все-таки разные технологии. Иначе "в среднем на всадника и лошадь приходится по три ноги".

Тем не менее результаты совмещения даже всего и вся (GSM-Wi-Fi-BT-FM-..) есть и совсем не плохие.
А с учетом того, что тот-же TI выпускает как интегрированные, так и отдельные решения, то ничего кроме свободы выбора Вам не грозит . И уж точно не угрожает концепции разработки.

[Evgeny_CD]

Или Да или Нет . Поймите меня правильно - я никоми образом не завязываюсь на конкретные архитектуры/производителей, я двумя руками за то, что-бы меня удивили, но ....

Когда я работал в одном большом проекте, я как-то пришел к его руководителю и сказал: "А давай сделаем вот так... И юзера офигеют!" А он мудро мне ответил: "Дурак! Они не офигеть, они заплатить должны".

Так и тут. Удивить просто так никого не получится - Атмел и не пытается. Но вот для думающих набор фич ATxmegа очень даже хорош

* доведенный кристалл. Да, может errata маленькая от того, что его мало кто гонял, но rev. G говорит о многом. Или кто-то фанатеет от errat современных недопатченных ARM'ов?

* DMA. Можно долго спорить о ее реализации, но даже в простейшем случае, когда DMA тормозит проц, она дает выиграш в разы.

Смотрите. Пусть мы принимаем по UART 3500кбит/сек. Это дает нам (1 старт и стоп) 350 кбайт/сек. Если работать по опросу - то нифига кроме приема потока не сделам. Либо очень извратное программирование - всосали, 10 тактов что-то поделали, снова всосали.

IF по прерываниям - 350 кгц прерывания угробят кого угодно, не только AVR

Пусть DMA тормозит проц на 3 такта при пересылке 1 байта (захват шины, передача, освобождение). Но при при этом нифига, кроме просто стояния, не делает. Итого за 1 сек при скорости 350 кбайт/сек мы затормозили проц на 1050 к тактов. Или 1050/32000, или 3% процессорного времени!!!! (у атмеля получилось 5% при той же скорости).

Так что даже простейший DMA, без кеша, TCM и пр. очень даже эффективен!

* маложручесть.

* память, возможность юзать толстую ОСь.


Кто понимает - готов за это доплатить 1$ за кристалл. А Атмелу большего и не надо

Я не о ZigBee - что-то там не то не то кривовато. Некоторые, типа NXP и производить уже перестали и из Альянса вышли..

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

Тем не менее результаты совмещения даже всего и вся (GSM-Wi-Fi-BT-FM-..) есть и совсем не плохие.

Верно!!! Но это все-таки специализированные, хоть и интегрированные решения. И их разработка встает ох в какие бабки....

Кроме того, например в GPS чипах, в одном BGA корпусе часто живут два кристалла - RF и Digital. Понятно, что производитель об этом умалчивает

[SasaVitebsk]

Если говорить не о "халтурах", то в основных моих изделиях одного процессора просто не бывает в принципе . Только вот причем здесь XMEGA?

А почему бы не XMEGA? Чем XMEGA то не устраивает? Всё в цену упирается и если она пойдёт с сопоставимой ценой, то будет очень приятно. Мелкие армы при той же структуре флэш/озу оказываются не так уж и привлекательны так как озу, как минимум требуется больше. AVR эффективнее использует. Опять таки скорость ногодрыганья у XMEGA выше и предсказуема без выкрунтасов, что также бывает востребовано. MSP, PIC и х51 естественно в том же вагоне что и AVR, именно поэтому появление некоторых новых фичей и вызывает интерес. Это же повлекёт за собой движение всего рынка восьмибитников.

Совершенно не понятно почему вы не хотите финансировать Atmel. То есть NXP и STM и ARM вы финансировать согласны, а вот Atmel - нет. Не вижу разницы.

К появлению одного монстра такой подход уже привёл. Теперь его не сковырнуть не как. Давайте теперь двумя руками и ногами создавать другого в области МК. Зато все проги будут совместимы. А там и виндоуз подоспеет.

[Evgeny_CD]

Мелкие армы при той же структуре флэш/озу оказываются не так уж и привлекательны так как озу, как минимум требуется больше. AVR эффективнее использует. Опять таки скорость ногодрыганья у XMEGA выше и предсказуема без выкрунтасов, что также бывает востребовано.

Именно! Только после появления Cortex ARM стал так же эффективен по FLASH, как и AVR. Иначе просто маразм получался. Сложить два регистра - 4 байта из FLASH улетело. THUMB - это круто, но маразм: вначале мы разгоняет ядро до 60 Мгц, затем трмозим его в полтора раза на декодировании. Мы хотим платить за такой цирк?

Как я уже писал, именно 16 битная система команд является оптимальной для большинства современных задач - AVR, CF, Cortex, SH, ... Она дает возможность эффективно манипулировать разумным количество регистров, и достаточно экономична.

Кроме того, на технологии 0.18 токи утечки не позволят просто так получить менее 1 мка ток кристалла в режиме сна. Тут сильно стараться надо. AVR, насколько я понимаю, чуть ли не до сих пор по 0.35 делают.

[zltigo]

Или кто-то фанатеет от errat современных недопатченных ARM'ов?

LPC2468, говорите используете? Вопрос на засыпку - сколько пунктов в Errata? Ревизия, кстати, всего-лишь "B". Если лень посмотреть, то сообщу - два пункта. Один из них относится к ядру ARM и не правится полагаю ввиду того, что так уже "принято". Теперь посмотрите на Atmel-овские erata на многие годы уде выпускаемые чипы - во уж действительно печальная картина "пипл хавает" называется .

Так что даже простейший DMA, без кеша, TCM и пр. очень даже эффективен!

И FIFO тоже эффективен вполне. А FIFO + отдельный банк вообще прилично.

Кроме того, например в GPS чипах, в одном BGA корпусе часто живут два кристалла - RF и Digital. Понятно, что производитель об этом умалчивает

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

[Evgeny_CD]

LPC2468, говорите используете? Вопрос на засыпку - сколько пунктов в Errata? Ревизия, кстати, всего-лишь "B". Если лень посмотреть, то сообщу - два пункта. Один из них относится к ядру ARM и не правится полагаю ввиду того, что так уже "принято".

Ревизия А там вообще малоюзабельная была. Да, LPC2468 - неплохой кристалл.

Теперь посмотрите на Atmel-овские erata на многие годы уде выпускаемые чипы - во уж действительно печальная картина "пипл хавает" называется .

Atmel ARM я использовал только AT91R40008. Там errat'ы нет - чудный кристалл!

На SAM лично мне просто противно смотреть - вот я их и "не хаваю".

[zltigo]

Именно! Только после появления Cortex ARM стал так же эффективен по FLASH, как и AVR.

Да ну? Вообще-то разница во многих случаях просто ничтожна. Для интереса можете по этому форуму поискать - народ не раз и не два удивлялся .

Сложить два регистра - 4 байта из FLASH улетело.

Ну так уж и только сложить не передергивайте и сводите систему команд ARM "к сложить" - и сложить, и сдвинуть и условие проверить и все это - за одну команду в 4 байта. В формате 32-бит команды указываеся до 3х регистра/константы, проверяются 4 флага и дополнительный сдвиг до 32 бит. А что у нас у AVR - сколько там Flash кушать придется? А адресоваться подальше 256 байт?

THUMB - это круто

Это в подавляющем большинстве случаев, если не писать сильно ориентированные вещи просто не эффективно. Это я Вам, как имеющий большую практику человек говорю.

[Evgeny_CD]

Ну так уж и только сложить не передергивайте и сводите систему команд ARM "к сложить" - и сложить, и сдвинуть и условие проверить и все это - за одну команду в 4 байта. В формате 32-бит команды указываеся до 3х регистра/константы, проверяются 4 флага и дополнительный сдвиг до 32 бит. А что у нас у AVR - сколько там Flash кушать придется? А адресоваться подальше 256 байт?

Вот она, сила маркетинга!!! Возникает вопрос - а как часто мне необходимо все это "и сложить, и сдвинуть и условие проверить". Например, если только каждую пятую операцию - нафига же я тогда потратил 4*(2 лишних байта)=8 байт FLASH?

Это будет эффективно при жестком асмовом кодинге - но для ARM обычно так не принято

Ладно, спор ни о чем - идеальная CPU архитектура пока не создана.

[Dog Pawlowa]

Как я уже писал, именно 16 битная система команд является оптимальной для большинства современных задач - AVR, CF, Cortex, SH, ... Она дает возможность эффективно манипулировать разумным количество регистров, и достаточно экономична.

Собственно, тогда к чему тогда весь разговор?
Лично для меня использование 8-битных AVR обусловлено только наличием "доступных" средств программирования и отладки. В случае 'X' этого преимущества не существует (в настоящее время).
К ламерью не отношусь , выше 16 бит ничего делать не хочу и не буду, но постоянно переключаясь между MSP430 и AVR в проектах хоть сколь-нибудь реального времени, вижу, насколько удобнее использовать 16-битные контроллеры.
XMEGA - всего лишь для узкой ниши.

[Evgeny_CD]

И FIFO тоже эффективен вполне. А FIFO + отдельный банк вообще прилично.

Отдельный банк - это отдельный геморой. Его надо по особому обслуживать и т.д. А если весь необходимый буфер не влазит в отдельный банк - процом данные таскать?

В общем, я пока не встречал случаев, чтобы DMA проиграло по CPU load процессорной обработке.

Лично для меня использование 8-битных AVR обусловлено только наличием "доступных" средств программирования и отладки. В случае 'X' этого преимущества не существует (в настоящее время).

Может, я чего не понял, но что мешает использовать AVR Studio + WinAVR для ATxmega? Ядро то то же самое, хидеры атмел вроде родил.

mkII денег стоит - ну не таких уж и страшных, что-то типа 8000р. Не думаю, что это критичная величина - покупается раз и на долгие годы.

выше 16 бит ничего делать не хочу и не буду, но постоянно переключаясь между MSP430 и AVR в проектах хоть сколь-нибудь реального времени, вижу, насколько удобнее использовать 16-битные контроллеры.

Спорный вопрос. If писать на С - мало волнует, как там код исполняется, лишь бы успевало. ASM кодинг - он только для малых проектов или небольших кусков сложных проектов эффективен. По размерам C код за счет грамотного написания, полного использования всех квалификаторов и #pragma для данного конкретного компилера можно всегда хорошо ужать.

[svs39]

[quote name='zltigo' date='May 18 2008, 17:48' post='413027']
Только вот.. кто-нибудь сможет назвать лучший в мире 4-бит процессор??? Набежало, похоже, понимешь ламерье и с воплями "8 лучше 4" затоптало


8-битный- объективная реальность в современном байт-ориентированном мире (лично я использую от 1 до 6МК и переходить на 16-32 не собираюсь- естественно аудио-видео потоки не обрабатываю)

[Dog Pawlowa]

mkII денег стоит - ну не таких уж и страшных, что-то типа 8000р. Не думаю, что это критичная величина - покупается раз и на долгие годы.

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

Спорный вопрос. If писать на С - мало волнует, как там код исполняется, лишь бы успевало. ASM кодинг - он только для малых проектов или небольших кусков сложных проектов эффективен. По размерам C код за счет грамотного написания, полного использования всех квалификаторов и #pragma для данного конкретного компилера можно всегда хорошо ужать.

Это все понятно, но прикидка быстродействия требуется поточнее, да и покажите мне того программиста, который будет сразу писать грамотно (с точки зрения быстродействия), если это сначала не требуется. Все будет делаться потом, внося озлобленность в жизнь
Да и чего стоит обращение к многобайтовым переменным. Мелочь, но неприятно.

[Rst7]

Не устаю замечать, что DMA на контроллерах без кэша или каких-либо специализированных архитектурных наворотов штука малоэффективная. А то, что сделано у помянутого всуе ARM7 LPC, это как раз и есть эффективное использование DMA, поскольку он работает НА ОТДЕЛЬНОЙ ШИНЕ с ОТДЕЛЬНЫМ банком. Что позволяет не тормозить контролер "контроллером DMA"

Я одного понять не могу. Почему-то Вы упорно забываете о том, что шина у AVR не занята постоянным потоком чтения комманд, ведь адресные простанства совсем отдельные, Гарвард все-таки (это я сравниваю с ARM7, ARM9 - там все пучком, там кеш есть). Поэтому на AVR DMA имеет полное право на жизнь, ведь запись-чтение из памяти данных происходит очень редко, пустого места по времени - море. Даже такой код

Код

LOOP:
LD R16,X+
ST Z+,R16
DEC R17
BRNE LOOP

имеет на XMega 4 пустых цикла доступа на шину данных. Даже таким способом

Код

LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
....

нельзя заблокировать шину данных, тут на каждую пару комманд есть один пустой цикл, куда DMA отлично влезет.

Так что DMA тут рулит.

[Evgeny_CD]

Это все понятно, но прикидка быстродействия требуется поточнее, да и покажите мне того программиста, который будет сразу писать грамотно (с точки зрения быстродействия), если это сначала не требуется. Все будет делаться потом, внося озлобленность в жизнь
Да и чего стоит обращение к многобайтовым переменным. Мелочь, но неприятно.

О! Вот с этого все и начинается! Ради чего я так и возбудился

Как учит теория TDD - лучший способ завалить проект - начать его сразу и по всем параметрам оптимизировать. Результат гарантирован .

В той идеологии, что я описал, и чему посвящена куча PDF в начале топика, вначале пишутся только дрова (они едва ли сожрут все место во FLASH), и затем они "телепортируются" на писюк.

Затем на писюке в синтетическом порту пишется целевой код, и проверяется на правильность решения целевой задачи.

Затем начинаем его по кусочкам утаскивать на целевой проц, проверяя размер и быстродействие. И оптимизируя по мере необходимости.

В конце концов, может, все так ужмется, что и XMEGA будет не нужна

[zltigo]

Гарвард все-таки...

Естественно это увеличивает пользу от DMA. Если поднять мои давнишние выступления по DMA, то они относились прежде всего к SAM7 - сейчас это я так - "старое помянул" встретив старого знакомого.

[Rst7]

А вообще, лично меня другой момент интересует...

Вот смотрим на таблицу комманд. Видим:

LD Rd,X+ - 2 такта
ST X+,Rd - 1 такт

Все понятно, во втором случае можно выполнить запись в процессе обработки следующей комманды. Так же понятно, почему STD X+disp,Rd - 2 такта, это происходит из-за того, что такт заняло вычисление адреса.

Но теперь очень интересный вопрос. Возле всех комманд LD стоит примечание 2. Оно гласит - "один дополнительный цикл должен быть добавлен при доступе во внутреннюю SRAM".... Причем, возле комманд ST этого примечания нет... Вот тут я чето совсем не понял...
И как это согласуется с утверждением в разделе 7.1 - "Single cycle access from CPU"? Почему в одну сторону (запись) действительно single, а в другую - double???

Ну про SBIS/SBIC я давно удивлялся, почему стало 2 такта минимум...

[defunct]

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

то они относились прежде всего к SAM7 - сейчас это я так - "старое помянул"

Полностью опробовав DMA SAM7 (для всей его периферии). Категорически несогласен с этим высказыванием.
Эффективность DMA каналов SAM7 очень значительная.

при передаче 100 байт по SPI, без DMA канала проц 100 раз войдет в прерывание для подгрузки очередного байта, т.о. 100 раз займет шину на перегонку байта, +100 раз произойдет немерянный оверхед на исполнение кода обслуживающего прерывание.
При передаче через DMA канал - DMA отминет только 100 циклов шины пямяти.
Так что эффективнее?

Что DMA работает именно так как я описал (захватывает шину когда периферий модуль "готов" принять, и отпускает когда периф. модуль не готов принимать), сомнений у меня нет, могу привести ссылки из Д/Ш.

[zltigo]

Возникает вопрос - а как часто мне необходимо все это "и сложить, и сдвинуть и условие проверить".

Часто. Компилятор это пользует часто. Настолько часто, что на сколь-нибудь ральных задачах, написанных с умом и даже в общем-то не заточенных под 32 бита - обычные коммуникационные задачи.
Проигрыша в размере кода в общем-то нет - когда больше, когда меньше. Никакого "маркетинга" - чистая реальная СОБСТВЕННАЯ практика. Если мне не верите - то уже говорил - посмотрите на форуме.

[aaarrr]

Так что эффективнее?

Можно я отвечу? Эффективнее DMA+FIFO на отдельной шине кешированного процессора

Это, конечно, так, но уважаемый zltigo очень уж любит сгущать краски.

[zltigo]

Чем XMEGA то не устраивает? Всё в цену упирается и если она пойдёт с сопоставимой ценой, то будет очень приятно.

Вот после "если" и продолжим разговор. Пока старые ATMEGA стоят неразумных денег и меня терзают смутные сомнения, что XMEGA вдруг резко опустят по цене. Поднимть - не поднимут, скорее всего так и оставят. Посему лично для меня сколь-нибудь привлекательными будут что-то типа Тинек.

Мелкие армы при той же структуре флэш/озу оказываются не так уж и привлекательны
так как озу, как минимум требуется больше. AVR эффективнее использует.

Неправда Ваша опять ОЗУ оно и в Африке ОЗУ. Если обильно использовать битовые переменные щедрой рукой отдавая по ячейке под каждую, то тогда да. Только вот RAM жрут больше байтовые буфера всякие. А прочие данные надо просто в структуры, поля и паковать. Тут всякие "ненужные" ARM команды вполне эффективно работают и RAM попусту не тратится. Единственно, что заметно больше кушает RAM это более широкий стек. Но в общем никакого сташного расхода RAM нет.

Совершенно не понятно почему вы не хотите финансировать Atmel. То есть NXP и STM и ARM вы финансировать согласны, а вот Atmel - нет. Не вижу разницы.

Разница в том, что за меньшие деньги я получаю, например, больше памяти и мегагерцев. Кроме экономии денег, я получаю большие возможности для сопровождения и модернизации софта и менее в этом стеснен. Платить налог на костность я не желаю.

[defunct]

Можно я отвечу? Эффективнее DMA+FIFO на отдельной шине кешированного процессора

Да это все понятно.

Но я например не представляю как можно сделать DSP обработку звука (оцифровка 44.1kHz, обработка и выдача результата через DAC) на типа более эффективном с т.з. zltigo LPC (с MAM) не имея DMA каналов. Для SAM7 же такая задачка по плечу и только благодаря наличию DMA каналов. Плюс еще остается время на ethernet, консольки и прочую фигню.

[zltigo]

Это, конечно, так, но уважаемый zltigo очень уж любит сгущать краски.

Есть такое - несколько неадекватная реакция на достаточно частые повторения мантры "DMA-DMA-DMA-..." без особых на то причин

[Rst7]

Вот смотрим на таблицу комманд. Видим:LD Rd,X+ - 2 такта

Это я малость не то написал, немного не туда глянул. Как раз LD Rd,X или X+, или другая регистровая пара, не суть - 1 такт, но если SRAM, то плюс еще один... Вот этот "плюс еще один" и не ясен. Хотя, с другой стороны, все равно имеем выигрыш, в виде 2+1=3 такта на пару LD Rx,X+/ST Z+,Rx вместо 2+2=4 такта в классическом ядре AVR. А вот с LDD/STD имеем небольшой проигрыш. Абыдно, но ладно.

PS Видимо, этот дополнительный такт доступа к SRAM - из-за наличия коммутации процессор/DMA.

[zltigo]

Но я например не представляю как можно сделать DSP обработку звука (оцифровка 44.1kHz, обработка и выдача результата через DAC) на типа более эффективном с т.з. zltigo LPC (с MAM) не имея DMA каналов. Плюс еще остается время на ethernet, консольки и прочую фигню.

1. У LPC23/24 есть DMA, причем макмимально для ARM7 правильный
2. У Всех LPC есть FIFO
3. Я вообще-то даже на LPC214x обрабатываю. Вот прямо сейчас буферизирую, переповторяю и прочее... 64-килобитные фреймы и в Ethernet (на SPI висит) складываю и консолька на 115K в полный рост отладку гонит...
4. Еще конфигурацию на ходу в EEPROM лить можно...
5. Ну а речевыми каналами, наигыванием музыки, суммировнием, ослаблением и прочей обработкой рядом стоящая FPGA занимется у нее это тоже без DMA получается . И что характерно стоит на уровне 10 баксов и даже трудно представить сколько XMEG с их 8 UART потребуется дабы изобразить то количество UART, которых можно задить в этот чиклончик. Это я к тому, что идея обвешивать центральный контроллер массой маленьких это тоже далеко не всегда разумное решение.
6. Вот только "фигни" вроде нет - ну разве только светодиодики мигают, но они тоже полезные.

[Evgeny_CD]

...3. Я вообще-то даже на LPC214x обрабатываю. ...5. Ну а речевыми каналами, наигыванием музыки, суммировнием, ослаблением и прочей обработкой рядом стоящая FPGA занимется у нее это тоже без DMA получается .

И как же у Вас FPGA к LPC прикручена? Не уж то по SPI?

[SasaVitebsk]

Разница в том, что за меньшие деньги я получаю, например, больше памяти и мегагерцев. Кроме экономии денег, я получаю большие возможности для сопровождения и модернизации софта и менее в этом стеснен. Платить налог на костность я не желаю.

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

[Evgeny_CD]

...Можно ездить на жигулях за меньшие деньги. Я езжу на Тойоте. Как то себе спокойнее. Переплачиваю правда ...

...Кто понимает - готов за это доплатить 1$ за кристалл. А Атмелу большего и не надо...

[defunct]

1. У LPC23/24 есть DMA, причем макмимально для ARM7 правильный

Но 23/24 дороже SAM'a будут..

2. У Всех LPC есть FIFO

FIFO меня бы неустроило.
Самое главное в моей задачке оцифровка и update DAC'a без jitter'a. Это нерешаемо без DMA.

3. Я вообще-то даже на LPC214x обрабатываю. Вот прямо сейчас буферизирую, переповторяю и прочее... 64-килобитные фреймы и в Ethernet (на SPI висит) складываю и консолька на 115K в полный рост отладку гонит...

Я прекрасно понимаю, что "мощности" процессора для обработки хватит (раз даже SAM7 справляется), LPC214x хороший камень для своих задач. Но вот на вводе/выводе он менее эффективен - мест где он не обеспечит real-time больше чем на SAM'е..

5. Ну а речевыми каналами, наигыванием музыки, суммировнием, ослаблением и прочей обработкой рядом стоящая FPGA занимется у нее это тоже без DMA получается .

Охотно верю, что у нее и без DMA получается, и даже без проца. Но это дорого

И что характерно стоит на уровне 10 баксов и даже трудно представить сколько XMEG с их 8 UART потребуется дабы изобразить то количество UART, которых можно задить в этот чиклончик.

В этом плане согласен. xmega не лучший вариант для периферийного сопроцессора. Больше в качестве основного для систем средней / малой сложности.

[zltigo]

Удобство и костность - разные понятия.

??? В чем удобство, если ездить на Жигулях приплачивая АвтоВАЗ стоимость Тойоты? Чем 16-32 битовики вдруг "неудобны" стали?

И как же у Вас FPGA к LPC прикручена? Не уж то по SPI?

Да к 213/4x по SPI. Как Вы, надеюсь, понимате, никаих ограничений по реализации SPI в FPGA нет, посему нормальная работа на 15/30MHz 16it*8FIFO. Несколько 64Kbit потоков без малейших проблем. На 2468/2378 на параллельной шине.

[Evgeny_CD]

На 2468/2378 на параллельной шине.

Именно! Параллельная внешняя шина - колоссальная фича LPC24XX/LPC23XX. По этой причине меня дико бесит "выбор" PIC24: либо параллельный порт, либо DMA.

Внешнаяя параллельная шина в ATxmega - еще один приятный +.

[zltigo]

Но 23/24 дороже SAM'a будут..

Младшие 23 что-то на уровне 120 рублей в MT-System. Дороже?

Посмотрел:
LPC2364FBD100,551 NXP (Philips) 114.14 131.7
LPC2366FBD100,551 NXP (Philips) 136.63 157.65
LPC2368FBD100,551 ver.A NXP (Philips) 157.04 181.2
LPC2378FBD144,551 NXP (Philips) 181.48 209.4
LPC2378FBD144,551 ver.A NXP (Philips) 181.48 209.4
LPC2378FBD144,551 ver.B NXP (Philips) 181.48 209.4
LPC2368FBD100,551 ver.B NXP (Philips) 181.25 195.75
LPC2364FBD100,551 ver.B NXP (Philips) 114.14 131.7
LPC2366FBD100,551 ver.B NXP (Philips) 136.63 157.65
LPC2387FBD100,551 NXP (Philips) 163.41 188.55
LPC2388FBD144,551 NXP (Philips) 198.9 229.5
LPC2365FBD100,551 NXP (Philips) 115.44 133.2
LPC2364FET100,518 NXP (Philips) 114.14 131.7

*Цены указаны в рублях с учетом всех налогов

А это цены, причем "за морем - полушка.." , которые почему-то внушают оптимизм Автору топика:

Цены - ABN Universal,Inc., например, дает для ATXMEGA128A1-AU 9,97 $ в розницу - достаточно обнадеживающе. Это на проц с 8К RAM, 4K EEPROM, 128K FLASH, 78 IO пинов.

Может кто-то без расскзов про Тойоту объяснить чего я не понимаю?
P.S. За последний год трижды использовал изделия от Atmel Atmega169P , Atmega162, ATtiny2313. Первые два почти штучная работа использовалось готовое железо которе можно было приспособить и из-за наличия LCD контроллера у 169P. А 2313 это действительно дешевый массовый контроллер - с умножением (генерация псевдослучайной последовательности в реальном времени) пришлось поизврашаться, но массовость и дешевизна того стоила. Ничего похожего на езду на Тойоте (хотя .... хотя руль-то всетаки левый! ) не испытал. Впрочем, как и какого-либо отвращения. Все нормально. Мелюзгу буду использовать и впредь. Но старшие модели незачем.

Сообщение отредактировал zltigo - May 18 2008, 22:00

[defunct]

Младшие 23 что-то на уровне 120 рублей в MT-System. Дороже?

Посмотрел каталог MT-System, что-то там не так, действительно там LPC дешевле.
В Киеве все в точности до наоборот, видать зависит от прямых/непрямых поставок.

SAM7S64 - сам лично брал по $5.2 (это должно быть меньше 120 руб если не ошибаюсь с курсом).
SAM7X256 - по $8

SAM7S32 - вообще по $4 в розницу (в виакоме)

Может кто-то без расскзов про Тойоту объяснить чего я не понимаю?

Цены ж "в розницу".
К примеру LPC2366 в розницу можно найти за 14$. LPC2378 за 18$ тут
так что 10$ получается типа как меньше.

[zltigo]

В Киеве все в точности до наоборот, видать зависит от прямых/непрямых поставок.

Можете заняться сравнением и где-нибудь в "третьей стране". Или цен за 10K у крупных поставщиков... На ARM цены от Atmel будут сопоставимы с прочими производителями. Это нормально.

Посмотрел каталог MT-System, что-то там не так, действительно там LPC дешевле.

[alexander55]

Кроме того, на технологии 0.18 токи утечки не позволят просто так получить менее 1 мка ток кристалла в режиме сна.

Можно, при более низком напряжении. Есть такое понятие - пробивное напряжение. Оно зависит только от геометрии.

Тут сильно стараться надо. AVR, насколько я понимаю, чуть ли не до сих пор по 0.35 делают.

Это для совместимости с 3.3 В питанием.

Посмотрел каталог MT-System, что-то там не так, действительно там LPC дешевле.
В Киеве все в точности до наоборот, видать зависит от прямых/непрямых поставок.

... и от объема закупок.

[608]

Наличие ОСьки позволяет по полной программе использовать технологию синтетических портов. Т.е., например,....

Что такое "технологию синтетических портов". Впервые встречаю это. Уточните, если можно суть и преимущества.
Еще говорилось где-то, что для XMEGA компилятор IAR в процессе улучшения и нужно еще подождать пока. Т.е. как с доступным софтом?

[Dog Pawlowa]

Затем начинаем его по кусочкам утаскивать на целевой проц, проверяя размер и быстродействие. И оптимизируя по мере необходимости.

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

Собственно, я не очень то против самой первой фразы "Xmega - самый лучший микроконтроллер среди 8-разрядных". Посмотрим

[zltigo]

Я имею некоторый опыт такого "портирования". Больших преимуществ...

Все зависит от сложности поднимаемых протоколов и вообще возможности их отладки. Даже какой-нибудь до невозможности обсосанный TCP/IP писать и отлаживать на реальном железе просто неудобно. Если говорить о чем-нибудь более сложном, то реальное железо просто будет мешать, ибо на самом деле сколь-нибудь отладить такое возможно только на модели с тестбенчами и прочим. Ни одно "реальное" применение не даст ничего подобного полной картине. Да и не протокольные вещи тоже - классический пример - ну как Вы собираетесь отлаживать, напрмер, какой-нибудь алгоритм сжатия залив его реальное железо?

[Rst7]

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

Ну и что, реальное железо тоже поддается отладке. А, например, может быть и так - вот я тут на днях написал кодер JPEG, и отладил его в AVR Studio. Вообще без железа, но писал сразу для целевого проца, отладил в симуляторе. И ничего, не умер, как ни странно. Хотя, конечно, другим так делать не посоветую

[Dog Pawlowa]

Все зависит от сложности поднимаемых протоколов и вообще возможности их отладки. Даже какой-нибудь до невозможности обсосанный TCP/IP писать и отлаживать на реальном железе просто неудобно. Если говорить о чем-нибудь более сложном, то реальное железо просто будет мешать, ибо на самом деле сколь-нибудь отладить такое возможно только на модели с тестбенчами и прочим. Ни одно "реальное" применение не даст ничего подобного полной картине. Да и не протокольные вещи тоже - классический пример - ну как Вы собираетесь отлаживать, напрмер, какой-нибудь алгоритм сжатия залив его реальное железо?

Удобнее - да, единственно возможно - нет.
Если речь идет о протоколах, то сложные протоколы, как правило, все равно сертифицируются с помощью инструментов, предоставляемых организацией, создавшей стандарт, на реальном устройстве, а все уровни взаимодействия прописаны детально. Модели - это всего лишь костыли
Что касается непротокольных вещей, то отладка через JTAG дает пусть неудобный и недостаточный, но достаточно эффективный контроль целевым устройством.

[GetSmart]

А, например, может быть и так - вот я тут на днях написал кодер JPEG,

Да, JPEG идеально ложится на 8-битник Там вроде бы пол алгоритма считается на плавучке. Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно.

[aaarrr]

Плавучка для JPEG'а вовсе не обязательна. А вот отлаживать его в симуляторе - это сильно. Не знаю, как в AVR Studio, но под VDSP у меня не хватило терпения: вычисления идут на много (4-6) порядков медленнее, чем в железе.

[Rst7]

Там вроде бы пол алгоритма считается на плавучке

Только целые. Причем 16 бит.

Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно.

А потом Вы будете меня убеждать, что на ARM быстрее?

Тестовая картинка 320*240 пакуется примерно за 12 миллионов тактов. Т.е. примерно секунду (кварц планируется 14-16МГц). Для последующей передачи через GPRS, например, такое малокадровое телевидение - самое оно.

[Evgeny_CD]

...Это для совместимости с 3.3 В питанием...

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

[zltigo]

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

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

[Evgeny_CD]

Что такое "технологию синтетических портов".

Почитайте PDF в корневом посте топика и поищите мои старые посты по теме.

Еще говорилось где-то, что для XMEGA компилятор IAR в процессе улучшения и нужно еще подождать пока. Т.е. как с доступным софтом?

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

[blackfin]

А потом Вы будете меня убеждать, что на ARM быстрее?
Тестовая картинка 320*240 пакуется примерно за 12 миллионов тактов.

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

[Evgeny_CD]

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

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

[Rst7]

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

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

[Evgeny_CD]

Да, JPEG идеально ложится на 8-битник Там вроде бы пол алгоритма считается на плавучке. Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно.

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

[Rst7]

если ее не использовать "в лоб", то можно использовать как пособие по разработке своего варианта кодека.

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

[Evgeny_CD]

Ну и что, реальное железо тоже поддается отладке. А, например, может быть и так - вот я тут на днях написал кодер JPEG, и отладил его в AVR Studio. Вообще без железа, но писал сразу для целевого проца, отладил в симуляторе. И ничего, не умер, как ни странно. Хотя, конечно, другим так делать не посоветую

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

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

[zltigo]

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

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

[Evgeny_CD]

Причем все вместе при сертификационных испытаниях проверит далеко даже не на 90%. Оставшихся десять хватит для полного облома...

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

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

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

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

[Rst7]

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

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

[Evgeny_CD]

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

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

[zltigo]

Во-первых, там Mega16...

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

..на реальном железе такое делать точно устанете

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

[blackfin]

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

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

[Evgeny_CD]

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

!уговаривал, но раскрывал Вашу мысль. Ибо согласен с ней.

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

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

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

[Dog Pawlowa]

Для тестирования, например, протокольчика SS7 http://en.wikipedia.org/wiki/Signaling_System_7 потребуется в буквальном смысле гора железа c соответствующей стоимостью. ...

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

[zltigo]

Чего не скажешь про стоимость средств разработки для BF...

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

а также стомость труда программиста для BF ...

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

..и *HDL

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

[Evgeny_CD]

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

Одно дополняет другое. Дрова на железо, разборки с хитрыми контроллерами прерываний - тут без JTAG тоска.

...ждать очередной реинкарнации AVR8 - YMEGA...

Иес! ZMEGA - это будет означать конец эры 8-битников.

[zltigo]

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

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

[Rst7]

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

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

Когда надо будет сделать 10-20-50-100 кадров в секунду - будет FPGA

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

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

[Evgeny_CD]

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

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

[GetSmart]

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

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

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

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

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

[aaarrr]

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

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

[Rst7]

если даже кодер JPEG легко ложится на AVR

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

[defunct]

Можете заняться сравнением и где-нибудь в "третьей стране". Или цен за 10K у крупных поставщиков... На ARM цены от Atmel будут сопоставимы с прочими производителями. Это нормально.

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

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

[SasaVitebsk]

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

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

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

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

[Evgeny_CD]

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

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

Сообщение отредактировал Evgeny_CD - May 19 2008, 15:11

[zltigo]

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

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

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

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

Дак а что? Вы предлагаете рассматривать MT-System как эталон?

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

Какова ситуация с RTOS на BF сейчас? ..

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

А вот у аналогичных по цене - мелких NXP DMA прото нет.

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

[defunct]

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

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

[Evgeny_CD]

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

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

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

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

[ILYAUL]

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

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

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

Сообщение отредактировал ILYAUL - May 19 2008, 20:41

[Evgeny_CD]

Datasheet - ATxmega64A1/128A1/192A1/256A1 Preliminary - Rev. B - 2008-05-09 -
http://www.atmel.com/dyn/general/tech_doc....p;family_id=607

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

[ILYAUL]

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

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

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

[Evgeny_CD]

Кстати MEGA164P теперича только до 16 Мгц - из DATA SHEET убрали 20 Mгц

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


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

[Evgeny_CD]

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

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

[Evgeny_CD]

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

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

caxapa::jorikdima

Уже на подходе новая серия МК MSP430F5xxx, которая будет иметь практически то же самое потребление, что и серия 2ххх, но при этом тактовая частота возрастет до 25 МГц, обеспечивая производительность 25 MIPS. Ожидается, что новые МК будут также полностью совместимы по системе команд и программному коду. Одним из первых должен появиться МК с интерфейсом USB и объемом flash-памяти 256 Кб, в дальнейших планах - появление МК с интегрированным радиоинтерфейсом.

Для поддержки разработчиков также появится новая версия среды разработки CodeComposer Essentials 3.0, которая в бесплатной версии позволит компилировать до 16 Кб С-кода. Из аппаратных средств - обновленный USB/JTAG-интерфейс, который будет поддерживать новые микроконтроллеры

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

[defunct]

МSР430F5436 192KB+512B, 16KB

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

[dxp]

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

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

[Evgeny_CD]

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

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

[defunct]

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

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

[SasaVitebsk]

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

[Evgeny_CD]

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

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

[zltigo]

ATxmega однозначно эффективнее по всем параметрам MSP430F1xx.

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

[АДИКМ]

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

[SasaVitebsk]

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

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

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

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


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

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

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

[proba]

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

[АДИКМ]

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

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

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

[rezident]

И прочие фичи - как будто читали мысли разработчиков. Например всё то, что реализовано по RTC и микропотреблению, всё до единого уже назрело. И, совершенно очевидно, что этот локомотив потянет за собой остальные конторы.

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

[Evgeny_CD]

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

Но на рынке микроконтроллеров у макса как-то не сложилось. Они делают зачечательную кучку мелких девайсиков, и... пусть делают! Каждый рожден для чего-то своего. Maxim - явно не для MCU

Так ещё picopower 1 свет толком не увидели. atmega48p пока недоступна.

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

Сообщение отредактировал Evgeny_CD - May 22 2008, 20:53