Здраввствуйте! Выбираю для изучения контроллер с ядром 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 МГц.
Под задачу лучше выбирать (с оглядкой на то, под что есть опыт).

Сообщение отредактировал Genadi Zawidowski - Aug 28 2014, 21:54

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? Странно как-то...