Здраввствуйте! Выбираю для изучения контроллер с ядром Cortex-M4. Подскажите пожалуйста, что на сегодня выглядит наиболее привлекательно? Очень интересует поддержка со стороны производителя и комьюнити.
По форуму заметно что STM32F4 почему-то наиболее поплярен, но все таки решил спросить совета. Прошу прощения за такой вопрос.

Контроллер выбирают, как невесту - кому-то нужна богатая, а кому-то красивая .

STM32F4 выбирают за то, что он дешев, хотя он и страшен, как чёрт .

Я выбрал ATSAM4SA16B, потому что уже более 12 лет люблю микроконтроллеры от Atmel.

Данный экземпляр привлёк частотой ядра и переферии в 120МГц.

Поддержку производителя ощутил скачав с сайта Студию, в которой есть куча готовых примеров.
На основе примеров легко написал работу USART, PLL, USB, ADC, IO.

Чья-то помощь пока не потребовалась. Поскольку сам МК мне понятен.
В основном удивляет Студия своими солюшенами-бормалюшенами.

С этой точки зрения может быть интересен STM32F3, который тоже CM4, но периферия попроще. Производитель рекомендует их как замену уже старенькому STM32F1, даже дешевле получается.

Семейство STM32F1хх никак не старенькое, оно проще, как в архитектуре, командах, отладке. Освоил от F1 ... до F4 - все там на своём месте. Семейство STM32F4хх достаточно навороченное, сложное как по архитектуре так и по доп командам, отладке и тп. Софтверно-философская совместимость семейств есть, но доп регистры, расширения, заставили ломать голову, писать, отлаживать пришлось немного иначе. Сразу за STM32F4хх это семейство браться без опыта с младшими не советовал бы, видел многих кто так и не освоил до нужного уровня F4, хотя с семейством F1 справляется. Хотя все от способностей конкретного чела зависит.

О... как вспомню, сколько (два) дней я искал, как включить в этом процессоре FPU, вместо того, чтобы прочесть документацию!
А в остальном Atmel удобен... но как-то само собой новые проекты подходят под STM32xxx... Где не хватит 180 МГц + FPU от STM32F429, поставим Renesas R7S721 с его 400 МГц.
Под задачу лучше выбирать (с оглядкой на то, под что есть опыт).

STM32F4 популярен из-за политики ST - продавать отладочные платы вместе с программаторами за копейки.

Выбирают всегда исходя из потребностей задачи.
Какие у вас потребности? Сколько ОЗУ/флеша нужно? Важна скорость или малое потребление? Какая и сколько периферии? И т.п.
По этим критериям и выбирать.
Маэйнстрим производителей M3/M4: NXP,ST,TI,ATMEL. Из их поделий и нужно выбирать.

А на форумы не смотрите. Подавляющее большинство их обитателей - чайники, а для чайников самый главный критерий - дешёвая(бесплатная) отладка. Поэтому они и выбирают ST.
Если Вы профессиональный разработчик и у Вас в планах - делать свои платы, а не использовать только отладки, то цена её не играет роли.


Почему-то большинство народу смотрит только на саму цифру в МГц и совсем не думает, что за ней скрывается.
И как работает prefetch и кеш, и какая ширина шины до флеш и какова её частота.
А ведь может оказаться что эти 180МГц будут тратиться на тупое ожидание данных из флеш.
И окажется что Tiva (TI) на 120МГц с 256-битной шиной к флеши гораздо быстрее ST со 128-битной.
А может вперёд выйдет Atmel с вдвое большим чем у ST L1-кешем команд.

А ведь есть ещё и периферия. И хроническое отсутствие буферов в UARTах и SPI у STM32, резко ужесточит требования
к латентности обслуживания периферии (а значит - сожрёт МГц и увеличит потребление).

PS: Мы, для своей новой разработки скорей всего выберем Tiva. Из-за требований к кол-ву периферии, интенсивности работы с ней (все UART и SPI имеют FIFO у Tiva),
удобству DMA-контроллера для работы с периферией (у STM32 получается затык с его большой потребностью к каналам DMA, ограниченностью их кол-ва и жёсткой привязкой
каналов к периферии). А лишние +60МГц STM32 думаю нивелируются удвоенной шириной шины к флеш у Tiva (хоть и почти без кеша (( ).
А раньше мы жили исключительно на NXP...

В свое время перепробовал и TI, и NXP, и ST

Не будет между ними значительного отрыва в быстродействии. Уж поверьте.
А запарить там цифрами ширины шины и проч. они могут, в этом они мастера.
Сходите на http://www.eembc.org/coremark/index.php и просто сравните и проанализируйте.
Только многоядерность и частота ядра может продвинуть параметр CoreMark/MHz далеко вперед.

Да, в первых STM32 с FIFO была проблема. Но она решается DMA. В последних STM32 каналов DMA вполне достаточно.

Важнее, ИМХО, качество сопровождающего железа софта.
И тут у Tiva все печально.

Из RTOS предлагается только какая-то доморощенная TI-RTOS с файловой системой стянутой у FatFS, TCP стек тоже напоминает LwIP. Т.е. все то же на чем пасутся и все остальные типа ST, Atmel, NXP...

Пречисляют много других осей, но интеграцию своего SDK с ними не предлагают.
Имеют достаточно сильные прикладные библиотеки, но на Tiva не портируют, а продвигают свои DSP.
Ассортимент самих Tiva очень узкий.


Сейчас в плане софта лидирует Freescale с их семейством Kinetis.

Буквально на днях они выпустили новую версию SDK для Kinetis куда входят готовые адаптации со всеми драйверами для RTOS: uCOS-II, uCOS-III, FreeRTOS и MQX.
Также туда входят все те же LwIP, FatFS.
Продолжается развитие их библитек для управления двигателями, подключения к облакам, медицинские библиотеки, библиотеки для радиопротоколов и ZigBee, визуальные eGUI, интерактивный рекордер-осциллограф FreeMASTER и проч.
Также для Kinetis есть самая работоспособная адаптированная версия ucLinux.

У Renesas R7S721 нет внутри FLASH. А что об prefetch/Icache думать? включаем их при инициализации и тупо смотрим осцилографом, сколько времени занимает вычисление FIR фильтра. Тут мегагерцы ядра почти всегда пропорциональны.

Нам и не нужно. Нужно чтобы Tiva не уступал или не сильно уступал STM32 и всё. А это так и есть на требуемой задаче.
Для нас важнее - наличие необходимой периферии.


Как раз недостаточно. Так как все каналы у STM32 сильно привязаны к запросам периферии, и когда нужно 5 UART + 2 SPI + 1/2 I2C + чтоб ещё резерв остался
(и всё это одновременно), то тут всё равно придётся с частью периферии без DMA работать.
А у Tiva гораздо легче с зависимостью DMA-каналов от периферии. Да к тому-же при 16 байт FIFO в UART, гораздо легче и без DMA работать.


Это как раз неважно. Любая ОС легко переносится между всеми M3/M4-ядрами.
А прочие библиотеки мы практически не используем, хватит уже наступать на грабли оставленные написателями халявного софта.


Это хорошо когда нужно только FIR-фильтры считать. Но в прикладном ПО такого практически не бывает, а всё гораздо сложнее. И на осциллографе ничего не проанализируешь.

Правильно, я и говорю, что с Tiva вы и остаетесь один на один к классическим халявным софтом в виде lwIP и FatFS.

А перенос RTOS нынче это не перенос ассеблерных реализаций переключателя контекста, как было еще недавно, а перенос всего OSA и HAL которые составляют 90% современной RTOS.

Глюки в железе CPU + баги HAL? Нет уж, увольте. Лучше просто refmanual.
Переносимость не нужна - не Hello world пишем.
FatFS - не нужна, а TCP-стек свой есть. Переписать MAC-уровень думаю будет не проблема.

Соглашусь с AlexandrY, ведь исторически TI проморгал и потерял время для развития своих M3/M4, теперь догоняет и обвешивает халявным софтом. Причем минимальным, зато в рекламу TI вкладывается хорошо. Из перечисленных TI, NXP, ST я выбрал ST; причем их линейка от STM8 понравилась из-за хорошей софтподдержки. На сегодня у меня много успешных проектов в серии с STM32Fxx. С NXP, M3 есть проекты двух летней давности, но ушёл от NXP по многим причинам. Freescale хорош, но его малая доля на нашем рынке ... и пока, их процы не решаюсь пользовать.


Так если FatFS - не нужна, а TCP-стек свой есть - тогда Microchip, будет подешевле для ваших проектов. На худой конец у того же TI - 430 семейство.

Вы нужность или ненужность M4 определяете по необходимости FAT и TCP? Странно как-то...

А вы у себя не находите странность? Задаете вопрос и сами отвечаете на него.
Нужность или ненужность M4 никак не связана с FAT и TCP.

Какой такой вопрос я задавал???

Большое спасибо всем! Вниматель прочел все посты и очень благодарен за помощь!
К сожалению или к счастью мне дали во временное пользование вот такую плату http://www.wvshare.com/product/Open1788-Standard.htm с NXP (Cortex-M3 правда) и китайский дебагер J-link, тем самым лишили меня возможности выбирать. Не знаю насколько страшен LPC1788, буду надеяться, что контроллер не слишком плохой.


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

Могу уверить Вас что это отличный и надёжный контроллер. В сети много примеров для семейства LPC17. Также можете скачать книгу Тревора Мартина где доступным языком описаны как простая переферия, так и сложная.

Нормальный МК. У нас на 1778 (это почти то же самое) несколько законченных проектов уже сделано. Никаких проблем.
Дальше - открываете usermanual (UM10470.pdf) и вперёд.

Спасибо большое всем!

Вот у меня еще есть такой бестолковый вопрос.
Пошел добывать драйверы и CMSIS для контроллера. На lpcware имеется архив с драйверами lpc177x_8x_08132012.zip но как я понял из того что пишут разработчики - товарищи из NXP на него забили и эти драйверы более необновляются. CMSIS Core там соответствует версии 2.10. Предлагают качать LPCOpen для Keil/IAR либо для ихнего LPCXpresso. А что если я хочу исользовать что-то другое, то как быть? Можно ли будет "подогнать" эти драйверы?
Прошу прощения за такой вопрос, немного запутался с драйверами и toolchain-ами.

Глянул как выглядит IDE Keil, это какой-то "привет" из 90-х годов. У них там чтоли прогресс остановился уже?

Давно остановился, посему пользую иар, а те кто еще тогда подсел на кейл просто не хоят слезать с него из-за наработаного. Понять их можно.

IAR тоже не меняет UI своего IDE уже десяток лет.

А вот Freescale для своей серии Kinetis постоянно выкладывает что-то новое.
На прошлой неделе выложили бесплатную Kinetis Design Studio IDE без ограничений кода!
Поддерживает JTAG отладчик JLink.
Все навороты современной IDE, мощный SDK, визуальный конфигуратор, Add-On-ы для известных RTOS и проч.

IAR тоже смотрел - страшный динозавр. А почем бы не Eclipse + GNU компилятор с плаганами для MCU? Есть какие-то сложности? Для меня вообще и Eclipse не верх совершенсто, но хоть не Юрский период.


В Freescale молодцы, сделали IDE на базе Eclipse да еще бесплатную. Но к сожалению у меня контроллер не Fresscale(( Разработчики в NXP тоже сделали свою IDE на базе Eclipse, но к сожалению она платная, а бесплатная с ограничением.

Оба на! А вот это серьезная заявка на победу.. Наверное, gcc под ним, но все равно.
Будет кандидат #1 вместо СТМ32.
Спасибо за инфо.

хорошо звучит.

Сложности есть: code completion работает через задницу и список файлов в проекте нужно руками задавать. Eclipse совсем не фонтан, IAR мне симпатичнее. Я для себя настроил Sublime Text для работы с иаровскими проектами. Пробовал Visual Studio, но внешний вид хромает.

Сlion от Jetbrains похоже будет самой лучшей IDE. Работал c intellij idea когда-то. Sublime Text тоже использовал, но потом ушел на Atom.


А чем GCC плох? Я прочел что оптимизирует и компилирует довольно неплохо. Судя по всему почти все разработчики контроллеров берут за основу его.