подбираю для нового проекта процик и смотрел старшие кортексы от ST и от NXP
все вроде примерно одинаково .....

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


от ST смотрел stm32f2 серию
от NXP серию LPC176x , LPC178x
из периферии которая не у всех ARM поголовно есть надо ethernet, желательно вход под квадратурный датчик, желательно USB хост

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

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

Сообщение отредактировал Batman - Nov 5 2012, 15:50

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

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

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 правда пока у меня не запустился. (

Сообщение отредактировал SyncLair - Nov 6 2012, 15:03