Atmel или NXP, помогите выбрать Опции

[Lotor]

Время поспело, в моей конторе дали добро переходить на современный МК. Выбор пал на ядро arm7. Осталось определиться с производителем. Если не трудно, можете назвать плюсы или минусы микроконтроллеров NXP и атмела. Объективно, без священной войны и шапкозакидательства. Занимаемся измерительными приборами, в основном простыми - из периферии только таймеры и уарт, SPI и I2C реализую программно (так проще). Но в скором времени будет проект с CAN. Во-общем хочется выбрать семейство МК на вырост. Производство серийное, цена значение тоже имеет. Еще некоторые приборы идут жить к военным, они почему-то легче соглашаются с мк производства атмел. У NXP напрягло отсутствие подтяжек - место на плате дорогого стоит, но главный его плюс - наличие литературы на русском и дешевые отладочные платы... Буду рад Вашим ответам.

[Dron_Gus]

Боюсь без религиозных споров не обойдется.
У Атмела I2C не I2C, а TWI. Хотя и совместим, работает не всегда адекватно.
У sam7 есть подобие DMA на всю периферию, несомненный плюс.
К CAN у sam7 претензий нет.
Если на вырост, то у Атмела прекрасная "наследственность" sam7s32 -> sam7s64 -> sam7x -> rm9200 (arm9)... и т.д.

[zltigo]

У Атмела I2C не I2C, а TWI. Хотя и совместим, работает не всегда адекватно.

У NXP он самый, что ни на есть родной - классика от Основоположников.

У sam7 есть подобие DMA на всю периферию, несомненный плюс.

Для контроллеров без кэша, коими являются SAM7 или отдельных банков памяти на разных шинах, как у свежих NXP "DMA" вещь вполне бесполезная. А вот у свежих NXP FIFO+DMA(на отдельной шине) явно гибкое решение.

Если на вырост...

Если на вырост, то SAM7 и 'прошлогодние' NXP достаточно похожи, но вот развивается ARM7 у NXP явно быстрее и выбор заметно больше.

У NXP напрягло отсутствие подтяжек...

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

цена значение тоже имеет.

Ценовая политика, в сочетании с большим диапазоном выбора, у NXP агрессивенее

[aaarrr]

Для контроллеров без кэша, коими являются SAM7 или отдельных банков памяти на разных шинах, как у свежих NXP "DMA" вещь вполне бесполезная.

Все-таки не совсем бесполезная - идеально подходит для USART в пакетном режиме, да и на более скоростной периферии иногда нужен. FIFO не хватает, согласен.

Еще один плюс NXP - более высокая производительность.

[sensor_ua]

напрягло отсутствие подтяжек

у 23xx поправлено.
А ограничение по производителям откуда? Почему не TMS470, не ST91x?
Я выбрал в своё время для своих задач филипс, но рассматривал и остальные. Вопросов было гораздо больше. Вот собрался для других задач юзать Luminary, но NXP остаётся.
Вы бы чётче задачу ставили, а то религиозные войны пока имеют пищу

[Lotor]

Спасибо за ответы.

А ограничение по производителям откуда? Почему не TMS470, не ST91x?

Собственно ограничение сам ввел - Atmel и NXP самые популярные представители ядра arm7, судя по информации в инете. Есть вариант использовать микроконтроллеры AD, но, на сколько я помню, там аналоговая и цифровая часть не разявязаны, что не есть хорошо.

[aaarrr]

Есть вариант использовать микроконтроллеры AD, но, на сколько я помню, там аналоговая и цифровая часть не разявязаны, что не есть хорошо.

Медленные они очень по сравнению с остальными. Не совсем понятно, что Вы имеете в виду под "неразвязанностью" аналоговой и цифровой части?

[Harbour]

Atmel avr32 - и нефиг париться по этому вопросу, если конечно нету серьезных ассемблерных наработок для ARM.

[Lotor]

Медленные они очень по сравнению с остальными.

Зато 12-битный АЦП не помешает, в некоторых задачах может даже от внешнего откажемся...

Не совсем понятно, что Вы имеете в виду под "неразвязанностью" аналоговой и цифровой части?

На сколько я помню, мы от ADUCов (на базе ядра x51) отказались как раз-таки из-за отсутствии развязки внутри МК между цифровой и аналоговой частью. Для измерительных задач это не есть хорошо..

Atmel avr32 - и нефиг париться по этому вопросу, если конечно нету серьезных ассемблерных наработок для ARM.

Тогда уж новые пики и программирование на Си, но боюсь это уже две новые религиозные войны. =)

[zltigo]

Тогда уж новые пики...

Тогда уж недурно-бы обрисовать начальный круг задач....

[Lotor]

Те задачи, которые есть сейчас, сможет выполнять любой МК с таймерами - снятие данных с внешнего АЦП, обработка, вывод на индикаторы, реализация интерфейса. Просто хочется выбрать современный микроконтроллер с прицелом на будущее. Вот выбор и пал на arm7. Я вообще сторонник того, чтобы не зависить от семейства или производителя, но сейчас надо заказывать отладочные платы, поэтому и интересует сабж.

[Qwertty]

У меня та же дилемма. Но я решил попробовать оба

[viael]

Те задачи, которые есть сейчас, сможет выполнять любой МК с таймерами - снятие данных с внешнего АЦП, обработка, вывод на индикаторы, реализация интерфейса. Просто хочется выбрать современный микроконтроллер с прицелом на будущее. Вот выбор и пал на arm7. Я вообще сторонник того, чтобы не зависить от семейства или производителя, но сейчас надо заказывать отладочные платы, поэтому и интересует сабж.

Тогда уж лучше на PIC24/dsPIC посмотреть, они практически на всех задачах рвут ARM7(кроме плавучки), да и цена более привлекательная, да и периферия у них очень даже. Если смотреть на ARM(который совсем не новый и современный(ARM7xxx)), то лучше на новое поколение ARM Cortex-M3. Сейчас какраз они только появились в продаже по ценам от 2 до 15$( Luminary Micro или STMicroelectronics).Рекомендую посмотреть и на них.

[alexander55]

Тут уже была тема.
Мое мнение: LPC полегче осваивать (посмотрите по форуму, люди мучаются с программированием периферии для Atmel, для LPC вопросов нет).
AVR32 хорошее решение, но там, наверняка, есть глюки (без коментариев).
По поводу DMA легкий экскурс в историю.
1. На первых XT контроллеры HDD (MFM и RLL) делали с DMA и без него. Преимущество было с DMA.
2. На 386 IDE делали уже без DMA. Преимущество у программной реализации.
3. На P5 появилось UltraDMA. Преимущество опять с DMA.
Опять спирали Гегеля.

[AlexandrY]

Ну вы так быстро окажетесь в аутсайдерах.

Просто мутно говорить о планах на вырост это ИМХО не верно.
Надо сразу ориентироваться на современные тенденции.
Новый дисплей - графический на OLED
Новая клава - сенсорная.
Новая обработка данных - расширяем полосу, выжимаем больше информации, рисуем графики, логи, историю, тренды, апроксимации, прогнозы ... и т.д.
Новый способы интерфейса с юзером - голосовая подсказка, прочитывает отрывки из мануала и т.д.
Новые коммуникационные каналы - беспроводные 3G, WiMAX, Wireless USB и т.д.
И тогда ясно что ARM7 - это уже не на вырост, а так чтоб только не загнуться.
Надо ориентироваться на ARM9.

Те задачи, которые есть сейчас, сможет выполнять любой МК с таймерами - снятие данных с внешнего АЦП, обработка, вывод на индикаторы, реализация интерфейса. Просто хочется выбрать современный микроконтроллер с прицелом на будущее. Вот выбор и пал на arm7. Я вообще сторонник того, чтобы не зависить от семейства или производителя, но сейчас надо заказывать отладочные платы, поэтому и интересует сабж.

[Vitaliy_ARM]

Могу от себя так же добавить + в сторону LPC23xx/LPC24xx. Сначала научился программировать SAM7S64, потом перешел на эту серию. Да действительно осваиваются они чуть по-легче. DMA у них куда лучше, чем у ATmel, жаль что всего 2 канала (DMA общего назначения), когда у атмела за десяток переваливает, однако он (DMA) более эффективен, практически не тормозит процессор, так как имеет две шины и т.п. От атмела пока нового в этой линейке не появляется, а если и появится, то не скоро.

[KRS]

LPC23xx конечно классный процессор и по быстродействию и по цене! Но его до сих пор не выпускают, только семплы! И там такие ошибки, которые сводят все на нет! Аналогичные SAM7X, STR... уже давно выпускаются приходитя делать все на них.

[zltigo]

Аналогичные SAM7X, STR... уже давно выпускаются приходитя делать все на них.

Справедливости ради следует заметить, что аналогичные упомянутым это STR213/4 выпускаются давноооо...

По поводу DMA легкий экскурс в историю.

Как-бы не совсем показательно.

1. На первых XT контроллеры HDD (MFM и RLL) делали с DMA и без него. Преимущество было с DMA.

Путаете за давностью лет В XT 8bit DMA контроллер работающий 1/4 от 4.7 MHz частоте годился разве только для обслуживания FDD. Пересылка порт-память даже не на турбо XT справлялась лучше.

3. На P5 появилось UltraDMA.

На старших процессорах прежде всего появился кэш, что и позволило вновь начать с пользой использовать и развивать DMA.

[shahr]

Тогда уж лучше на PIC24/dsPIC посмотреть, они практически на всех задачах рвут ARM7(кроме плавучки), да и цена более привлекательная, да и периферия у них очень даже. Если смотреть на ARM(который совсем не новый и современный(ARM7xxx)), то лучше на новое поколение ARM Cortex-M3. Сейчас какраз они только появились в продаже по ценам от 2 до 15$( Luminary Micro или STMicroelectronics).Рекомендую посмотреть и на них.

пока не всё ясно с М3 кортексом. в основном в области энергопотребления и реального быстродействия. если ST не сделает что-то с доступом к флеш, то им что кортекс, что АРМ9 - ничего не поможет. про люминари ничего сказать не могу

[Lotor]

LPC23xx конечно классный процессор и по быстродействию и по цене! Но его до сих пор не выпускают, только семплы! И там такие ошибки, которые сводят все на нет!

А мы только хотели заказывать серию LPC2378, говорите не стоит? Жаль.

[shahr]

А мы только хотели заказывать серию LPC2378, говорите не стоит? Жаль.

никого не слушайте, заказывайте серию. до нового года обязательно получите. и выпускается уже ревизия B, где все ошибки исправлены. смотрим еррату.
http://www.standardics.nxp.com/support/doc...ata.lpc2378.pdf

[zltigo]

говорите не стоит? Жаль.

Стоит. Про ошибки лучше лично прочитать свежую errata, а не судить с чьих-то слов.

[Lotor]

Спасибо, будем разбираться)

[uriy]

Не могу понять за что народ хвалит LPC. Начинаю осваивать параллельно ARM от atmel и nxp. Пока у NXP одни минусы. Начал искать документацию на сайте, на NXP ушло полчаса. Эта дурацкая привычка некоторых фирм дробить доку на даташит и юзер мануал. Щас еще раз попробовал зайти на сайт nxp и уже опять не могу найти где там этот юзер мануал. На поиск даташита у atmel ушло не более минуты. Уважаю документацию от atmel еще с 51 ядра. Все подробно и в одном документе. Дальше еще лучше. Решил залить пробную прошивку в LPC c помощью FlashUtil LPC2000 (так вроде называется) Оказалось там нет моего контроллера LPC2378 да и программа эта не работает под вистой и больше она похоже не развивается вовсе. Нашел FlashMagic с ним все ОК. Этой самой пробной прошивкой был вторичный бут, который якобы позволяет кидать во флеш bin файл, а сам контроллер виден как mass storage. Ничего не получилось, не работает, нет никакого внешнего диска. У nxp есть такой документ AN10711_2.pdf в котором описан этот самый загрузчик, причем этот документ находится на страничке LPC2378. Оказывается этот бут для другой модели контроллера. Так зачем спрашивается помещать документ на эту страничку. Там есть такая фраза "This code can be easily modified to work with the LPC23xx and LPC24xx." Написали бы еще что его легко переделать для ARM7 от STM например. Делать мне больше нечего как щас этим заниматься. Контроллеры сделали, а там ладно пусть покупают и разбираются как хотят. У Atmel же USB и UART бут записаны с завода, софт на сайте обновляется. У них нет таких pdf чтобы было написано в таком духе: "Вот мы тут наваляли pdf, для новых контроллеров он уже не актуален. Кому будет надо сами разберетесь". Посмотрим что будет дальше с железом. Тут многие пишут что nxp шустрее atmel. Так неужели вы выбирается для своих проектов контроллеры которые загружены на 99,9%. Я не думаю что быстродействие разных контроллеров отличается в разы. Например, с одной и той же задачей nxp будет загружен на 60% а atmel на 80% и что вам плохо от этого? Так что утверждение nxp шустрее аргумент не весомый.

[aaarrr]

Эта дурацкая привычка некоторых фирм дробить доку на даташит и юзер мануал.

Так делают почти все производители, за исключением Atmel.

Дальше еще лучше. Решил залить пробную прошивку в LPC c помощью FlashUtil LPC2000 (так вроде называется) Оказалось там нет моего контроллера LPC2378 да и программа эта не работает под вистой и больше она похоже не развивается вовсе. Нашел FlashMagic с ним все ОК.

Ссылка на FlashMagic есть на сайте NXP.

Тут многие пишут что nxp шустрее atmel. Так неужели вы выбирается для своих проектов контроллеры которые загружены на 99,9%. Я не думаю что быстродействие разных контроллеров отличается в разы. Например, с одной и той же задачей nxp будет загружен на 60% а atmel на 80% и что вам плохо от этого? Так что утверждение nxp шустрее аргумент не весомый.

Найдите у Атмела контроллеры SD/MMC, флешовые кристаллы с LCD контроллером. Да просто хотя бы рабочий I2C

[zltigo]

Не могу понять....

А еще крайне интересно узнать, как Вам оттенок цвета корпуса у LPC? Устраивает?

[uriy]

Ссылка на FlashMagic есть на сайте NXP.

Наверно я слепой... Этого на сайте я тоже не увидел.

Найдите у Атмела контроллеры SD/MMC, флешовые кристаллы с LCD контроллером. Да просто хотя бы рабочий I2C

В SD/MMC контроллерах надобности пока не возникало. LCD предпочитаю со встроенным контроллером. I2C тоже не часто нужен, SPI больше.

А еще крайне интересно узнать, как Вам оттенок цвета корпуса у LPC? Устраивает?

Вполне.

[Dog Pawlowa]

LCD предпочитаю со встроенным контроллером.

Насколько я понял, встроенный контроллер LCD значит, что прибор получится дороже.

[aaarrr]

Насколько я понял, встроенный контроллер LCD значит, что прибор получится дороже.

Дороже и хуже (по потреблению и скорости работы).

[zltigo]

Наверно я слепой...

Ну думаю не совсем, а выборочно, ибо SAM-BA Вам на сайте Аtmel каким-то образом удалось найти без жалоб . Ну а если серьезно без пурги типа "не могу найти" и сваливания всех и вся документов в одну кучу, то для ARM7 выбор Atmel/NXP не стоит уже года 4. Atmel по инерции чего-то еще конечно рожает, но уже мало конкурентоспособное. Естественно, что для какого-то конкретного изделия за счет нюансов периферии возможно попадание в точку и с Atmel/ST/TI..., но выбор надо начинать с NXP.

[dENIM]

Эта дурацкая привычка некоторых фирм дробить доку на даташит и юзер мануал.

меня лично бесят атмеловские даташиты

в которых 500+ страниц, и, например, сведения о максимальной частоте шины, возможно отыскать только в параграфе про потребление тока на этой самой максимальной частоте

[aaarrr]

в которых 500+ страниц, и, например, сведения о максимальной частоте шины, возможно отыскать только в параграфе про потребление тока на этой самой максимальной частоте

Это где такое безобразие? Обычно все на месте - в AC Characteristics или Clock Characteristics.

[dENIM]

Это где такое безобразие? Обычно все на месте - в AC Characteristics или Clock Characteristics.

Это я утрировал.
в 9260
в Electrical Characteristics

я конечно понимаю, что можно и там посмотреть, но почему нельзя это продублировать в параграфе про установку значения этого самого MCK, а то там написанно, что значение может быть равно PCK, PCK/2, PCK/4....
Но РСК может быть больше 105 МГц, а вот МСК - нет. И выясняется это только косвенно..через Electrical Characteristics

[aaarrr]

я конечно понимаю, что можно и там посмотреть, но почему нельзя это продублировать в параграфе про установку значения этого самого MCK, а то там написанно, что значение может быть равно PCK, PCK/2, PCK/4....

Гораздо худший вариант я встречал у Cirrus Logic'ов - там в даташите были предельные значения для FCLK и HCLK, а ограничение на PCLK только вскользь упомянуто в User Manual'е.

[singlskv]

Найдите у Атмела контроллеры SD/MMC,

Например AT91SAM7A3

[dENIM]

Гораздо худший вариант я встречал у Cirrus Logic'ов - там в даташите были предельные значения для FCLK и HCLK, а ограничение на PCLK только вскользь упомянуто в User Manual'е.

ну я туда не лазил пока...и наверно не полезу

[aaarrr]

Например AT91SAM7A3

И правда. Один кристалл против, если не ошибаюсь, трех у NXP.

[SergeiCh]

К CAN у sam7 претензий нет.

Разве что mailbox’ов маловато. У тех же C8051F04x их 32 против 8 у SAM7X - про NXP не в курсе. SAM7A3, imho, какой-то не однозначный: SRAM маловато, самбы нет.

[aaarrr]

SAM7A3, imho, какой-то не однозначный: SRAM маловато, самбы нет.

Первый блин у Атмела просто. Поэтому я его даже не рассматривал всерьез.

[Diman_]

выбор Atmel/NXP не стоит уже года 4.

Не во всем согласен с уважемым гуру. ИМХО SAM7S32-256 vs. LPC21xx-LPC22xx примерно равноценны, что-то лучше у первых, что то у вторых. SAM7X128-512 vs. LPC23xx тоже еще посмотреть. А вот по поводу SAM7SE32-512 vs. LPC24xx согласен полностью. Из-за багов первого при работе с SDRAM был вынужден в пожарном порядке переводить начатый проект на LPC2468, кстати после шести лет работы с АТ91.

[DmitryM]

Не во всем согласен с уважемым гуру. ИМХО SAM7S32-256 vs. LPC21xx-LPC22xx примерно равноценны, что-то лучше у первых, что то у вторых. SAM7X128-512 vs. LPC23xx тоже еще посмотреть. А вот по поводу SAM7SE32-512 vs. LPC24xx согласен полностью. Из-за багов первого при работе с SDRAM был вынужден в пожарном порядке переводить начатый проект на LPC2468, кстати после шести лет работы с АТ91.

IMHO, большую роль в данном случае играют личные предпочтения. Мне лично LPC ну не нравятся и все, значительно приятнее с Atmel.

P.S. Про какие глюки SDRAM SE речь идет??? нашел только один с инициализацией или есче есть грабли???

P.P.S. LPC2468 - LQFP208 в отличие от AT91SAM7SE512 - LQFP128, место млин.

[Diman_]

IMHO, большую роль в данном случае играют личные предпочтения. Мне лично LPC ну не нравятся и все, значительно приятнее с Atmel.

P.S. Про какие глюки SDRAM SE речь идет??? нашел только один с инициализацией или есче есть грабли???

P.P.S. LPC2468 - LQFP208 в отличие от AT91SAM7SE512 - LQFP128, место млин.

1. Полностью согласен с первым посылом и со вторым частично.
2.Про него родимого. Прошлой осенью при подключении k4s28 столкнулся с этим глюком, кстати так и недокументированым. Про выполнение инициализации SDRAM на портах тоже думал, но не рискнул на это пойти. Чуть позже стало известно о неработоспособности DMA из SDRAM на передачу, что вкупе с малым оъемом внутренней памяти тоже достаточно неприятно.
3.Есть такое, а учитывая расположенные "случайным" образом по всему периметру выводы внешней шины, можно забыть про двуслойку.

[zltigo]

Не во всем согласен с уважемым гуру. ИМХО SAM7S32-256 vs. LPC21xx-LPC22xx примерно равноценны, что-то лучше у первых, что то у вторых.

Так вот LPC21/22 это и есть LPC 4х летней давности - о выборе можно было серьезно думать.

Мне лично LPC ну не нравятся и все, значительно приятнее с Atmel.

Ненаказуемо , но свершенно не убедительно

[Diman_]

Так вот LPC21/22 это и есть LPC 4х летней давности - о выборе можно было серьезно думать.

Да, но чего то нового среди микроконтроллеров с малым формфактором (LQFP 48 - 64) не видно ни у тех ни у других, поэтому вопрос выбора между ними иногда попрежнему актуален.

[uriy]

Где все-таки взять USB бут для LPC2378. Может быть для LPC есть какой-нибудь сайт полезный подобный at91.com для atmel?

[SpiritDance]

Да, но чего то нового среди микроконтроллеров с малым формфактором (LQFP 48 - 64) не видно ни у тех ни у других, поэтому вопрос выбора между ними иногда попрежнему актуален.

Хм.. если бы передо мной сейчас стоял такой выбор освоения... я бы выбрал stm32

[Dog Pawlowa]

3.Есть такое, а учитывая расположенные "случайным" образом по всему периметру выводы внешней шины, можно забыть про двуслойку.

А можно подробнее, во сколько слоев LPC2478+2 SDRAM + мелочи могут лечь?

[zltigo]

А чего тут думать трясти надо - два слоя работа, в лучшем случае, на грани фола, больше 4х - пижонство.

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

Смотря что, какой разрядности и в каком количестве на эту шину вешать. Например, одинокая 16bit RAM укладывается с обратной стороны платы под корпус контроллера без напрягов. FPGA на 8bit шине тоже не смертельный номер. Ну а если, конечно навешать всего,чего только можно на 32bit, то, смотри выше...

[Diman_]

А можно подробнее, во сколько слоев LPC2478+2 SDRAM + мелочи могут лечь?

Разводкой еще не занимался, пока работаю с отладочной платой SK-LPC2478-SE StarterKit. Там LPC2478, SDRAM 16-bit, NAND, FPGA-16bit вполне изящно, может слегка плотновато разведены по четырем слоям, насколько я могу разглядеть. Кстати SAM-SE в почти такой же конфигурации (FPGA-8bit), не то чтобы влет и красиво, но не думаю что "на грани фола", развелся по двум слоям.

[zltigo]

...но не думаю что "на грани фола", развелся по двум слоям.

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

[aaarrr]

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

ИМХО, хуже: даже будучи хорошо вооруженным, проверить досконально все не получится. Всегда остается вероятность, что при некотором стечении обстаятельств случится бяка.

[zltigo]

Всегда остается вероятность, что при некотором стечении обстаятельств случится бяка.

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

[Dog Pawlowa]

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

Мы про какие два слоя говорим? -
Только два сигнальных? Или два сигнальных плюс два питания?

[aaarrr]

Только два сигнальных, естественно.

[zltigo]

Мы про какие два слоя говорим? -

Естественно, про ОБЩЕЕ количество . А то рассуждая о выделенных слоях под питания и земли для какой-нибудь по нынешнми временам вполне обычной FPGA можно ооочень глубоко зарыться в слои .

Только два сигнальных, естественно.

C Выделенными земляными уже можно и думать, и моделировать и на опыт опираться... А вот без них совсем шаманство

[aaarrr]

Да, выразился неудачно Имелось в виду общее количество, разумеется.

[Dog Pawlowa]

Естественно, про ОБЩЕЕ количество . А то рассуждая о выделенных слоях под питания и земли для какой-нибудь по нынешнми временам вполне обычной FPGA можно ооочень глубоко зарыться в слои .

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

[zltigo]

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

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

[uriy]

Повторяю свой вопрос!
Где взять бут для LPC2378 работающий через USB?
Тут много любителей LPC, неужели вы не знаете где можно его достать.

[zltigo]

Повторяю свой вопрос!

А к чему это здесь? Да и еще повторять?

Где взять бут для LPC2378 работающий через USB?

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

[uriy]

Опять минус LPC, они даже не удосужились модифицировать этот бут для новых серий контроллеров.

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

Это единственная причина не работающего бута на LPC23XX?. Теперь еще и придется читать манул на LPC21XX и сравнивать. Откуда мне, начинающему с контроллерами LPC знать что там менять. NXP даже лень создать какой-нибудь Migration для модификации бута. Я был лучшего мнения о них. На рассыпуху у них документация хорошая. А тут полный бардак.

[zltigo]

Теперь еще и придется читать манул на LPC21XX и сравнивать.

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

Откуда мне, начинающему с контроллерами LPC знать....

Так Вы хотите стать не начинающим? Тогда придется узнавать много нового , ну а если только поговорить на тему "как сделать так, что-бы ничего не делать", то для этого на форуме есть специальный раздел.

А тут полный бардак.

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

[aaarrr]

Мануалы хорошие - мусора мало

Вот где количество мусора запредельное, так это в Атмеловских даташитах на AVR'ки. Когда они добавили примеры работы в описание периферии, пользоваться мануалом стало ну очень неудобно

[KRS]

А мне вот в LPC нравится что таймеры 32 битные еще и с прескалером 32 битным! и PWM контроллер тоже. Мелочь конечно, но приятно
У Атмела конечно PDC очень прост в использовании, но зато у переферии вообще нет фифо! что очень неудобно. и приходится использвать PDC буквально на пару байтов.

[zltigo]

Вот где количество мусора...

Ну, дык, я о том-же, правда у AVR это еще усугубляется подходом "делаем,думаем,переделываем".
Тут относительно недавно "все в одном и больше ничего знать не желаю" на одну из самых правильных TI MSP430 документаций (вот где вопрос типа, "а чем конкретно отличается железо LPC23 и LPC214" решился-бы пулей) наезжали. Душераздерающее зрелище.

[aaarrr]

У Атмела конечно PDC очень прост в использовании, но зато у переферии вообще нет фифо! что очень неудобно. и приходится использвать PDC буквально на пару байтов.

Зато у NXP маразматичные UART'ы в духе '550. FIFO есть, зато нет возможности прочитать его текущий уровень. И возможности управления драйвером RS485 нет. Хотя в другом их продукте (весьма, кстати, замечательном) - SC16IS762 - все это предусмотрено.

[zltigo]

Зато у NXP маразматичные UART'ы в духе '550

Не в духе, а в миимальном варианте они и есть. Классика, есть курутонавороченнее, но и IBM PC и NXP вполне работоспособны . В свежих чипах добален и ряд наворотов в частности и аппаратный flow control.

[aaarrr]

Но ведь можно же сделать нормальный продукт, даже не ломаю "классику", и IS16SC762 тому пример.

[zltigo]

Но ведь можно же сделать нормальный продукт, даже не ломаю "классику"...

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

[aaarrr]

Я не впадаю в депрессию, меня лишь удивляет бездумное копирование устаревших и неоптимальных решений в современных продуктах, точнее, только одного решения. И созданием похожих на '550 UART'ов, порой даже абсолютно не совместимых с оригиналом, грешит не только NXP.

[zltigo]

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

Во! Ну для начала, пожалуй, не стоит-ли задать себе вопрос об использовании в "современных продуктах" UART/RS485 . Лично у меня его использование закончилось во времена XT/AT286 с теми самыми еще 8250 ну и 8251 в периферии (причем без неразрешенных проблем!). Ну а классическому использованию 82550/LPC претензии-то есть?

[aaarrr]

Во! Ну для начала, пожалуй, не стоит-ли задать себе вопрос об использовании в "современных продуктах" UART/RS485 .

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

Лично у меня его использование закончилось во времена XT/AT286 с теми самыми еще 8250 ну и 8251 в периферии (причем без неразрешенных проблем!). Ну а классическому использованию 82550/LPC претензии-то есть?

Дык я тоже не изобретаю велосипед. Но мои эстетические чуства все же страдают, когда я встречаю очередной 550.

[zltigo]

От RS485 еще очень долго никто не откажется.

RS232, пожалуй, "вечен" а вот вариации.. Я, например, отказался от RS485 (и отнюдь не по причине засилья 550 ). Просто массовые кабели под LAN или даже телефонные четырехпроводные стоят неприлично дешево, а канал хочется все побольше и побольше .... Посему, RS422 еще как-то используется в простейших применениях, ну а вообще меня много-много больше волнует (и не только с эстетической точки зрения) качество CAN, Еthernet, USB, SPI, SPORT,...

[aaarrr]

У меня, к сожалению, специфика продуктов - промышленная автоматика - не позволяет отказаться от RS485.

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

[zltigo]

..выделяется этакий безобразный прыщ

Ну явно демонизируете мелкую проблему. Вот, например, что делать если у контроллера вообще нет изохронного режима USB, или эндпойнтов по минимуму, или в Ethernet контроллер по производительности уперлись - это проблема.

[aaarrr]

Я не демонизирую, а добросовестно не понимаю, что побуждает производителя делать так

И не такая уж это и мелкая проблема: попробуйте на классическом 550 управлять драйвером RS485. Будет очень криво.

А они, понимаете ли, flow-control аппаратный добавляют...

[zltigo]

И не такая уж это и мелкая проблема: попробуйте на классическом 550 управлять драйвером RS485.

Я уже писал,что занимался такой реализацией на PC и еще жив. И другие тоже успешно решали и решают. Проблема решаема.

А они, понимаете ли, flow-control аппаратный добавляют...

Правильно. Вот это надежно без резкого падения скорости софтом решить невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы. А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании. И подстройка бодов под почти любой кварц (тот-же USB 12MHz) эта та проблема которую никак не решить, если подстройки нет. Ее в свежих чипах и добавили. C тем-же некошерным с точки зрения UART 12MHz/произвольным кварцем проблемы работы bootloader на высоких скоростях - тоже не решаемая проблема, если производитель ее не решит. Ее решили.

[aaarrr]

Я уже писал,что занимался такой реализацией на PC и еще жив. И другие тоже успешно решали и решают. Проблема решаема.

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

Правильно. Вот это надежно без резкого падения скорости невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы.

Результаты работы с аппаратным управлением потоком под виндой дали обратные результаты - для надежной работы нужен большой софтварный FIFO, т.к. после выставления RTS может свалиться еще байт 20-60. Trigger level у меня использовался 64, с меньшим были проблемы. А Auto-RTS пришлось выкинуть за бесполезностью.

А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании.

RS485 может быть и 20 мбит/с.

[zltigo]

Результаты работы с аппаратным управлением потоком под виндой...

Для связи с Виндой в общем случае это глухой номер, именно по причине отсутствия железной поддержки со стороны PC железа усугубляемой зачастую и большей глубиной TX FIFO (у меня, например мультипортовки по 128-256 байт). Это, увы, уже только для раскочегаривания канала между контроллерами.

RS485 может быть и 20 мбит/с.

Естественно, я эти приемопередатчики на синхронных 2-4-8-16 мегабитах широко пользую, вопрос на каких скоростях Вы работаете в симплексе со своим промышленным RS485 оборудованием ?

А в программе это таймер...

Ну или обработка эха, или второй UART, или...

и дополнительные тормоза.

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

[aaarrr]

Для связи с Виндой в общем случае это глухой номер, именно по причине отсутствия железной поддержки со стороны PC железа усугубляемой зачастую и большей глубиной TX FIFO (у меня, например мультипортовки по 128-256 байт). Это, увы, уже только для раскочегаривания канала между контроллерами.

Ну вот, а часто ли Вам нужен канал между контроллерами с управлением потоком?

Естественно, я эти приемопередатчики на синхронных 2-4-8-16 мегабитах широко пользую, вопрос на каких скоростях Вы работаете в симплексе со своим промышленным RS485 оборудованием ?

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

Ну или обработка эха, или второй UART, или...

Или еще что-нибудь в этом роде - ПЛИСка там внешняя, например. Удобно?

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

На 115.2 килобит уже не совсем символические.

[zltigo]

Ну вот, а часто ли Вам нужен канал между контроллерами с управлением потоком?

Не пользовал, но почему-бы и нет? Тот-же RS422, банальный 4x2 витой кабель и простейший, но мегабитный межблочный канал готов.

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

Вот только нафиг там RS485, а не TTL/RS422/....

Удобно?

Нот. Но не не слишком и хлопотно во многих случаях можно поступить, например, при работе без parity или с менее, чем 8bit подключаем TX одного имеющихся в избытке UART прямо к управлению предатчиком и запихнув в него нолик с нулевой parity получаем желаемое управление без потери, возможно, нужного таймера. Есть более удобные железки - есть! Есть UART железо максимально приближающееся к идеалу - есть! (у Am186, например). Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

На 115.2 килобит уже не совсем символические.

Повторяю вопросы - на каких скоростях работает существующее промышленное оборудование и зачем закладывать RS485 в новое? "Громадность" затрат я представляю более, чем хорошо.

[aaarrr]

Вот только нафиг там RS485, а не TTL/RS422/....

Дык межблочный, один мастер - N слейвов. Рядом килоамперы разрываются.

...имеющихся в избытке UART

Не имелись они в избытке до последних времен.

Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

Я разве это предлагал? Но учитывать эту особенность приходится.

Повторяю вопросы - на каких скоростях работает существующее промышленное оборудование и зачем закладывать RS485 в новое? "Громадность" затрат я представляю более, чем хорошо.

1. 19200, 115200.
2. Оборудование не только мое, так что от RS485 никуда не деться.

[zltigo]

Дык межблочный, один мастер - N слейвов.

Ну так - RS422, все сидят слушают мастера. Получив свой адрес подключает передатчик и вперед. Получив не свой адрес - отключает. Линия приема мастера почти всегда хорошо подтянута одним из передатчиков- меньше помех.

Но учитывать эту особенность приходится.

Ну дык, естественно, приходится.

[aaarrr]

Ну так - RS422, все сидят слушают мастера. Получив свой адрес подключает передатчик и вперед. Получив не свой адрес - отключает. Линия приема мастера почти всегда хорошо подтянута одним из передатчиков- меньше помех.

Работа идет в стиле запрос-ответ. В результате получаем практически тот же 485, только проводов больше.

[zltigo]

В результате получаем практически тот же 485, только проводов больше.

Ну а что еще из 485/422 красивого в случае шины сделаешь
Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы.
Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,...
Все это по здравому размышлению приводит к малоцелесообразности использования RS485, там где это не навязано внешними неподвласными факторами.

[aaarrr]

Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы.

Проблема не в проводах, а в разъемах и месте в них.

Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,...

Дуплекс мне даром не нужен. В оличие от RS485 экстренно передающий слейв в RS422 не увидит конфликта на шине с другим.

[zltigo]

Дуплекс мне даром не нужен.

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

В оличие от RS485 экстренно передающий слейв в RS422 не увидит конфликта на шине с другим.

Его увидет master и аккуратно заткнув текущего спросит "ну кто там хотел экстренно столько-то времени тому назад передать". Вообще-то если, как мне показалось,мы уже ведем разговор о своем оборудовании, то... то CAN, а не пляски с двумя проводами RS485 смотрятся много более уместно.

Проблема не в проводах, а в разъемах и месте в них.

Мы вроде уже до разговора о межблочных связей, причем в своем оборудовании, докатились? А блок, по крайней мере в моем понятии, штука большая, c солидной начинкой, со своим питанием... Какое такое "место в разьеме"?
P.S.
Может в теме обсудим более суровую периферию чипов поминаемых в топике произволителей? А то ведь, действительно докатимся до споров об оттенках черного у корпусов .

[aaarrr]

Так, докатились до CAN'а Скажите, а зачем я должен отказываться от RS485? Из-за наличия у используемого мной контроллера поддержки CAN'а?
Но это уже даже больший маразм, чем:

Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

Ибо уровень решения и объем последствий несоразмерен.

CAN меня не устраивает по причине очень уж короткого поля данных.

P.S.
Может в теме обсудим более суровую периферию чипов поминаемых в топике произволителей? А то ведь, действительно докатимся до споров об оттенках черного у корпусов .

Давайте. Только вот действительно суровой периферии у них нет практически.

[zltigo]

CAN меня не устраивает по причине очень уж короткого поля данных.

По большому счету у 485 оно вообще байт - все остальное уже протоколы верхнего уровня.Тем не менее все устраивает .

Давайте. Только вот действительно суровой периферии у них нет практически.

Неожиданное утверждение. Пожалуй тогда не буду продолжать разговоры - хватит мне UARTа.

[aaarrr]

По большому счету у 485 оно вообще байт - все остальное уже протоколы верхнего уровня.Тем не менее все устраивает .

Рад за Вас. Меня, скажем так, устраивает почти все, но это можно пережить

Неожиданное утверждение. Пожалуй тогда не буду продолжать разговоры - хватит мне UARTа.

Обсуждать действительно почти нечего: EMAC, USB, архитектура подсистемы памяти и т.п. у Atmel'а объективно хуже, чем аналогичные модули современных NXP. Хотя вполне работоспособны.

[Diman_]

Если вернуться к теме топика, то имею сказать следующее :
Продукты атмела не АВР использовать можно только после предварительной обкатки на всевозможные глюки периферии, про которые не вы, не ерата ничего не знаете. Последняя никогда так и не узнает. Вы старательно читаете даташит, не упускаете и ерату, изготавливаете плату а потом начинаете биться с недокументированными багами (те на которые я наступил: SDRAM от samsung и sam7SE512, SSC и передача последнего бита). И если вы думаете, что атмел выпустит ревизию чипа с исправленными багами, то вы ошибаетесь - их инженеры торопятся выпустить новых уродцев не пытаясь лечить старых. И как после этого можно обсуждать преимущества их периферии если при этом она может работать не так как написано в документации.
С тех пор у меня отвращение к атмелу.

PS: Может пост получился совсем мрачным - просто накипело (четыре месяца работы в трубу).

[aaarrr]

SSC и передача последнего бита

Можете поподробнее описать глюк?

С тех пор у меня отвращение к атмелу.

Глюки бывают у всех производителей, в том числе и у NXP. Заносят в еррату и исправляют неохотно тоже все.

[SpiritDance]

Заносят в еррату и исправляют неохотно тоже все.

Не скажите. NXP вроде правит. А ST например (судя по докам на str9 например) вобще молодцы. Атмел в этом смысле не правит пчти ничего. WDT вот в Sках 7ых подправили, остальное вроде так и осталось. Хотя не с атмелом вплотную не общался может чего не знаю.

[Diman_]

Можете поподробнее описать глюк?

Цеплял кодек к этому интерфейсу все было более менее нормально, а когда им же попытался грузить альтеру выяснилось, что при передаче в режиме мастера последний бит всегда равен нулю, хоть тресни ( камень sam7s256). На звук это не влияло почти никак. Подозреваю что глюк перекачевал во все их последующие кристаллы.

Глюки бывают у всех производителей, в том числе и у NXP. Заносят в еррату и исправляют неохотно тоже все.

Тут позвольте не согласиться - у NXP ревизии камней выходят, чего не скажешь про атмел (где исправленный rm9200, sam7Sxx, sam7se и тп)?

[vmp]

Цеплял кодек к этому интерфейсу все было более менее нормально, а когда им же попытался грузить альтеру выяснилось, что при передаче в режиме мастера последний бит всегда равен нулю, хоть тресни ( камень sam7s256). На звук это не влияло почти никак. Подозреваю что глюк перекачевал во все их последующие кристаллы.

А вот тут я с вами не соглашусь. Уже в нескольких своих устройствах прекрасно гружу Альтеру (Циклоны-2,3, ArriaGX) именно sam7s256. Никаких проблем не было.

[GetSmart]

У NXP последние полгода или уже год как подорожали процы. Слишком много багов фиксят?

[aaarrr]

Тут позвольте не согласиться - у NXP ревизии камней выходят, чего не скажешь про атмел (где исправленный rm9200, sam7Sxx, sam7se и тп)?

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

[uriy]

А вот похоже и плюсы со стороны LPC. Я правильно поянл что у LPC23xx выводы UART продублированы на несколько портов. Например TXD1 и RXD1 встречаются дважды. Значит можно из UART1 получить сразу два UART если они не будут работать одновременно? Что произойдет если я назначу TXD1 на два GPIO. Вроде защиты от этого в контроллере не предусмотрено.

[Dog Pawlowa]

Значит можно из UART1 получить сразу два UART если они не будут работать одновременно?

"Месье знает толк в извращениях"

[VslavX]

Еще из плюсов - UART в LPC23xx еще поддерживает дробный делитель для генератора baudrate. Я уже опробовал - весчь.
А вот GPDMA - слабоват - каналов мало, да и память не вся через него доступна. Если используется SD/MMC то один канал DMA надо отдать сразу, иначе читать из карточки очень некомфортно и еще дополнительно начинается геморрой из-за недоступности памяти - в общем случае приходится копировать данные из/в промежуточный буфер. Второй канал DMA желательно отдать USB, и все - DMA в LPC23xx на этом закончился. В моих изделиях идет массированный реалтаймовый обмен по SPI, пришлось второй DMA на него отдать, а вот контроллер USB c DMA обломался .