Прошу совета в выборе mcu. Опции

[Cree]

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

[Xenia]

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

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

[_4afc_]

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

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

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

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

[kan35]

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

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

[Aner]

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

[Genadi Zawidowsk...]

ATSAM4SA16B

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

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

[Dejmos]

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

[jcxz]

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

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

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

А в остальном Atmel удобен... но как-то само собой новые проекты подходят под STM32xxx... Где не хватит 180 МГц + FPU от STM32F429, поставим Renesas R7S721 с его 400 МГц.

Почему-то большинство народу смотрит только на саму цифру в МГц и совсем не думает, что за ней скрывается.
И как работает 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...

[AlexandrY]

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.

[Genadi Zawidowsk...]

И как работает prefetch и кеш, и какая ширина шины до флеш и какова её частота.
А ведь может оказаться что эти 180МГц будут тратиться на тупое ожидание данных из флеш

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

[jcxz]

Не будет между ними значительного отрыва в быстродействии. Уж поверьте.

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

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

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

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

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

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

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

[AlexandrY]

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

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

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

[jcxz]

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

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

[Aner]

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

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

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

[jcxz]

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

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

[Aner]

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

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

[jcxz]

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

[Cree]

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

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

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

[mempfis_]

Не знаю насколько страшен LPC1788, буду надеяться, что контроллер не слишком плохой.

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

[jcxz]

Не знаю насколько страшен LPC1788, буду надеяться, что контроллер не слишком плохой.

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

[Cree]

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

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

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

[Aner]

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

[AlexandrY]

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

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

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

[Cree]

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

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

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

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

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

Сообщение отредактировал Cree - Sep 8 2014, 15:37

[A. Fig Lee]

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

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

[Aner]

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

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

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

[andrewlekar]

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

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

[Cree]

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

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

Наверное, gcc под ним, но все равно.

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