Спасибо за разъяснения, буду пробовать!

Добавлю, кое-что от себя. Достаточно близко познакомился с LPC. Посидел пару дней с Atmel SAM3X. STM не трогал. Меня НЕ интересует ни цена, ни скорострельность, ни многое еще чего. Меня интересует целостный дезайн, сопровождение/поддержка разработчика и прочие, тому подобные, мелочи.
Начну с СЭМа. Какое удовольствие я получал от него...целых 2 дня, пока не стал исследовать TWI(I2C). Ну чем они думали??? Все направлено на то, чтобы все было сделано за тебя, даже если тебе это не надо или вообще не устраивает! Пример: NACK от slave вызывае АВТОМАТИЧЕСКИЙ STOP от мастера. Представьте себе настолько умный автомобиль, который сам останавливается на красный свет! Даже если у вас есть веские причины поступить иначе... Короче, я закрыл СЭМа, а жалко.
К LPC у меня масса претензий, ну кроме I2C, классика, как было замечено выше. Таймер только таймер, PWM с ним не выйдет без прерываний, несмотря на то, что есть matching pins. UART и CAN: NXP "изобрел" прерывания по фронту!Привожу заключение моей переписки со службой поддержки

Комментарии излишни...

Добавлю еще один недостаток: качество кода, примеров, знание принципов программирования, языка С отавляет, мягко говоря, желать...Понятия bit-field, enum NXP незнакомы, количество "magic number" зашкаливает... Простие меня электрики, но это ваш стиль. Другими словами, софтвер НЕПРОФЕССИОНАЛЕН!
Да, и вайла описания битое у NXP нет! У Atmel с этим серьезных проблем не обнаружил.

Был бы рад подобной информации о STM и TI...
Спасибо.

Я скорее на стороне производителя, есть реалии - не он делает железо под наши программы, а мы пишем программы под его железо.

- А Вы сексом заниматься любите?
- Да, конечно! Особенно стоя и в гамаке!

Есть и другой вариант...
Скупите вы этот ненавистный NXP... целиком и полностью... и на правах хозяина диктуйте свои правила...
ИМХО... ситуация напоминает "все шагают не в ногу, только товарищ прапорщик"...

Ужос-то какой! Гадский NXP не написал хидеры в приятном Вам стиле.
Если микроконтроллер берется в разработку плотно и надолго (на несколько проектов/серию, не для "халтурки"), то хидеры вообще-то желательно написать полностью "под себя" самому. Внести свою систему обзывания регистров, битов в регистрах, размещения определений в секциях, учесть особенности компилятора(-ов). Попутно, создавая хидер, внимательно прочесть документацию (когда обзываешь биты - так или иначе читаешь за что они отвечают и как работают) и получить более-менее полное представление об аппаратуре. Для начала можно описывать не все блоки - а только нужные, и потом расширять хидер по мере освоения новых блоков. Угу, это сначала долго, требует кропотливого труда, но потом проблем сильно меньше обычно и при наличии в работе полудюжины архитектур мозгам потом сильно проще работать в едином, собственноручно созданном формате.
ИМХО, если компания/разработчик профессионалы (опытные, уже занимается софтом для контроллеров некоторое время), то обычно есть свои наработки в виде выбранной RTOS, стеков USB/TCP и прочего, и от контроллера требуется только соответствовать заявленным техническим характеристикам, и иметь более-менее удобоваримую документацию. На софтовый мусор, предлагаемый производителями, как правило можно не смотреть - это для хомячков, глючное, непортируемое, часто с лицензионными ограничениями.

Переход на ARM ядро у меня и было обусловлено, тем что в глаза бросился STM32. Низкая цена, доступность средств разработки. Изучение заняло неделю + неделя на портирование текущих проектов. Atmel нервно курит со своими подходами (Про NXP к сожалению не скажу). А удобство программирования на лицо. Взаимозаменяемость чипов+четкая логика в наборе интерфейсов и возможностей для каждой градации контроллеров.

Желаю всяческих успехов в переписывании всех и вся! И не жалейте времени...

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

PS: Работал (т.е. делал реальные проекты, а не игрался с отладками) с мк атмела, nxp и stm. Самые приятные ощущения от nxp.

Не вижу смысла в переписывании заголовочных файлов. К примеру, в stm32f2xx.h все регистры и биты описаны, близко к техническому руководству, зачем же их "обзывать" иначе? Другое дело - дополнить чем-то... Лучше пройтись по этому заголовку, глядишь, на умное решение натолкнешься...

ИМХО, готовые хидеры тоже как бы имеют право на жизнь. Тогда разработчик их принимает "как есть", не парится насчет их формата и не устраивает "хомячковых драм онлайн" типа "гадский разработчик не знает про битовые поля".
С другой стороны, если есть уже куча своего софта, уже отлаженного и вылизанного, портируемого на разные чипы, и все уже разложено по полочкам - то почему бы новый контроллер не встроить в эту систему полочек.
Это как штаны - можно открыть шкаф и бросить комом, а можно аккуратно сложить и положить на полку (или даже повесить на вешалку). Результат то один - штаны в шкафу, вот только слегка по-разному они там лежат.
Собственно писать свои хидеры недолго, у меня основное время тратится на чтение документации и вникание в нее. Новополученная информация закрепляется еще и в письменном виде - такая вот особенность со студенческих лет у меня - при подготовке к экзаменам исписывал еще бумаги в 2-3 раза больше чем объем конспекта. Поэтому лично для меня переписывание хидеров достаточно полезно - дальше работать с контроллером мне проще. Ну и удовольствие от того, что "мои штаны аккуратно висят на вешалке". (Не, в реальном шкафу джинсы таки часто комом )
И еще момент. Софт-то усложняется и усложняется. Сотни тысяч сишных строк. И если постоянно "пихать штаны комом" то в шкафу появляется неряшливая куча, которую может оказаться достаточно тяжело разгребать.

+1. Сам так же делаю. Время написания своих хедеров пренебрежимо мало по сравнению с остальными этапами разработки. Кстати, устраняется зависимость от компилятора (keil/iar/...). Ну и эстетический эффект немаловажен: иногда чужие хедеры вызывают омерзение.

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

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

+1 в пользу NXP - LPC17 - основной процессор для серийных проектов
+1 в пользу KINETIS - хороший набор периферии при малопотребляющем ядре M0, много режимов сна с огромными возможностями по выхода.

-1 против STM32 - кто пользуется CMSIS начнут защищать что это упрощает/ускоряет разработку - IMHO забивает голову, раздувает код, снижает производительность - один раз попробовал - впечатления ужасные.

А вы, случаем, CMSIS с SPL не перепутали??? ))))

Дык... "один раз" - ещё не... эксперт по STM32...

Я сейчас смирился с хедерами. Там того HALа с гулькин нос... Ну в 500 строчек попаду, ну в 1000 - максимум. Хотя, желание потихоньку рихтовать хедеры осталось.

Тем более, что по рукам за это никто и не бьёт... а в случае с STM32F0XX... там явно придётся ручёнки шаловливые приложить...

1. CMSIS есть и для LPC.
2. Никто не заставляет пользоваться CMSIS применительно к STM32. Я, например, не пользуюсь и более чем доволен (имеется в виду STM32).

Тут следует, наверное, уточнить, что CMSIS определяет поддержку ядра, и определяет поддержку периферии.
Те макросы и функции что относятся к ядру наверное использовать следует, так как они распространяются на ВСЕ Cortex-M3 а также скорее всего пригодны и для M4 и для M0.

А вот поддержка перифирии, да она у NXP не идеальна, код местами написан кривовато, тем не менее всё тщательно задоксигенено и примеры и библиотека.

Еще пару слов об NXP ибо в рабочей обстановке имел дело только с ними. В своё время выбор был сделан в пользу LPC2478 ибо такой комбайн из периферии был только у голландцев.
Периферия у них неплохая UART сделан аля '550, SPI имеет поддержку DMA, I2C ясное дело сделано лучше всех так как это детище Philips-а(как и компакт диски ).

Разработчики стараются соблюсти наследсвенность, совместимость софта. Начиная с LPC2101...03 заканчивая LPC23xx 24xx.
При переходе на Cortex-M3 -- были сохранены многие модули почти неизменёнными или доработанными чуть-чуть. Поэтому LPC23xx--LPC176x,175x а LPC24xx -- LPC177x. Другое дело что не во всех случаях эта совместимость приятна и радует. Благодоря этой совместимости мне удалось примеры (UART, USB HOST) для LPC176x запустить на LPC2468, чему и посвящен мой проект
USB device правда пока у меня не запустился. (

Не совсем понимаю как CMSIS раздувает код. Я оттуда пользуюсь определениями, и, на мой взгляд, удобно. Библиотеки тоже не все свои пишу. То что вызывается единожды - типа инициализации PLL, кое-какие настройки часов ещё мелочь, я оставил. Ту переферию, что используется во всём проекте, а не только при инициализации - полностью переписал. Тем более, что жизнь заставляет. Всё равно стандартными библиотеками пользоваться невозможно. Даже если плюнуть на то, что они избыточны и раздуты.
Во вторых сложно говорить о "раздувании кода", когда минимум на кристалле 512к. Его ещё заполнить надо... ))
Некоторые вещи понравились у NXP. Вполне их можно оттуда и перетянуть. С другой стороны есть очень сильные стороны у STM.
1. Упоминалось уже - совместимость по ногам. + конструктор который они предлагают. Очень удобная фича. Достаточно сказать, что как правило развития у NXP просто нет. Применили 1764 - ну 1765 можно поставить. И то ... Применил я stm32f103 (в 100 ножном)- могу поставить и 207 и 405, и 100 и f0 из последних. Да там есть некоторые вопросы по периферии, но почти все решаемы. Это десятки кристаллов с разной периферией и разными объёмами FLASH/RAM. Ну очень удобно. Так в текущем проекте я применил 407. Отлаживаю. В последствии думаю выпустить урезанную версию прибора без Ethernet на 103. Задействованы почти все ноги, а всего то придётся только один SPI программный сделать и как-то выкрутится с выходом калибратора часов. 207 так вообще один к одному. Результирующий проект перекомпилю, если всё OK, то на нём и выпускаться будет полная версия.
1.1. Хорошо продуманная совместимость по периферии... Мне понравилось больше чем в NXP. Особенно в старших моделях. Там на одну ногу до 7 ф-ций альтернативных выкатывается. Почти любой вариант раскладки прокатывает. Очень большое количество периферии куча таймеров USART и прочее. И очень хорошо совмещаются друг с другом. При грамотном написании библиотек - просто молодцы.
2. С периферией всё в принципе не плохо. Слегка ADC перекручен. А так всё неплохо. I2C запустили и в мастере и в слэйве. Да есть там некоторые нюансы. Например мультимастер неотключаемый. То есть если SLAVE не обработает подтверждение, то мастер отвалится без спроса - потеря шины. Ну и немного они намутили в SLAVE. Короче надо вводить мультимастер и всё работает.
Зато есть бонус. ST по крайней мере принимает критику и пытается улучшать и развивать периферию. Например RTC в 103 так убого сделаны ... И вот в 20x/40x - вполне прилично. А с учётом хранения данных от часов - ещё и пендаль для NXP. В NXP 4 регистра... Чаще всего этого мало. В ST их помоему 11 (по памяти не помню) + в старших камнях кусок ОЗУ. В NXP тоже есть такие камни, но это некоторые камни, а здесь все старшие ... Разница однако ... А посмотрите какой убогий CAN у NXP. И они его благополучно перетащили на CM3. Я специально смотрел. Например SAE J1939 аппаратно невозможно. Нужна маска, а у них коридор. A ST позволяет и так и так. Единственное, что конечно является бестселером это контроллер TFT. Здесь 2478/1788/1850 рулят. Альтернативы у ST нет.
3. Ну и цена - достовабельность не последние вещи. Понравилось мне и качество/ надёжность/ устойчивось. Пусть и субъективно, но всё таки осталось хорошее ощущение ... Нет непоняток... Хорошо отлаживается ...
---
Короче посовокупности мне больше stm нравится.
KINETIS хорош безусловно. Понравилась аппаратная обработка сенсорных кнопок, АЦП/ ЦАП ... Но всётаки дорог ... Да и семейство пока ещё .... Короче немного задержались они с выходом ...

Тут Вы слегка погорячились, 100-ножечных f0 пока нет и не предвидятся, но основная мысль понятна.

То есть в автомобильные приложения не годится?
О какой конкретно серии речь? CAN вреде разный на разных семействах?


А все сообщения не получится обрабатываться на предмет их совпадения с небольшим списком интересующих?

ИМХО, не все там так гладко. По софту с LPC1768 на LPC1788 переходится довольно коряво. Куча мелких не бросающихся в глаза изменений. Регистры потасовали, GPIO настраивается по-другому, тактирование другое и еще всякое. При переходе 1768->1788 разочаровался - ожидался мгновенный запуск, а пришлось таки повозиться.
У ST32F2xx однозначно лучше Ethernet контроллер (тут в этой ветке про это писал уже, на сегодня плюшки все опробованы практически - реально вкусные). А вот USB device у STM32F2xx довольно самобытные. Первый раз такое вижу - все принимаемые пакеты валят в одно FIFO, с вытекающими последствиями, когда надо выполнить SET FEATURE STALL например (и есть у меня некоторое подозрение что в ST-шной библиотеке код написан для этой функции не очень верно). Прикручивал USB-device Intel/Samsung/Atmel/Freescale/NXP - везде конечные точки отдельные, со своими независимыми FIFO. Про хост вообще молчу - тоже самобытное извращение вместо стандартных OHCI/EHCI. Там вообще, похоже USB куплен у Синопсиса в виде IP-модуля и прикручен с далеко не косметическими швами (модуль походу 64-битным выглядит). Документация тоже явно патчилась с готовой - много незаимплеменченого выкинуто, но пара непонятных/нерабочих битов в документации осталась. Еще SPI у STM32 помедленнее - без DMA (не подходит DMA - надо в потоке принятые данные анализировать) тормозит, не получается без пропусков его загрузить в режиме поллинга. У LPC там FIFO было встроенное в SSP, шустро работало - пока анализируем очередной байт, SPI работает параллельно.

Сейчас Атмел еще "поднимает голову". Из Cortex-M3 у них SAM3X интересный - SDRAM контроллер, Ethernet (старый, правда, без плюшек), USB HS (трансивер на борту). Но традиционно - питание наружу торчит в двух уровнях (оно с SAM7 все так тянется - цоколевка такая же у новых серий). Еще пугают новым комбайном - SAM4E - где будет "все-все-все". Поживем - увидим.

Freescale делает свои камни на М4 и все-таки вы имели ввиду SPL.
Последний конечно не везде радует, но инициилизацией обойтись можно

Вот что-то не получается "прочувствовать", скорее - наоборот, так "продумано", что постоянно не хватает нескольких нужных ног, думал в 100+ корпусах попустит - куда там! Все те же грабли, главным образом из-за того, что стратегически важный АЦП висит на не менее стратегических по функциям пинах. Беда...

Может все дело в прокладке, а не в руле?
Атмел последнее время все чаще стал мелькать перед глазами. Правда после смены SAM7 на LPC2x нет веры в него, что касается армов конечно...

Глубокомысленно.. Не подскажете, где разрулить MII + ADC 16 каналов из обозначенных 24? 144 ноги не помогают.

Всегда хочется чего-то большего. Если Ethernet включаешь или контролер SDRAM (LCD), то отрубается куча ног. Конечно не есть хорошо, но как без этого? Этож не система на кристалле. Мыж в сравнении. У NXP при таком раскладе тоже всё не лучшим образом абстоит.

Все это так, но если ST сделали по мультиплексору 16:1 на ножках, что им стоило сделать это на всех I/O ?
Оно же места в кристалле много не занимает, а у них на куч ножек и половины нет!
Конечно это еще надо оттрассировать в кристалле, но неужели это сложнее ядра, FPU/MPU/DSP и всей периферии?
И есть вещи, которые просто бесят - например использование некоторых функций вообще только на одной ножке, без альтернативы, что сразу отменяет совместное использование двух периферий в полном обьеме.
Ну ладно еще, когда речь идет о многоногих интерфйсах типа MII, ULPI, LCD/ExtMem, но например - внешнее тактирование I2S сразу отменяет 4-х битный режим SDIO, потому что вход тактовой только один, и совмещен с D1 SDIO, ни тому ни тому альтернативы нет, и таких примеров много.

не только, даже у stdlib ужасный код. Посмотрите на листинг memset/memcpy и т.д. - каждая функция под несколько сотен байт. Для чипа с 512К Flash может и приемлемо, но для STM32F100C4 пришлось переписать.

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


Ну если размер кода совсем критичен, то такой вариант вполне возможен.

+1. У кейла на этот случай есть опция microlib. Может быть, ничего переписывать тогда и не пришлось бы.

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

Возвращаясь к основному вопросу - LPC(17 и 18-серии) или STM32(Х серии)?
Выбираем под новый проект проц., хотел бы спросить:
1. какой максимальной скорости по SPI могут достигать аппоненты (60Мгц-SPI CLK)?
2. По итогам выбора п.1. - Насколько просто/сложно будет реализовать поддержку USB (HOST), у кого больше ресурсов для этого?

P.S. Может кто слышал про 18Х серию NXP с 1МБ флешкой на борту - когда предположительно появятся?

Прошу помощи, заранее благодарен.

USB билиотека с разными классами девайсов и хостов есть у STM32, применял неоднократно, очень доволен. Тем более USB 2 штуки, есть пример когда один работает девайсом, другой - хостом. Под проекты могут давать бесплатные VID/PID номера.
SPI у STM32F2 до 30М, у STM32F4 до 40М.

А что на сайте нет документации про 18Х серию NXP?
Ну у меня получилось реализовать под LPC17xx USB HOST, у STM тоже есть реализация. А насколько она круче не могу сказать.

Пишу на LPC17xx, по сравнению с STM32 (который только изучаю) мне кажется LPC лучше с примерами,несложная, но продуманная архитектура периферии, на LPC17xx USB и ETHERNET использовал, все хорошо работает. Насчет архитектуры периферии на LPC сразу обратил внимание на нормальное описание и не замудренный код в примерах. От STM32 пока не могу отойти от шока взглянув на поддержку USB и ETHERNET, такое впечатление как будто там Страуструп работает главным куда пошлют. Точнее, не код а напрасный труд, анти-помехозащищенный код, в структурах вместо обычных данных присутствуют указатели на функции которые возвращают эти данные ну и т.д. , гибкости этого решения - никакого, а время выполнения кода в несколько раз возрастает, попутно архитектура периферийных регистров говорит то, что разрабатывал ее человек отдаленно имеющем представление о программировании и алгоритмах оптимизации быстродействия, мож и имеет, но все-таки отдаленое, непонятная экономия пространства адресов против быстродействия программной обработки периферии.
Об LPC - глюков не обнаружил, регистровая архитектура периферии отличная и удобная (работал с ADC,DAC,TIMER,USB,ETHERNET,GPIO,UART), об поддержке USB (классовые драйверы не использовал) использовал сырой endpoint режим. Единственное что огорчило что в таймерах для дополнительного использования в качестве Single Mode PWM на старших моделях LPC убран регистр PWMCON, оставлен только регистр полупрограмной реализации PWM - регистр EMR, причем позже как-раз этот режим и пригодился для алгоритма генерации серии двухтактовых импульсов для тестовой модели трансформаторного блока питания.
Об STM32 - в процессе изучения,периодичное чтение и изучение возможностей периферийных блоков по мануалу, привело к тому что я по сей день кроме блока GPIO пока ничего не использовал. Использовать программную поддержку эстеэмовского местного "Страуструпа" извините тоже не вариант, ничего универсального не бывает, банальные примеры работают, а возится с переделыванием или адаптацией примеров - неблагодарное и никчемное дело. По программной архитектуре реализации кода поддержки, действительно потрачено столько сил на так сказать универсонализацию кода, что в итоге привело к плохой помехозащищености и очень длительному времени выполнения и растрате оперативной памяти на сохранения непонятно зачем созданных периферийных структур, возможно это как раз выход с положения из-за неудачной регистровой реализации периферии.

Там не просто "труп страуса", там достаточно хорошо забагованный труп. Пишу сейчас свой MSD для UDEV (универсальный, ессно, от архитектуры не зависит - пойдет на любом процессоре). Подглядываю в файлы примера от STM, вот весьма милый кусочек:

Проверяет поле MSC_BOT_cbw.bLUN, и если оно неверное то тут же использует его как аргумент SCSI_SenseCode() для записи статуса . И похожих косячков есть еще. Код взят из свежей "STM32F105/7xx, STM32F2xx and STM32F4xx USB Device Library".

Плохой пример, SCSI_SenseCode не использует переменную lun плохой код - да, но еще не баг

Согласен, не использует. Но все равно достаточно коряво и этот весь код к "многолуновому" варианту привести будет достаточно тяжко (а я как раз многолуновый пишу). А тут какая прелесть:

Там разве не USBD_STD_INQUIRY_LENGTH - 4 должно быть согласно SCSI стандарта?
А "Produt" - это новая торговая марка от STM?
Оно вроде как и не фатально (работает же как-то), но достаточно неопрятно. Еще во многих местах смешивает уровни SCSI и BOT, например нужно phase error для BOT генерить, а оно ILLEGAL_REQUEST в sense data валит. Вот и получается, народ "мимодумно бросает апельсин в воду" (с) и потом начинаются крики - "процессор - фуфло, USB - очень ненадежный интерфейс".

Тут, наверное, вряд ли кто с Вами будет спорить. У них действительно примеры написаны просто и достаточно полно ...

Честно говоря, этого выссказывания я не понял. Регистры у STM - просто регистры. Наверное Вы о библиотеке? Так плюньте на неё ... Раньше как-то обходились и без этого ...

Периферийные модули у STM значительно более навороченные, чем у LPC. И здесь возникает определённая колизия. Некоторые фичи самому раскопать достаточно затруднительно. Надо чтобы кто-нибудь тренинги проводил, либо примеры применения конкретные ... Иначе эти идеи останутся невостребованными, так как в даташите невозможно написать задумку автора - разработчика ...
Ну например, в некоторых stm есть 3 АЦП. Приятно узнать, что они сидят на одних и тех же ножках. Первая мысль - раздражение. Начинаешь читать - есть возможность синхронизации и фазового сдвига м/у запусками. Иными словами, можно поднять частоту сэмплирования сигнала в 3 раза. Ну да ... мне это не надо... Но раз разрабатывалось - кому-то нужно. Это одна маленькая фича, а их море. В результате сложность модуля возрастает очень сильно и работать с ним становится сложнее. Но в целом всё не так плохо. В одном проекте мне потребовалось определить скважность импульсов ШИМ. STM это делает аппаратно.
К сожалению, думаю, что я узнаю по даташиту лишь десятую долю заложенных возможностей. Даже простых узлов. А за сложные я уже и не говорю.
От библиотек я отказался. Тут я получаю тоже раздражение, что и остальные. Я их, в большинстве случаев, даже не смотрю. Беру даташит и сам пишу базовые примитивы, под конкретный проект ...
Мне, конечно, тоже предстоит самому работать с Ethernet. И тут конечно, придётся повоевать. Тем не менее, если народ готов пойти на жертвы ( например пост VslavX) и переписать начисто USB либо Ethernet, то это как раз говорит в пользу продукта. Это говорит о том, что разработчики в него поверили, и готовы потратить значительное время... Это значит, что они признали, что этот продукт надолго ... В него стоит вкладываться.

ИМХО, вкладываться надо не в конкретный продукт, а в повторное использование своего кода - нарабатывать кубики "софтового конструктора". Тогда будет почти все равно какой контроллер использовать. Например, в TCP/IP стеке, архитектурно-зависимая часть общая для, допустим, Cortex-M3, занимает менее 0,1 процента. Контроллерно-зависимая часть, допустим, для STM32F2xx занимает 2-3 процента. Аналогично для стека USB-device. Для USB-host цифры еще более незначительные. Поэтому при выборе контроллера LPC vs STM уже можно себе позволить посматривать на другие критерии, у меня основной - цена. STM32 на сегодня один из самых недорогих ARM7xxx/Cortex-M3. По сведениям наших снабженцев LPC17/23 значительно проигрывает (говорим про партии 10-20К штук). Ну а все остальные факторы уже вторичны (после 20 лет разработки столько всякого насмотришься) - документация, примеры, качество имеющегося софта.

Я имел ввиду у LPC чаще "проскакиваю" в регистровой модели периферии регистры только для сброса битов или установки. Скорее всего вы правы, что я неправ, видимо это у меня нервическое такое раздражение сложилось при чтении STM исходников. Да PWM по входу аппаратный, еще и энкодер квадратурный на половине таймеров присутствует, это хорошо. Но периферия обычных таймеров тоже сложная, но наряду с этим вроде там не хватает вроде для полного счастья регистров сравнения, чтоб можно было вместо Edge( Single PWM mode) или Center-Aligment PWM-ов сделать за период испульса произвольный сигнал, то есть хотелось бы реализовать по два сравнения на канал, одно бы устанавливало, а другое бы сбрасывало уровень, причем желательно чтобы каналов у одного таймера было три таких, соответственно по два регистра сравнения на канал. Я видимо не дочитал мануал, или плохо его перевел, но вроде в таймерах нет возможности создать произвольный PWM сигнал или есть ? У LPC такое делать умеет только PWM модуль который как отдельная периферия стоит и к таймерам LPC не имеет никакого отношения, кроме похожести.
На STM таймерах можно сделать произвольный PWM сигнал по 3 каналам сразу ??? Подскажите пожалуйста.

Дык там всё стандартное, по 3-м каналам - комплементарный выход с дедтаймом, на одном time-base счетчике То, что Вам нужно - нестандарт, его надо готовить из нескольких таймеров. Со всеми сложностями синхронизации. Наверное, за счет RCC- настроил, вырубил клоки, обнулил счетчики, врубил клоки атомарно...и чтоб на одной шине сидели..
Что удивительно - как железо попроще - таких вопросов и возникнуть не может - сразу садишься и пишешь, и получается все,что угодно.

Все очень похоже. Начал с LPC ушел на STM...Главная причина в том, что MCU позволяет делать то, что я хочу, а не ОНИ за меня решили... СТМ документация гнусномерзкопрепогано отвратительная и код весьма кривой...У LPC кривизна гораздо глубже и никак с ней не побороться... Но, в конце концов, каждый делает свой выбор.