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

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

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. Вот только "фигни" вроде нет - ну разве только светодиодики мигают, но они тоже полезные.

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

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

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


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


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


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


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

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



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

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

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

Младшие 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

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

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

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

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

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

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

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


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

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

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


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


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

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

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

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

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