А как сейчас модно писать под STM32?

Я использую CubeMx + emacs + свой пакет для емакса + свои скрипты cmake для генерации проекта(можно выбрать шланг).

Пиши как нравится - главное чтоб работало.

Я пробовал прогать на расте и могу сказать, что он не дорос для более-менее серьёзных проектов. Без фич анстейбл версии даже не скомпилировать. Существующие ртоси на расте полное уг по сравнению с фриртос, а фреймворки уг по сравнению с HAL.

Использование раста совместно с си просто не даёт особых бонусов.

Я пока не планировал писать на расте, но спасибо за информацию.

Потому что под немейнстримные задачи с немейнстримными платформами нужно использовать nightly обязательно.

Ваш кэп.

Nighlty — не значит что компилятор будет генерить мусор вместо кода, это просто возможность включения фич языка, которые еще не было решено стабилизировать и тем самым подписаться на их поддержку во всех последующих релизах.

Включение фич опционально: то есть фичи типа asm или интринсики можно использовать спокойно, они скорее всего в стейбле будут. Экзотику типа экспериментальных реализаций вчерашнего rfc всё таки не стоит.

У @japaric есть неплохой гайд и либы с обвязкой для периферии стмок

http://blog.japaric.io/quickstart/

писать хорошо и правильно.

Ну смотри

наиболее православные версии тулчейна для C

Наиболее православным будет c++. Инфа сотка.

желательно clang

Тут согласен

билд-системы (желательно cmake)

Qbs, а симаке на помойку.

программатора и отладчика

У китайцев копию st-link. Вот такой http://s2.electrodragon.com/wp-content/uploads/2013/09/ST-Link-V2-Programmer-... Проверено, работает

альтернативной библиотеки периферии

HAL от stm32. Нефиг всякий шлак по интернету собирать

Или не стоит в 2018 пинать STM32?

Стоит. Других нормальных мк нет. Авр и прочее 8 битное дерьмо идёт на помойку.

Кот-то запрещает использовать растишку вместе с кубом и халом?

А тем временем беларусы клепают IoT девайсы на PIC-ах. Даже Ethernet-шлюз на PIC

У китайцев копию st-link

Такой у меня есть уже. Я про софт для него. Использовал OpenOCD, st-flash, stm32flash, везде были какие-то косяки.

Наиболее православным будет c++. Инфа сотка.

Никаких плюсов на МК. Они раздувают бедный код до неимоверных размеров, если использовать хоть сколько-нибудь полезные фичи, а без них ц++ сакс, да и вообще, они просто раскрепощают

CubeMx это случаем не vendor-lock?

Вопрос автору темы: LibOpenCM3 какие недостатки, как показалось?

Какие есть МК в продаже на SiFive, насколько они развиты по сравнению с stm32? Я вообще пишу из танка.

Не помню. Домой приду, посмотрю.

Пики - дорого, малопроизводительно, и жрёт как целый танк. Да и с ДМА не так всё радужно, как на кортексах и с другими интерфейсами.

Плюсы нужны для нормальной агрегации и структурирования кода. Не обязательно использовать исключения, RTTI и прочую жирноту.

Использовал OpenOCD, st-flash, stm32flash, везде были какие-то косяки.

Юзаю st-util. Отладка и загрузка - прекрасно

STM32CubeMx - явовская программа, которая просто генерирует код иницализации переферии под фреймворк HAL. Всё открытое.

Это такой же вендорлок, как и разница opengl и directx

CubeMx это случаем не vendor-lock?

Он самый, потому и не хочу SPL или Cube.

LibOpenCM3 какие недостатки, как показалось?

Если «въехать», то никаких. Но «въехать» нужно и это занимает время, пока не «въедешь», будет путаница и в хэдерах и в голове. Так что недостатком можно назвать высокий порог вхождения, но я не думаю, что это что-то плохое.

Какие есть МК в продаже на SiFive, насколько они развиты по сравнению с stm32?

SiFive — это компания, архитектура называется RISC-V. Из чипов пока только E310, но не знаю, как у него с продажей.

Кстати, раз уж раст затегал, я тут еще поевангелирую.

Те же либы japaric позволяют писать в safe rust со всеми гарантиями и инициализацию периферии и ее использование и реализовывать вытесняющую многозадачность c общей памятью задач без гонок.

бложик

STM32CubeMx - явовская программа, которая просто генерирует код иницализации переферии под фреймворк HAL. Всё открытое.

Сама явовская программа закрытая.

Я использую scmRTOS, eclipse и makefile. Ось плюсовая, очень быстрая.

Тестовые проекты с использованием этой RTOS: раз, два. По второй ссылке используется библиотека stm32tpl.

Cube не вендорлок, что еще ты в нем плохого видишь?

CubeMX — это проприетарь и вендорлок, так как завязывает твои проекты на HAL. Я же не хочу использовать HAL.

Linux — это проприетарь и вендорлок, так как завязывает твои пректы на Linux. Я же не хочу использовать Linux.

Алсо, оно называется не «вендорлок», а «vendor lock-in», чучело.

Какие есть МК в продаже на SiFive, насколько они развиты по сравнению с stm32?

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

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

Ну и делать обёртки над периферией это та ещё боль. Хотя когда появляются более-менее внятные абстракции над железом становится попроще.

выдавай оно тебе .o без которого никак - это lock-in, а так тебе никто не запретит срать в регистры самому. Но по опыту скажу, что HAL для «слепить по-быстрому» лучше.

Ну и так, из неизвестных загашников интернета - https://github.com/alexeyk13/rexos

Вдруг пригодится

проприетарь и вендорлок.

Проприеатрь - ок, почему это не вендорлок тебе уже объяснил Dark_SavanT.

Поехали дальше, чем тебе HAL не угодил? Тебе тоже засрали мозг тру хацкеры с easyelectronics?

Конь, ты этого говна исходники видел вообще? А как по-наркомански функции обзываются?

Тебе хочется, чтобы мигалка диодом 8кБ флеша занимала, а код чуть сложней не влезал и в 16?

Калокуб создан в жалкой попытке расширить диапазон пользователей вовлечением ацефалов, которые абдурину мучают. А, как ты знаешь, тем, что создается для дебилов, в итоге лишь дебилы и пользуются! Явный пример — мастдайка.

Красные глаза! Собираю, компиляю...

При чем здесь «красные глаза»? Это — единственный удобный и рациональный путь. Минимум тычков мышей. Максимум понимания и оптимизации.

А вантузоиды пусть в калокубе натыкивают и вопят потом на форуме «ой, у меня прошивка в 32кБ не лезет, надо МК на 64кБ покупать!». А фактически, если бы их быдлокод причесать, влезло бы и в 16кБ со свистом!

Покажи пример своего Makefile'а.

Ты по ссылке не хочешь ходить?

Например.

Эдик, не передёргивай. Никаких 8кБ. Оверхед минимальный, зато польза огромна. Хал прекрасен.

Эдуард, ты хоть помечай свои сообщения секретным значком, если не хочешь заводить новый аккаунт.

На лоре, насколько я понимаю, не так уж и много людей, которые по-настоящему что-то делают с STM32. Твое мнение по этому поводу очень ценно.

Тут в теме уже несколько анонимусов, становится непонятно кто пишет по делу, а кто тралирует

У него есть жжешечка.

Почему выравнивание табами?

Потому что Makefile же!

Если в geany и для makefile'ов сделать выравнивание пробелами, то придется придумывать, как в начало втыкать табы...

В нормальном коде я уже давно использую выравнивание пробелами, на всех компах geany настроил соответствующим образом.

Анонимус прав: у меня есть ЖЖ. Есть гитхаб, почта... В общем, способов связи уйма.

ЛОР — не место для серьезных тем. Это обычная срачельня.

Да я об этом

Так и я о том же: не вручную же пробелы ставить! А перед целями компиляции в Makefile обязательно должны быть табы.

Эдик, по твоим постам понятно, что ты не имеешь никакого отношения ни к профессиональной разработке ПО на микроконтроллеры, ни к вообще какой-либо деятельности направленной на извлечение прибыли.

В этом мире, Эдик, платят не за задроченный до зубой даташит от STM сто пятого, а за умение быстро и качественно воспринимать новую информацию и приобретать новые умения (тебе это недоступно, т.к. до сих пор сидишь на KOI8-R), а так же способность оценивать стоимость человекочасов, необходимых для завершения проекта (тебе это недоступно, т.к. сомневаюсь что ты хоть раз заработал деньги, доставшиеся не в виде гранта, нищенской зарплаты научного сотрудника или грошей в виде подачек от студентов, которым ты делаешь дипломы).

ТС спрашивает о том, как правильно делать, а не как подставить свой зад работодателю и стать шлюхой последней!

Мне нравится работать так, как я работаю. А тебе если нравится быть последней шлюхой и сосать у каждого встречного-поперечного — это твое дело. Я таким заниматься не собираюсь.

ТС спрашивает о том, как надо делать, чтобы получить работающую вещь, а не потратить месяцы на моргание светодиодом.

И дело тут не в работодателе, а в распределении своего времени. Если CYB3R хочется разбираться в регистрах, ему никто не запрещает. Но если он хочет разрабатывать на STM32 устройства, то HAL тут нет альтернативы. Нет никакого смысла разбираться в даташите, если это уже сделали за тебя и предоставили удобный API. Да, там есть баги и ошибки, но значительно меньше, чем в locm3

Еще раз объясняю, почему HAL — дерьмо!

Когда ты пишешь без внешних либ, тебе нужно лишь читать даташит. Если же ты пишешь с калокубом, тебе нужно не только даташит читать, но и исходники этих либ (мало ли что там накосячили), что только усложняет разработку!

Нет никакого смысла разбираться в даташите, если это уже сделали за тебя

Да что ты говоришь! Не надо тут бред нести. Я уже несколько десятков стонов любителей калокуба видел на тех же казусах и изиэлектрониксах, когда они пытались код с одного камня на другой портировть. Типа «кал же кроссплатформенный!».

Да, там есть баги и ошибки, но значительно меньше, чем в locm3

Т.к. после SPL я ни в каком говне ковыряться больше не желал, то исходники кала, понятное дело, не смотрел. Но то, что было в SPL — это лютый треш! Даже opencm3 по сравнению с этим трешем — дар свыше!

Не прогай я на стмки уже больше двух лет, возможно согласился бы с тобой. Но с ХАЛом уже сделал множество всевозможных устройств различной сложности. Писать под хал мне удобно, но главное - они работают и я уверен в их надёжности. Большего мне не надо.

С портированием бывают проблемы, но они решаются за полчаса. Буквально перед новым годом перенёс огромный проект с STM32F4 на STM32L4 без проблем - работает до сих пор хорошо.

Не буду больше спорить. Некоторые прогают на Keil и им тоже хорошо.

А некоторые и на асме спокойно под STM32 пишут...

В общем, фломастеры, как говорится.

Но таки если хочется написать что-то понятное, что и через 10 лет можно будет завести, HAL не годится.

Вот уж не думал, что буду согласен с Эдиком, но да - HAL то еще говно. То, что он «упрощает» разработку, не делает его годным.

http://www.st.com/content/st_com/en.html

С Эдиком спорить - только если душа просит набросить он упёртый.