STM Studio -- монітор змінних STM32

Намагаючись дійти толку із SemiHosting без зневаджувача, натрапив на цікавий інструмент: STM Studio. Не слід плутати із купою інших "студій", це не IDE, це: "run-time variables monitoring and visualization tool for STM32 microcontrollers" -- програма, яка дозволяє інтерактивно спостерігати за змінними програми, залитої в мікроконтролер.

Вона використовує згадуваний тут режим моніторингу, тому теж змінює налаштування відладки MCU, але, принаймні (іноді) очищає їх, на відміну від OpenOCD.

Така можливість корисна тоді, коли зупинка в дебагері -- не варіант. Наприклад, при зневадженні коду SemiHosting ;-). Або коли відбуваються якісь процеси, де паузи -- неприйнятні.  

Чудес від цього, доволі простого, інструменту, очікувати не доводиться, але він корисний -- шкодую, що не знав про нього раніше. Не претендуючи на повноту, коротко глянемо, як його можна використовувати.

USB VCP інших плат сімейства STM32 Discovery

"USB Zoo"

Мікроконтролери навіть в межах одного сімейства трішки відрізняються один від одного. Якщо користуватися HAL, портабельність буде високою, але, все ж, не абсолютною. Вирішив повторити описане в попередньому пості, про USB на STM32F3Discovery, для інших плат, обладнаних роз'ємом USB, поміж описаних тут. Їх три (Blue pill поки не розглядав):

• STM32F4Discovery, із MCU STM32F407VG -- ARM Cortex M4F,
• STM32F072BDiscovery, із MCU STM32F072RBT6 -- ARM Cortex M0,
• 32L0538Discovery, із STM32L053C8T6 -- ARM Cortex M0+.

Кожна із цих плат чимось цікава, наприклад, акселерометр та мікрофон в F4, e-Ink-дисплей в L0 тощо -- думаю, ще не раз до них повернемося. Але тут говоритимемо лише про USB CDC VCP.

Досьє на плати сімейства STM32 Discovery

Останнім часом, у нас, в CS@UCU, завелося багато демоплат, поміж них, за кількістю, домінують плати Discovery від STM32. В них почав плутатися вже й і я, що говорити про студентів. Тому вирішив написати такий собі довідничок: короткий опис плати, ключові компоненти, зокрема -- присутня на платі периферія, особливості її мікроконтролера (MCU), супроводжуючи інформацію посиланнями на офіційні сторінки, даташіти і т.д. 

Варто зауважити, що на офіційних сторінках мікроконтролерів, крім даташітів є також посилання на величезну кількість так-званих AppNote -- прикладів використання якихось можливостей мікроконтролерів. Дуже рекомендую ознайомитися хоча б із списками. :-)

Порядок плат менш-більш довільний, грубо -- по спаданню потужності мікроконтролера на платі та різноманітності периферії.

Описано:

• STM32F4Discovery
• STM32F3Discovery
• 32F072BDISCOVERY  
• 32L0538DISCOVERY  
• 32L152CDISCOVERY
• STM32VLDISCOVERY
• китайська "Blue pill"
• екзотична M24LR-DISCOVERY

Вони обладнані мікроконтролерами на базі ядер ARM Cortex M0, M0+, M3, M4F, а M24LR обладнана 8-бітним MCU із сімейства STM8.

STM32F4Discovery

Цікава плата із одним із найпотужніших мікроконтролерів сімейства (на М7 не заглядатимемося поки). Новіший варіант, (із кодом замовлення STM32F407G-DISC1).

Зовсім просто про Virtual COM Port поверх USB плати STM32F3Discovery

Взято тут.

Шина USB, Universal Serial Bus, складна. Звична плата за універсальність і простоту використання. На жаль, я поки із нею знайомий лише побіжно. Однак, не тільки в мене такі проблеми :-). Тому багато популярних мікроконтролерів містять периферію, котра бере турботу про низькорівневі подробиці функціювання USB на себе. Зокрема, є підтримка і у багатьох MCU STM32. На платах STM32F3Discovery, STM32F4Discovery та інших навіть виведено окремий роз'єм (Mini-B та Micro-B, відповідно).

Є він і у ряду плат серії STM32F0, на клонах Maple Mini із STM32F103, тощо. Про них напишу трішки пізніше. Але не ARM-ами єдиними. Поміж плат на AVR теж такі трапляються, зокрема, в сімействі плат Arduino. Я б виділив Digispark -- найменший із Arduino. Детальніше про AVR + USB див. серію статей "AVR ATtiny USB Tutorial Part", але, в принципі, такі фокуси можливі і з іншими Arduino.

Крім того, STMicroelectronics надає Middleware, програмні бібліотеки, які спрощують роботу із USB до майже тривіальної -- якщо не хотіти чогось хитрого.

І ось поверх цього USB демоплат можна влаштувати зручний та дуже швидкий (особливо в порівнянні із semihosting) канал обміну інформацією із комп'ютером --  віртуальний COM-порт (чи UART) , VCP. Подивимося, як це можна зробити.

Зміст:

1. Огляд USB
2.  USB VCP на STM32F3Discovery -- початок
3.  USB VCP -- доводимо до юзабельності

SemiHosting без дебаггера

Взято із: "Getting printf Output from Target to Debugger".

Якщо ви користувалися SemiHosting, то могли зауважити -- коли програма виконується без під'єднаного відладчика (зневаджувача), нічого корисного вона не робить. Звичайно, без згаданого відладчика, чим вона зайнята, не видно, але жодної зовнішньої активності (мигання світлодіодами, комунікація шинами) після спроби скористатися семихостингом не буде. В чому справа і як із тим боротися? 

Найпростіший варіант -- мати "Debug" i "Release" версію програми, і в останній SemiHosting   повністю викидати. В принципі, враховуючи, що даний інтерфейс -- чисто відладочний, це, певне, найкращий варіант -- не варто залишати відладочний код в приладі. Але він має й свої мінуси -- зростає громіздкість коду, більше способів його зламати (див. весь список заперечень проти використання умовної компіляції), все таке. 

Щоб знати, що ще можна зробити, слід розібратися, а чого, власне, програма зупиняється на використанні SemiHosting. Потім -- придумати, як із тим боротися. Наперед скажу -- на жаль, повністю вирішити проблему не вдасться. Все рівно буде потрібно вимкнути-ввімкнути живлення мікроконтролера (демоплати), перш ніж код зможе працювати автономно.

Update 12.12.2017:  Описано особливості ARM Cortex M0 та M0+.

Таймери STM32 -- зміст

Статей про таймери вийшло багато. Щоб краще орієнтуватися, пасує зробити зміст. Потім треба буде його зробити ще й для постів про далекомір. Аналогічний зміст для постів про далекомір.

Проекти із кодом, який використовується в постах, зазвичай можна скачати за посиланням в кінці посту. Історично склалося так, що більшість проектів проекти для CoIDE. В принципі, зараз перейшов на System Workbench for STM32, але якби взявся всі проекти переносити -- написання цих постів точно ніколи б не завершилося.

Розглядається використання CMSIS та HAL+STM32CubeMX. Код Cube та HAL розтинається та аналізується аж до рівня CMSIS -- безпосередньої маніпуляції регістрами.

На жаль, не передбачено простого візуального способу пропустити цей reverse engineering для тих, кому цікаво лише знайти підказку, як скористатися тією чи іншою можливістю. Однак, в тексті все-таки відділяється опис способі використання від аналізу подробиць роботи.

Зовсім просто про далекомір HC-SR04 із GPIO/HAL

Взято тут.

Пост: "Далекомір HC-SR04 -- використовуючи GPIO/HAL/STM32CubeMX" написано виходячи із того, що попередні тексти, зокрема: "Далекомір HC-SR04 -- використовуючи GPIO/CMSIS" читачу відомі, виклад зосереджено лише на нюансах роботи з Cube/CoIDE/HAL. 

Для деяких моїх задач це виявилося незручним. Тому вирішив написати даний текст, де розглянуто роботу із далекоміром, не відволікаючись на подробиці реалізації внутрішньої HAL. 

Подробиці генерації проекту та роботи із середовищем тут не описуватимемо, за ними див., посилання вище та "GPIO мікроконтролерів STM32F303 з використанням HAL". Нам достатньо знати, що один пін, в режимі GPIO-Output, виділено під Trig, один -- в режимі GPIO-Input, під Echo:

Звертаюся самі-знаєте-до-кого -- бездумно "перемальовувати" схему із скріншота -- погана ідея. Для запобігання, тут, за можливості, наводжу лише важливі фрагменти.

Підключаємо їх до відповідних пінів далекоміра.  Увага -- він нормально спрацьовує від логічної одинички 3.3В-мікроконтролера, але для свого живлення потребує 5 вольт!

Принципи роботи із даним пристроєм описані тут: "Далекомір HC-SR04 -- огляд", коротко нагадаємо їх:

Мікросекундні затримки та відлік мікросекунд для STM32

Взято тут.

Затримки тривалістю в мікросекунди, які, наприклад, потрібні для роботи із нашим ультразвуковим далекоміром, не підтримуються HAL. При тому, HAL використовує SysTick, конфігуруючи його так, щоб той лічив мілісекунди, а переконфігуровувати його не завжди можна і не завжди хочеться.

Про те, як переконфігурувати, якщо є таке бажання, див. "Далекомір HC-SR04 -- використовуючи GPIO/HAL/STM32CubeMX", після слів "Ось з відліком часу складніше".

Аналогічно, HAL_GetTick() повертає, по замовчуванню, кількість мілісекунд. Це доволі велика одиниця...

В цьому пості розглянемо альтернативи:

• Активне очікування -- затримку можна зробити, скориставшись так званим busy loop (холостим циклом).
• Лічильник тактів -- його використання дозволяє вирішити обидві задачі, і створення затримок і відлік часу із мікросекундною точністю. (Старші моделі STM32 обладнані лічильником, схожим на той, який на x86 читає команда RDTSC -- DWT->CYCCNT).
• Найбільш загальний варіант -- використання повноцінних таймерів.

Закінчимо виклад кодом, що дозволяє легко переключатися між розглянутими варіантами.

Таймер SysTick

Тактування SysTick. Клікабельно.

Про цей таймер не раз писав раніше, та й інші автори про нього не забували. Однак в цьому блозі про нього завжди говорилося в глибині великих простирадл тексту, вирішив винести в окремий пост.

SysTick timer 

SysTick timer -- простий 24-бітний таймер, частина ядра Cortex M, тому присутній у відповідних мікроконтролерах всіх виробників. Належить до підсистеми контролера переривань, NVIC.

Відлік часу без таймерів

Альтернативний спосіб відліку часу

Кам'яна сокира. (c) Wiki

Відмірювати час за допомогою таймерів -- найбільш зручний і коректний спосіб. Однак, іноді він може не підходити, з тих чи інших мотивів. Одна з альтернатив -- чисто програмна затримка. Іншими словами, контролер змушують якийсь час виконувати задані інструкції. Якщо потік виконання один і переривань не виникає, такий спосіб доволі точний (а з перерахунку вимог, щоб він був точним, видно основні його недоліки). Важливо, що на відміну від x86, час виконання інструкцій мікроконтролера значно більш передбачуваний.

Наведений нижче приклад реалізації базується на коді з Leaflab Maple IDE, аналогу оболонки Ардуїно для STM32. Увага: Приклад може бути неточним -- особливо ретельно я не тестував.

Update: Див. також розвиток теми в "Мікросекундні затримки та відлік мікросекунд для STM32".