Pull to refresh

Comments 31

И самый простой вариант, который Я не буду рассматривать в статье: ST CubeIDE.

Тут кому что удобнее и по сути это дело вкуса.

Можете немного подробнее раскрыть чем же установка и настройка целого набора программ и прочих средств разработки удобнее, чем установка установка одной среды, где уже производителем настроено всё? Спрашиваю на полном серьёзе, не с целью наехать. Может быть мне тоже такое надо, но я просто не понимаю плюсов такого решения.

Мне VSCode как-то больше по душе пришелся из рассмотренных в статье вариантов)))

учитывая что половина статьи это таки эклипс...

Потому что объем действий в нем больше чем в VSCode)))

так вроде о том и вопрос - зачем производить "объем действий" когда можно поставить в полторы команды cubeide.

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

Ну, если исключительно stm в разработке - да. А если сразу несколько разных микроконтроллеров и, одновременно сервис для работы с ними с хоста? Между IDE прыгать - неудобно.

Эклипс - комбайн.

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

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

Не в контексте именно разработки, но да, мне такое надо. Спасибо.

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

Установка одной среды не спасает при необходимости делать сборку на тех же Github Actions. Я как-то раз настраивал сборку при помощи headless eclipse одной вендорской IDE, и это было самым большим стимулом перейти окончательно на gcc+cmake+vscode

Как минимум VS Code поддерживает кучу плагинов, типа cmake, Ctest, pvs stduio, asciidoc, ouml и так далее, все можно делать в одной среде, и код и требования, и дизайн и юнит тесты и проверка статический анализатором и так далее.

Один раз настроил и дальше уже удобно и просто.

-наличие make cmake + gcc проектов не от stm , проекты на других платформах и языках

-куда более шустрый и функциональный интерфейс редактора кода чем в эклпипсе

-обнаружил в vscode в качестве плагина просто изумительный uart терминал

сколь я помню, учетку новую теперь тоже создать не так просто. Мою забанили/удалили, восстановить/создать новую не получилось, хотя почта была совсем не .ru

Кажется что проблем с регистрацией gmail.com почты у меня не возникло, а при авторизации в CubeIDE нет такой сумасшедшей проверки геопозиции и должен пустить. Пока что.

Пока что

Перешли на GigaDevice + eclipse. Забыли эту ромашку: "поставляем" - "не поставляем".

Зато вспомнили ромашку "работает" - "не работает"

Аналогично. Старую учётку забанили. При попытке регистрации с gmail.com либо не присылают письмо, либо присылают с уже протухшей ссылкой.

Немного изучив вопрос я нашел интересным для себя интересным плагин для отладки (и он, как оказалось, единственный) Cortex-Debug.

Есть еще Native-Debug, по сути то же самое, никаких преимуществ. Из полезного, но упущенного я бы отметил RTOS-Views плагин

Я бы наверно никогда не добрался непосредственно до эстээмки, если бы это всё было бы необходимо.

Нисколько не критикую автора и его путь, просто апофигел.

Ну на Linux easy-way - это CubeIDE

while (1)
  {
    /* USER CODE END WHILE */
    HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_8|GPIO_PIN_9);
    HAL_Delay(1000);
    /* USER CODE BEGIN 3 */
  }

Лучше размещать код в другом месте, т.к. при переформировании проекта в CubeIDE  расположенный таким образом будет стерт.

while (1)
  {
    HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_8|GPIO_PIN_9);
    HAL_Delay(1000);

    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
    HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_8|GPIO_PIN_9);
    HAL_Delay(1000);

}

Да, дельное замечание

Подскажите, не много не понял. CubeIDE и Eclipse это разве не одно и тоже? Ну в том плане, что CubeIDE это преднастроенный Exlipse? Есть ли смысл морочиться именно с настройкой Eclipse?

Смысл для меня был только в том ,чтобы понять как и из чего слеплен CubeIDE и какие ему есть достойные альтернативы)

Понял понял) Я просто думал, может если в ручную поднимать, то либо лишнее убрать можно или наоборот чего-то полезного прибавилось)

Это уже как следствие, но кажется от ручной настройки как раз накручивается необходимый минимум)

Хотелось бы ещё увидеть настройку SWV( serial wire viever) в связке openocd + vscode. Я долго мучился, но так и не смог поднять этот механизм, хотя он крайне полезен при разработке для отладки т.к. есть способ печати дебага из коробки и не надо занимать другие интерфейсы.

Ещё есть вопрос, почему rdimon, a не файл с заглушками для системных вызовов?

Но у меня тут Cortex-M0, он не поддерживает SWV. Тему возьму на заметку себе. Спасибо.

А что насчёт системных вызовов, в том моменте где проверял компиляцию - на самом деле вообще было не принципиально, что использовать :)

Sign up to leave a comment.