Подключение стандартной библиотеки периферии к любому семейству STM32. Подпиленный USB Middleware
Я опять пошел длинным путем - сгенерировал соответствующие заготовки в STM32CubeMX, добавил в свой проект USB Middleware из пакета STM32F1Cube. Нужно только включить тактирование USB, определить обработчики соответствующих прерываний USB и полирнуть по мелочи. По большей части все важные настройки USB модуля я скопировал из STM32GENERIC, разве что чуток подпилил распределение памяти (они использовали malloc, а я статическое распределение).
Вот парочка интересных кусков, которые я утащил к себе. Например, чтобы хост (компьютер) понял, что к нему что-то подключили, устройство “передергивает” линию USB D+ (которая подключена к пину A12). Увидев такое хост начинает опрашивать устройство на предмет кто оно такое, какие интерфейсы умеет, на какой скорости оно хочет общаться, и т.д. Я не очень понимаю, почему это нужно делать до инициализации USB, но в stm32duino делается примерно так же.
Передергивание USB
USBD_HandleTypeDef hUsbDeviceFS;
void Reenumerate()
{
// Initialize PA12 pin
GPIO_InitTypeDef pinInit;
pinInit.Pin = GPIO_PIN_12;
pinInit.Mode = GPIO_MODE_OUTPUT_PP;
pinInit.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOA, &pinInit);
// Let host know to enumerate USB devices on the bus
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_RESET);
for(unsigned int i=0; i<512; i++) {};
// Restore pin mode
pinInit.Mode = GPIO_MODE_INPUT;
pinInit.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &pinInit);
for(unsigned int i=0; i<512; i++) {};
}
void initUSB()
{
Reenumerate();
USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS);
USBD_RegisterClass(&hUsbDeviceFS, &USBD_CDC);
USBD_CDC_RegisterInterface(&hUsbDeviceFS, &USBD_Interface_fops_FS);
USBD_Start(&hUsbDeviceFS);
}
Еще один интересный момент - поддержка бутлоадера stm32duino. Для того, чтобы заливать прошивку нужно сначала перезагрузить контроллер в бутлоадер. Самый простой способ это нажать кнопку ресет. Но чтобы сделать это более удобно можно перенять опыт ардуино. Когда деревья были молодыми контроллеры AVR еще не имели на борту поддержки USB, на плате находился переходник USB-UART. Сигнал DTR UART’а подключен к ресету микроконтроллера. Когда хост посылает сигнал DTR, то микроконтроллер перегружается в бутлоадер. Работает железобетонно!
В случае использования USB мы только эмулируем COM порт. Соответственно перезагрузку в бутлоадер нужно делать самостоятельно. Загрузчик stm32duino кроме сигнала DTR на всякий случай еще ожидает специальную магическую константу (1EAF - отсылка к Leaf Labs)
static int8_t CDC_Control_FS (uint8_t cmd, uint8_t* pbuf, uint16_t length)
{
...
case CDC_SET_CONTROL_LINE_STATE:
dtr_pin++; //DTR pin is enabled
break;
...
static int8_t CDC_Receive_FS (uint8_t* Buf, uint32_t *Len)
{
/* Four byte is the magic pack "1EAF" that puts the MCU into bootloader. */
if(*Len >= 4)
{
/**
* Check if the incoming contains the string "1EAF".
* If yes, check if the DTR has been set, to put the MCU into the bootloader mode.
*/
if(dtr_pin > 3)
{
if((Buf == "1")&&(Buf == "E")&&(Buf == "A")&&(Buf == "F"))
{
HAL_NVIC_SystemReset();
}
dtr_pin = 0;
}
}
...
}
Обратно: MiniArduino
В общем USB заработал. Но этот слой работает только с байтами, а не строками. Поэтому дебаг принты выглядят вот так некрасиво.CDC_Transmit_FS((uint8_t*)"Ping\n", 5); // 5 is a strlen(“Ping”) + zero byte
Т.е. поддержки форматированного вывода нет вообще - ни тебе число напечатать, ни собрать строку из кусочков. Вырисовываются следующие варианты:
- Прикрутить классический printf. Вариант вроде бы неплохой, но тянет на +12кб прошивки (я уже как-то нечаянно вызвал у себя sprintf)
- Откопать у себя в загашниках свою собственную реализацию printf. Я когда то под AVR писал, вроде эта реализация поменьше была.
- Прикрутить класс Print из ардуино в реализации STM32GENERIC
Я создал у себя в проекте директорию MiniArduino с целью положить туда минимально необходимое количество кода, чтобы реализовать нужные мне куски интерфейса arduino. Я начал копировать по одному файлику и смотреть какие еще нужны зависимости. Так у меня появилась копия класса Print и несколько файлов обвязки.
Но этого мало. По прежнему нужно было как то связать класс Print с функциями USB (например, CDC_Transmit_FS()). Для этого пришлось втянуть класс SerialUSB. Он потянул за собой класс Stream и кусок инициализации GPIO. Следующим шагом было подключение UART’а (у меня к нему GPS подключен). Так что я втянул к себе еще и класс SerialUART, который потянул за собой еще пласт инициализации периферии из STM32GENERIC.
В общем я оказался в следующей ситуации. Я скопировал в свою MiniArduino почти все файлы из STM32GENERIC. У меня также была своя копия библиотек USB и FreeRTOS (должна была бы быть еще копии HAL и CMSIS, но мне было лень). При этом я уже полтора месяца топтался на месте - подключал и отключал разные куски, но при этом не написал ни строчки нового кода.
Стало понятно, что моя оригинальная задумка взять под контроль всю системную часть не очень-то получается. Все равно часть кода инициализации живет в STM32GENERIC и, похоже, ему там комфортнее. Конечно, можно было рубануть все зависимости и написать свои классы-обертки под свои задачи, но это бы затормозило меня еще на месяц - этот код же еще отлаживать нужно. Конечно, для собственного ЧСВ это было бы круто, но нужно же двигаться вперед!
В общем, я выкинул все дубликаты библиотек и почти весь свой системный слой и вернулся к STM32GENERIC. Проект этот развивается достаточно динамично - несколько коммитов в день стабильно. К тому же за эти полтора месяца же я много изучил, прочитал большую часть STM32 Reference Manual, посмотрел как сделаны библиотеки HAL и обертки STM32GENERIC, продвинулся в понимании USB дескрипторов и периферии микроконтроллера. В общем я теперь был намного более уверен в STM32GENERIC чем ранее.
Обратно: I2C
Впрочем, мои приключения на этом не закончились. Еще оставался UART и I2C (у меня там дисплей живет). С UART все было достаточно просто. Я только убрал динамическое распределение памяти, а чтобы неиспользованные UART’ы эту самую память не жрали я их просто напросто закомментировал.А вот реализация I2C в STM32GENERIC подложила каку. При чем весьма интересную, но которая отняла у меня как минимум 2 вечера. Ну или подарила 2 вечера жесткого дебага на принтах - это с какой стороны посмотреть.
В общем, реализация дисплея не завелась. В уже традиционном стиле - вот просто не работает и все. Что не работает - не понятно. Библиотека самого дисплея (Adafruit SSD1306) вроде как проверена на предыдущей реализации, но интерференцию багов исключать все же не стОит. Подозрение падает на HAL и реализацию I2C от STM32GENERIC.
Для начала я закомментировал весь код дисплея и I2C и написал инициализацию I2C без всяких библиотек, на чистом HAL
Инициализация I2C
GPIO_InitTypeDef GPIO_InitStruct; GPIO_InitStruct.Pin = GPIO_PIN_6|GPIO_PIN_7; GPIO_InitStruct.Mode = GPIO_MODE_AF_OD; GPIO_InitStruct.Pull = GPIO_PULLUP; GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); __I2C1_CLK_ENABLE(); hi2c1.Instance = I2C1; hi2c1.Init.ClockSpeed = 400000; hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 = 0; hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLED; hi2c1.Init.OwnAddress2 = 0; hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLED; hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLED; HAL_I2C_Init(&hi2c1);
Я задампил состояние регистров сразу после инициализации. Такой же дамп я сделал в рабочем варианте на stm32duino. Вот что я получил (с комментариями самому себе)
Good (Stm32duino):
40005404: 0 0 1 24 - I2C_CR2: Error interrupt enabled, 36Mhz
40005408: 0 0 0 0 - I2C_OAR1: zero own address
40005410: 0 0 0 AF - I2C_DR: data register
40005418: 0 0 0 0 - I2C_SR2: status register
Bad (STM32GENERIC):
40005400: 0 0 0 1 - I2C_CR1: Peripheral enable
40005404: 0 0 0 24 - I2C_CR2: 36Mhz
40005408: 0 0 40 0 - I2C_OAR1: !!! Not described bit in address register set
4000540C: 0 0 0 0 - I2C_OAR2: Own address register
40005410: 0 0 0 0 - I2C_DR: data register
40005414: 0 0 0 0 - I2C_SR1: status register
40005418: 0 0 0 2 - I2C_SR2: busy bit set
4000541C: 0 0 80 1E - I2C_CCR: 400kHz mode
40005420: 0 0 0 B - I2C_TRISE
Первое большое различие это установленный 14й бит в регистре I2C_OAR1. Этот бит вообще не описан в даташите и попадает в секцию reserved. Правда с оговоркой, что туда таки нужно писать единицу. Т.е. это бага в libmaple. Но раз там все работает, значит проблема не в этом. Копаем дальше.
Другое различие - выставленный бит busy. Поначалу я не придал ему значения, но забегая вперед скажу - это именно он сигнализировал о проблеме!.. Но обо всем по порядку.
Я на коленке сварганил код инициализации без всяких библиотек.
Инициализация дисплея
void sendCommand(I2C_HandleTypeDef * handle, uint8_t cmd) { SerialUSB.print("Sending command "); SerialUSB.println(cmd, 16); uint8_t xBuffer; xBuffer = 0x00; xBuffer = cmd; HAL_I2C_Master_Transmit(handle, I2C1_DEVICE_ADDRESS<<1, xBuffer, 2, 10); } ... sendCommand(handle, SSD1306_DISPLAYOFF); sendCommand(handle, SSD1306_SETDISPLAYCLOCKDIV); // 0xD5 sendCommand(handle, 0x80); // the suggested ratio 0x80 sendCommand(handle, SSD1306_SETMULTIPLEX); // 0xA8 sendCommand(handle, 0x3F); sendCommand(handle, SSD1306_SETDISPLAYOFFSET); // 0xD3 sendCommand(handle, 0x0); // no offset sendCommand(handle, SSD1306_SETSTARTLINE | 0x0); // line #0 sendCommand(handle, SSD1306_CHARGEPUMP); // 0x8D sendCommand(handle, 0x14); sendCommand(handle, SSD1306_MEMORYMODE); // 0x20 sendCommand(handle, 0x00); // 0x0 act like ks0108 sendCommand(handle, SSD1306_SEGREMAP | 0x1); sendCommand(handle, SSD1306_COMSCANDEC); sendCommand(handle, SSD1306_SETCOMPINS); // 0xDA sendCommand(handle, 0x12); sendCommand(handle, SSD1306_SETCONTRAST); // 0x81 sendCommand(handle, 0xCF); sendCommand(handle, SSD1306_SETPRECHARGE); // 0xd9 sendCommand(handle, 0xF1); sendCommand(handle, SSD1306_SETVCOMDETECT); // 0xDB sendCommand(handle, 0x40); sendCommand(handle, SSD1306_DISPLAYALLON_RESUME); // 0xA4 sendCommand(handle, SSD1306_DISPLAYON); // 0xA6 sendCommand(handle, SSD1306_NORMALDISPLAY); // 0xA6 sendCommand(handle, SSD1306_INVERTDISPLAY); sendCommand(handle, SSD1306_COLUMNADDR); sendCommand(handle, 0); // Column start address (0 = reset) sendCommand(handle, SSD1306_LCDWIDTH-1); // Column end address (127 = reset) sendCommand(handle, SSD1306_PAGEADDR); sendCommand(handle, 0); // Page start address (0 = reset) sendCommand(handle, 7); // Page end address uint8_t buf; buf = 0x40; for(uint8_t x=1; x<17; x++) buf[x] = 0xf0; // 4 black, 4 white lines for (uint16_t i=0; i<(SSD1306_LCDWIDTH*SSD1306_LCDHEIGHT/8); i++) { HAL_I2C_Master_Transmit(handle, I2C1_DEVICE_ADDRESS<<1, buf, 17, 10); }
После некоторых усилий этот код у меня заработал (в данном случае рисовал полоски). Значит проблема в I2C слое STM32GENERIC. Я начал понемногу удалять своей код, заменяя его соответствующими частями из библиотеки. Но как только я переключил код инициализации пинов с моей реализации на библиотечную вся передача по I2C стала валиться по таймаутам.
Тут я вспомнил про бит busy и попробовал понять когда он возникает. Оказалось что флаг busy возникает как только код инициализации включает тактирование I2c. Т.е. Модуль включается и сразу не работает. Интересненько.
Валимся на инициализации
uint8_t * pv = (uint8_t*)0x40005418; //I2C_SR2 register. Looking for BUSY flag
SerialUSB.print("40005418 = ");
SerialUSB.println(*pv, 16); // Prints 0
__HAL_RCC_I2C1_CLK_ENABLE();
SerialUSB.print("40005418 = ");
SerialUSB.println(*pv, 16); // Prints 2
Выше этого кода только инициализация пинов. Ну что делать - обкладываем дебаг принтами через строку и там
Инициализация пинов STM32GENERIC
void stm32AfInit(const stm32_af_pin_list_type list, int size, const void *instance, GPIO_TypeDef *port, uint32_t pin, uint32_t mode, uint32_t pull)
{
…
GPIO_InitTypeDef GPIO_InitStruct;
GPIO_InitStruct.Pin = pin;
GPIO_InitStruct.Mode = mode;
GPIO_InitStruct.Pull = pull;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
HAL_GPIO_Init(port, &GPIO_InitStruct);
…
}
Но вот незадача - GPIO_InitStruct заполняется правильно. Только моя работает, а эта нет. Реально, мистика!!! Все как по учебнику, но ничего не работает. Я изучал код библиотеки построчно в поисках хоть чего нибудь подозрительного. В конце концов я наткнулся на этот код (он вызывает функцию выше)
Еще кусочек инициализации
void stm32AfI2CInit(const I2C_TypeDef *instance, …) { stm32AfInit(chip_af_i2c_sda, …); stm32AfInit(chip_af_i2c_scl, …); }
Видите в нем багу? А она есть! Я даже убрал лишние параметры, чтобы проблема была виднее. В общем, разница в том, что мой код инициализирует оба пина сразу в одной структуре, а код STM32GENERIC по очереди. Видимо код инициализации пина как то влияет на на уровень на этом пине. До инициализации на этом пине ничего не выдается и резистором уровень подтягивается до единицы. В момент инициализации почему-то контроллер выставляет на соответствующей ноге ноль.
Этот факт сам по себе безобидный. Но проблема в том, что опускание линии SDA при поднятой линии SCL является start condition’ом для шины i2c. Из-за этого приемник контроллера сходит с ума, выставляет флаг BUSY и начинает ждать данных. Я решил не потрошить библиотеку, чтобы добавить возможность инициализации нескольких пинов сразу. Вместо этого я просто переставил эти 2 строки местами - инициализация дисплея прошла успешно. Фикс был принят в STM32GENERIC .
Кстати, в libmaple инициализация шины сделана интересно. Перед тем как начать инициализацию периферии i2c на шине сначала делают ресет. Для этого библиотека переводит пины в обычный GPIO режим и дрыгает этими ногами несколько раз, имитируя start и stop последовательности. Это помогает привести в чувство залипшие на шине устройства. К сожалению аналогичной штуки нет в HAL. Иногда мой дисплей таки залипает и тогда спасает только отключение питания.
Инициализация i2c из stm32duino
/** * @brief Reset an I2C bus. * * Reset is accomplished by clocking out pulses until any hung slaves * release SDA and SCL, then generating a START condition, then a STOP * condition. * * @param dev I2C device */ void i2c_bus_reset(const i2c_dev *dev) { /* Release both lines */ i2c_master_release_bus(dev); /* * Make sure the bus is free by clocking it until any slaves release the * bus. */ while (!gpio_read_bit(sda_port(dev), dev->sda_pin)) { /* Wait for any clock stretching to finish */ while (!gpio_read_bit(scl_port(dev), dev->scl_pin)) ; delay_us(10); /* Pull low */ gpio_write_bit(scl_port(dev), dev->scl_pin, 0); delay_us(10); /* Release high again */ gpio_write_bit(scl_port(dev), dev->scl_pin, 1); delay_us(10); } /* Generate start then stop condition */ gpio_write_bit(sda_port(dev), dev->sda_pin, 0); delay_us(10); gpio_write_bit(scl_port(dev), dev->scl_pin, 0); delay_us(10); gpio_write_bit(scl_port(dev), dev->scl_pin, 1); delay_us(10); gpio_write_bit(sda_port(dev), dev->sda_pin, 1); }
Опять туда: UART
Я был рад, наконец, вернуться к программированию и продолжить писать фичи. Следующим крупным куском было подключение SD карты через SPI. Это само по себе захватывающее, интересное и полное боли занятие. О нем я обязательно расскажу отдельно в следующей статье. Одной из проблем была большая загрузка (>50%) процессора. Это ставило под вопрос энергоэффективность устройства. Да и использовать устройство было некомфортно, т.к. UI тупил ужасно.Разбираясь в вопросе я нашел причину такого потребления ресурсов. Вся работа с SD картой происходила побайтово, средствами процессора. Если нужно было записать на карту блок данных, то для каждого байты вызывается функция отправки байта
For (uint16_t i = 0; i < 512; i++) {
spiSend(src[i]);
Нет, ну это же несерьезно! Есть же DMA! Да, библиотека SD (та, которая идет в комплекте с Ардуино) корявая и нужно менять, но ведь проблема то глобальнее. Та же самая картина наблюдается в библиотеке работы с экраном, и даже слушание UART’а у меня сделано через опрос. В общем, я начал думать, что переписывание всех компонентов на HAL это не такая уж и глупая идея.
Начал, конечно, с чего попроще - драйвера UART, который слушает поток данных от GPS. Интерфейс ардуино не позволяет прицепиться к прерыванию UART и выхватывать приходящие символы на лету. В итоге единственный способ получать данные - это постоянный опрос. Я, конечно, добавил vTaskDelay(10) в обработчик GPS, чтобы хоть немного снизить загрузку, но на самом деле это костыль.
Первая мысль, конечно, была прикрутить DMA. Это даже сработало бы, если бы не протокол NMEA. Проблема в том, что в этом протоколе информация просто идет потоком, а отдельные пакеты (строки) разделяются символом переноса строки. При этом каждая строка может быть различной длины. Из-за этого заранее неизвестно сколько данных нужно принять. DMA так не работает - там количество байт нужно задавать заранее при инициализации пересылки. Короче говоря, DMA отпадает, ищем другое решение.
Если посмотреть внимательно на дизайн библиотеки NeoGPS, то видно, что входные данные библиотека принимает побайтно, но значения обновляются только тогда, когда пришла вся строка (если быть точнее, то пакет из нескольких строк). Т.о. без разницы, кормить библиотеке байты по одному по мере приема, или потом все сразу. Так, что можно сэкономить процессорное время – сохранять принятую строку в буфер, при этом делать это можно прямо в прерывании. Когда строка принята целиком – можно начинать обработку.
Вырисовывается следующий дизайн
Класс драйвера UART
// Size of UART input buffer
const uint8_t gpsBufferSize = 128;
// This class handles UART interface that receive chars from GPS and stores them to a buffer
class GPS_UART
{
// UART hardware handle
UART_HandleTypeDef uartHandle;
// Receive ring buffer
uint8_t rxBuffer;
volatile uint8_t lastReadIndex = 0;
volatile uint8_t lastReceivedIndex = 0;
// GPS thread handle
TaskHandle_t xGPSThread = NULL;
Хотя инициализация слизана из STM32GENERIC она полностью соответствует той, которую предлагает CubeMX
Инициализация UART
void init()
{
// Reset pointers (just in case someone calls init() multiple times)
lastReadIndex = 0;
lastReceivedIndex = 0;
// Initialize GPS Thread handle
xGPSThread = xTaskGetCurrentTaskHandle();
// Enable clocking of corresponding periperhal
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_USART1_CLK_ENABLE();
// Init pins in alternate function mode
GPIO_InitTypeDef GPIO_InitStruct;
GPIO_InitStruct.Pin = GPIO_PIN_9; //TX pin
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_10; //RX pin
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
// Init
uartHandle.Instance = USART1;
uartHandle.Init.BaudRate = 9600;
uartHandle.Init.WordLength = UART_WORDLENGTH_8B;
uartHandle.Init.StopBits = UART_STOPBITS_1;
uartHandle.Init.Parity = UART_PARITY_NONE;
uartHandle.Init.Mode = UART_MODE_TX_RX;
uartHandle.Init.HwFlowCtl = UART_HWCONTROL_NONE;
uartHandle.Init.OverSampling = UART_OVERSAMPLING_16;
HAL_UART_Init(&uartHandle);
// We will be using UART interrupt to get data
HAL_NVIC_SetPriority(USART1_IRQn, 6, 0);
HAL_NVIC_EnableIRQ(USART1_IRQn);
// We will be waiting for a single char right received right to the buffer
HAL_UART_Receive_IT(&uartHandle, rxBuffer, 1);
}
Вообще-то пин TX можно было бы и не инициализировать, а uartHandle.Init.Mode установить в UART_MODE_RX – мы же только принимать собираемся. Впрочем, пускай будет - вдруг мне понадобится как-то настраивать GPS модуль и писать в него команды.
Дизайн этого класса мог бы выглядеть и получше, если бы не ограничения архитектуры HAL. Так, мы не можем просто выставить режим, мол, принимай все подряд, напрямую прицепиться на прерывание и выхватывать принятые байты прямо из приемного регистра. Нужно заранее рассказать HAL’у сколько и куда мы будем принимать байт – соответствующие обработчики сами запишут принятые байты в предоставленный буфер. Вот для этого в последней строке функции инициализации есть вызов HAL_UART_Receive_IT(). Поскольку длина строки заранее неизвестна, приходится принимать по одному байту.
Также нужно объявить аж 2 коллбека. Один - это обработчик прерывания, но его работа всего лишь вызвать обработчик из HAL. Вторая функция – это «отзвон» HAL’а, что байт уже принят и он уже в буфере.
Коллбеки UART
// Forward UART interrupt processing to HAL
extern "C" void USART1_IRQHandler(void)
{
HAL_UART_IRQHandler(gpsUart.getUartHandle());
}
// HAL calls this callback when it receives a char from UART. Forward it to the class
extern "C" void HAL_UART_RxCpltCallback(UART_HandleTypeDef *uartHandle)
{
gpsUart.charReceivedCB();
}
Метод charReceivedCB() готовит HAL к приему следующего байта. А еще именно он определяет, что строка уже закончилась и можно об этом сигнализировать основной программе. В качестве средства синхронизации можно было бы использовать семафор в режиме сигнала, но для таких простых целей рекомендуют использовать прямые нотификации.
Обработка принятого байта
// Char received, prepare for next one
inline void charReceivedCB()
{
char lastReceivedChar = rxBuffer;
lastReceivedIndex++;
HAL_UART_Receive_IT(&uartHandle, rxBuffer + (lastReceivedIndex % gpsBufferSize), 1);
// If a EOL symbol received, notify GPS thread that line is avaialble to read
if(lastReceivedChar == "\n")
vTaskNotifyGiveFromISR(xGPSThread, NULL);
}
Ответной (ожидающей) функцией является waitForString(). Ее задача просто висеть на объекте синхронизации и ждать (или выходить с таймаутом)
Ждун конца строки
// Wait until whole line is received
bool waitForString()
{
return ulTaskNotifyTake(pdTRUE, 10);
}
Работает это так. Поток, который отвечает за GPS в обычном состоянии спит в функции waitForString(). Приходящие от GPS байтики обработчиком прерывания складываются в буфер. Если пришел символ \n (конец строки), то прерывание будит основной поток, который начинает переливать байты из буфера в парсер. Ну а когда парсер закончит обрабатывать пакет сообщений он обновит данные в GPS модели.
Поток GPS
void vGPSTask(void *pvParameters)
{
// GPS initialization must be done within GPS thread as thread handle is stored
// and used later for synchronization purposes
gpsUart.init();
for (;;)
{
// Wait until whole string is received
if(!gpsUart.waitForString())
continue;
// Read received string and parse GPS stream char by char
while(gpsUart.available())
{
int c = gpsUart.readChar();
//SerialUSB.write(c);
gpsParser.handle(c);
}
if(gpsParser.available())
{
GPSDataModel::instance().processNewGPSFix(gpsParser.read());
GPSDataModel::instance().processNewSatellitesData(gpsParser.satellites, gpsParser.sat_count);
}
vTaskDelay(10);
}
}
Я столкнулся с одним очень нетривиальным моментом, на котором залип на несколько дней. Вроде как код синхронизации взят из примеров, но он поначалу не работал – вешал всю систему. Я думал, что проблема в прямых нотификациях (функциях xTaskNotifyXXX), переделал на обычные семафоры, но приложение по прежнему вешалось.
Оказалось, нужно быть очень аккуратным с приоритетом прерываний. По умолчанию я всем прерываниям выставил нулевой (самый высший) приоритет. Но у FreeRTOS есть требование, чтобы приоритеты находились в заданном диапазоне. Прерываниям со слишком большим приоритетом нельзя вызывать функции FreeRTOS. Только прерывания с приоритетом configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY и ниже могут вызывать системные функции (неплохое объяснение и ). Эта настройка по умолчанию задана в 5. Я поменял приоритет прерывания UART на 6 и все завелось.
Опять туда: I2C через DMA
Теперь можно заняться чем нибудь посложнее, например драйвером дисплея. Но тут нужно сделать экскурс в теорию шины I2C. Сама по себе эта шина не регламентирует протокол передачи данных по шине – можно либо писать байты, либо читать. Можно даже в одной транзакции сначала писать, потом читать (например записать адрес, а потом читать данные по этому адресу).Тем не менее большинство устройств определяют протокол более высокого уровня примерно одинаково. устройство предоставляет пользователю набор регистров, каждый со своим адресом. При этом в протоколе общения первый байт (или несколько) в каждой транзакции определяет адрес ячейки (регистра) в которую дальше будем читать или писать. При этом возможен также многобайтный обмен в стиле «ща будем писать/читать много байт начиная с этого адреса». Последний вариант неплохо подходит для DMA.
К сожалению дисплей на базе контроллера SSD1306 предоставляет совсем другой протокол – командный. Первым байтом каждой транзакции идет признак «команда или данные». В случае команды вторым байтом идет код команды. В случае если команде нужны аргументы, то они передаются как отдельные команды следом за первой. Для инициализации дисплея нужно отправить порядка 30 команд, но их нельзя сложить в один массив и отправить одним блоком. Нужно их отправлять по одной.
А вот с отправкой массива пикселей (фрейм буфер) вполне можно воспользоваться услугами DMA. Это мы и попробуем.
Вот только библиотека Adafruit_SSD1306 написана весьма коряво и втиснуться туда малой кровью не получается. По всей видимости библиотеку сначала написали для общения с дисплеем по SPI. Потом кто-то дописал поддержку I2C, причем поддержка SPI осталась включенной. Потом кто-то начал дописывать всякие низкоуровневые оптимизации и прятать их за ifdef"ами. В итоге получилась лапша из кода поддержки разных интерфейсов. Так что прежде чем идти дальше нужно было это причесать.
Сначала я пробовал привести это в порядок обрамляя код для разных интерфейсов ифдефами. Но если я захочу писать код коммуникации с дисплеем, использовать DMA и синхронизацию через FreeRTOS, то у меня мало что получится. Точнее получится, но этот код нужно будет писать прямо в коде библиотеки. Поэтому я решил еще разок перетрусить библиотеку , сделать интерфейс и каждый драйвер вынести в отдельный класс. Код стал чище, и можно было бы безболезненно добавлять поддержку новых драйверов не меняя саму библиотеку.
Интерфейс драйвера дисплея
// Interface for hardware driver
// The Adafruit_SSD1306 does not work directly with the hardware
// All the communication requests are forwarded to the driver
class ISSD1306Driver
{
public:
virtual void begin() = 0;
virtual void sendCommand(uint8_t cmd) = 0;
virtual void sendData(uint8_t * data, size_t size) = 0;
};
Итак, поехали. Инициализацию I2C я уже показывал. Ничего там не поменялось. А вот с отправкой команды немного упростилось. Помните я рассказывал про разницу между регистровым и командным протоколом для устройств I2C? И хотя дисплей реализует командный протокол, его неплохо можно имитировать с помощью регистрового. Просто нужно представить, что у дисплея всего 2 регистра – 0x00 для команд и 0x40 для данных. И HAL даже предоставляет функцию для такого вида передачи
Отправка команды в дисплей
void DisplayDriver::sendCommand(uint8_t cmd)
{
HAL_I2C_Mem_Write(&handle, i2c_addr, 0x00, 1, &cmd, 1, 10);
}
С отправкой данных поначалу было не очень понятно. Исходный код отправлял данные небольшими пакетами по 16 байт
Странный код отправки данных
for (uint16_t i=0; i
Я пробовал поиграться с размером пакетов и отправлять бОльшими пакетами, но в лучшем случае я получал покореженный дисплей. Ну или все висло.
Покореженный дисплей
Причина оказалась тривиальной – переполнение буфера. Класс Wire из ардуины (во всяком случае STM32GENERIC) предоставляет собственный буфер всего на 32 байта. Но зачем нам вообще дополнительный буфер, если у класса Adafruit_SSD1306 уже есть один? Тем более с HAL отправка получается в одну строку
Правильная передача данных
void DisplayDriver::sendData(uint8_t * data, size_t size)
{
HAL_I2C_Mem_Write(&handle, i2c_addr, 0x40, 1, data, size, 10);
}
Итак, полдела сделано – написали драйвер для дисплея на чистом HAL. Но в таком варианте он все еще требователен к ресурсам – 12% проца для дисплея 128x32 и 23% для дисплея 128x64. Использование DMA тут аж просится.
Для начала инициализируем DMA. Мы хотим реализовать пересылку данных в I2C №1, а эта функция живет на шестом канале DMA. Инициализируем побайтовое копирование из памяти в периферию
Настройка DMA для I2C
// DMA controller clock enable
__HAL_RCC_DMA1_CLK_ENABLE();
// Initialize DMA
hdma_tx.Instance = DMA1_Channel6;
hdma_tx.Init.Direction = DMA_MEMORY_TO_PERIPH;
hdma_tx.Init.PeriphInc = DMA_PINC_DISABLE;
hdma_tx.Init.MemInc = DMA_MINC_ENABLE;
hdma_tx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
hdma_tx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
hdma_tx.Init.Mode = DMA_NORMAL;
hdma_tx.Init.Priority = DMA_PRIORITY_LOW;
HAL_DMA_Init(&hdma_tx);
// Associate the initialized DMA handle to the the I2C handle
__HAL_LINKDMA(&handle, hdmatx, hdma_tx);
/* DMA interrupt init */
/* DMA1_Channel6_IRQn interrupt configuration */
HAL_NVIC_SetPriority(DMA1_Channel6_IRQn, 7, 0);
HAL_NVIC_EnableIRQ(DMA1_Channel6_IRQn);
Прерывания - обязательная часть конструкции. Иначе функция HAL_I2C_Mem_Write_DMA() начнет I2C транзакцию, но никто ее не завершит. Опять имеем дело с громоздким дизайном HAL и необходимостью аж двух колбеков. Все точно так же как и с UART. Одна функция это обработчик прерывания - просто перенаправляем вызов в HAL. Вторая функция - сигнал о том, что данные уже отправились.
Обработчики прерываний DMA
extern "C" void DMA1_Channel6_IRQHandler(void)
{
HAL_DMA_IRQHandler(displayDriver.getDMAHandle());
}
extern "C" void HAL_I2C_MemTxCpltCallback(I2C_HandleTypeDef *hi2c)
{
displayDriver.transferCompletedCB();
}
Разумеется, мы не будем постоянно опрашивать I2C а не закончилась ли уже пересылка? Вместо этого нужно уснуть на объекте синхронизации и ждать пока пересылка закончится
Передача данных через DMA с синхронизацией
void DisplayDriver::sendData(uint8_t * data, size_t size)
{
// Start data transfer
HAL_I2C_Mem_Write_DMA(&handle, i2c_addr, 0x40, 1, data, size);
// Wait until transfer is completed
ulTaskNotifyTake(pdTRUE, 100);
}
void DisplayDriver::transferCompletedCB()
{
// Resume display thread
vTaskNotifyGiveFromISR(xDisplayThread, NULL);
}
Пересылка данных по прежнему занимает 24 мс - это практически чистое время пересылки 1 кб (размер дисплейного буфера) на скорости 400кГц. Только при этом бОльшую часть времени процессор просто спит (или занимается другими делами). Общая загрузка процессора упала с 23% всего лишь до 1.5-2%. Я думаю за этот показатель стОило бороться!
Опять туда: SPI через DMA
С подключением SD карты через SPI в каком то смысле было проще - к этому времени я начал прикручивать библиотеку sdfat , а там добрые люди уже выделили общение с картой в отдельный интерфейс драйвера. Правда с помощью дефайнов можно выбрать только одну из 4 готовых версий драйвера, но это можно было легко расточить и подставить свою реализацию.Интерфейс драйвера SPI для работы с SD картой
// This is custom implementation of SPI Driver class. SdFat library is
// using this class to access SD card over SPI
//
// Main intention of this implementation is to drive data transfer
// over DMA and synchronize with FreeRTOS capabilities.
class SdFatSPIDriver: public SdSpiBaseDriver
{
// SPI module
SPI_HandleTypeDef spiHandle;
// GPS thread handle
TaskHandle_t xSDThread = NULL;
public:
SdFatSPIDriver();
virtual void activate();
virtual void begin(uint8_t chipSelectPin);
virtual void deactivate();
virtual uint8_t receive();
virtual uint8_t receive(uint8_t* buf, size_t n);
virtual void send(uint8_t data);
virtual void send(const uint8_t* buf, size_t n);
virtual void select();
virtual void setSpiSettings(SPISettings spiSettings);
virtual void unselect();
};
Как и прежде начинаем с простого - с дубовой реализации без всяких DMA. Инициализация частично сгенерирована CubeMX’ом, а отчасти слизана с SPI реализации STM32GENERIC
Инициализация SPI
SdFatSPIDriver::SdFatSPIDriver()
{
}
//void SdFatSPIDriver::activate();
void SdFatSPIDriver::begin(uint8_t chipSelectPin)
{
// Ignore passed CS pin - This driver works with predefined one
(void)chipSelectPin;
// Initialize GPS Thread handle
xSDThread = xTaskGetCurrentTaskHandle();
// Enable clocking of corresponding periperhal
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_SPI1_CLK_ENABLE();
// Init pins
GPIO_InitTypeDef GPIO_InitStruct;
GPIO_InitStruct.Pin = GPIO_PIN_5|GPIO_PIN_7; //MOSI & SCK
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_6; //MISO
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_4; //CS
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
// Set CS pin High by default
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET);
// Init SPI
spiHandle.Instance = SPI1;
spiHandle.Init.Mode = SPI_MODE_MASTER;
spiHandle.Init.Direction = SPI_DIRECTION_2LINES;
spiHandle.Init.DataSize = SPI_DATASIZE_8BIT;
spiHandle.Init.CLKPolarity = SPI_POLARITY_LOW;
spiHandle.Init.CLKPhase = SPI_PHASE_1EDGE;
spiHandle.Init.NSS = SPI_NSS_SOFT;
spiHandle.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;
spiHandle.Init.FirstBit = SPI_FIRSTBIT_MSB;
spiHandle.Init.TIMode = SPI_TIMODE_DISABLE;
spiHandle.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
spiHandle.Init.CRCPolynomial = 10;
HAL_SPI_Init(&spiHandle);
__HAL_SPI_ENABLE(&spiHandle);
}
Дизайн интерфейса заточен под ардуино с нумерованием пинов одним числом. В моем же случае задавать пин CS через параметры не было смысла - у меня этот сигнал жестко завязан на пин A4, но нужно было соблюдать интерфейс.
По дизайну библиотеки SdFat скорость SPI порта настраивается перед каждой транзакцией. Т.е. теоретически можно начинать общение с картой на малой скорости, а потом ее повышать. Но я на это забил и настроил скорость один раз в методе begin(). Так что методы activate/deactivate у меня получились пустые. Как и setSpiSettings()
Тривиальная обработчики транзакций
void SdFatSPIDriver::activate()
{
// No special activation needed
}
void SdFatSPIDriver::deactivate()
{
// No special deactivation needed
}
void SdFatSPIDriver::setSpiSettings(const SPISettings & spiSettings)
{
// Ignore settings - we are using same settings for all transfer
}
Методы управления сигналом CS вполне тривиальны
Управление сигналом CS
void SdFatSPIDriver::select()
{
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_RESET);
}
void SdFatSPIDriver::unselect()
{
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET);
}
Подбираемся к самому интересному - чтению и записи. Первая самая дубовая реализация без DMA
Передача данных без DMA
uint8_t SdFatSPIDriver::receive()
{
uint8_t buf;
uint8_t dummy = 0xff;
HAL_SPI_TransmitReceive(&spiHandle, &dummy, &buf, 1, 10);
return buf;
}
uint8_t SdFatSPIDriver::receive(uint8_t* buf, size_t n)
{
// TODO: Receive via DMA here
memset(buf, 0xff, n);
HAL_SPI_Receive(&spiHandle, buf, n, 10);
return 0;
}
void SdFatSPIDriver::send(uint8_t data)
{
HAL_SPI_Transmit(&spiHandle, &data, 1, 10);
}
void SdFatSPIDriver::send(const uint8_t* buf, size_t n)
{
// TODO: Transmit over DMA here
HAL_SPI_Transmit(&spiHandle, (uint8_t*)buf, n, 10);
}
В интерфейсе SPI прием и передача данных происходит одновременно. Чтобы принять что нибудь нужно что нибудь при этом отправлять. Обычно HAL это делает за нас - мы просто вызываем функцию HAL_SPI_Receive() а она организует и отправку и прием. Но на самом деле эта функция отправляет мусор, который был в приемном буфере.
Чтобы продать что нибудь ненужное нужно сначала купить что нибудь ненужное (С) Простоквашино
Но есть нюанс. SD карточки весьма капризны. Они не любят, когда им подсовывают что попало во время того, как карта отправляет данные. Поэтому пришлось использовать функцию HAL_SPI_TransmitReceive() и насильно отправлять 0xff’ы во время приема данных.
Займемся измерениями. Пускай один поток будет в цикле записывать на карту 1кб данных.
Тестовый код по отправке потока данных в SD карту
uint8_t sd_buf;
uint16_t i=0;
uint32_t prev = HAL_GetTick();
while(true)
{
bulkFile.write(sd_buf, 512);
bulkFile.write(sd_buf, 512);
i++;
uint32_t cur = HAL_GetTick();
if(cur-prev >= 1000)
{
prev = cur;
usbDebugWrite("Saved %d kb\n", i);
i = 0;
}
}
При таком подходе за секунду успевает записать порядка 15-16кб. Негусто. Но оказалось, что я поставил прескейлер аж на 256. Т.е. тактирование SPI выставлено намного меньше возможной пропускной способности. Экспериментальным путем я выяснил, что частоту выше чем 9МГц (прескейлер установлен в значение 8) ставить бессмысленно - скорость записи выше 100-110 кб/с достичь не получается (на другой флешке, кстати почему-то только 50-60кб/с получалось записывать, а на третьей вообще только 40кб/с). Видимо все упирается в таймауты самой флешки.
В принципе этого уже более чем достаточно, но мы же собрались прокачивать данные через DMA. Действуем по уже привычной схеме. Первым делом инициализация. Прием и передача по SPI у нас живут на втором и третьем каналах DMA соответственно.
Инициализация DMA
// DMA controller clock enable
__HAL_RCC_DMA1_CLK_ENABLE();
// Rx DMA channel
dmaHandleRx.Instance = DMA1_Channel2;
dmaHandleRx.Init.Direction = DMA_PERIPH_TO_MEMORY;
dmaHandleRx.Init.PeriphInc = DMA_PINC_DISABLE;
dmaHandleRx.Init.MemInc = DMA_MINC_ENABLE;
dmaHandleRx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
dmaHandleRx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
dmaHandleRx.Init.Mode = DMA_NORMAL;
dmaHandleRx.Init.Priority = DMA_PRIORITY_LOW;
HAL_DMA_Init(&dmaHandleRx);
__HAL_LINKDMA(&spiHandle, hdmarx, dmaHandleRx);
// Tx DMA channel
dmaHandleTx.Instance = DMA1_Channel3;
dmaHandleTx.Init.Direction = DMA_MEMORY_TO_PERIPH;
dmaHandleTx.Init.PeriphInc = DMA_PINC_DISABLE;
dmaHandleTx.Init.MemInc = DMA_MINC_ENABLE;
dmaHandleTx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
dmaHandleTx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
dmaHandleTx.Init.Mode = DMA_NORMAL;
dmaHandleTx.Init.Priority = DMA_PRIORITY_LOW;
HAL_DMA_Init(&dmaHandleTx);
__HAL_LINKDMA(&spiHandle, hdmatx, dmaHandleTx);
Не забываем включить прерывания. У меня они будут идти с 8 приоритетом - чуть ниже чем у UART и I2C
Настройка прерываний DMA
// Setup DMA interrupts
HAL_NVIC_SetPriority(DMA1_Channel2_IRQn, 8, 0);
HAL_NVIC_EnableIRQ(DMA1_Channel2_IRQn);
HAL_NVIC_SetPriority(DMA1_Channel3_IRQn, 8, 0);
HAL_NVIC_EnableIRQ(DMA1_Channel3_IRQn);
Я решил, что накладные расходы на запуск DMA и синхронизацию для коротких передач могут превысить выигрыш, потому для небольших пакетов (до 16 байт) я оставил старый вариант. Пакеты длиннее 16 байт пересылаются через DMA. Способ синхронизации точно такой же как и в предыдущем разделе.
Пересылка данных через DMA
const size_t DMA_TRESHOLD = 16;
uint8_t SdFatSPIDriver::receive(uint8_t* buf, size_t n)
{
memset(buf, 0xff, n);
// Not using DMA for short transfers
if(n <= DMA_TRESHOLD)
{
return HAL_SPI_TransmitReceive(&spiHandle, buf, buf, n, 10);
}
// Start data transfer
HAL_SPI_TrsnsmitReceive_DMA(&spiHandle, buf, buf, n);
// Wait until transfer is completed
ulTaskNotifyTake(pdTRUE, 100);
return 0; // Ok status
}
void SdFatSPIDriver::send(const uint8_t* buf, size_t n)
{
// Not using DMA for short transfers
if(n <= DMA_TRESHOLD)
{
HAL_SPI_Transmit(&spiHandle, buf, n, 10);
return;
}
// Start data transfer
HAL_SPI_Transmit_DMA(&spiHandle, (uint8_t*)buf, n);
// Wait until transfer is completed
ulTaskNotifyTake(pdTRUE, 100);
}
void SdFatSPIDriver::dmaTransferCompletedCB()
{
// Resume SD thread
vTaskNotifyGiveFromISR(xSDThread, NULL);
}
Конечно же без прерываний никак. Тут все также как и в случае I2C
Прерывания DMA
extern SdFatSPIDriver spiDriver;
extern "C" void DMA1_Channel2_IRQHandler(void)
{
HAL_DMA_IRQHandler(spiDriver.getHandle().hdmarx);
}
extern "C" void DMA1_Channel3_IRQHandler(void)
{
HAL_DMA_IRQHandler(spiDriver.getHandle().hdmatx);
}
extern "C" void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi)
{
spiDriver.dmaTransferCompletedCB();
}
extern "C" void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef *hspi)
{
spiDriver.dmaTransferCompletedCB();
}
Запускаем, проверяем. Дабы не мучать флешку я решил отлаживать на чтении большого файла, а не на записи. Тут я обнаружил очень интересный момент: скорость чтения в не-DMA версии была порядка 250-260 кб/с, тогда как с DMA всего 5!!! Более того, потребление процессора без использования DMA было 3%, а с DMA - 75-80%!!! Т.е. результат прямо противоположный ожидаемому.
Оффтоп про 3%
Тут у меня был смешной глюк с измерением загрузки процессора - иногда функция говорила что процессор загружен всего на 3%, хотя проц должен был молотить без остановки. На самом деле загрузка была 100% и моя функция измерения вообще не вызывалась - у нее самый низкий приоритет и на нее просто не хватало времени. Поэтому я получал последнее запомненное значение перед началом экзекуции. В нормальных условиях функция работает более корректно.
Обложив логгированием код драйвера чуть ли не через строку я обнаружил проблему: я использовал не ту коллбек функцию. Изначально у меня в коде использовался HAL_SPI_Receive_DMA() и вместе с ним в паре использовался коллбек HAL_SPI_RxCpltCallback. Эта конструкция не работала из-за нюанса с одновременной отсылкой 0xff. Когда я поменял HAL_SPI_Receive_DMA() на HAL_SPI_TransmitReceive_DMA() нужно было заодно менять и коллбек на HAL_SPI_TxRxCpltCallback(). Т.е. по факту чтение проходило, но из-за отсутствия коллбеков скорость регулировалась таймаутом в 100мс.
Починив коллбек все встало на свои места. Загрузка процессора упала до 2.5% (теперь уже честных), а скорость даже подскочила аж до 500кб/с. Правда прескейлер пришлось поставить на 4 - с прескейлером на 2 сыпались ассерты в библиотеке SdFat. Похоже это предел скорости моей карточки.
К сожалению к скорости записи это отношение не имеет. Скорость записи по прежнему была около 50-60кб/с, а загрузка процессора колебалась в диапазоне 60-70%. Но проковырявшись целый вечер, и сделав замеры в разных местах я выяснил, что собственно функция send() моего драйвера (которая записывает один сектор 512 байт) отрабатывает всего за 1-2мс включая ожидание и синхронизацию. Иногда, правда, выстреливает таймаут какой нибудь и запись длится 5-7мс. Но проблема на самом деле не в драйвере а в логике работы с файловой системой FAT.
Поднимаясь на уровень файлов, разделов и кластеров задача записи 512 в файл не такая уж и тривиальная. Нужно прочитать таблицу FAT, найти в ней место для записываемого сектора, записать сам сектор, обновить записи в таблице FAT, записать и эти сектора на диск, обновить записи в таблице файлов и директорий, и еще кучу всего другого. В общем один вызов FatFile::write() мог занимать до 15-20мс, причем здоровенный кусок этого времени занимает собственно работа процессора по обработке записей в файловой системе.
Как я уже отметил, загрузка процессора при записи составляет 60-70%. Но это число также зависит и от типа файловой системы (Fat16 или Fat32), размера, а соответственно и количества этих кластеров на разделе, скорости самой флешки, забитости и фрагментированности носителя, использовании длинных имен файлов и многого другого. Так что прошу относится к этим замерам как к неким относительным цифрам.
Опять туда: USB с двойной буферизацией
С этим компонентом вышло интересно. В оригинальной реализации USB Serial от STM32GENERIC было некоторое количество недочетов и я его взялся переписывать под себя. Но пока я изучал как работает USB CDC, читал исходники и штудировал документацию, ребята из STM32GENERIC значительно улучшили свою реализацию. Но обо всем по порядку.Итак, оригинальная реализация меня не устраивала по следующим причинам:
- Отправка сообщений происходит синхронно. Т.е. банальное побайтное переливание данных из GPS UART в USB ждет отправки каждого отдельного байта. Из-за этого загрузка процессора может доходить до 30-50%, что разумеется очень много (скорость UART’а всего то 9600)
- Отсутствует всякая синхронизация. При печати сообщений из нескольких потоков на выходе получается лапша из сообщений, которые частично затирают друг друга
- Переизбыток буферов приема и отправки. Пара буферов объявлены в USB Middleware, но по факту не используются. Еще пара буферов объявлена в классе SerialUSB, но поскольку я использую только вывод, то приемный буфер только зря занимает память.
- Наконец, меня просто раздражает интерфейс класса Print. Если я, например, хочу вывести строку “текущая скорость XXX км/ч”, то мне нужно сделать аж 3 вызова - для первой части строки, для числа и для остатка строки. Лично мне ближе по духу классический printf. Плюсовые потоки тоже ничего, но нужно смотреть какой именно код генерируется компилятором.
Реализация `в лоб`
extern USBD_HandleTypeDef hUsbDeviceFS;
void usbDebugWrite(uint8_t c)
{
usbDebugWrite(&c, 1);
}
void usbDebugWrite(const char * str)
{
usbDebugWrite((const uint8_t *)str, strlen(str));
}
void usbDebugWrite(const uint8_t *buffer, size_t size)
{
// Ignore sending the message if USB is not connected
if(hUsbDeviceFS.dev_state != USBD_STATE_CONFIGURED)
return;
// Transmit the message but no longer than timeout
uint32_t timeout = HAL_GetTick() + 5;
while(HAL_GetTick() < timeout)
{
if(CDC_Transmit_FS((uint8_t*)buffer, size) == USBD_OK)
{
return;
}
}
}
Формально это не синхронный код, т.к. он не ждет отправки данных. Но эта функция ждет пока предыдущие данные будут отправлены. Т.е. первый вызов отправит данные в порт и выйдет, зато второй вызов будет ждать пока данные, отправленные в первый заход, реально отправятся. В случае таймаута данные теряются. Также ничего не происходит если вообще нет USB соединения.
Разумеется это только заготовка, т.к. эта реализация не решает обозначенных проблем. Что же нужно, чтобы этот код стал асинхронными и неблокирующим? Ну как минимум буфер. Только вот когда этот буфер передавать?
Я думаю тут стОит сделать небольшой экскурс в принципы работы USB. Дело в том, что передачу в USB протоколе может инициировать только хост. Если устройству нужно передать данные в сторону хоста, данные подготавливаются в специальном PMA (Packet Memory Area) буфере и устройство ожидает пока хост заберет эти данные. Подготовкой PMA буфера занимается функция CDC_Transmit_FS(). Буфер этот живет внутри USB периферии, а не в пользовательском коде.
Честно хотел тут нарисовать красивую картинку, но так и не придумал как это лучше отобразить
Но было бы классно реализовать следующую схему. Клиентский код по мере необходимости записывает данные в некий накопительный (пользовательский) буфер. Время от времени приходит хост и забирает все что накопилось в буфере к этому моменту. Это очень похоже на то, что я описал в предыдущем абзаце, но есть один ключевой нюанс: данные находятся в пользовательском буфере, а не в PMA. Т.е. я бы хотел вообще обойтись без вызова CDC_Transmit_FS(), который переливает данные из пользовательского буфера в PMA, а вместо этого ловить коллбек “тут хост пришел, данные спрашивает”.
К сожалению в текущем дизайне USB CDC Middleware такой подход невозможен. Точнее может быть и возможен, но нужно вклиниваться в реализацию драйвера CDC. Я еще недостаточно искушен в протоколах USB, что-бы так делать. К тому же я не уверен, что временнЫх лимитов USB хватит на такую операцию.
Благо в этот момент я обратил внимание, что STM32GENERIC такую штуку уже объехали. Вот код, который я у них творчески переработал.
USB Serial с двойной буферизацией
#define USB_SERIAL_BUFFER_SIZE 256
uint8_t usbTxBuffer;
volatile uint16_t usbTxHead = 0;
volatile uint16_t usbTxTail = 0;
volatile uint16_t usbTransmitting = 0;
uint16_t transmitContiguousBuffer()
{
uint16_t count = 0;
// Transmit the contiguous data up to the end of the buffer
if (usbTxHead > usbTxTail)
{
count = usbTxHead - usbTxTail;
}
else
{
count = sizeof(usbTxBuffer) - usbTxTail;
}
CDC_Transmit_FS(&usbTxBuffer, count);
return count;
}
void usbDebugWriteInternal(const char *buffer, size_t size, bool reverse = false)
{
// Ignore sending the message if USB is not connected
if(hUsbDeviceFS.dev_state != USBD_STATE_CONFIGURED)
return;
// Transmit the message but no longer than timeout
uint32_t timeout = HAL_GetTick() + 5;
// Protect this function from multiple entrance
MutexLocker locker(usbMutex);
// Copy data to the buffer
for(size_t i=0; i < size; i++)
{
if(reverse)
--buffer;
usbTxBuffer = *buffer;
usbTxHead = (usbTxHead + 1) % sizeof(usbTxBuffer);
if(!reverse)
buffer++;
// Wait until there is a room in the buffer, or drop on timeout
while(usbTxHead == usbTxTail && HAL_GetTick() < timeout);
if (usbTxHead == usbTxTail) break;
}
// If there is no transmittion happening
if (usbTransmitting == 0)
{
usbTransmitting = transmitContiguousBuffer();
}
}
extern "C" void USBSerialTransferCompletedCB()
{
usbTxTail = (usbTxTail + usbTransmitting) % sizeof(usbTxBuffer);
if (usbTxHead != usbTxTail)
{
usbTransmitting = transmitContiguousBuffer();
}
else
{
usbTransmitting = 0;
}
}
Идея этого кода в следующем. Хоть и не удалось словить нотификацию “хост пришел, данных хочет”, оказалось можно организовать коллбек “я данные хосту отправил, можешь следующие наливать”. Получается такой себе двойной буфер - пока устройство ожидает отправки данных из внутреннего PMA буфера, пользовательский код может дописывать байтики в накопительный буфер. Когда отправка данных завершилась накопительный буфер переливается в PMA. Осталось только организовать этот самый коллбек. Для этого нужно чуток подпилить функцию USBD_CDC_DataIn()
Подпиленный USB Middleware
static uint8_t USBD_CDC_DataIn (USBD_HandleTypeDef *pdev, uint8_t epnum)
{
USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;
if(pdev->pClassData != NULL)
{
hcdc->TxState = 0;
USBSerialTransferCompletedCB();
return USBD_OK;
}
else
{
return USBD_FAIL;
}
}
Кстати говоря функция usbDebugWrite защищена мутексом и должна правильно работать из нескольких потоков. Функцию USBSerialTransferCompletedCB() защищать не стал - она вызывается из прерывания и оперирует volatile переменными. Откровенно говоря, где-то бага тут таки гуляет, очень изредка глотаются символы. Но мне для дебага это не критично. В “продакшен” коде это вызываться не будет.
Опять туда: printf
Пока эта штука умеет оперировать только константными строками. Пора докрутить аналог printf(). Настоящую функцию printf() я использовать не хочу - она тянет за собой лишнего кода килобайт на 12 и “кучу” (heap), которой у меня нет. Я таки нашел свой debug logger, который я когда-то писал для AVR. Моя реализация умеет печатать строки а также числа в десятичном и шестнадцатеричном формате. После некоторого допиливания и тестирования получилось как то так:Упрощенная реализация printf
// sprintf implementation takes more than 10kb and adding heap to the project. I think this is
// too much for the functionality I need
//
// Below is a homebrew printf-like dumping function which accepts:
// - %d for digits
// - %x for numbers as HEX
// - %s for strings
// - %% for percent symbol
//
// Implementation supports also value width as well as zero padding
// Print the number to the buffer (in reverse order)
// Returns number of printed symbols
size_t PrintNum(unsigned int value, uint8_t radix, char * buf, uint8_t width, char padSymbol)
{
//TODO check negative here
size_t len = 0;
// Print the number
do
{
char digit = value % radix;
*(buf++) = digit < 10 ? "0" + digit: "A" - 10 + digit;
value /= radix;
len++;
}
while (value > 0);
// Add zero padding
while(len < width)
{
*(buf++) = padSymbol;
len++;
}
return len;
}
void usbDebugWrite(const char * fmt, ...)
{
va_list v;
va_start(v, fmt);
const char * chunkStart = fmt;
size_t chunkSize = 0;
char ch;
do
{
// Get the next byte
ch = *(fmt++);
// Just copy the regular characters
if(ch != "%")
{
chunkSize++;
continue;
}
// We hit a special symbol. Dump string that we processed so far
if(chunkSize)
usbDebugWriteInternal(chunkStart, chunkSize);
// Process special symbols
// Check if zero padding requested
char padSymbol = " ";
ch = *(fmt++);
if(ch == "0")
{
padSymbol = "0";
ch = *(fmt++);
}
// Check if width specified
uint8_t width = 0;
if(ch > "0" && ch <= "9")
{
width = ch - "0";
ch = *(fmt++);
}
// check the format
switch(ch)
{
case "d":
case "u":
{
char buf;
size_t len = PrintNum(va_arg(v, int), 10, buf, width, padSymbol);
usbDebugWriteInternal(buf + len, len, true);
break;
}
case "x":
case "X":
{
char buf;
size_t len = PrintNum(va_arg(v, int), 16, buf, width, padSymbol);
usbDebugWriteInternal(buf + len, len, true);
break;
}
case "s":
{
char * str = va_arg(v, char*);
usbDebugWriteInternal(str, strlen(str));
break;
}
case "%":
{
usbDebugWriteInternal(fmt-1, 1);
break;
}
default:
// Otherwise store it like a regular symbol as a part of next chunk
fmt--;
break;
}
chunkStart = fmt;
chunkSize=0;
}
while(ch != 0);
if(chunkSize)
usbDebugWriteInternal(chunkStart, chunkSize - 1); // Not including terminating NULL
va_end(v);
}
Моя реализация значительно проще библиотечной, но умеет все что мне нужно - печатать строки, десятичные и шестнадцатеричные числа с форматированием (ширина поля, добивание числа нулями слева). Пока еще оно не умеет печатать отрицательные числа и числа с плавающей запятой, но это несложно добавить. Позже я, возможно, сделаю возможность записывать результат в строковый буфер (как sprintf), а не только в USB.
Производительность данного кода около 150-200 кб/с вместе с передачей через USB и зависит от количества (длины) сообщений, сложности строки формата, а также от размера буфера. Такой скорости вполне достаточно для отправки пару тысяч небольших сообщений в секунду. Самое главное, что вызовы не блокирующие.
Еще тудее: Low Level HAL
В принципе, на этом можно было бы и закончить, но я обратил внимание, что дядьки из STM32GENERIC буквально на днях влили новый HAL . Интересно в нем то, что появилось много файликов в названием stm32f1xx_ll_XXXX.h. В них обнаружилась альтернативная и более низкоуровневая реализация HAL. Т.е. обычный HAL предоставляет достаточно высокоуровневый интерфейс в стиле “возьми вот этот массив и передай мне его вот по этому интерфейсу. О завершении доложи прерыванием”. Напротив, файлики с буквами LL в названии предоставляют более низкоуровневый интерфейс вроде “установи вот эти флаги такого-то регистра”.Мистика нашего городка
Увидев новые файлы в репозитории STM32GENERIC я захотел скачать полный комплект с сайта ST. Но гуглеж приводил меня только к HAL (STM32 Cube F1) версии 1.4, которая не содержит этих новых файлов. Графический конфигуратор STM32CubeMX также предлагал эту версию. Я поинтересовался у разработчиков STM32GENERIC где они взяли новую версию. К моему удивлению я получил ссылку на ту же самую страницу, только теперь там предлагалось скачать версию 1.6. Гугл тоже вдруг стал “находить” новую версию, а также обновленный CubeMX. Мистика да и только!
Зачем это надо? В большинстве случаев высокоуровневый интерфейс действительно неплохо решает задачу. HAL (Hardware Abstraction Layer) полностью оправдывает свое название - абстрагирует код от регистров процессора и железа. Но в некоторых случаях HAL ограничивает полет фантазии программиста, тогда как используя более низкоуровневые абстракции можно было бы реализовать задачу более эффективно. В моем случае это GPIO и UART.
Попробуем пощупать новые интерфейсы. Начнем с лампочек. К сожалению примеров в интернете пока маловато. Будем пробовать разобраться в коде комментариях к функциям, благо с этим все впорядке.
Судя по всему эти низкоуровневые штуки также можно поделить на 2 части:
- чуть более высокоуровневые функции в стиле обычного HAL - вот тебе структура инициализации, проинициализируй мне, пожалуйста, периферию.
- Чуть более низкоуровневые сеттеры и геттеры отдельных флагов или регистров. По большей части функции этой группы inline и header-only
Моргулька на LL HAL
// Class to encapsulate working with onboard LED(s)
//
// Note: this class initializes corresponding pins in the constructor.
// May not be working properly if objects of this class are created as global variables
class LEDDriver
{
const uint32_t pin = LL_GPIO_PIN_13;
public:
LEDDriver()
{
//enable clock to the GPIOC peripheral
__HAL_RCC_GPIOC_IS_CLK_ENABLED();
// Init PC 13 as output
LL_GPIO_SetPinMode(GPIOC, pin, LL_GPIO_MODE_OUTPUT);
LL_GPIO_SetPinOutputType(GPIOC, pin, LL_GPIO_OUTPUT_PUSHPULL);
LL_GPIO_SetPinSpeed(GPIOC, pin, LL_GPIO_SPEED_FREQ_LOW);
}
void turnOn()
{
LL_GPIO_ResetOutputPin(GPIOC, pin);
}
void turnOff()
{
LL_GPIO_SetOutputPin(GPIOC, pin);
}
void toggle()
{
LL_GPIO_TogglePin(GPIOC, pin);
}
};
void vLEDThread(void *pvParameters)
{
LEDDriver led;
// Just blink once in 2 seconds
for (;;)
{
vTaskDelay(2000);
led.turnOn();
vTaskDelay(100);
led.turnOff();
}
}
Все очень просто! Приятно то, что тут действительно работа с регистрами и флагами напрямую идет. Нет оверхеда на модуль HAL GPIO, который сам по себе компилируется аж в 450 байт, и управления пинами от STM32GENERIC, который тянет еще на 670 байт. Тут вообще весь класс со всеми вызовами заинлайнился в функцию vLEDThread размером всего то 48 байт!
Управление тактированием через LL HAL я ниасилил. Но это не критично, т.к. вызов __HAL_RCC_GPIOC_IS_CLK_ENABLED() из обычного HAL на самом деле макрос, который всего лишь устанавливает парочку флагов в определенных регистрах.
С кнопочками все также просто
Кнопочки через LL HAL
// Pins assignment
const uint32_t SEL_BUTTON_PIN = LL_GPIO_PIN_14;
const uint32_t OK_BUTTON_PIN = LL_GPIO_PIN_15;
// Initialize buttons related stuff
void initButtons()
{
//enable clock to the GPIOC peripheral
__HAL_RCC_GPIOC_IS_CLK_ENABLED();
// Set up button pins
LL_GPIO_SetPinMode(GPIOC, SEL_BUTTON_PIN, LL_GPIO_MODE_INPUT);
LL_GPIO_SetPinPull(GPIOC, SEL_BUTTON_PIN, LL_GPIO_PULL_DOWN);
LL_GPIO_SetPinMode(GPIOC, OK_BUTTON_PIN, LL_GPIO_MODE_INPUT);
LL_GPIO_SetPinPull(GPIOC, OK_BUTTON_PIN, LL_GPIO_PULL_DOWN);
}
// Reading button state (perform debounce first)
inline bool getButtonState(uint32_t pin)
{
if(LL_GPIO_IsInputPinSet(GPIOC, pin))
{
// dobouncing
vTaskDelay(DEBOUNCE_DURATION);
if(LL_GPIO_IsInputPinSet(GPIOC, pin))
return true;
}
return false;
}
C UART все будет поинтереснее. Напомню проблему. При использовании HAL прием нужно было “перезаряжать” после каждого принятого байта. Режим “принимай все подряд” в HAL не предусмотрен. А с LL HAL у нас все должно получится.
Настройка пинов заставила не только призадуматься, но и заглянуть в Reference Manual
Настройка пинов UART
// Init pins in alternate function mode
LL_GPIO_SetPinMode(GPIOA, LL_GPIO_PIN_9, LL_GPIO_MODE_ALTERNATE); //TX pin
LL_GPIO_SetPinSpeed(GPIOA, LL_GPIO_PIN_9, LL_GPIO_SPEED_FREQ_HIGH);
LL_GPIO_SetPinOutputType(GPIOA, LL_GPIO_PIN_9, LL_GPIO_OUTPUT_PUSHPULL);
LL_GPIO_SetPinMode(GPIOA, LL_GPIO_PIN_10, LL_GPIO_MODE_INPUT); //RX pin
Переделываем инициализацию UART’а на новые интерфейсы
Инициализация UART
// Prepare for initialization
LL_USART_Disable(USART1);
// Init
LL_USART_SetBaudRate(USART1, HAL_RCC_GetPCLK2Freq(),
9600);
LL_USART_SetDataWidth(USART1, LL_USART_DATAWIDTH_8B);
LL_USART_SetStopBitsLength(USART1, LL_USART_STOPBITS_1);
LL_USART_SetParity(USART1, LL_USART_PARITY_NONE);
LL_USART_SetTransferDirection(USART1, LL_USART_DIRECTION_TX_RX);
LL_USART_SetHWFlowCtrl(USART1, LL_USART_HWCONTROL_NONE);
// We will be using UART interrupt to get data
HAL_NVIC_SetPriority(USART1_IRQn, 6, 0);
HAL_NVIC_EnableIRQ(USART1_IRQn);
// Enable UART interrupt on byte reception
LL_USART_EnableIT_RXNE(USART1);
// Finally enable the peripheral
LL_USART_Enable(USART1);
Теперь прерывание. В прошлом варианте у нас было целых 2 функции - одна обрабатывала прерывание, а вторая являлась коллбеком (из того же прерывания) о принятом байте. В новом варианте мы настроили прерывание только на прием байта, так что принятый байт мы получим сразу.
Прерывание UART
// Store received byte
inline void charReceivedCB(uint8_t c)
{
rxBuffer = c;
lastReceivedIndex++;
// If a EOL symbol received, notify GPS thread that line is available to read
if(c == "\n")
vTaskNotifyGiveFromISR(xGPSThread, NULL);
}
extern "C" void USART1_IRQHandler(void)
{
uint8_t byte = LL_USART_ReceiveData8(USART1);
gpsUart.charReceivedCB(byte);
}
Размер кода драйвера уменьшился с 1242 до 436 байт, а потребление ОЗУ с 200 до 136 (из них 128 это буфер). По моему неплохо. Жаль только, что это не самая прожорливая часть. Можно было бы еще что нибудь немного подпилить, но на данный момент за потреблением ресурсов я особо не гонюсь - у меня их еще есть. Да и высокоуровневый интерфейс HAL в случае остальной периферии работает весьма неплохо.
Оглядываясь назад
Хотя на старте этой фазы проекта я был настроен скептически на счет HAL, но мне все же удалось переписать всю работу с периферией: GPIO, UART, I2C, SPI и USB. Я глубоко продвинулся в понимании работы этих модулей и попытался передать знание в этой статье. Но это совсем не перевод Reference Manual. Напротив, я работал в контексте настоящего проекта и показал как можно писать драйвера периферии на чистом HAL.В статье получилась более-менее линейная история. Но на самом деле у меня расплодилось некоторое количество бранчей в которых я одновременно пилил в прямо противоположных направлениях. Утром я мог упереться в проблемы с производительностью какой нибудь ардуино библиотеки и твердо решить все переписывать на HAL, а к вечеру обнаружить, что кто-то уже запилил поддержку DMA в STM32GENERIC и у меня возникало желание бежать назад. Или, например, пару дней бодаться с ардуино интерфейсами пытаясь понять как же удобнее передавать данные по I2C, тогда как на HAL это делается в 2 строки.
В целом я достиг чего хотел. Основная работа с периферией находится под моим контролем и написана на HAL. Ардуино же выполняет только роль адаптера для некоторых библиотек. Правда, еще пооставались хвосты. Нужно таки собраться с духом и удалить из своего репозитория STM32GENERIC, оставив только пару действительно нужных классов. Но к этой статье такая уборка уже относится не будет.
Что касается арудино и ее клонов. Мне по прежнему нравится этот фреймворк. С ним можно побырику напрототипировать что нибудь не особо утруждая себя чтением мануалов и даташитов. С ардуино, в принципе, можно делать даже конечные устройства, если нет особых требований по быстродействию, потреблению или памяти. В моем случае эти параметры весьма важны, поэтому мне пришлось переехать на HAL.
Начинал я работу на stm32duino. Этот клон действительно заслуживает внимания, если хочется иметь «ардуино» на STM32 и чтобы все работало из коробки. К тому же там внимательно следят за потреблением ОЗУ и флеша. Напротив STM32GENERIC сам по себе толще и базируется на монстрообразном HAL. Зато этот фреймворк активно развивается и гляди еще допилят. В целом могу рекомендовать оба фреймворка с небольшим предпочтением STM32GENERIC ибо HAL и более динамичное развитие в данный момент. К тому же для HAL в интернете полно примеров и всегда можно что нибудь подтюнить под себя.
К самому HAL я по прежнему отношусь с некоторой долей отвращения. Библиотека слишком громоздкая и некрасивая. Я делаю скидку на то, что библиотека сишная, что обуславливает использование длиннючих имен функций и констант. Но все равно это не та библиотека, работа с которой приносит удовольствие. Скорее это вынужденная мера.
Ладно интерфейс - внутренности тоже заставляют задуматься. Огромные функции с функционалом на все случаи жизни влекут за собой бесполезную трату ресурсов. Причем если с лишним кодом во флеше можно побороться с помощью link time optimization, то огромное потребление ОЗУ лечится разве что переписыванием на LL HAL.
Но расстраивает даже не это, а местами просто наплевательское отношение к ресурсам. Так я обратил внимание огромный перерасход памяти в коде USB Middleware (формально это не HAL, но поставляется в составе STM32Cube). Структуры usb занимают 2.5кб в памяти. При чем структура USBD_HandleTypeDef (544 байта) во многом повторяет PCD_HandleTypeDef из нижнего слоя (1056 байт) - в ней так же определяются эндпоинты. Приемопередающие буферы так же объявлены как минимум в двух местах - USBD_CDC_HandleTypeDef и UserRxBufferFS/UserTxBufferFS.
Дескрипторы вообще объявлены в ОЗУ. Зачем? Они же константные! Почти 400 байт в ОЗУ. Благо часть дескрипторов таки константные (чуть меньше 300 байт). Дескрипторы это неизменяемая информация. А тут есть специальный код, который их патчит, причем, опять же, константой. Да еще и такой, которая там уже вписана. Функции типа SetBuffer почему то принимают не константный буфер, что также мешает положить дискрипторы и некоторые другие штуки во флеш. В чем причина? Оно же фиксится за 10 минут!!!
Или вот, структура инициализации является частью хендла объекта (например i2c). Зачем это хранить после того, как периферия проинициализирована? Зачем мне указатели на неиспользуемые структуры - например зачем данные связанные с DMA, если я его не использую?
А еще дубликаты кода.
case USB_DESC_TYPE_CONFIGURATION:
if(pdev->dev_speed == USBD_SPEED_HIGH)
{
pbuf = (uint8_t *)pdev->pClass->GetHSConfigDescriptor(&len);
pbuf = USB_DESC_TYPE_CONFIGURATION;
}
else
{
pbuf = (uint8_t *)pdev->pClass->GetFSConfigDescriptor(&len);
pbuf = USB_DESC_TYPE_CONFIGURATION;
}
break;
Особая конвертация в “типа юникод”, которую можно было бы и в компайл тайме делать. Да еще и специальный буфер под это выделен
Издевательство над констатными данными
ALIGN_BEGIN uint8_t USBD_StrDesc __ALIGN_END;
void USBD_GetString(const char *desc, uint8_t *unicode, uint16_t *len)
{
uint8_t idx = 0;
if (desc != NULL)
{
*len = USBD_GetLen(desc) * 2 + 2;
unicode = *len;
unicode = USB_DESC_TYPE_STRING;
while (*desc != "\0")
{
unicode = *desc++;
unicode = 0x00;
}
}
}
Не смертельно, но заставляет задуматься, а так ли хорош HAL как о нем пишут апологеты? Ну не этого ожидаешь от библиотеки от производителя и рассчитанной на профессионалов. Это же микроконтроллеры! Тут люди каждый байт экономят и каждая микросекунда дорога. А тут, понимаешь, буфер на полкило и конвертация константных строк на лету. Стоит отметить, что бОльшая часть замечаний к USB Middleware относится.
UPD: в HAL 1.6 еще и I2C DMA Transfer Completed callback отламали. Т.е. там вообще исчез код, который в случае отсылки данных через DMA подтверждение генерит, хотя в документации оно описано. На прием есть, а на передачу нет. Пришлось переехать обратно на HAL 1.4 для модуля I2C, благо тут один модуль - один файл.
Напоследок приведу потребление флеша и ОЗУ различных компонентов. В разделе Drivers я привел значения как для драйверов на базе HAL, так и для драйверов на LL HAL. Во втором случае соответствующие секции из раздела HAL не используются.
Потребление по памяти
| Category | Subcategory | .text | .rodata | .data | .bss |
| System | interrupt vector | 272 | |||
| dummy ISR handlers | 178 | ||||
| libc | 760 | ||||
| float math | 4872 | ||||
| sin/cos | 6672 | 536 | |||
| main & etc | 86 | ||||
| My Code | My Code | 7404 | 833 | 4 | 578 |
| printf | 442 | ||||
| Fonts | 3317 | ||||
| NeoGPS | 4376 | 93 | 300 | ||
| FreeRTOS | 4670 | 4 | 209 | ||
| Adafruit GFX | 1768 | ||||
| Adafruit SSD1306 | 1722 | 1024 | |||
| SdFat | 5386 | 1144 | |||
| USB Middleware | Core | 1740 | 333 | 2179 | |
| CDC | 772 | ||||
| Drivers | UART | 268 | 200 | ||
| USB | 264 | 846 | |||
| I2C | 316 | 164 | |||
| SPI | 760 | 208 | |||
| Buttons LL | 208 | ||||
| LED LL | 48 | ||||
| UART LL | 436 | 136 | |||
| Arduino | gpio | 370 | 296 | 16 | |
| misc | 28 | 24 | |||
| 822 | |||||
| HAL | USB LL | 4650 | |||
| SysTick | 180 | ||||
| NVIC | 200 | ||||
| DMA | 666 | ||||
| GPIO | 452 | ||||
| I2C | 1560 | ||||
| SPI | 2318 | ||||
| RCC | 1564 | 4 | |||
| UART | 974 | ||||
| heap (not really used) | 1068 | ||||
| FreeRTOS Heap | 10240 |
На этом все. Буду рад получить конструктивные комментарии, а также рекомендации если что нибудь тут можно улучшить.
Теги:
- HAL
- STM32
- STM32cube
- arduino
При создании первого приложения на микроконтроллере STM32 можно пойти несколькими путями. Первый, классический, берём точное описание контроллера на сайте www.st.com , которое фигурирует под названием «Reference Manual» и читаем описание регистров периферии. Дальше пробуем записывать их и смотрим, как работает периферия. Чтение этого документа очень полезно, но на первом этапе освоения микроконтроллера от этого можно отказаться, как это не странно. Инженеры STMicroelectronics написали библиотеку драйверов стандартной периферии. Более того, они написали множество примеров использования данных драйверов, что может свести программирование вашего приложения к нажатию клавиш Ctrl+C и Ctrl+V, с последующей небольшой правкой примера использования драйвера под свои потребности. Таким образом, подключение библиотеки драйверов периферии к вашему проекту является вторым методом построения приложения. Кроме скорости написания есть и другие достоинства этого метода: универсальность кода и применение других фирменных библиотек, таких как USB, Ethernet, управление приводом и т.д., которые предоставляются в исходниках и использующих стандартный драйвер периферии. Недостатки данного метода тоже есть: Там где можно обойтись одной строкой кода стандартный драйвер периферии STM32 напишет 10. Сама библиотека периферии также предоставляется в виде исходных файлов, так что можно проследить какой бит какого регистра меняет та или иная функция. При желании можно будет перейти от второго метода написания программы к первому, закомментировав часть кода, использующего стандартную библиотеку на свою, управляющую непосредственно регистром периферии. В результате такого действия вы выиграете в скорости управления, объёме ОЗУ и ПЗУ, а потеряете в универсальности кода. В любом случае, инженеры компании "Промэлектроника" рекомендуют использовать библиотеку стандартной периферии хотя бы на первом этапе.
Наибольшие трудности ожидают разработчика при подключении библиотеки к своему проекту. Если не знать, как это делать, можно потратить много времени на это мероприятие, что противоречит самой идее использования готового драйвера. Материал посвящён подключению стандартной библиотеки к любому семейству STM32.
Каждое семейство STM32 имеет свою библиотеку стандартной периферии. Это связано с тем, что сама периферия разная. Например, периферия контроллеров STM32L в качестве одной из задач имеет функцию энергосбережения, что тянет за собой добавление функций управления. Классическим примером, можно считать АЦП, который в STM32L имеет возможность аппаратного отключения, при длительном отсутствии команды преобразования – одно из следствий задачи энергосбережения. АЦП контроллеров семейств STM32F не имеют такой функции. Собственно говоря, в силу наличия аппаратной разницы периферии имеем разные библиотеки драйверов. Кроме очевидного различия функций контроллера имеет место улучшение периферии. Так, периферия контроллеров семейств, которые были выпущены позже, может быть более продуманной и удобной. Например, периферия контроллеров STM32F1 и STM32F2 имеет различия по управлению. На взгляд автора управление периферией STM32F2 более удобное. И это понятно почему: STM32F2 семейство было выпущено позже и это позволило разработчикам учесть некоторые нюансы. Соответственно, для данных семейств – индивидуальные библиотеки управления периферией. Идея вышесказанного проста: на странице микроконтроллера, который вы собираетесь использовать, находится подходящая ему библиотека периферии.
Несмотря на различие периферии в семействах драйверы скрывают 90% различий внутри себя. Например, функция настройки, упомянутого выше АЦП, для всех семейств выглядит одинаково:
void ADC_Init(ADC_Nom, ADC_Param) ,
где ADC_Nom – номер АЦП в виде ADC1, ADC2, ADC3 и т. д.
ADC_Param – указатель структуры данных, каким образом надо настроить АЦП (от чего запускаться, сколько каналов оцифровывать, выполнять ли это циклически и т.д.)
10% различий семейств, в данном примере, которые придётся поправить при переходе с одного семейства STM32 на другое, спрятаны в структуре ADC_Param. В зависимости от семейства количество полей этой структуры может быть разным. Общая же часть, имеет одинаковый синтаксис. Таким образом, перевод приложения для одного семейства STM32, написанного на базе стандартных библиотек периферии на другое, весьма прост. В части универсализации решений на микроконтроллерах STMicroelectronics неотразим!
Итак, мы скачали библиотеку для применяемого STM32. Что дальше? Далее, нам надо создать проект и подключить к нему требуемые файлы. Создание проекта рассмотрим на примере среды разработки IAR Embedded Workbench. Запускаем среду разработки и заходим на вкладку “Project”, выбираем пункт создания проекта “Create project”:
В появившемся новом проекте вводим настройки, наведя курсор на название проекта, нажав правую клавишу мыши и выбрав в выпавшем меню «Options»:
Области памяти ОЗУ и ПЗУ:
При нажатии кнопки “Save” среда предложит записать новый файл описания контроллера в папку проекта. Автор рекомендует создавать каждому проекту индивидуальный файл *.icp и хранить его в папке с проектом.
Если вы собираетесь внутрисхемно отлаживать свой проект, что рекомендуется, то вводим тип применяемого отладчика:
На вкладке выбранного отладчика указываем интерфейс подключения отладчика (в нашем случае выбран ST-Link) к контроллеру:
 |
С этого момента наш проект без библиотек готов к компиляции и загрузке в контроллер. В других средах, таких как Keil uVision4, Resonance Ride7 и т. п. потребуется выполнить эти же действия.
Если в файле main.c написать строку:
#include "stm32f10x.h" или
#include "stm32f2xx.h" или
#include "stm32f4xx.h" или
#include "stm32l15x.h" или
#include "stm32l10x.h" или
#include "stm32f05x.h"
с указанием расположения данного файла, либо копированием данного файла в папку проекта, то произойдёт ассоциация некоторых областей памяти с регистрами периферии соответствующего семейства. Сам файл находится в папке библиотеки стандартной периферии в разделе: \CMSIS\CM3\DeviceSupport\ST\STM32F10x (или похожее по названию для других семейств). С этого момента вы заменять адрес регистра периферии в виде числа его названием. Даже если вы не собираетесь использовать функции стандартной библиотеки, рекомендуется сделать такое подключение.
Если вы собираетесь использовать в своём проекте прерывания, то рекомендуется подключить стартовый файл с расширением *.s, который находится по пути \CMSIS\CM3\DeviceSupport\ST\STM32F10x\startup\iar, или подобном, для других семейств. Важно отметить, что для каждой среды файл свой. Соответственно, если мы используем IAR EWB, то должны взять файл из папки IAR. Это обусловлено небольшим различием синтаксиса сред. Поэтому, чтобы проект запустился сразу, инженеры STMicroelectronics написали несколько вариантов стартовых файлов для нескольких наиболее популярных сред разработки. Большинство семейств STM32 имеют один файл. Семейство STM32F1 имеет несколько запускающих фалов:
- startup_stm32f10x_cl.s – для микроконтроллеров STM32F105/107
- startup_stm32f10x_xl.s - для микроконтроллеров STM32F101/STM32F103 768кб и более
- startup_stm32f10x_hd.s - для микроконтроллеров STM32F101/STM32F103 c памятью Flash 256-512 кб
- startup_stm32f10x_md.s - для микроконтроллеров STM32F101/ STM32F102/STM32F103 c памятью Flash 64-128 кб
- startup_stm32f10x_ld.s - для микроконтроллеров STM32F101/ STM32F102/STM32F103 c памятью Flash менее 64кб
- startup_stm32f10x_hd_vl.s для микроконтроллеров STM32F100 c памятью Flash 256-512 кб
- startup_stm32f10x_md_vl.s для микроконтроллеров STM32F100 c памятью Flash 64-128 кб
- startup_stm32f10x_ld_vl.s для микроконтроллеров STM32F100 c памятью Flash 32кб и менее
Итак, в зависимости семейства, подсемейства и среды разработки добавляем запускающий файл в проект:
Именно здесь оказывается микроконтроллер при старте программы. Прерывание последовательно вызывает функцию SystemInit(), а затем __iar_program_start. Вторая функция обнуляет либо записывает заранее заданные значения глобальных переменных, после чего осуществляет переход в программу пользователя main(). Функция SystemInit() настраивает тактирование микроконтроллера. Именно она даёт ответы на вопросы:
- Надо ли переключаться на внешний кварц (HSE)?
- Как умножить частоту от HSI/HSE?
- Требуется ли подключение очереди загрузки команд?
- Какая требуется задержка при загрузке команды (из-за низкой скорости работы Flash памяти)
- Как поделить тактирование шин периферии?
- Требуется ли разместить код во внешней ОЗУ?
Функцию SystemInit() можно прописать вручную в своём проекте. Если оформить эту функцию как пустую, то контроллер будет работать на внутреннем RC-генераторе с частотой порядка 8МГц (в зависимости от типа семейства). Вариант 2 – подключить к проекту файл system_stm32f10x.c (либо похожий по названию в зависимости от типа используемого семейства), который расположен в библиотеке по пути: Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x. В этом файле имеется функция SystemInit(). Обратите внимание на частоту внешнего кварца HSE_VALUE. Данный параметр выставляется в заголовочном файле stm32f10x.h. Стандартное значение 8 и 25МГц, в зависимости от семейства STM32. Основная задача функции SystemInit() – переключить тактирование на внешний кварц и умножить определённым образом данную частоту. Что произойдёт, если значение HSE_VALUE указано 8МГц, ядро должно тактироваться частотой 72МГц, а по факту на плате стоит кварц 16МГц? В результате таких некорректных действий ядро получит тактирование 144МГц, которые могут оказаться за пределами гарантированной работы системы на STM32. Т.е. при подключении файла system_stm32f10x.c потребуется указать значение HSE_VALUE. Всё это означает, что файлы system_stm32f10x.c, system_stm32f10x.h и stm32f10x.h (или похожие по названию для других семейств) должны быть индивидуальными для каждого проекта. И
нженеры STMicroelectronics создали инструмент Clock Configuration Tool, который позволяет правильно настроить тактирование системы. Это файл Excel, генерирующий файл system_stm32xxx.c (похожий по названию для заданного семейства семейств), после задания входных и выходных параметров системы. Рассмотрим его работу на примере STM32F4 семейства.
Варианты: внутренний RC-генератор, внутренний RC-генератор с умножением частоты, либо внешний кварц с умножением частоты. После выбора источника тактирования вводим параметры желаемой конфигурации системы, такие как входную частоту (при использовании внешнего кварца), частоту тактирования ядра, делители частоты тактирования шин периферии, работу буфера выборки команд и другие. Нажав на кнопку “Generate”, получаем окно
 |
Подключение файла system_stm32f4xx.c и его аналогов потребует подключение ещё одного файла стандартной библиотеки периферии. Для управления тактированием имеется целый набор функций, которые вызываются из файла system_stm32xxxxxx.c. Эти функции расположены в файле stm32f10x_rcc.c и его заголовке. Соответственно, подключая к проекту файл файла system_stm32xxxxxx.c требуется подключить stm32f10x_rcc.c, иначе линкер среды сообщит об отсутствии описания функций с именем RCC_xxxxxxx. Указанный файл находится в библиотеке периферии по пути: Libraries\STM32F10x_StdPeriph_Driver\src, а его заголовок \Libraries\STM32F10x_StdPeriph_Driver\inc.
Подключение заголовочных файлов драйвера периферии происходит в файле stm32f10x_conf.h, на который ссылается stm32f10x.h. Файл stm32f10x_conf.h – это просто набор заголовочных файлов драйверов конкретных периферий контроллера, подлежащих включению в проект. Изначально все заголовки «#include» отмечены как комментарии. Подключение заголовочного файла периферии заключается в снятии комментария с соответствующего названия файла. В нашем случае – это строка #include "stm32f10x_rcc.h". Очевидно, что файл stm32f10x_conf.h индивидуален для каждого проекта, т.к. разные проекты используют разную периферию.
И последнее. Надо указать несколько директив препроцессору компилятора и пути к заголовочным файлам.
 |
Пути к заголовочным файлам могут быть иными, в зависимости от расположения библиотеки периферии относительно папки проекта, а вот наличие “ USE_STDPERIPH_DRIVER” – обязательно при подключении драйверов периферии стандартной библиотеки.
Итак, мы подключили стандартную библиотеку, к проекту. Более того, мы подключили один из стандартных драйверов периферии к проекту, выполняющих управление тактированием системы.
Мы познали, как выглядит устройство библиотеки изнутри, теперь пара слов о том как она выглядит снаружи.
 |
Таким образом, подключение заголовочного файла stm32f10x.h в приложении тянет за собой подключение других заголовочных файлов и файлов кода. Некоторые из представленных на рисунке описаны выше. Несколько слов об остальных. Файлы STM32F10x_PPP.x – это файлы-драйверы периферии. Пример подключения такого файла показан выше, это RCC – периферия управления тактированием системы. Если мы хотим подключить драйверы другой периферии, то название подключаемых файлов получается заменой «PPP» названием периферии, например АЦП - STM32F10x_ADC.с, или порты ввода-вывода STM32F10x_GPIO.с, или ЦАП - STM32F10x_DAC.с. В целом интуитивно понятно какой файл нужно подключить при подключении заданной периферии. Файлы «misc.c», «misc.h» - это по большому счёту те же STM32F10x_PPP.x, только выполняют управление ядром. Например настройку векторов прерываний, который встроен в ядро или управление таймером SysTick, который является частью ядра. Файлы xxxxxxx_it.c описывают вектора немаскируемых прерываний контроллера. Они могут быть дополнены векторами прерываний периферии. Файл core_m3.h описывает ядро CortexM3. Данное ядро стандартизовано и может встречаться в микроконтроллерах других производителей. Для кросс-платформенной универсализации компания STMicroelectronics провела работу по созданию отдельной библиотеки ядра CortexM, после чего компания ARM стандартизировала её и распространила на других производителей микроконтроллеров. Так что переход на STM32 с контроллеров других производителей с ядром CortexM будет чуть проще.
Итак, мы можем подключить библиотеку стандартной периферии к любому семейству STM32. Того, кто научился это делать ждёт приз: очень простое программирование микроконтроллеров. Библиотека кроме драйверов в виде исходных файлов содержит множество примеров применения периферии. Для примера, рассмотрим создание проекта с участием выходов сравнения таймера. При традиционном подходе мы будем внимательно изучать описание регистров данной периферии. Но сейчас мы можем изучить текст работающей программы. Заходим в папку примеров стандартной периферии, которая находится по пути ProjectSTM32F10x_StdPeriph_Examples. Здесь находятся папки примеров с названием применяемой периферии. Заходим в папку «TIM». Таймеры в STM32 имеют множество функций и настроек, поэтому одним примером возможности контроллера продемонстрировать невозможно. Поэтому внутри указанного каталога имеется множество примеров применения таймеров. Нас интересует генерация ШИМ сигнала таймером. Заходим в папку «7PWM_Output». Внутри имеется описание работы программы на английском языке и набор файлов:
| main.c stm32f10x_conf.h stm32f10x_it.h stm32f10x_it.c system_stm32f10x.c |
Если проект не имеет прерываний, то содержательная часть полностью расположена в файле main.c. Копируем эти файлы в каталог проекта. Скомпилировав проект, мы получим программу для STM32, которая настроит таймер и порты ввода-вывода на генерацию 7-ми ШИМ сигналов от таймера 1. Далее, мы можем приспособить уже написанный код под свою задачу. Например, уменьшить число ШИМ сигналов, изменить скважность, направление счёта и т.п. Функции и их параметры хорошо описаны в файле stm32f10x_stdperiph_lib_um.chm. Названия же функций и их параметров легко ассоциируются с их назначением для тех, кто немного знает английский язык. Для наглядности приводим часть кода взятого примера:
| /* Time Base configuration */ TIM_TimeBaseStructure.TIM_Prescaler = 0; // предделение счётных импульсов отсутствует (16-битный регистр) TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; // направление счёта вверх TIM_TimeBaseStructure.TIM_Period = TimerPeriod; // счёт выполнять до значения TimerPeriod (константа в программе) TIM_TimeBaseStructure.TIM_ClockDivision = 0; // предделение счётных отсутствует TIM_TimeBaseStructure.TIM_RepetitionCounter = 0; // счётчик переполнений для генерации событий (не используется в программе) TIM_TimeBaseInit(TIM1, &TIM_TimeBaseStructure); // ввод значений TimeBaseStructure в регистры таймера 1 (ввод данных в эту // переменную - выше) /* Channel 1, 2,3 and 4 Configuration in PWM mode */ // настройка ШИМ выходов TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_PWM2; // режим работы ШИМ2 TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Enable; // разрешитьвыход ШИМ сигналов таймера TIM_OCInitStructure.TIM_OutputNState = TIM_OutputNState_Enable; // разрешить комплиментарный выходШИМтаймера TIM_OCInitStructure.TIM_Pulse = Channel1Pulse; // ширина импульс Channel1Pulse – константа в программе TIM_OCInitStructure.TIM_OCPolarity = TIM_OCPolarity_Low; // настройка полярности выхода TIM_OCInitStructure.TIM_OCNPolarity = TIM_OCNPolarity_High; // настройка полярности комплиментарного выхода TIM_OCInitStructure.TIM_OCIdleState = TIM_OCIdleState_Set; // установка безопасного состояния выхода ШИМ TIM_OCInitStructure.TIM_OCNIdleState = TIM_OCIdleState_Reset; // установка безопасного состояния комплиментарного выхода ШИМ TIM_OC1Init(TIM1, &TIM_OCInitStructure); // ввод значений переменной TIM_OCInitStructure в регистры ШИМ канала 1 // таймера1 TIM_OCInitStructure.TIM_Pulse = Channel2Pulse; // меняем ширину импульса в переменной OCInitStructure и вводим её в TIM_OC2Init(TIM1, &TIM_OCInitStructure); // регистры ШИМ канала 2 таймера1 TIM_OCInitStructure.TIM_Pulse = Channel3Pulse; // меняем ширину импульса в переменной OCInitStructure и вводим её в TIM_OC3Init(TIM1, &TIM_OCInitStructure); // регистры ШИМ канала 3 таймера1 TIM_OCInitStructure.TIM_Pulse = Channel4Pulse; // меняем ширину импульса в переменной OCInitStructure и вводим её в TIM_OC4Init(TIM1, &TIM_OCInitStructure); // регистры ШИМ канала 4 таймера1 /* TIM1 counter enable */ TIM_Cmd(TIM1, ENABLE); // запускаем таймер1 /* TIM1 Main Output Enable */ TIM_CtrlPWMOutputs(TIM1, ENABLE); // разрешаем работу выходов сравнения таймера 1 |
В правой части автор оставил комментарий на русском языке к каждой строке программы. Если открыть этот же пример в описании функций библиотек stm32f10x_stdperiph_lib_um.chm, то мы увидим, что все используемые параметры функций имеют ссылку на собственное описание, где будут указаны их возможные значения. Сами функции тоже имеют ссылку на собственное описание и исходный код. Это очень полезно, т.к. зная, что функция делает, мы можем проследить, каким образом она это делает, на какие биты регистров периферии и как она воздействует. Это, во-первых, ещё один источник информации для освоения контроллера, основанный на практическом использовании контроллера. Т.е. вы сначала решите техническую задачу, а потом изучите само решение. Во-вторых, это поле для оптимизации программы тому, кого библиотека не устроит по скорости работы и объёму кода.
 |
Список статей который поможет изучить микроконтроллер STM32 даже начинающему. Подробно обо всем с примерами начиная от мигания светодиодом до управления бесколлекторным двигателем. В примерах используется стандартная библиотека SPL (Standard Peripheral Library).
Тестовая плата STM32F103, ST-Link программатор, и программное обеспечение для прошивки под Windows и Ubuntu.
VIC (Nested vectored interrupt controller) – модуль контроля прерываний. Настройка и использование прерываний. Приоритеты прерываний. Вложенные прерывания.
АЦП (аналого-цифровой преобразователь). Схема питания и примеры использования АЦП в различных режимах. Regular и Injected каналы. Использование АЦП вместе с DMA. Внутренний термометр. Аналоговый watchdog.
Таймеры общего назначения. Генерирование прерывания через равные промежутки времени. Измерение времени между двумя событиями.
Захвата сигнала таймером на примере работы с ультразвуковым датчиком HC-SR04
Использование таймера для работы с энкодером.
Генерация ШИМ. Управление яркостью светодиода. Управление сервоприводом (сервомашинками). Генерация звука.
Когда только начинаешь программировать микроконтроллеры или давно не занимался программированием, то разбираться в чужом коде довольно не легко. Вопросы "Что это такое?" и "Откуда это взялось?" возникают чуть ли не на каждом сочетании букв и цифр. И чем быстрее приходит понимание логики "что? зачем? и откуда?", тем легче проходит изучение чужого кода, в том числе и примеров. Правда иногда для этого приходиться не один день "попрыгать по коду" и "полистать мануалов".
У всех микроконтроллеров STM32F4xx довольно много периферии. За каждым периферийным устройством микроконтроллеров закреплена определённая, конкретная и неперемещаемая область памяти. Каждая область памяти состоит из регистров памяти, причём эти регистры могут быть 8-разрядными, 16-разрядными, 32-разрядными или ещё как, зависит от микроконтроллера. В микроконтроллере STM32F4 эти регистры 32-разрядные и каждый регистр имеет своё назначение и свой конкретный адрес. Ничто не мешает в своих программах обращаться к ним напрямую, указывая адрес. По какому адресу размещен тот или иной регистр и к какому периферийному устройству он относиться указывается в карте памяти. Для STM32F4 такая карта памяти есть в документе DM00031020.pdf, который можно найти на сайте st.com. Документ называется
RM0090
Reference manual
STM32F405xx/07xx, STM32F415xx/17xx, STM32F42xxx and STM32F43xxx advanced ARM-based 32-bit MCUs
В разделе 2.3 Memory map на странице 64 начинается таблица с адресами областей регистров и их принадлежностью к периферийному устройству. В той же таблице есть ссылка на раздел с более подробным распределением памяти для каждой периферии.
Слева в таблице указан диапазон адресов, в середине название периферии и в последнем столбце - где находиться более подробное описание распределения памяти.
Так для портов ввода-вывода общего назначения GPIO в таблице распределения памяти можно найти что для них выделены адреса начиная с 0х4002 0000. Порт ввода-вывода общего назначения GPIOA занимает диапазон адресов от 0х4002 000 до 0х4002 03FF. Порт GPIOB занимает диапазон адресов 0х4002 400 - 0х4002 07FF. И так далее.
Для того чтобы посмотреть более подробное распределение в самом диапазоне, нужно просто пройти по ссылке.
Здесь также находиться таблица, но уже с картой памяти для диапазона адресов GPIO. Согласно этой карте памяти первые 4 байта принадлежат регистру MODER, следующие 4 байта принадлежат регистру OTYPER и так далее. Адреса регистров считаются от начала диапазона, принадлежащему конкретному порту GPIO. То есть каждый регистр GPIO имеет конкретный адрес, который можно использовать при разработке программ для микроконтроллера.
Но использование адресов регистров для человека неудобно и чревато большим количеством ошибок. Поэтому производители микроконтроллеров создают стандартные библиотеки, которые облегчают работу с микроконтроллерами. В этих библиотеках физическим адресам ставиться в соответствие их буквенное обозначение. Для STM32F4xx эти соответствия заданы в файле stm32f4xx.h . Файл stm32f4xx.h принадлежит библиотеке CMSIS и лежит в папке Libraries\CMSIS\ST\STM32F4xx\Include\.
Посмотрим как определяется в библиотеках порт GPIOA. Аналогично определяется и всё остальное. Достаточно понять принцип. Файл stm32f4xx.h
довольно большой и поэтому лучше использовать поиск или возможности, которые предоставляет ваш toolchain.
Для порта GPIOA находим строку в которой упоминается GPIOA_BASE
GPIOA_BASE определяется через AHB1PERIPH_BASE
AHB1PERIPH_BASE в свою очередь определяется через PERIPH_BASE
А в свою очередь PERIPH_BASE определяется как 0х4000 0000. Если посмотреть карту рапределения памяти периферийных устройств (в разделе 2.3 Memory map на странице 64), то увидим этот адрес в самом низу таблицы. С этого адреса начинаются регистры всей периферии микроконтроллера STM32F4. То есть PERIPH_BASE - это начальный адрес всей периферии микроконтроллеров STM32F4xx вообще, и микроконтроллера STM32F407VG в частности..
AHB1PERIPH_BASE определяется как сумма (PERIPH_BASE + 0x00020000). (см.картинки обратно). Это будет адрес 0х4002 0000. В карте памяти с этого адреса начинаются порты ввода-вывода общего назначения GPIO.
GPIOA_BASE определяется как (AHB1PERIPH_BASE + 0x0000), то есть это начальный адрес группы регистров порта GPIOA.
Ну а сам порт GPIOA определяется как структура из регистров, размещение которых в памяти начинается с адреса GPIOA_BASE (см строку #define GPIOA ((GPIO_TypeDef *) GPIOA_BASE).
Структура каждого порта GPIO определяется как тип GPIO_TypeDef.
Таким образом, стандартные библиотеки, в данном случае файл stm32f4xx.h , просто очеловечивают машинную адресацию. Если вы увидите запись GPIOA->ODR = 1234, то это означает, что по адресу 0х40020014 будет записано число 1234. GPIOA имеет начальный адрес 0х40020000 и регистр ODR имеет адрес 0х14 от начала диапазона, поэтому GPIOA->ODR имеет адрес 0х40020014.
Или например, вам не нравиться запись GPIOA->ODR, то можно определить #define GPIOA_ODR ((uint32_t *) 0x40020014) и получить тот же самый результат, записав GPIOA_ODR = 1234;. Только вот насколько это целесообразно? Если действительно хочется ввести свои обозначения, то лучше просто переназначить стандартные. Как это делается, можно посмотреть в файле stm32f4_discovery.h Например, вот так там определяется один из светодиодов:
#define LED4_PIN GPIO_Pin_12
#define LED4_GPIO_PORT GPIOD
#define LED4_GPIO_CLK RCC_AHB1Periph_GPIOD
Более детальное описание периферии портов находиться в stm32f4xx_gpio.h
Взаимодействие пользовательского кода с регистрами ядра и периферии микроконтроллеров STM32 может быть осуществлено двумя способами: с помощью стандартных библиотек или с помощью наборов сниппетов (программных подсказок). Выбор между ними зависит от объема собственной памяти контроллера, требуемого быстродействия, срока выполнения разработки. В статье анализируются особенности структуры, достоинства и недостатки наборов сниппетов для микроконтроллеров семейств STM32F1 и STM32L0 производства компании STMicroelectronics.
Одно из преимуществ использования микроконтроллеров STMicroelectronics – широкий спектр средств разработки: документации, отладочных плат, программного обеспечения.
Программное обеспечение для STM32 включает в себя собственное ПО производства компании STMicroelectronics, источники Open Source, коммерческое ПО.
ПО от STMicroelectronics обладает важными достоинствами. Во-первых, оно доступно для бесплатного скачивания. Во-вторых, программные библиотеки представлены в виде исходных кодов – пользователь сам может модифицировать код, учитывая незначительные ограничения, описанные в лицензионном соглашении.
Библиотеки STMicroelectronics соответствуют ANSI-C и могут быть разделены по уровню абстракции (рисунок 1):
- CMSIS (Core Peripheral Access Layer) – уровень регистров ядра и периферии, ARM библиотека;
- Hardware Abstraction Layer – низкоуровневые библиотеки: стандартные библиотеки периферии (standard peripheral library), наборы сниппетов (snippets);
- Middleware – библиотеки среднего уровня: операционные системы реального времени (RTOS), файловые системы, USB, TCP/IP, Bluetooth, Display, ZigBee, Touch Sensing и другие;
- Application Field – библиотеки прикладного уровня: аудио, управление двигателями, автомобильные и промышленные решения.
На рисунке 1 видно, что для взаимодействия с уровнем CMSIS компания STMicroelectronics предлагает использовать два основных инструмента – стандартные библиотеки и сниппеты.
Стандартная библиотека – это набор драйверов. Каждый драйвер предоставляет пользователю функции и определения для работы с конкретным периферийным блоком (SPI, USART, ADC и так далее). Напрямую пользователь с регистрами уровня CMSIS не взаимодействует.
Наборы сниппетов – это высокоэффективные программные примеры, использующие прямой доступ к регистрам CMSIS. Разработчики ПО могут использовать реализации функций из этих примеров в собственном коде.
Каждый из способов имеет достоинства и недостатки. Выбор между ними делается с учетом доступного объема FLASH и ОЗУ, требуемого быстродействия, срока выполнения разработки, опытности программистов и других обстоятельств.
Уровень CMSIS
Микроконтроллер – это сложная цифро-аналоговая микросхема, состоящая из процессорного ядра, памяти, периферийных блоков, цифровых шин и так далее. Взаимодействие с каждым блоком происходит с помощью регистров.
С точки зрения программистов, микроконтроллер представляет собой пространство памяти. В нем размещены не только ОЗУ, FLASH и EEPROM, но и программные регистры. Каждому аппаратному регистру соответствует ячейка памяти. Таким образом, чтобы записать данные в регистр или вычитать его значение, программисту необходимо обратиться к соответствующей ячейке адресного пространства.
Человек имеет некоторые особенности восприятия. Например, символьные названия воспринимаются им гораздо лучше, чем адреса ячеек памяти. Это особенно заметно, когда используется большое число ячеек. В микроконтроллерах ARM число регистров, а значит, и используемых ячеек, превышает тысячу. Чтобы упростить работу, необходимо произвести определение символьных указателей. Это определение выполнено на уровне CMSIS.
Например, чтобы установить состояние выводов порта А, нужно записать данные в регистр GPIOA_ODR. Это можно сделать двумя способами – воспользоваться указателем с адресом ячейки 0xEBFF FCFF со смещением 0x14 или применить указатель с символьным названием GPIOA и готовую структуру, определяющую смещение. Очевидно, что второй вариант гораздо проще для восприятия.
CMSIS выполняет и другие функции. Он реализован в виде следующей группы файлов:
- startup_stm32l0xx.s содержит ассемблерный стартовый код Cortex-M0+ и таблицу векторов прерываний. После выполнения стартовой инициализации происходит передача управления сначала функции SystemInit() (ниже будут приведены пояснения), а затем – основной функции int main(void);
- stm32l0xx.h содержит определения, необходимые для выполнения основных операций с битами и определение типа используемого микропроцессора;
- system_stm32l0xx.c/.h. После начальной инициализации выполняется функция SystemInit(). Она производит первичную настройку системной периферии, таймингов блока RCC;
- stm32l0yyxx.h – файлы реализации конкретных микроконтроллеров (например, stm32l051xx.h). Именно в них определяются символьные указатели, структуры данных, битовые константы и смещения.
Взаимодействие со CMSIS. Стандартные библиотеки и сниппеты
Число регистров для микроконтроллеров STM32 в большинстве моделей превышает тысячу. Если использовать прямое обращение к регистрам, пользовательский код станет нечитаемым и абсолютно непригодным для поддержки и модернизации. Эта проблема может быть решена при использовании стандартной библиотеки периферии (standard peripheral library).
Стандартная библиотека периферии – это набор низкоуровневых драйверов. Каждый драйвер предоставляет пользователю набор функций для работы с периферийным блоком. Таким образом пользователь использует функции, а не обращается напрямую к регистрам. При этом уровень CMSIS оказывается скрытым от программиста (рисунок 2а).
|
|
|
Рис. 2. Взаимодействие с CMSIS с помощью стандартной библиотеки (а) и сниппетов (б)
Например, взаимодействие с портами ввода/вывода в STM32L0 реализовано с помощью драйвера, выполненного в виде двух файлов: stm32l0xx_hal_gpio.h и stm32l0xx_hal_gpio.c. В stm32l0xx_hal_gpio.h даны основные определения типов и функций, а в stm32l0xx_hal_gpio.c представлена их реализация.
Такой подход имеет вполне очевидные достоинства (таблица 1):
- Быстрота создания кода. Программисту не требуется изучать перечень регистров. Он сразу начинает работать на более высоком уровне. Например, для прямого взаимодействия с портом ввода/вывода в STM32L0 необходимо знать и уметь работать с одиннадцатью регистрами управления/состояния, большинство из которых имеют до 32 настраиваемых битов. При использовании библиотечного драйвера достаточно освоить восемь функций.
- Простота и наглядность кода. Пользовательский код не забит названиями регистров, может быть прозрачным и легко читаемым, что важно при работе команды разработчиков.
- Высокий уровень абстракции. При использовании стандартной библиотеки код оказывается достаточно платформо-независимым. Например, если сменить микроконтроллер STM32L0 на микроконтроллер STM32F0 , часть кода, работающего с портами ввода/вывода, вообще не придется менять.
Таблица 1. Сравнение способов реализации пользовательского кода
| Параметр сравнения | При использовании стандартной библиотеки периферии |
При использовании наборов сниппетов |
| Размер кода | средний | минимальный |
| Затраты ОЗУ | средние | минимальные |
| Быстродействие | среднее | максимальное |
| Читаемость кода | отличная | низкая |
| Уровень независимости от платформы | средний | низкий |
| Скорость создания программ | высокая | низкая |
Наличие дополнительной оболочки в виде драйверов имеет и очевидные недостатки (таблица 1):
- Увеличение объема кода программы. Реализованные в библиотечном коде функции требуют дополнительного места в памяти.
- Повышенные затраты ОЗУ за счет увеличения числа локальных переменных и использования громоздких структур данных.
- Снижение быстродействия за счет увеличения накладных расходов при вызове библиотечных функций.
Именно наличие этих недостатков приводило к тому, что пользователь зачастую был вынужден оптимизировать код – самостоятельно реализовывать функции взаимодействия с CMSIS, оптимизировать библиотечные функции, убирая все лишнее, копировать реализации библиотечных функций непосредственно в свой код, использовать __INLINE-директивы для увеличения скорости выполнения. В результате, тратилось дополнительное время на доработку кода.
Компания STMicroelectronics, идя навстречу разработчикам, выпустила сборники сниппетов STM32SnippetsF0 и STM32SnippetsL0 .
Сниппеты входят в пользовательский код (рисунок 2б).
Использование сниппетов предоставляет очевидные преимущества:
- повышение эффективности и быстродействия кода;
- уменьшение объема программы;
- снижение объемов используемой ОЗУ и нагрузки на стек.
Впрочем, стоит отметить и недостатки:
- уменьшение простоты и наглядности кода за счет «загрязнения» его названиями регистров и самостоятельной реализацией низкоуровневых функций;
- исчезновение платформо-независимости.
Таким образом, выбор между стандартной библиотекой и сниппетами не является очевидным. В большинстве случаев стоит говорить не о конкуренции, а о взаимном их использовании. На начальных этапах для быстрого построения «красивого» кода, логично использовать стандартные драйвера. При необходимости оптимизации можно обратиться к готовым сниппетам, чтобы не тратить время на разработку собственных оптимальных функций.
Стандартные библиотеки драйверов и сниппетов STM32F0 и STM32L0 (таблица 2) доступны для свободного скачивания на сайте www.st.com.
Таблица 2. Низкоуровневые библиотеки для STM32F10 и STM32L0
Более тесное знакомство со сниппетами, как и с любым ПО, следует начинать с рассмотрения особенностей лицензионного соглашения.
Лицензионное соглашение
Любой ответственный программист перед использованием сторонних программных продуктов внимательно изучает лицензионное соглашение. Несмотря на то, что сборники сниппетов производства ST Microelectronics не требуют лицензирования и доступны для свободного скачивания, это не значит, что на их использование не накладываются ограничения.
Лицензионное соглашение входит в комплект всех свободно скачиваемых продуктов производства компании STMicroelectronics. После загрузки STM32SnippetsF0 и STM32SnippetsL0 в корневом каталоге легко обнаружить документ MCD-ST Liberty SW License Agreement V2.pdf, который знакомит пользователя с правилами использования данного ПО.
В папке Project содержатся подкаталоги с примерами для конкретных периферийных блоков, готовые проекты для ARM Keil и EWARM, а также файлы main.c.
Запуск и особенности использования наборов сниппетов STM32SnippetsF0 и STM32SnippetsL0
Особенностью данных наборов снипетов является их платформозависимость. Они предназначены для работы с конкретными платами. STM32SnippetsL0 использует платформу STM32L053 Discovery board, а STM32SnippetsF0 – плату STM32F072 Discovery board.
При использовании плат собственной разработки код и проекты должны быть изменены, об этом будет более подробно рассказано в последнем разделе.
Для запуска примера необходимо выполнить ряд шагов:
- запустить готовый проект из директории с требуемым примером. Для простоты можно воспользоваться готовыми проектами для сред ARM Keil или EWARM, расположенными в папке MDK-ARM\ и EWARM\ соответственно;
- включить питание отладочной платы STM32L053 Discovery/STM32F072 Discovery;
- подключить питание отладочной платы к ПК с помощью USB-кабеля. Благодаря встроенному отладчику ST-Link/V2 дополнительного программатора не потребуется;
- открыть, настроить и запустить проект;
- Для ARM Keil:
- открыть проект;
- скомпилировать проект – Project → Rebuild all target files;
- загрузить его в контроллер – Debug → Start/Stop Debug Session;
- запустить программу в окне Debug → Run (F5).
- Для EWARM:
- открыть проект;
- скомпилировать проект – Project → Rebuild all;
- загрузить его в контроллер – Project → Debug;
- запустить программу в окне Debug → Go(F5).
- Для ARM Keil:
- провести тестирование в соответствии с алгоритмом, описанном в main.c.
Для анализа программного кода рассмотрим конкретный пример из STM32SnippetsL0: Projects\LPUART\01_WakeUpFromLPM\.
Запуск примера для LPUART
Отличительной особенностью новых микроконтроллеров семейства STM32L0 на ядре Cortex-M0+ является возможность динамического изменения потребления за счет большого числа нововведений. Одним из таких новшеств стало появление Low Power-периферии: 16-битного таймера LPTIM и приемопередатчика LPUART. Эти блоки обладают способностью тактирования, не зависящего от тактирования основной периферийной шины APB. При необходимости снижения потребляемой мощности рабочая частота шины APB (PCLK) может быть уменьшена, а сам контроллер переведен в режим пониженного потребления. При этом Low Power-периферия продолжает работу с максимальной производительностью.
Рассмотрим пример из директории Projects\LPUART\01_WakeUpFromLPM\, в котором рассматривается возможность независимой работы LPUART в режиме пониженного потребления.
При открытии проекта в среде ARM Keil отображаются всего три файла: startup_stm32l053xx.s, system_stm32l0xx.c и main.c (рисунок 4). В случае применения стандартной библиотеки в проект было бы необходимо добавить файлы драйверов.
Функционирование и анализ структуры файла Main.c
Программа из выбранного примера выполняется в несколько этапов.
После старта запускается функция SystemInit(), реализованная в system_stm32l0xx.c. Она проводит настройку параметров блока тактирования RCC (тайминги и рабочие частоты). Далее осуществляется передача управления в основную функцию int main(void). В ней инициализируется пользовательская периферия – порты вводы/вывода, LPUART – после чего контроллер переводится в режим пониженного потребления STOP. В нем обычная периферия и ядро остановлены, работает только LPUART. Он ждет начала передачи данных от внешнего устройства. При приходе стартового бита LPUART пробуждает систему и принимает сообщение. Прием сопровождается мерцанием светодиода отладочной платы. После этого контроллер вновь переводится в состояние STOP и ждет следующей передачи данных, если не было обнаружено ошибок.
Передача данных происходит при помощи виртуального COM-порта и дополнительного ПО.
Рассмотрим main.c из нашего проекта. Этот файл представляет собой стандартный С-файл. Главной его особенностью является самодокументация – наличие подробных комментариев, пояснений и рекомендаций. Пояснительная часть содержит несколько разделов:
- заголовок с указанием названия файла, версии, даты, автора, краткого пояснения назначения;
- описание последовательности настройки системной периферии (RCC specific features): FLASH, ОЗУ, системы питания и тактирования, периферийных шин и так далее;
- перечень используемых ресурсов микроконтроллера (MCU Resources);
- краткое пояснение по использованию данного примера (How to use this example);
- краткое пояснение по тестированию примера и алгоритм его проведения (How to test this example).
Функция int main(void) имеет компактную форму и снабжена комментариями, которые в листинге 1, для большей наглядности, переведены на русский.
Листинг 1. Пример реализация функции main
int main(void)
{
/* К началу выполнения этой части когда уже произведена конфигурация системных блоков в функции SystemInit(), реализованной в system_stm32l0xx.c. */
/* конфигурация периферийных блоков*/
Configure_GPIO_LED();
Configure_GPIO_LPUART();
Configure_LPUART();
Configure_LPM_Stop();
/* проверка наличия ошибок при приеме */
while (!error) /* бесконечный цикл */
{
/* ожидание готовности LPUART и переход в режим STOP */
if((LPUART1->ISR & USART_ISR_REACK) == USART_ISR_REACK)
{
__WFI();
}
}
/* при возникновении ошибки */
SysTick_Config(2000); /* установка периода прерываний системного таймера 1 мс */
while(1);
}
В файле main.c объявлены и определены функции конфигурации периферии и две функции обработки прерываний. Рассмотрим их особенности.
В приведенном примере используются четыре функции конфигурации (листинг 2). Все они не имеют аргументов и не возвращают значений. Их главное предназначение – быстро и с наименьшими затратами занимаемого кода произвести инициализацию периферии. Это реализуется за счет двух особенностей: применения прямого обращения к регистрам и использования директивы __INLINE (листинг 3).
Листинг 2. Объявление функций конфигурации периферии
void Configure_GPIO_LED(void);
void Configure_GPIO_LPUART(void);
void Configure_LPUART(void);
void Configure_LPM_Stop(void);
Листинг 3. Пример реализации __INLINE-функции с прямым доступом к регистрам LPUART
INLINE void Configure_LPUART(void)
{
/* (1) Enable power interface clock */
/* (2) Disable back up protection register to allow the access to the RTC clock domain */
/* (3) LSE on */
/* (4) Wait LSE ready */
/* (5) Enable back up protection register to allow the access to the RTC clock domain */
/* (6) LSE mapped on LPUART */
/* (7) Enable the peripheral clock LPUART */
/* Configure LPUART */
/* (8) oversampling by 16, 9600 baud */
/* (9) 8 data bit, 1 start bit, 1 stop bit, no parity, reception mode, stop mode */
/* (10) Set priority for LPUART1_IRQn */
/* (11) Enable LPUART1_IRQn */
RCC->APB1ENR |= (RCC_APB1ENR_PWREN); /* (1) */
PWR->CR |= PWR_CR_DBP; /* (2) */
RCC->CSR |= RCC_CSR_LSEON; /* (3) */
while ((RCC->CSR & (RCC_CSR_LSERDY)) != (RCC_CSR_LSERDY)) /*(4)*/
{
/* add time out here for a robust application */
}
PWR->CR &=~ PWR_CR_DBP; /* (5) */
RCC->CCIPR |= RCC_CCIPR_LPUART1SEL; /* (6) */
RCC->APB1ENR |= RCC_APB1ENR_LPUART1EN; /*(7) */
LPUART1->BRR = 0x369; /* (8) */
LPUART1->CR1 = USART_CR1_UESM | USART_CR1_RXNEIE | USART_CR1_RE | USART_CR1_UE; /* (9) */
NVIC_SetPriority(LPUART1_IRQn, 0); /* (10) */
NVIC_EnableIRQ(LPUART1_IRQn); /* (11) */
}
Обработчики прерываний от системного таймера и от LPUART также используют прямое обращение к регистрам.
Таим образом, общение с CMSIS производится без стандартной библиотеки. Код оказывается компактным и высокоэффективным. Однако его читаемость значительно ухудшатся из-за обилия обращений к регистрам.
Использование сниппетов в собственных разработках
Предложенные наборы сниппетов имеют ограничения: необходимо использовать отладочную плату STM32L053 Discovery board для STM32SnippetsL0 , а плату STM32F072 Discovery board – для STM32SnippetsF0 .
Для применения сниппетов в своих разработках потребуется произвести ряд изменений. Во-первых, необходимо переконфигурировать проект под нужный процессор. Для этого в нем нужно сменить стартовый файл startup_stm32l053xx.s на файл другого контроллера и определить нужную константу: STM32L051xx, STM32L052xx, STM32L053xx, STM32L062xx, STM32L063xx, STM32L061xx, STM32F030, STM32F031, STM32F051 и другие. После этого при компиляции stm32l0xx.h, будет автоматически подключен нужный файл с определением периферии контроллера stm32l0yyxx.h (stm32l051xx.h/stm32l052xx.h/stm32l053xx.h/stm32l061xx.h/stm32l062xx.h/stm32l063). Во-вторых, нужно выбрать соответствующий программатор в настройках свойств проекта. Во-третьих – изменить код функций из примеров, если они не отвечают требованиям пользовательского приложения.
Заключение
Наборы сниппетов и стандартные библиотеки периферии производства компании ST Microelectronics не являются взаимоисключающими. Они дополняют друг друга, добавляя гибкость при создании приложений.
Стандартная библиотека дает возможность быстрого создания ясного кода с высоким уровнем абстракции.
Сниппеты позволяют повысить эффективность кода – увеличить производительность и сократить объем занимаемой памяти FLASH и ОЗУ.
Литература
- Data brief. STM32SnippetsF0. STM32F0xx Snippets firmware package. Rev. 1. – ST Microelectronics, 2014.
- Data brief. STM32SnippetsL0. STM32F0xx Snippets firmware package. Rev. 1. – ST Microelectronics, 2014.
- MCD-ST Liberty SW License Agreement V2.pdfElectromechanical Relays. Technical Information. – ST Microelectronics, 2011.
- Data brief. 32L0538DISCOVERY Discovery kit for STM32L053 microcontrollers. Rev. 1. – ST Microelectronics, 2014.
- http://www.st.com/.