LINUX.ORG.RU

Посоветуйте IDE + билиотеки под STM32 на C/C++

 


3

2

Я в курсе про CubeMX, но это только драйверы, а у проекта чуть больше задач:

- пакетный менеджер для библиотек (чтобы не копировать ручками)
- библиотеки uart, LCD (хз, как выбрать качественные и поддерживаемые)
- какое-то совсем примитивное подобие async/await и эвентов, можно через «псевдо-rtos». Грубо говоря, чтобы проверка состояния кнопки с контролем дребезга выглядела как линейный код, а не FSM.
- IDE (?).

С виду platform.io - «прям то што хотел». Но когда начал копать - запутался в библиотеках и погиб. Там протухшая свалка какая-то. Искать актуальные версии терпения не хватило, пошел плакаться сюда :)

Напишите кто пилит под stm32, как нынче можно организовать разработку модного молодежного проекта. Он rust пришлось временно отказаться, но хочется хотя бы на плюсах или си сделать так чтобы не стыдно было.

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

★★★★★

А все библиотеки - ручками, это не ардуино. Тут нельзя написать универсальные библиотеки, для каждого случая всё-равно приходится переписывать.

Для кнопок и светодиодов, вот, например моя библиотека: https://github.com/SL-RU/binary-clock/tree/master/src/binclock/Controls А так всё нарабатывается со временем самостоятельно. Чужим библиотекам в серьёзных проектах нельзя доверять, а на стмке другие делать бессмысленно - есть ардуина.

SL_RU ★★★ ()

Можно взять ChibiStudio и писать под ней с использованием CubeMX и freertos. ChibiStudio удобна тем, что там сразу настроен отладчик, компилятор итд.

Есть еще плагин к clion, но он стоит денег.

Библиотеки - надо делать свои

vromanov ★★ ()
Ответ на: комментарий от SL_RU

светодиоды - это hal. Но есть же библиотеки ПИД, FSM и т.п. К тому же в platform.io можно указать под какие процы библиотека. Правда сам пока не пользовался.

Vit ★★★★★ ()
Ответ на: комментарий от vromanov

Меня напрягает отсутствие нормального пакетного менеджера. Из-за этохо хотел на rust соскочить, но он для эмбедов не готов, как оказалось. Есть вменяемое решение чтобы зависимости ставить и обновлять?

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Нету в эмбеде зависимостей! Основное это HAL или подобное от производителя. Остальное в основное пишется вручную. Какие пакеты вы хотели бы обновлять?

vromanov ★★ ()
Последнее исправление: vromanov (всего исправлений: 1)
Ответ на: комментарий от vromanov

Не из текущего проекта, но допустим FAT, парсер G-кода, и т.п. Вероятность что найдут и пофиксят там багу - есть. Хотелось бы как минимум знать.

IMHO «в эмбеде нет зависимости» это не причина а следствие кривых инструментов. В эмбеде еще тестов нет :)

Vit ★★★★★ ()
Ответ на: комментарий от anonymous

почему?

Из-за этохо хотел на rust соскочить, но он для эмбедов не готов

BceM_IIpuBeT ★☆☆☆☆ ()
Ответ на: комментарий от Vit

Вот тесты есть. На прошлой неделе как раз делал доклад на эту тему. Мы запускаем юниттесты на устройствах и отчёты в Дженкинс выкладываем. Речь идёт именно о микроконтроллерах

vromanov ★★ ()

Для идиотов есть абдурины, а для думающих и понимающих людей — даташиты с RM. Вход достаточно просто, благо, на гитхабе уже завались проектов!

Мое.

anonymous ()
Ответ на: комментарий от anonymous

Там 64 кило памяти всего. Да и не вижу смысла ради не блокирующего delay целый линупс втаскивать.

Vit ★★★★★ ()
Ответ на: комментарий от vromanov

Только полный идиот будет кал использовать! Есть CMSIS, есть документация. Вперед!!!

anonymous ()
Ответ на: комментарий от Vit

64 кило памяти всего

Фигасе! У меня и в 8 нормально кое-что укладывалось. Прост думать надо, а не идиотизмом маяться!!!

anonymous ()
Ответ на: комментарий от anonymous

Эдвард, у меня вопрос не как бросить пить и начать программировать на stm32, а про среды разработки и способы управления проектом/зависимостями. Как-то не хочется возвращаться в девяностые после современного и прекрасного яваскрипта.

Vit ★★★★★ ()
Ответ на: комментарий от anonymous

Наконец-то пошли советы по существу. А то никто и не вспомнил, что надо думать. Спасибо, родимый.

Vit ★★★★★ ()
Ответ на: комментарий от vromanov

Что не так с зависимостями-то? Это ж сишная фишка, что пакеты не завезли, а не эмбедная. На расте по крейтам очень бордо код раскладывают, и это выглядит красиво и удобно.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Среда разработки — любой текстовый редактор. Прошивать либо через бутлодыря, либо через st-link (мне первый вариант больше нравится), управление проектом стандартное — VCS вроде гита или ртути.

А если мозгов нет, то в канаву на абдурину!

anonymous ()
Ответ на: комментарий от Vit

Имхо потому, что в тот-же фат надо прикручивать. И часто не нужны последние версии пакета, т.к. ничего нового не появляется. А большая часть работы в написании драйверов к какой-либо перемирии или бизнесс-логики. При этом для разных платформ это надо делать по разному. Если хочется красоты, попробуйте какой-нибудь autosar по цене лицензии для разработчика 50к

vromanov ★★ ()
Ответ на: комментарий от vromanov

Какой, нафиг, фат? Есть куча файловых систем для МК! Для элементарных вещей можно тупо в виде tar писать!!!

anonymous ()
Ответ на: комментарий от vromanov

Посмотри Rust. Там и HAL и все прочее нормально по пакетам разнесено. Нет такой проблемы. Есть раздолбайство и дурные привычки из девяностых.

Если хочется красоты, попробуйте какой-нибудь autosar по цене лицензии для разработчика 50к

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Посмотри Rust
Надо чтобы любая обезьяна смогла быстро все поднять

Тогда только абдурина, т.к. обезьяне — обезьянье!!!

anonymous ()
Ответ на: комментарий от vromanov

https://github.com/japaric/embedded-hal я таки настойчиво предлагаю сначала заглянуть в документацию. Там просто надо заменить крейт с имплементацией под конкретную архитектуру. Можно даже под линукс собрать для тестов.

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

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

Vit ★★★★★ ()
Ответ на: комментарий от vromanov

У себя на работе под одеялом каждый волен делать что хочет. Просто надо аккуратнее экстраполировать на всех, IMHO.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Ты уже осилил раст в эмбедах или будешь конца светагода ждать?

Я не занимаюсь мелким эмбедом. В любом случае, заказчик требует С/С++, да и на целевых платформах Rust не будет как минимум никогда.

tailgunner ★★★★★ ()
Ответ на: комментарий от Vit

Эээ. Было бы интересно посмотреть, на процент количества проектов на расте и с использованием пакетного менеджера на stm32, я уж не говорю о более серьезных MCU.

vromanov ★★ ()

Эмбедщики, по наблюдениям, наиболее упоротые даже среди системных погромистов (вспоминаем про царя-ссишку), а вы про какой-то попсовый раст заикаетесь, IDE, пакетный менеджер(!)

Virtuos86 ★★★★★ ()
Ответ на: комментарий от Virtuos86

Ну это лирика, которая никак не отвечает на вопрос, а как же под эмбеды кодить прилично и современно.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Так физики выше уже ответили, как прилично, а современно им, не привыкшим к передовым инновациям, и не нужно.

Virtuos86 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.