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

Тема как-то убежала от STM32 микроконтроллеров, на мой взгляд зря.
Работал я и с LPC2368 (ARM7TDMI) и с STM32F10x (Cortex-M3). Все, что будет сказано ниже, естественно, субъективно, но надеюсь будет полезно:
1. По поводу контроллеров NXP на ядре ARM7 (LPC23xx, LPC24xx), ярко запомнились мне слова, сказанные представителями этой компании конференции(не дословно): "Наши контроллеры дешевле конкурентов, за счет экономии на некоторых тестах...", список этих "забытых" тестов я не знаю, но видимо определенный отпечаток на контроллеры этот факт наложил. При работе с семейством LPC23xx умер не один миллион мозговых клеток: кривая работа модуля ускорителя памяти (MAM), т.е. практически его неработоспособность делали МК довольно тормознутым, проблемы при работе с UART, а так же множество разных мелочей, многие из которых к счастью описаны в еррате. Ах да... два контроллера (из разных партий, в разных приборах) просто-напросто приказали долго жить, без всяких на то видимых причин, запускались только под отладчиком а самостоятельно не запускались. Зато порадовало наличие гибкого SSP интерфейса с FIFO, а так же FIFO на USART, что частично позволило компенсировать скудность DMA.
2. По поводу STM32F10x: ну они мне сразу как-то приглянулись, все в них красиво, все расписано чего и как. Очень порадовало то, что на сайте доступны для свободного скачивания и постоянно обновляются библиотеки (STD Peripherial Lib) для этих контроллеров, имеющие порты по Keil, IAR и GCC, с примерами и описаниемхотя в качестве платы прихотится жертвовать производительностью, ибо даже для дергания портом В/В, приходится вызывать функцию, но при желании критичные места можно и самому написать, хоть даже в ассемблере. Таким образом время от начала разработки до более-менее работающего проекта значительно сокращается. Под STM32 работал как с ОС (uC/OS-II), так и без неё, в обоих случаях остался доволен. Врятли эти контроллеры безгрешны, но явных глюков выявлено пока что не было.
Повторюсь, это субъективная оценка, некоторых функций этих контроллеров я не использовал (из-за специфики поставленных задач).

Сравнивая цены, заметил, что STM как то получше смотрятся по сравнению с LPC. Про ошибки в LPC читал много и чего то не радует перспектива их обходить. От АТ91SAM7 уже просто устал глюков тоже как комаров в тайге.

Не совсем понял, что там с ногодрыганием у STM? В августе тоже собираюсь их начать осваивать.
Не радует, что младшие версии не имеют встроенного бута по USB:( Но это, по большому счету мелочи.

Представитель? Не верю .

Не умерла ни одна, ну или самую малость

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

Ну заливать на надо, ибо за счет 128bit Flash LPC уже не тормознутые, даже если MAM на всю катушку не включен.

UART чистый как слеза 550, как и на IBM PC. Проблемы говорите?

Да errata на крайние ревизии, считайте, вообще пустая. Причем, это действительно так.

бла...бла...бла... Честно говоря, я однажды целый год ругался на отдельные экземпляры LPC и шаманил с тем-же MAM и WS.... Только потом нашел у себя в загрузчике ошибку - прошивал Flash указав на порядок меньшую частоту. В результате программы работали, но чтение данных из Flash сбоило.

А вот как раз НИФИГА не расписано. Железо сырое, описание скуднейшее, errata практически скрыта, а вместо описаний и errat - получите писанную с бодуна бангалорскими студентами "библиотеку" с заплатками и минимумом функционала и "радуйтесь" . На эксперименты по выявлению как оно работает и как не работает уходит масса времени .

Уважаемый zltigo, Вы уж простите, комментировать каждое Ваше предложение не буду.
На счет представителя можете и не верить, я не настаиваю, тем боле что уже и не помню был ли он из российского представительства или из европейского...
Проблемы с MAM были как и на LPC2144, так и на LPC2368 и умерли они на пару, LPC2144 - после 3-х месяцев эксплуатации прибора, LPC2368 - на второй день... (помнится даже ветку открывал, думал траблы с CCO, к стати и Вы там засветились, однако дело было не в этом) оба контроллера похоронили с почестями.
На данный момент, возможно, LPC имеют меньше багов и больше фичей, однако они для меня оставили впечатление ненадежных контроллеров как раз потому что, цитирую: "На эксперименты по выявлению как оно работает и как не работает уходит масса времени".
Ну а насчет бангалорских студентов я бы не был столь категоричен, меня, написанная ими библиотека вполне устраивает, на счет ограниченного функционала я Вас не совсем понял, прошу пояснить.
Ну и я так понимаю, что вы достаточно работали с микроконтроллерами STM32 и знаете их слабые места. Если так то прошу о них рассказать, хотя бы в общих чертах, дабы не наступать на ваши грабли.

У STM понравилось CSS, но неудобно, что таймеры 16 бит.
В STM32F107RCT при задействовании Ethernet уж больно много периферии "съедается".
Есть LPC1766 с интересной багой (из тестовых образцов NXP): Ethernet память доступна только когда прошил проц через JTAG, после сброса хоть пиши, хоть читай - всегда ноль.
Жертвы "наколенок" есть как с той, так и с этой стороны. Есть LPC2368 у которого кварц стартует через раз, а стортовавши - уход частоты значительный (уровни напряжений тоже сильно отличаются от других). Есть STM с битыми ногами JTAG, жрет много, сильно греется, но работает (словила 220 с незаемленного компа). Хотя все это лирика)

Попробовал STM-библиотеку. Запустил USB довольно быстро, но увы так и не нашел, где поменять частоту кварца(
В итоге плюнул, написал за выходные с нуля, без всяких библиотек. На STM делал программную развертку VGA: с UARTа выводит на моник)

Сейчас в основном сижу на STM (103, 107), нравятся цены. Из LPC смотрю в сторону LPC11.

Без комментариев. "Дохлых" начиная LPC2114 и до нынешних не имел и не имею. Кроме одного LPC2148 с выбитым статикой генератором на часовом кварце (документирована низкая стойкость именно этих пинов ). Выбил собственноручно на макете, а не в изделии на объекте.

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

Нет, только с Circle. Реальных вещей не делал. Но и плотного предыдущего знакомства с STR7xx/STR9xx хватило, что-бы понять - картина не изменилась . Пытаются бежать впереди паровоза выбрасывая "новые" чипы и забывая старые проблемы. Работать с чипами, естественно, можно, но только это много более хлопотно, если не быть пофигистом. При этом никаких решающих преимуществ (ну еще ценовая политика в общем-то агрессивная, что неполохо), у ST обычно нет. На STR7 клюнул из-за HDLC - вот уж что оказалось реально совершенно не пригодным для работы, На STR9 падал из-за попугаев но помаялся и в конце концов на данный момент заложен появившийся несколько позже LPC2468, не столь быстр, но за счет внешней памяти справляется.
Такой-же подход к делу и у уже бывшего Luminary - быстрее, быстрее, все остальное (которое так и не наступает) потом. Тем не менее использую ARM контроллеры и ST и TI, только выбор начинаю с LPC. Не срослось ни разу только с ARM7 от Atmel.

P.S.
На STM8 я уже сильно рассчитываю.

Да ей Богу, начну я, пока руки не доходят хоть что-то купить.
Собственно выбор я уже сделал, о чем и была тема.
Вы, кстати, зря радуетесь - я ж как начну, так вопросами засыплю. Шутка.



Вот спасибо, этого и ждал. Учту ваши комментарии.



Ну поскольку для меня сроки ввода не так критичны, то библиотеки - не очень большой плюс. А с доками у них ИМХО большая проблема.



Причем сильно получше.



Возможно я вас удивлю, но меня обширная еррата только радует - видно, что производитель хотя бы отслеживает баги, если не фиксит (а филипс фиксит). Вы вот доки от RDC не видели. Еррату на их процы можно найти только у тех, кто уже оные пользовал - например у Фаствела. А сами RDC и их представитель Прософт либо тупо молчат в ответ на прямо поставленные вопросы, либо бубунят всякую шнягу. На два моих вопроса относительно ОЧЕВИДНЫХ ошибок в документации (я так понял, что в проце все же сделано правильно, а это именно баги доков) они долго не отвечали, потом выслали новый даташит, в котором один баг был пофиксен, а касательно другого все так и осталось. Спросил еще раз - Джэки Янг молчит. И это только то, что мне попалось (слава Богу от этих багов все равно ничего не зависит). А сколько было обнаружено другими людьми..... Чего стоит один НЕустанавливающийся бит сброса от ватчдога! Представьте себе - произошел сброс по ватчдогу, а мы об этом никогда не узнаем! Ну ладно, фикс есть - завести ватчдог на NMI (тоже так себе решение), но во-первых они об этом молчали (и если кто-то УЖЕ понадеялся на этот бит, то в перспективе он может и к прокурору попасть), а во-вторых они решительно не хотят сообщать о ревизиях проца, например стали они выпускать процы с буковкой D в конце - и непонятно, пофиксено там это, или нет. Официальный ответ Прософта - фабрику сменили и "чего-то поменяли". Что???



Вот! Давайте.

Какая такая "большая проблема", может просветите?
Я никогда (за очень редким исключением) не пользуюсь сторонним софтом, предпочитая писать своё, согласно документации производителя.
И STM32 не стал исключением.
Нормальные у них доки, не хуже NXP.

А вот начав знакомство с новым LPC1768, сразу столкнулся с кривым user manual, в котором в регистре PCONP напрочь отсутствовал бит GPIO, без которого оный модуль никак не хотел работать.

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

Ну так у Поляков появились ATMEGA48PA-AU 1336шт. лежит.

"Все надо делать самому".
Документация у STM хорошая, правда "тонкости" раскиданы по разным документам, но это не проблема.

С битиком GPIO - было такое. В самой старой доке он был описан, потом была дока в которой его уже не было, затем все поправили. Я не попался, а у знакомого "не взлетело" с первого раза - сравнили мануалы: в его более свежем битика не было.

Заодно уж если теребить выбор, то хотелось бы поинтересоваться.
Своим "паябельным" корпусом привлек LM3S102. Но насколько я понял у него есть особенность: для запуска нужен внешний кварц, после программно можно переключится на IRC. Это так? У новых тоже?

В продолжение темы о документации на контроллеры NXP и LPC. Вот сейчас скачал с сайта NXP последнюю версию User Manual на семейство LPC17xx (Cortex-M3) и с сайта ST для семейства STM32F10x (тоже Cortex-M3). Для сравнения самое то. По информативности они примерно равны, за исключением того, что NXP кое-где вдаются в подробности, а кое где, наоборот, дают мало информации (так, например: не смог найти блок схемы портов В/В), оно может и не критично, но бывает полезно. Документация же от ST равномерная и аскетичная (это не значит что она не полная, это вам не доки на AVR где все разжевано вплоть до примеров на асемблере и С).
В целом документация от NXP выглядит лучше, но только за счет того, что она лучше воспринимается, цветовое выделение таблиц и блок схем, сведенные в таблицу описания битов регистров и т.п. Этого, конечно, документации от ST не достает, ну а в остальном ничего плохого про ST сказать не могу.

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

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

Самая ХУДШАЯ, по организации. Жуткая бессистемная свалка со сплошными copy-paste. Восхитить сие может разве только поклонников игры найди десять отличий (а иногда и меньше) в двух разных документах на почти одинаковые контроллеры. Даже если в одном документе, то тоже приходится искать отличия. Например описаны три варианта контроллера, три немаленьких таблицы, две таблицы просто одинаковы. Третья отличается от первых двух одной строчкой. Дурдом.

Почему дурдом? Взял нужную таблицу, и действуй. Нет, серьезно, их доки дюже хороши. Причем доки на АРМы пожалуй еще так себе, но на АВРы и память - просто очень хорошо сделано. В доках на CPLD традиционно разобраться непросто, но в этом отношении они по крайней мере не хуже Альтеровских. Что вам так там не нравится?

P.S.: Нас тут за флуд не накажут? Вопрос-то уже выяснили.

Нужно выбрать контроллер, или портануть и $%#%#%^$%^ - "найди десять отличий" при, например, чтении ТРЕХ РАЗНЫХ ДАТАШИТОВ Atmega48, Atmega48P, Atmega48A. А зачем мне даже в одном документе ТРИЖДЫ перечитывать одни и те-же строчки про три таймера и искать отличия и одинаковости среди всего этого торжества copy-paste?

С точностью до наоборот

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

На Атмеловские ARM доки, на мой взгляд, достаточно внятные и структурированные:

Overview
Block Diagram
Product Dependencies
Functional Description
User Interface

Что еще нужно?!

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

Вы у кого, конкрентно, спрашиваете? У модератора?

Вы еще не поняли, что на все Ваши плюсы последуют ответные минусы?

Это вы о чем?

Вернее о ком. Это я о zltigo и его беспросветном оптимизме

Вот уж давайте Altera сюда не мешайте! Даже близко сравнивать нельзя. По сравнению с альтерой документация NXP полный дурдом - например в ранних версиях докумантации таймингов на работу с внешней памятью LPC2478 вообще нет, в последних появилось, но все надо считать вручную - максимальные и минимальные значения отсутсвуют. Может програмистам зашибись, но железку делать с таким DS еще тот гемор.

Я сравнивал Альтеру и Атмел. Про CPLD от NXP я ничего не говорил, ибо не видел их в природе.

Вот это что есть, то есть. Тайминги вообще описаны только иногда , вешать ту-же FPGA без лабораторных работ с осциллографом неудобно. Хотя...., например, контроллер памяти там ARM PrimeCell™ корка от ARM - надо смотреть и те документы.

может поэтому NXP и не помещает информацию о EMC в DS камня?

Работаю с STM32F103 около года. Правда, не все время, урывками. За это время было несколько засад, которые можно описать одним правилом- вся проблема в кривом софте сторонних писальщиков, который несколько раз пытался применять.
Единственная неоднозначность в документации которая мне показалась не подробно описанной- это бит TXE в статус регистре USART (что после старта процессора он выставляется). Хотя, возможно в голове уже штамп от AVR сидел.

Ну как обычно начали за здравие, закончили за упокой С доками Atmel'а достаточно пообщался и уже привык к однотипным описаниям, я вообще в их доке всё ищу поиском, вполне удобно STшные доки тоже читал, когда выбирал камень для разработки, документация скудной какой-то показалась... Наверно плохое прошлое от AVR сказалось