Pull to refresh

Comments 7

Какие-нибудь плюсы по сравнению с младшими STM32 имеются? )
Естественно, это один и тот же класс микроконтроллеров, но дьявол, как известно, в деталях.

Из очевидных преимуществ — энергопотребление и цена. Под энергопотреблением я подразумеваю и заявленные цифры по режимам "сна", и специализированную периферию (вроде описанных счетчика импульсов и Low Energy UART), и специализированные средства разработки (то что связано с Energy Profiler).

Субъективно, инструментарий у EFM проработан лучше, но я имею довольно скромный опыт работы с STM32. Возможно, специалисты по ST поспорят со мной и дополнят ответ на ваш вопрос.
Как раз за счет инструментария STM и выигрывает.
EFM имеет очень низкое энергопотребление, но и потребление STM-ок, вполне приличное для большинства задач. А вот стоимость и доступность их отладочных наборов STM32fxdiscovery, плюс поддержка FreeRTOS, IDE и вообще кучи софта от сторонних производителей делают STM-ки очень привлекательными для разработчиков.
Короче говоря, STM выигрывает тем, что уже невероятно популярен) А главная ниша EFM32 — это всё таки приложения, критичные к энергопотреблению. Батарейное питание и вот это всё.

К слову, поддержка FreeRTOS у EFM32 есть (у меня в Примере #1 на скриншоте пара примеров видна), а куча софта — сомнительное преимущество, если есть качественное ПО от производителя и поддержка в наиболее популярных IDE.

А доступность STM32fxdiscovery — это да, тут не поспоришь..
Короче говоря, STM выигрывает тем, что уже невероятно популярен)

Сложно не согласиться:)

а куча софта — сомнительное преимущество, если есть качественное ПО от производителя и поддержка в наиболее популярных IDE.

Сложно согласиться:)
Дело в том, что мы года два назад портировали к себе поддержку EFM32 использовали как раз EFM32ZG-STK3200. Естественно, пробовали оригинальные средства разработки, которые Вы хорошо описали в своих статьях. Но они были крайне непривычные, ориентированные на показ потребления тока, что для программиста не так важно на начальном этапе работы, а вот хорошо выдираемого BSP или огромного выбора всевозможных сторонних средств, не было. И это было печально. Поэтому как программист я предпочту STM32, если есть возможность его использовать. Не такая уж там большая разница в потреблении для обычных приложений.
Мы исследовали EFM32, как раз для автономных устройств с временем работы от батарейки порядка года, но устройства сейчас умные должны много чего уметь, а это проще делать с помощью готового и распространенного софта.

Резюмирую, если критично потребление и его не обойти, то EFM32 идеален, все таки 32 разрядный ARM. Но в остальных случаях, пока рулят STM-ки, поскольку проще вход именно из за кучи софта.
Убедили!)

А что для STM используете? Я, естественно, о ПО
Я, к сожалению, не показатель. Поскольку являюсь разработчиком ОС Embox и использую gcc который одинаковый для обоих серий и какой либо редактор.
Но для обычных разработчиков важно, что для STM-ки есть множество примеров не от производителя, есть интересный проект CooCox, есть сетевой стек lwIP, то есть разработчик может выбрать средства разработки по своему вкусу (и на свой страх и риск конечно).
Sign up to leave a comment.