Комментарии 36
Решение довольно простое - нужно исправить досадную ошибку и запустить процесс программирования или стирания удерживая кнопку сброса. Когда программа будет выполнять повторы подключения, отпустить сброс.
Все гораздо проще. Перед подачей питания на контроллер (либо нажатием кнопки сброса) нужно BOOT0 подтянуть к VCC. Делается это соответствующей перемычкой или зажатием соответствующей кнопки. Контроллер переводится в режим DFU и его можно шить хоть через SWD, хоть через UART, хоть через USB (в F1 не поддерживается)
А можно один раз в китайском "свистке" вывести наружу сигнал сброса (нога 18 контроллера) и забыть об этих мучениях навсегда.
насколько я помню, можно в настройках openocd указать сброс через сам отладчик
-f ../scripts/board/st_xnucleo_f4.cfg -c "reset_config none separate" -c "init" -c "reset halt"
-c "reset_config none separate" — означает, что сброс производится через SWD без использования отдельной ножки сброса (а у меня как раз такой китайский отладчик)
Проблема в том, что самим пинам SWD программно могут быть назначены другие функции (по ошибке, как в примере, либо намеренно). В таком случае для установления связи по SWD нужно держать ядро в сбросе (тогда пины будут исполнять функцию по умолчанию - SWD). Для случая «по ошибке», как написали выше, действительно достаточно замкнуть nRST любым подручным средством. Однако для проекта с сознательно переназначаемым SWD это уже будут постоянные мучения и проще один раз допаять один провод в самом отладчике.
Плагин PlatformIO к VSCode не рассматривали? Я поставил его, а от Куба полностью отказался.
Я смотрел на PlatformIO, но решил отказаться. Очень не люблю когда на двадцать строк кода добавляется пол-мегабайта служебных файлов. И от меня прячется основная часть работы. По этой причине я в своё время отказался от AVR CodeVision, потом от AVR Studio, потом от Eclipse. Сам PlatformIO показался громоздким и избыточным. Опять же этомоё мнение и никого ни к чему не призываю.
Мне кажется, что куб прячет гораздо больше и добавляет в проект несколько мегабайт файлов. Причём я если при генерации проекта выбирал везде LL, и копировать только используемые файлы, он мне все равно в папку проекта кроме CMSIS накидывает и HAL, и main.c создаёт довольно не слабый. Может я конечно кубик готовить не умею. Я использую CMSIS, и всю инициализации пишу сам, а платформио библиотеки в проект не копирует, и вся папка проекта у меня килобайт на 60 выходит.
А компилированный проект при этом тяжелый или сравнительно лёгкий?
Кубик про запас накидывает всё необходимое
Если посмотрите Makefile, то там подключаются только те файлы исходников, которые используются, а дальше всё на совести gcc.
#include "stm32f4xx.h"
#define BLUE (15)
#define ORANGE (13)
int main()
{
RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN | RCC_AHB1ENR_GPIOAEN | RCC_AHB1ENR_GPIOCEN;
// для выбора порта прерывания обязательно включить тактирование контроллера системного конфигурирования
RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN;
GPIOD->MODER |= GPIO_MODER_MODER13_0 | GPIO_MODER_MODER15_0;
GPIOC->PUPDR |= GPIO_PUPDR_PUPDR6_0; // подтягивающий резистор к питанию
EXTI->RTSR |= EXTI_RTSR_TR0; // прерывание по 0 линии по повышению (rising)
EXTI->FTSR |= EXTI_FTSR_TR6; // прерывание по 6 линии по падению (falling)
EXTI->IMR |= EXTI_IMR_MR0 | EXTI_IMR_MR6; // снимаем маскирование прерываний по линиям 0 и 6
SYSCFG->EXTICR[0] |= SYSCFG_EXTICR1_EXTI0_PA; // прерывание по 0 линии с порта A
SYSCFG->EXTICR[1] |= SYSCFG_EXTICR2_EXTI6_PC; // прерывание по 6 линии с порта C
NVIC_SetPriority(EXTI0_IRQn, 15);
NVIC_SetPriority(EXTI9_5_IRQn, 10);
NVIC_EnableIRQ(EXTI0_IRQn);
NVIC_EnableIRQ(EXTI9_5_IRQn);
for(;;){
asm("NOP");
}
}
void EXTI0_IRQHandler(void)
{
EXTI->PR = EXTI_RTSR_TR0;
GPIOD->ODR ^= (1 << BLUE);
}
void EXTI9_5_IRQHandler(void)
{
EXTI->PR = EXTI_RTSR_TR6;
GPIOD->ODR ^= (1 << ORANGE);
}Мне не с чем сравнивать, я начинаю только. Сейчас разбираюсь с прерываниями. Два светодиода, две кнопки, два прерывания. Код в платформио выглядит так. Файл bin 884 байта.
Бинарник вполне компактный. Минимальный размер. Можете еще утрамбовать, но там уже придётся руками адреса прописывать, плюс в ассемблер удариться.
Спасибо за совет, но думаю мне пока рано. Первый месяц в микроконтроллеры ударился. Но может через какое-то время и до ассемблера доберусь. Адреса вручную есть смысл? Ведь все определения в CMSIS задефайнены, и вроде на размер влиять не должны. Разве что функции работы с прерываниями заменить на запись в регистры.
Как вы оценили минимальность? Сам вот этот видимый код выше со включённой оптимизацией оттранслируется во что-то порядка 200 байт. А остальное — раздутые startup, SystemInit и прочие чудеса, заботливо добавляемые Кубом до вызова main, о существовании которых немало начинающих и не подозревает, т.к. их код туда не ссылается.
Я тоже выкидываю из Кубовского проекта всё безбожно, меня от него интересуют только свежие библиотеки и начальная инициализация тактировки, HAL выпиливаю начисто.
Пробовали STM32CubeIDE? Или не рассматривали так как основано на eclipse? Просто всё-равно использовали CubeMX для конфигурации, а в обозначенной IDE он встроен
STM32CubeIDE я смотрел когда тот ещё был совсем маленьким и запустить проект на Eclipse было проще чем на STM32CubeIDE. К тому же тогда его не было для Linux. Сейчас для меня основным набором являются Си для микроконтроллеров (STM8, STM32 AVR) и Python для служебных утилит. Если учесть что я перемещаюсь между Window, Debian и Raspberry (да, я использую RPI 4 8 Gb как нормальную машину) то полная кросплатформенность для меня важна.
Уже пару лет как вполне хорошо с CubeID, посмотрите еще раз.
Уже пару лет как всё очень плохо с STM32CubeIDE.
Оно медленное. Оно очень плохо работает с Makefile-проектами. Оно постоянно качает гигабайты обновлений.
Вы скачали CubeIDE и решили попрограммировать. Выбираете процессор или плату и оно начинает качать библиотеки - так мегабайт по 700. Поменяли семейство? Опять качать ВСЁ. Невозможно выбрать компоненты, оно скачает весь BSP, примеры, библиотеки для фат, фриртос, аудио, сенсорных экранов и ещё 100500 компоненотов.
А через пару недель прилетает обновление и пожалуйте качать заново библиотеки для старых проектов. С STM32CubeIDE не бывает так что его просто можно запустить и начать программировать. Впрочем, у других производителей ситуация не лучше, а наверно ещё хуже. При таком качестве бесплатного софта не удивительно что IAR прямиком из 1998 года продают за большие деньги и он народу нравится.
IAR комуто нравиться? Не знал этого.
Интерфейс топорный, плюшек типа автокомплита и интеграции с гитом нету, но работает очень стабильно, быстро, и имеет кучу плагинов для отладки (например для ОСРВ). И конечно же нету добровольно-принудительных обновлений посреди рабочего дня и всплывающих "помощников". Он для тех кому ехать, а не шашечки.
Не знаю как IAR, а вот с Keil'а пытаемся слезть на описанную в статье связку. Сейчас занимаемся корректировкой рабочего проекта.
Там вроде свой компилятор какой-то крутой плюс очень много всяких плюшек в виде плагинов.Очень мощная штука для серьезных вещей. Есдинственный "минус" - интерфейс.
А CubeIDE научилось в нормальный автокомплит не по горячим клавишам?
По RPI как впечатления? Не тормозит? Намного дольше собирает?
Смотря с чем сравнивать. Первая сборка идёт дольше, но потом пересобираются только изменённые файлы, а это один - два. Если учесть, что большую часть времени тупишь над котодом или смотришь результат в режиме отладки, то если время полной сборки будет пятнадцать секунд, а не десять - я переживу.
Всё остальное работает как и на большой машине.
Идём Файл -> Настройки -> Параметры, откроется вкладка с настройками. Далее Текстовый редактор -> Шрифт и ищем надпись Изменить в settings.json.
Можно проще перейти в файл с настройками: ctrl+shift+P -> Open settings (JSON)
А ещё есть прекрасное расширение для VSCode STM32-for-vscode, которое из подготовленного кубом проекта и мэйкфайла конфигурирует task.json, settings.json, launch.json, c_cpp_properties.json. А также может сам скачать и настроить openocd и arm-none-eabi-gcc. Короче, сделать всё что описано в статье :)
Не спорю, но зачем мне ещё один плагин, если я всё это могу и сам сделать за пять минут.
Что Вы будете делать, когда автору плагина надоест его поддерживать, а вы знать не знаете о той ерунде которую он делал? Уже не раз столкнулся с такой ерундой на Eclipse, когда программист решил не переписывать плагин под новую версию среды.
Не, так не пойдёт, мне нужно намного более подробней, а автор первоначально заявил что это для тех кто с AVR на STM32 перескакивает, и тут же несколько раз заявляет что это он объяснять не собирается и типа везде есть инфо - сами разберётесь. У меня например проблема CubeIDE установить, недавно мне подсказали что типа Java не той версии, надо устаревшую, хотел обойтись только VSCode, но из текста пришлось типа "самому" разобраться и без куба всё равно не пойдёт. Не хорошо так поступать, многообещающее название но по сути пустая болтовня.
Настройка VSCode для программирования stm32 в Linux и не только в Linux