[porty 0]

Из STM32 или LPC в последнее время всё чаще выбираю ПЛИС. Потому что и у STM32 и у LPC есть такая штука как ограничения на использование переферии, и там и там возникает такая ситуация что либо PWM не хватает критически или АЦП либо шумит либо имеет дурацкие ограничения, либо активируя одни блоки блокируешь другие блоки, например SSP и I2S перекрываются, аналогично в STM32. Из за специфики задач (цифра в режиме реального времени порой до 20-50мегагерц десятками каналов) всё проще использовать ПЛИС, даже если можно тоже самое применить на DMA v ARM. И ещё что у плис проще - как тебе надо так и разместил выводы и тем самым можно уместить на двухслойную плату в 0.2кв дм всё что нужно.

[MK2 0]

ПЛИС хорошая штука стоит только дорого... ну очень дорого. тем более ацп там внешний приходится вешать (внутреннего нету ). А выводы удобно конечно, но цена решает слишком многое

[amater 0]

Без холиваров жизнь скучна.

 

Я года 3 назад выбрал LPC. Сначала на LPC2368 делал потом перементнулся на LPC1768.

Выбор был из-за разнице в цене в 2 раза для сопостовимых параметров.

 

Теперь встает вопрос с памятью, да и производительности мало не бывает. А сейчас похоже ST начал опережать LPC. При одинаковой цене заметно лучше параметры. У меня Ethernet и других задачь достаточно, что бы загрузить и по быстродействию и RAM и Flash. Что делать?

 

Надеюсь дождатся Zynq-7000, потому что все равно мне приходится с FPGA систему делать. Кстати на мой взгляд Zynq-7000 как раз и будет серебрянной пулей или dream-chip для меня. А для мелких проектов до сих пор 51 использую, потому что выгодно.

 

Изменено 9 октября, 2011 пользователем Аматер

[Axie 0]

Как раз нужно было что-то наподобие. Долго сравнивал, остановился на STM. Почему? Потому что:

1) У LPC пинауты - это просто кошмар какой-то. Логику и разум разработчиков я не наблюдаю. Ну вот присмотришь себе камень, вроде все при нем. А тут вдруг бац - нужная периферия оказывается взаимоисключающая. Нет, все бы ничего, но альтернативные функции пинов отличаются не меньшей [CENSORED], поэтому некоторые комбинации периферии не получится использовать совсем, хотя казалось бы лапок более чем хватает и периферия есть. Но [CENSORED] разработчиков вносит свою лепту. У STM же напротив все более-менее культурно. Может конечно мне так везло с задачами, но впечатление осталось вот такое вот. Тем более что ST старается не сильно переколбашивать пинауты, что им лишний раз в плюс.

2) Запись флеша. У LPC там черт знает что. Я так понял что NXP вообще постеснялись опубликовать как это делать с их контроллером флеша и вместо этого сватают какое-то свое горбатое API. Вот была мне охота с их глюками разбираться и вообще, а какие гарантии что это их супер-апи всегда впишется в мои требования к тому как и когда я хочу флеш шить? Зачем мне заранее загонять себя в неудобные рамки?

3) Номенклатура у STM32 весьма симпатичная. Вплоть до минимального Cortex M3 за аж целый $1. Что-то NXP таким не может похвастать.

 

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

Изменено 10 октября, 2011 пользователем IgorKossak
Цензурнее надо быть!

[ukpyr 0]

У STM же напротив все более-менее культурно

угу, особенно USB+CAN

[AltemirX 0]

Ребят, а если посмотреть за горизонт LPC и STM32? TI сейчас готовит некислую линейку с Cortex-M4 на борту. Через месяц обещают кит. Извините, что не в рамках темы... Но сам сижу на LPC и зажат в некоторые рамки из которых хотелось бы вырваться.

[dac 0]

Ребят, а если посмотреть за горизонт LPC и STM32? TI сейчас готовит некислую линейку с Cortex-M4 на борту. Через месяц обещают кит. Извините, что не в рамках темы... Но сам сижу на LPC и зажат в некоторые рамки из которых хотелось бы вырваться.

еще freescale обещают контроллер DRAM в старших чипах, а energymicro - микропотребление. а ти пусть пока с багами разбираются :)

но на мой взгляд у STM32 самая сбалансированная линейка М3, М4 причем сквозная совместимость, за исключением нескольких выводов, если это учесть при проектировании, можно ставить от STM32F100 до STM32F417

[ubit 0]

TI сейчас готовит некислую линейку с Cortex-M4 на борту. Через месяц обещают кит.

А я после нехилого пролета с TI перешел на LPC... Пролет был с LM3S9В9х - кит появился, начал делать на нем, даже несколько сэмплов удалось достать. А потом у них резко начала расти Errata (кстати, один Workaround я им подарил, они мне за это киты меняли:-)) и чипов стало не достать... Не выдержал, перетащил все на LPC. Да и подешевле они оказались.

[VslavX 0]

Работали с SAM7S/SE/X, LPC21/23/17, сейчас делаем проект на STM32F1xx,есть такие замечания:

- 16-битные таймеры (у LPC17 - 32-битные, используются в программах)

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

- разбитая на кусочки область хранения данных под батарейкой (два набора 16-битных backup регистров "несплошняком")

- два разных контроллера USB в семействе

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

- "сваренная из топора" периферийная библиотека, к тому же не всегда полезная даже как пример

- нет документации по замещению встроенного заводского загрузчика

- мутное описание ремапиннга пинов между периферийными блоками

А так - само по себе семейство STM32 неплохое, основные претензии у меня пока к документации.

 

[VslavX 0]

Добавлю еще 5 копеек - у STM очень странный роутинг запросов на DMA - каждый канал жестко привязан к своему набору периферии. И получается что каналов-то DMA много - аж 12, но например SPI1 и UART3 одновременно использовать DMA не могут, такой вот туповатый дизайн.

 

[scifi 1]

например SPI1 и UART3 одновременно использовать DMA не могут

... что не является проблемой для инженера, который прочитал даташит прежде, чем зафиксировал привязку сигналов к ножкам МК.

[VslavX 0]

... что не является проблемой для инженера, который прочитал даташит прежде, чем зафиксировал привязку сигналов к ножкам МК.

Даташит не поможет. Тут "Reference Manual" читать нужно, качество сего документа - так себе, "индийское".

И я всегда конструкторам давал некоторую свободу - вот мне нужен SPI, берите любой из имеющихся, тасуйте ножки исходя из топологии конкретной платы. Соответственно программные модули написаны так что работают с любым аналогичным блоком. И LPC тут позволял не особо задумываться - все блоки равноценны. А теперь надо вот для STM выполнять перекрестный анализ. Причем убогость архитектуры просто необъяснима - кто мешал ST матрицу/мультиплексор запросов DMA сделать? А OR всех запросов от источников - это сказка просто, биты управления получаются размазаны по нескольким периферийным модулям. Да у меня еще и тактирование модулей отключается - код шерстения этих всех регистров просто тупо раздувается.

 

[=F8= 0]

Добавлю еще 5 копеек - у STM очень странный роутинг запросов на DMA - каждый канал жестко привязан к своему набору периферии. И получается что каналов-то DMA много - аж 12, но например SPI1 и UART3 одновременно использовать DMA не могут, такой вот туповатый дизайн.

Что в сочетании с однобайтным буфером UARTа делает жизнь особенно приятной. У LPC никогда и не думал UART c DMA юзать, а в STM без этого никак...

[topkin 0]

Господа, вы уточняйте в каком из семейств STM32 вас не устраивает DMA контроллер. Все же DMA в семействах STM32F1xx, в STM32Lxx и особенно в STM32F2xx имеют довольно сильные различия. В последних семействах он стал куда более гибче и сложнее, я еще сам пока до конца не разобрался :) Проблемы с буфером не вижу в STM32F1x, контроллер позволяет организовывать кольцевые буферы глубиной до 65535

 

[VslavX 0]

Очередные 5 копеек.

ИМХО, DMA у STM32F1xx реально убог. Там что, про gather-scattering буферов не слышали? Дескрипторы и цепочки из них, спрашивается, где? Вот же ж, мне сейчас прийдется писать программную эмуляцию. Или я чего-то таки недопонял в "индийском" документе?