Pull to refresh

Comments 79

Важно, что просто так взять и построить проект под STM32 не выйдет

Легко и очень просто. STM32Cube и через 5 минут готовый каркас со всей инициализацией готов.
О, я отстал от жизни. Когда я последний раз его смотрел, он назывался по-другому и генерации кода не имел.
(смущенно) Сам недавно переоткрыл его :) Пока у него только один большой и жирный минус — полностью завязан на HAL, назвать который «свободным от глюков» и «документированным» у меня ничего не поворачивается. :)
Ну вот напишу, как собрать проект с нуля и темплейты сделать в IAR-е
У меня уже есть аналогичное для Keil & STMCube, но правила хабра не позволяют сюда запостить. Думаю, с IARом будет разница только в одном дропселекте :)

Но в любом случае, давайте, ибо мало, катастрофически мало материалов по stm32
Печально, что оный STM32CubeMX есть только под Win (хотя и написан на яве). И, судя по всему, они таки выпилили StdPeriphLib и заменили её на hal в составе STM32CubeFx.
ну под wine он пускался у меня отлично, а под макосью у меня виртуалка есть.

А про STD — они ее забросили окончательно и теперь все на HAL тащат. И в этом я их поддерживаю, ибо STD — это реально за гранью добра и зла :)
ну под wine он пускался у меня отлично, а под макосью у меня виртуалка есть
Оно сейчас требует jre 7u45+, а оно под wine 1.7 не заводится (ни x86, ни amd64 версия, во всех трёх комбинациях winearch). А виртуалки я периодически выношу, т. к. эта порнография места жрёт немерено.

А про STD — они ее забросили окончательно и теперь все на HAL тащат. И в этом я их поддерживаю, ибо STD — это реально за гранью добра и зла :)
Посмотрел в код hal по тем модулям, с которыми уже имел дело. И не вижу принципиальных отличий от spl. Чуть более причёсано и документации побольше. Из приятных бонусов — сделали, похоже, нормальную поддержку dma для периферии. Что вы подразумевали под «за гранью добра и зла»?
Для меня за «гранью добра и зла» (когда я очень сильно матерился и соскочил на opencmp3) было то, что код общения с периферией был для каждого контроллера свой (отличался в нюансах типа смещений регистров, но отличался). А у меня как раз был период, когда мне надо было «раскатить» один код на несколько моделей (да, изврат, но надо было)…

А сейчас (скажу честно, пока большого опыта с HAL нет) — мои околотестовые задачи таскаются с контроллера на контроллер «как есть» — единственное что меняется — это частоты и делители. Очень радует
Я вот на микрочиповских примерах понял суть драйверов — они под несколько мк пишут драйвер (и ты под свой можешь написать), а код при этом тот де остается. В СТМ-ных примерах есть зачатки этого, но мне сильно меньше это нравится — все на дефайнах…
Надо будет подробнее посмотреть на libopencm3. Несмотря на то, что написано по поддержке железа поддержка stm32 неплохая. Количество открытых тикетов, конечно, большое, но для бурно развивающейся библиотеки это нормально. Ещё радует, что код в libopencm3 куда качественнее, чем в StdPeriphLib от st.

С контроллера на контроллер всё хорошо таскается в рамках одного семейства. А при скачке с F1 на F4, например, меняются как само ядро (с cm3 на cm4/cm4f, что сказывается на доступных интристиках, появлении hardfp, dsp-инструкций), так и периферия с errata ко всему этому барахлу. Например, на F4 у GPIO есть отдельные биты для управления подтяжкой. Доступная периферия разная, DMA потоки и каналы разные и т. п. Если нужна портируемость между семействами, то, в любом случае, надо изолировать платформо-зависимый код и делать условную сборку (где-то на дефайнах, где-то по разным файлам раскидывать).

В любом мало-мальски нетривиальном приложении выделится свой hal под данную задачу. В качестве примера могу привести свой код с гитхаба: github.com/grossws/stm32-lcd/blob/master/lcd.c. Низкоуровневые функции изолированы в отдельном куске, что облегчает портирование при необходимости. Даже для хобби-проектов это может быть полезно.

Посмотрел на stm32cubef4 (новый hal). Может, они наняли новых индусов. Или стали использовать металлическую линейку, но качество кода и комментариев подросло. Всякий io код почти однообразно выглядит для блокирующих и асинхронных (через прерывания или dma) вызовов. И пляшут теперь не от железа конкретной линейки, а от функционала, что должно упростить портирование в будущем. Пока из неприятностей столкнулся с тем, что dma выставляет fifo error даже в случае, если fifo был отключен. ST предлагает его игнорировать, но не делает это в cube.

куски кода
int main(void) {
  HAL_Init();
  uart_init();
  while(1) {
    uart_loop();
  }
  return 1; // never
}

// from uart.c
void uart_init(void) {
  uart.Instance = USARTx;

  uart.Init.BaudRate = 57600;
  uart.Init.WordLength = UART_WORDLENGTH_8B;
  uart.Init.Parity = UART_PARITY_NONE;
  uart.Init.StopBits = UART_STOPBITS_1;
  uart.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  uart.Init.Mode = UART_MODE_TX_RX;

  if(HAL_UART_Init(&uart) != HAL_OK) {
    Error_Handler();
  }
}

void uart_loop(void) {

  if(HAL_UART_Receive(&uart, rx_buf + rx_buf_idx, 1, UART_TIMEOUT) != HAL_OK) {
    return;
  }
  rx_buf_idx++;

  LEDg_ON();
  HAL_Delay(10);
  LEDg_OFF();

  // buffer full
  if(rx_buf_idx == BUFSIZE) {
    _uart_flush();
  }

  if(rx_buf[rx_buf_idx - 1] == '\r' || rx_buf[rx_buf_idx - 1] == '\n') {
    _uart_flush();
  }
}

static void _uart_flush(void) {
  // wait for tx_buf
  while(!_uart_tx_ready);

  memcpy(tx_buf, rx_buf, rx_buf_idx);
  tx_buf_idx = rx_buf_idx;
  rx_buf_idx = 0;

  LEDo_ON();
  if(HAL_UART_Transmit_DMA(&uart, tx_buf, tx_buf_idx) != HAL_OK) {
    Error_Handler();
  }
}

// uart dma/it tx complete callback 
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) {
  _uart_tx_ready = 1;
  LEDo_OFF();
}

// uart dma/it error callback
void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart) {
  LEDr_ON();
  // FIXME: irq prio
  HAL_Delay(50);
  LEDr_OFF();
  _uart_tx_ready = 1;
}

DMA_HandleTypeDef uart_tx_dma;

// HAL_UART_Init callback to init required periph
void HAL_UART_MspInit(UART_HandleTypeDef *huart) {
  USARTx_RX_CLK_EN();
  USARTx_TX_CLK_EN();
  USARTx_CLK_EN();
  USARTx_DMA_CLK_EN();

  GPIO_InitTypeDef gpio;

  gpio.Pin = USARTx_TX_PIN;
  gpio.Mode = GPIO_MODE_AF_PP;
  gpio.Speed = GPIO_SPEED_FAST;
  gpio.Pull = GPIO_NOPULL;
  gpio.Alternate = USARTx_TX_AF;
  HAL_GPIO_Init(USARTx_TX_PORT, &gpio);

  gpio.Pin = USARTx_RX_PIN;
  gpio.Alternate = USARTx_RX_AF;
  HAL_GPIO_Init(USARTx_RX_PORT, &gpio);

  // not used currently
//  HAL_NVIC_SetPriority(USARTx_IRQn, 0, 1);
//  HAL_NVIC_EnableIRQ(USARTx_IRQn);

  uart_tx_dma.Instance = USARTx_DMA_TX_STREAM;
  uart_tx_dma.Init.Channel = USARTx_DMA_TX_CHANNEL;
  uart_tx_dma.Init.Direction = DMA_MEMORY_TO_PERIPH;
  uart_tx_dma.Init.Mode = DMA_NORMAL;
  uart_tx_dma.Init.PeriphInc = DMA_PINC_DISABLE;
  uart_tx_dma.Init.MemInc = DMA_MINC_ENABLE;
  uart_tx_dma.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
  uart_tx_dma.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
  uart_tx_dma.Init.Priority = DMA_PRIORITY_LOW;
  uart_tx_dma.Init.FIFOMode = DMA_FIFOMODE_DISABLE;
  uart_tx_dma.Init.FIFOThreshold = DMA_FIFO_THRESHOLD_FULL;
  uart_tx_dma.Init.MemBurst = DMA_MBURST_INC4;
  uart_tx_dma.Init.PeriphBurst = DMA_PBURST_INC4;

  HAL_DMA_Init(&uart_tx_dma);
  __HAL_LINKDMA(huart,hdmatx,uart_tx_dma);

  HAL_NVIC_SetPriority(USARTx_DMA_TX_IRQn, 0, 1);
  HAL_NVIC_EnableIRQ(USARTx_DMA_TX_IRQn);

  // indication leds rcc en
  LEDg_CLK_EN();
  LEDo_CLK_EN();

  // rx indication led
  gpio.Pin = LEDg_PIN;
  gpio.Mode = GPIO_MODE_OUTPUT_PP;
  gpio.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(LEDg_PORT, &gpio);

  // tx indication led
  gpio.Pin = LEDo_PIN;
  HAL_GPIO_Init(LEDo_PORT, &gpio);
}

void HAL_UART_MspDeInit(UART_HandleTypeDef *huart) {
  USARTx_FORCE_RESET();
  USARTx_RELEASE_RESET();

  HAL_GPIO_DeInit(USARTx_TX_PORT, USARTx_TX_PIN);
  HAL_GPIO_DeInit(USARTx_RX_PORT, USARTx_RX_PIN);

  HAL_DMA_DeInit(&uart_tx_dma);
  HAL_NVIC_DisableIRQ(USARTx_DMA_TX_IRQn);
//  HAL_NVIC_DisableIRQ(USARTx_IRQn);

  HAL_GPIO_DeInit(LEDg_PORT, LEDg_PIN);
}


// from it.c
void SysTick_Handler(void) {
    HAL_IncTick();
}

void USARTx_Handler(void) {
  HAL_UART_IRQHandler(&uart);
}

void USARTx_DMA_TX_IRQHandler(void) {
  HAL_DMA_IRQHandler(uart.hdmatx);
}

Поддерживаю использование STM32 Discovery. Тоже заказывал её. Плата недорогая. Правда я заказал сразу STM32F429 с сенсорным экраном. Потом понял, что сначала нужно было взять STM32F407, т.к. под неё примеров значительно больше. У этих двух плат есть отличия.

Добавлю, что с разворачиванием тулчейна под Linux тоже никаких проблем нет. Чтобы запустить мигающий светодиод пользовался вот этой инструкцией: www.wolinlabs.com/blog/linux.stm32.discovery.gcc.html. Всё компилируется и прошивается очень просто в 2 команды.
вроде вот таких. Платка такая за 6 долларов — совсем неплохо

По ссылке:
Цена: US $28.60

А где по 6?
Там цена за партию из 5 штук.
Цена за партию из 1000 наверно будет еще меньше.
Посмотрел другие предложения, если покупать одну плату, то ценник где-то $10.
Я вообще не понимаю, в чём суть проблем, из-за чего флейм. Чем плохи Discovery? Купите и пользуйтесь, очень недорого.
Все-таки, Discovery 20$ стоит, а минимальная Maple Mini-подобная — ровно впятеро дешевле.
Discovery бывают разные, и стоят по-разному.
1000 ± 200 рублей — не очень большая цена за вход, особенно по сравнению с другими производителями отладочных плат.
Соглашусь. Хотя, сам начинал с AVR, где та самая «плата за вход» оказалась на уровне… буквально 300 рублей (ATMega8535 + программатор Громова на рассыпухе + бесплатный UniProf).
У самого сейчас пара Discovery (F3 + F4 без особых наворотов) и несколько отдельных чипов.
Надеюсь, когда доделаю проект на AVR, займусь ими.
Цена «за вход» ардуины — 4$. А уж за 1000 можно в догонку цветной сенсорный экран получить. Ну так, для сравнения.

Лично я промышленно этим заниматься не планирую, поэтому желание ST продать мне отладочную плату за 1000р я не разделяю.
Не надо путать божий дар с яичницей. Никогда ты не купишь ардуино за $4. Скорее за 20+. А китайские клоны стоят те же $4.

А на Дискавери такой обвес, что 1000р — это халява, радоваться надо. Тем более, что это не вина ST, что у нас нет нормальной почтовой службы. Во всем мире можно Дискавери купить за $8 самую маленькую. И уж точно не их вина в том, что сегодня $8 это не $8 летом, а в два раза дороже
> А на Дискавери такой обвес, что 1000р — это халява

Это не «халява», а оверхед.
ОК, у каждого свои потребности.
Я вот занимаюсь «промышленно», и уверяю вас, что 1000 рублей, это даром по сравнению с некоторыми другими платформами.
Не спорю. Но те платформы ещё менее интересны широким кругам.
Но те платформы ещё менее интересны широким кругам.

И не предназначены для широких кругов, заметим.
Поддерживаю, дискавери это очень удобно! До этого писал под HY-Mini STM32, там каждый раз при прошивке приходилось одним пальцем выполнять комбинацию нажатий Boot0+Reset, получалось не всегда сразу. А на дискавери ничего делать не надо, программатор сам сбрасывает чип и заливает прошивку. К тому же есть отладчик, и его можно подцепить к тому же gdb.
Рискую нарваться на вопли «Сжечь еретика!», но когда мне захотелось приобщиться к ARM, я взял Arduino Due…
Заказывал и юзал. В качестве платы для того, чтобы поиграться — шик. Можно что-то включать/выключать прямо в live-консоли, как в консоли браузера. Случайно сжег её, и сразу заказал новую.
Из очевидных минусов — нужно больше RAM, чем на большинстве дешевых чипов, и интерпритатор JS отъедает и RAM и Flash. То есть программа не компилируется на компе и затем зашивается бинарик, а именно что на плате настоящий JS-интерпритатор. Ну и сама плата не из дешевых.

Если я где не прав или заблуждаюсь, пусть меня поправят.
Espruino работает на куче обычных плат типа Дискавери. Так что можно обойтись дешевыми платами.
Автор активно работает над прекомпиляцией. Чтобы код занимал меньше места и исполнялся быстрее.
Безусловно оно работает на Дискавери. Однако использовать Дискавери в продакшен-устройствах нельзя по соображениям лицензии(об этом тоже написано на сайте Espruino). По поводу прекомпиляции — это очень круто. Означает ли это, что можно будет зашивать готовый бинарик на любой STM32?
Прекомпиляция позволяет не хранить в памяти текстовое представление программы, прошить ссылки на внутренние функции и переменные, соптимизировать еще что-нибудь, но Espruino по прежнему будет в железке со всеми вытекающими ограничениями.
Я так понял, что эта прекомпиляция существует пока в виде эксперимента в ветке репозитория. Полный план и список фич не формализованы.
Не нашел ограничений «по соображениям лицензии». Наоборот есть конкретный вопрос и ответ на эту тему:
CAN I SELL BOARDS CONTAINING THE ESPRUINO SOFTWARE?

Yes, as long as you abide by the terms of Espruino's MPLv2 licence and respect the Espruino trademark (eg. don't call your board an Espruino board unless agreed with us).
LICENSE
STMicroelectronics (“ST”) grants You the right to use the enclosed Evaluation Board offering limited features only to evaluate and test ST
products solely for Your evaluation and testing purposes in a research and development setting. The Evaluation Board shall not be, in any
case, directly or indirectly assembled as a part in any production of Yours as it is solely developed to serve evaluation purposes and has no
direct function and is not a finished product. If software and/or firmware is accompanied by a separate end user license agreement (“EULA”),
then such software and/or firmware shall be governed by such EULA.

EVALUATION BOARD STATUS
The Evaluation Board offers limited features allowing You only to evaluate and test the ST products. The Evaluation Board is not intended for
consumer or household use. You are not authorized to use the Evaluation Board in any production system, and it may not be offered for sale
or lease, or sold, leased or otherwise distributed for commercial purposes. If the Evaluation Board is incorporated in an evaluation system,
the evaluation system may be used by You solely for Your evaluation and testing purposes. Such evaluation system may not be offered for
sale or lease or sold, leased or otherwise distributed for commercial purposes and must be accompanied by a conspicuous notice as follows:
“This device is not, and may not be, offered for sale or lease, or sold or leased or otherwise distributed for commercial purposes”.
Выше ответили уже. Речь шла о том, что нельзя использовать платы Дискавери в продакшене.
ST Nucleo and Discovery boards are sold at a very low price, for evaluation purposes only. According to the Evaluation products license agreement that comes with each board, you must not use them as part of a finished product.
А ну это понятно. Было бы странно использовать их в продакшн.
Из-за фразы «написано на сайте Espruino» я понял, что Espruino нельзя использовать в коммерческих продуктах кроме их родной платы.
Большое спасибо за развернутый ответ про дружбу с STM!

STM32F4Discovery у меня была, но я убоялся количества ножек и общей монструозности сей конструкции и по-тихому ее сбагрил другому желающему поиграться. Хотя, предварительно ввалил в нее Micro Python (тогда еще я был Read-only, и небольшая статейка про это дело песочницу не покинула) и малость поигрался. В целом, после поверхностного знакомства с Discovery. я решил начинать с чего-то попроще.

А вот соорудить ST-Link — это мне в голову не приходило, наверное, прямо сегодня и займусь.

P.S. Платы, которые я заказывал. По 4$.
F4Discovery — хороша! С ней я от мигания диодами до распарсивания команд по WiFi и плавной анимации светодиодов на FreeRTOS практически с нуля дошел за 2-3 мес. Работаю в программировании на WPF под десктоп. Изучал вечерами и по некоторым выходным. Все доступно и удобно.
А вы, случайно, не в курсе — на STM32F0DISCOVERY возможно ли залить Micro Python так, чтобы он на ней работал?
Заливал на STM32F4DISCOVERY, работало (кроме акселерометра). За F0 ничего сказать не могу.
UFO just landed and posted this here
st-link не нужен, iar не нужен, мастдайка не нужна! Мк прекрасно шьются в линксе безо всяких извращений!
МК не нужны, на 155-й серии все отлично собирается.
Зачем 155-я серия? Делаем на голых транзисторах! Так будет эротиШнее ;)
На реле тогда уж. Щелкают прикольно.
Тёплые ламповые тиратроны же!
Может, просто электроны пинать ногами?
Ну, МК-то нужны. Не нужны идиоты, которые вообще не имея образования, суют куда попало свои ручонки!
ПОПУляризация техники не нужна! Нужна популяризация знаний.
В мире знаний всякое говно вроде «ардуйни», «бубунты», «яблофонов» было бы не нужно, т.к. просто не было бы клиентуры. Умный человек говно покупать не будет.
Давайте еще про капиталистических акул и зомбирование хомячков искусственными потребностями.
хомячков зомбировать не надо: они по определению уже зомбированы. их учить надо, чтобы не было вокруг этой непробиваемой тупости с мастдайками, ардуйней, гей-осями и прочей дрянью!
Ок. Всем выдать по красной книжечке с текстом GNU GPL, загнать в бараки и учить уму-разуму. Ничего так, утопичненько.
Хмм. Собрал сейчас подобие ST-Link, не работает от слова «вообще». Не определяется компом как устройство.
И… проблема решена. На Maple резистор между D+ и 3v3 подтягивается через транзистор, управляемо. Тут нам такое не надо, поэтому ставим резистор на 1.5 КОм и радуемся.
Итого, для превращения Maple Mini в ST-Link нужно четыре резистора (220 Ом, 1.5 КОм, 2 шт. по 4.7 КОм) и несколько проводков. Работает (проверил заливку прошивки и кокосовый дебаг).
Прекрасно! Я статейку уже написал.
ограничение кода 8 кб, я ни разу не утыкался в него

Ничего дружище, всё ещё впереди!
я периодически упираюсь в объем флеша на камне :) Приходится подключать оптимизацию, чтобы как-то уместиться
mbed.org — совсем игрушка. Детский сад — штаны на лямках. И с документацией беда. Но вот светодиодом поморгать, не устанавливая вообще ничего на свой комп — это да, легко и непринужденно.
Эээ… Это, пожалуй, самое необычное, что я видел на главной странице в своей ленте:) Даёшь больше технических батлов!:)
>>как надо дружиться с STM32.
через datasheet.
Не знаю, на мой взгляд они там в ST что-то не совсем то делают в смысле продвижения этих МК. Заявлено вроде бы как замена Ардуино, но замены как-то не получается, слишком сложно пользовать. Это скорее уровень после освоения Ардуино, больше возможностей, но порог вхождения выше. Платы же отладочные, дискавери, можно сказать, копеечные, расчет явно на массовость. Тут на хабре разрекламировали эти контроллеры, а у меня соображение было, на МК примитивную систему навигации сделать, чтобы положение сенсора в пространстве грубо отслеживать, в пределах нескольких метров и показания сенсора на ПК передавать. Можно было бы это потом как-то попользовать для сканеров, например, металлоискателей, ближней локации и т.п. Сам я не программист, больше железячник, причем, больше по аналоговой технике. Тем не менее, решил попробовать. Ну вот приобрел я эту плату, сначала на кортекс M3, кое-как через кейл запрограмировал, поморгал дидами, потом взял пример (не из Cube) и сделал обмен с ПК через аудиопорт (понятно, что лучше через COM, USB и пр., но уж как смог). Даже отписался по этому поводу здесь: habrahabr.ru/post/224169/
Дальше нужно было акселерометр/гироскоп как-то к этому приделать, данные с него обрабатывать и в ПК передавать. Отдельно акселерометр брать не стал, приобрел другую плату STM дискавери, со встроенным акселерометром, но уже на кортекс М4. Взял пример с акселерометром из Cube, попытался допилить — весь мозг сломал. Сначала оказалось что на моей плате акселерометр не того типа, что в примере. Причем, определять это пришлось экспериментально, маркировки там нет и никакой сопроводительной документации к плате также. Ну ладно, нашел даташит на нужный акселерометр, переставил цифирьки-буковки, что-то вроде заработало — но только в пределах примера, а в явном виде в примере значения ускорений мне там найти не удалось. Обмен там шел через DMA, все летало мимо процессора. Для обработки же нужно было иметь ускорения по трем осям в явном виде в дискретные моменты времени. Возился долго, потом бросил — времени нет, нужно же и по работе что-то делать. У меня приятель есть, под Ардуино программирует, я ему STM32 порекомендовал, плату предложил попользовать, думал, разберется, потом меня научит, он вроде сначала загорелся, потом почитал все эти даташиты и то что есть по этому поводу в интернете и энтузиазм пропал. Так что начинающим, на мой взгляд, вряд ли это посоветуешь.
Дык не нужно уж совсем за идиота меня держать, все скачал, что мог с этого сайта, и схемы, и даташиты, и библиотеки, и даже рекламные листы посмотрел. С русскоязычных форумов тоже информацию брал, т.к. английский знаю плохо. В платах с акселерометром они сначала ставили акселерометр одного типа, потом стали ставить другого, схемы на сайте оказались для старого варианта и примеры в библиотеках также. Сейчас, возможно, заменили уже.
Я на stm32f4-discovery при экспериментах с spi тоже матерился, т. к. акселерометр на плате оказался не тот, что в примерах кода (в частности, он возвращает другой id, 0x3f, а не 0x3b). Хотя сейчас на сайте указано, что устанавливается «LIS302DL or LIS3DSH».
Что еще досадно, нашел несколько примеров использования акселерометра, несложные сравнительно программы, статьи на русском языке — но для 302DL. Для 3DSH их приспособить не удалось. 3DSH это вроде бы более новый акселерометр, более точный или более чувствительный. Библиотечный пример для 302DL приспособить для 3DSH удалось, частота моргания светодиодов зависела от направления и величины наклона. Как мышь плата тоже работала. Правки там были незначительные, типа этот самый id поменять и/или еще что-то, не помню точно. Библиотечный пример для использования оказался непригоден, там какой-то сложный многоуровневый код, очень запутанный. Только в рамках функциональности примера — диоды местами поменять и т.п., да и то не слишком просто.
И еще добавлю, по поводу качества кода примеров. Загружается стандартный набор, компилируется и линкуется, Времени это занимает много, минуты или даже десятки минут. Большая часть файлов в проекте примера не нужна, при удалении их из проекта функциональность не страдает. Еще часть просто удалить нельзя, хотя их ненужность очевидна. При их удалении линковщик выдает ошибки, на них есть ссылки в других файлах. Если закомментировать эти ссылки, проект примера нормально собирается и нормально функционирует. Т.е. никто оптимизацией примеров явно не занимался, просто втупую что-то наваяли под копирку.
А STM32 вроде же можно программировать через UART. Обычный USB-UART конвертер для этих целей не подойдёт?
У SWD немного больше возможностей, чем просто заливка бинарного файла. А так, да, можно.
Просто немного знаком с AVR микроконтроллерами и планирую попробовать STM32. Так что пока больше интересуют не возможности, а как можно более простой старт.
Простой старт — это ST Nucleo и mbed. На Nucleo отладчик ST-Link встроенный.
Если хочется разбираться «с основ», тогда можно взять любой голый чип, и заливать прошивку по UART.

Собственно, тут habrahabr.ru/post/247241 я прошивал STM32F103CB с помощью USB UART.
Самое неудобное — это то, что для прошивки по UART нужно совершить пару манипуляций, чтобы ввести МК в режим UART загрузчика. Быстро надоест. SWD можно вообще не отключать, он работает «на лету».
Пойдет, причем я сейчас поигрался с ESP8826, там народ делает так — нога, которую при прошивке требутся тянуть к земле/питанию подключают к DTR, а ресет МК подключаеют к RST переходника. А в прошивальном скрипте дергают DTR/RST и проц автоматом входит в режим перограммирования. Но придется, похоже, делать обертку на каком-нить питоне, плюс без отладки тяжко жить в мире МК…
Я тоже сейчас играюсь с ESP8266. Только на моём глубоко китайском конвертере не так то просто будет вытащить DTR/RST.
Sign up to leave a comment.

Articles

Change theme settings