Библиотеки cmsis для stm32 ver. 3.1.0

NEONを使用する場合

「32ビットSIMD命令を使う場合」に加え、下記の変更を行う。IARだとビルドエラーになる。

1. FPUのオプションの変更
   コンパイラのFPUのオプションを»-mfpu=neon»に設定する。
2. コンパイラオプションの追加
   コンパイラのオプションに以下を追加する。
   «-DARM_MATH_NEON»
3. エラーファイルの修正 (GCCの場合)
   下記ファイルが型に関するエラーが発生するので修正する。
   — Source/DistanceFunctions/arm_canberra_distance_f32.c
   コード修正箇所 arm_canberra_distance_f32.c の「#if(1) neon test」を参照。
4. エラーファイルの修正 (Arm Compiler 6の場合)
   下記ファイルがエラーとなるので修正する。
   — Source/TransformFunctions/arm_bitreversal2.S
   コード修正箇所 «arm_bitreversal2.S» の「/* Arm Compiler 6 */」を参照。

arm_canberra_distance_f32.c

float32_t arm_canberra_distance_f32(const float32_t *pA,const float32_t *pB, uint32_t blockSize)
{
   float32_t accum=0.0, tmpA, tmpB,diff,sum;
   uint32_t i,blkCnt;
   float32x4_t a,b,c,d,accumV;
   float32x2_t accumV2;
   int32x4_t   isZeroV;
   float32x4_t zeroV = vdupq_n_f32(0.0);

   accumV = vdupq_n_f32(0.0);

   blkCnt = blockSize >> 2;
   while(blkCnt > 0)
   {
        a = vld1q_f32(pA);
        b = vld1q_f32(pB);

        c = vabdq_f32(a,b);

        a = vabsq_f32(a);
        b = vabsq_f32(b);
        a = vaddq_f32(a,b);
#if(1) // neon test
        isZeroV = (int32x4_t)vceqq_f32(a,zeroV);
#else
        isZeroV = vceqq_f32(a,zeroV);
#endif

        /* 
         * May divide by zero when a and b have both the same lane at zero.
         */
        a = vinvq_f32(a);
        
        /*
         * Force result of a division by 0 to 0. It the behavior of the
         * sklearn canberra function.
         */
#if(1) // neon test
        a = (float32x4_t)vbicq_s32((int32x4_t)a,isZeroV);
#else
        a = vbicq_s32(a,isZeroV);
#endif
        c = vmulq_f32(c,a);
        accumV = vaddq_f32(accumV,c);

        pA += 4;
        pB += 4;
        blkCnt --;
   }
==  omit ==
}

Универсальный код HelloWorld

RTOS2

Рассмотрим процесс запуска RTOS2. После конфигурации структуры входных параметров для будущего потока в функции main() необходимо произвести инициализацию RTOS и создать поток, который описывается, как обычная функция в Си. После же запустить планировщик ядра ОСРВ функцией osKernelStart (), который и начнёт запускать созданный поток.

При вызове  функции osDelay() поток, вызывающий функцию, переводится в режим ожидания Wait на указанное время, и запускается поток ожидания osRtxIdleThread, в составе которого находится бесконечный цикл. При желании в него можно прописать свою функцию. Приоритет у этого потока наименьший — osPriorityIdle, поэтому после его запуска при следующем тике таймера системы (его частота по умолчанию 1000 Гц) запускается поток с наибольшим приоритетом, находящийся в состоянии готовности «Ready». Это очень удобно, так как пока запустивший функцию задержки поток находится в режиме ожидания, будут выполняться другие потоки

При этом важно понимать, что задержки, которые формируются функцией osDelay(), а также другие времена для отсчётов в ОСРВ, высчитываются на основе тиков системного таймера SysTick

В текущем универсальном примере вывод микроконтроллера будет переключать своё состояние каждые 500 тиков таймера операционной системы (один тик связан с параметром «Kernel Tick Frequency « (freq) при конфигурировании файла RTX_Config.h — см. рисунок 2). На основе этих данных можно очень точно разграничивать время выполнения каждого потока, если, например, их используется много. Умение системы разделять процессорное время и является преимуществом использования ОСРВ на практике. В свою очередь, можно регулировать время выполнения каждого потока. Для этого в файле «RTX_Config.h» необходимо задать параметр «Round-Robin Thread switching», который также измеряется в тиках таймера системы. По умолчанию, если опция включена, выставляется 5 тиков таймера системы на выполнение каждого потока, но это значение можно и увеличивать, тем самым, задавая верхнюю границу выполнения каждой структурной части программного обеспечения

GPIO.CPP

В конструкторе класса сохраняется ссылка на порт и тактируется выбранный порт.

В методе конфигурации сохраняем заданный режим в переменную pin_m. Это нужно для того, чтобы при использовании методов setPin()/resetPin() и заданном режиме альтернативной функции эти методы не управляли выводом, так как в данном случае управление должно осуществляться из модуля альтернативной функции.

Далее проверяем задан ли режим входа с подтяжкой. Если задан то меняем переменную pin_mode так как для обоих режимов входа с подтяжкой биты пина конфигурируются одинаково, а выбор подтяжки к питанию или земле осуществляется записью в регистр ODR 1 или 0.

В условии if ( pin_nomber < 8 ) и аналогичном if ( pin_nomber > 7 ) рассчитываем смещение относительно начала регистра CRL или CRH соответственно, учитывая, что на вывод отводится 4 бита, и кладем в переменную offset. Затем сначала затираем биты конфигурации маской GPIO BIT MASK, а затем записываем новые биты конфигурации вывода.

if ( pin_mode == INPUT_PULL_UP ) — проверяем, если задан режим подтяжки к питанию, то выставляем в регистре ODR единицу. Аналогично проверяем режим подтяжки к земле и скидываем бит, если условие верно.

В методе setPin() сначала проверяем не задана ли альтернативная функция. Если да, то выходим ничего не делая. Далее в регистре BSSR устанавливаем 1 на соответствующий вывод.

В методе resetPin() все аналогично предыдущему, за исключением того, что пишем в регистр BRR тем самым скидывая вывод.

В методе getPin() создаем маску для сравнения, сравниваем регистр IDR с маской. Если тру — возвращаем 1, иначе 0.

Применяется все это дело так :

Semaphore¶

The Semaphore Management function group is used to manage and protect access to shared resources. For example, with a Semaphore the access to a group of identical peripherals can be managed. The number of available resources is specified as parameter of the osSemaphoreCreate function.

Import programcmsis_rtos_semaphore — main.cpp

00001 #include "mbed.h"
00002 #include "cmsis_os.h"
00003 
00004 osSemaphoreId two_slots;
00005 osSemaphoreDef(two_slots);
00006 
00007 void test_thread(void const *name) {
00008     while (true) {
00009         osSemaphoreWait(two_slots, osWaitForever);
00010         printf("%s\n\r", (const char*)name);
00011         osDelay(1000);
00012         osSemaphoreRelease(two_slots);
00013     }
00014 }
00015 
00016 void t2(void const *argument) {test_thread("Th 2");}
00017 osThreadDef(t2, osPriorityNormal, DEFAULT_STACK_SIZE);
00018 
00019 void t3(void const *argument) {test_thread("Th 3");}
00020 osThreadDef(t3, osPriorityNormal, DEFAULT_STACK_SIZE);
00021 
00022 int main (void) {
00023     two_slots = osSemaphoreCreate(osSemaphore(two_slots), 2);
00024     
00025     osThreadCreate(osThread(t2), NULL);
00026     osThreadCreate(osThread(t3), NULL);
00027     
00028     test_thread((void *)"Th 1");
00029 }

Contributions and Pull Requests

Contributions are accepted under Apache 2.0. Only submit contributions where you have authored all of the code.

Issues and Labels

Please feel free to raise an issue on GitHub
to report misbehavior (i.e. bugs) or start discussions about enhancements. This
is your best way to interact directly with the maintenance team and the community.
We encourage you to append implementation suggestions as this helps to decrease the
workload of the very limited maintenance team.

We will be monitoring and responding to issues as best we can.
Please attempt to avoid filing duplicates of open or closed items when possible.
In the spirit of openness we will be tagging issues with the following:

• bug – We consider this issue to be a bug that will be investigated.

• wontfix — We appreciate this issue but decided not to change the current behavior.

• enhancement – Denotes something that will be implemented soon.

• future — Denotes something not yet schedule for implementation.

• out-of-scope — We consider this issue loosely related to CMSIS. It might by implemented outside of CMSIS. Let us know about your work.

• question – We have further questions to this issue. Please review and provide feedback.

• documentation — This issue is a documentation flaw that will be improved in future.

• review — This issue is under review. Please be patient.

• DONE — We consider this issue as resolved — please review and close it. In case of no further activity this issues will be closed after a week.

• duplicate — This issue is already addressed elsewhere, see comment with provided references.

• Important Information — We provide essential informations regarding planned or resolved major enhancements.

HAL_SPI модуль

Для программирования SPI HAL определяет С структуру SPI_HandleTypeDef:

Давайте проанализируем наиболее важные поля данной структуры.

• Instance: указатель на дескриптор SPI, который мы будем использовать. Например, SPI1 — это дескриптор первого SPI интерфейса.
• Init: объект C структуры SPI_InitTypeDef, которая используется для настройки интерфейса, далее мы рассмотрим ее более подробно.
• ptxBuffPtr, pRxBuffPtr: указатели на временные буферы для принимаемых и отправляемых данных SPI. Они используются, когда SPI работает в режиме прерывания и не могут быть изменены из программы пользователя.
• hdmatx, hdmarx: указатели на объекты DMA_HandleTypeDef структуры, используемой, когда SPI работает в режиме с DMA.

Настройка SPI производится с использованием объекта структуры SPI_InitTypeDef:

• Mode: параметр, определяющий в каком режиме, master или slave работает SPI интерфейс. Может принимать два значения SPI_MODE_MASTER и SPI_MODE_SLAVE.
• Direction: параметр, задающий работу SPI интерфейса либо в 4-проводном режиме (2 отдельные линии для входных и выходных данных соответсвенно), либо в 3-проводном режиме (одна I/O линия). Может принимать следующие значения: SPI_DIRECTION_2LINES или полнодуплексный 4-проводной режим; SPI_DIRECTION_2LINES_RXONLY или полудуплексный 4-проводной режим; SPI_DIRECTION_1LINE или полудуплексный 3-проводной режим.
• DataSize: параметр, задающий размер данных, передаваемых по шине SPI. Может принимать два следующих значения: SPI_DATASIZE_8BIT и SPI_DATASIZE_16BIT.
• CLKPolarity: настройка SCK CPOL, принимает значения SPI_POLARITY_LOW (CPOL=0) и SPI_POLARITY_HIGH (CPOL=1).
• CLKPhase: настройка фазы тактового сигнала SCK, принимает также два значения SPI_PHASE_1EDGE (CPHA=0) и SPI_PHASE_2EDGE (CPHA=1).
• NSS: параметр, задающий поведение линии NSS. Принимает значения SPI_NSS_SOFT для программного управления NSS, SPI_NSS_HARD_INPUT и SPI_NSS_HARD_OUTPUT для настройки NSS сигнала в аппаратном режиме.
• BaudRatePrescaler: делитель частоты шины APB, определяет максимальную тактовую частоту линии SCK. Может принимать значения SPI_BAUDRATEPRESCALER_2, SPI_BAUDRATEPRESCALER_4,…,SPI_BAUDRATEPRESCALER_256.
• FirstBit: параметр, определяющий порядок передачи данных по шине SPI: SPI_FIRSTBIT_MSB или SPI_FIRSTBIT_LSB.
• TIMode: включение/выключение режима поддержки протокола TI. Значения: SPI_TIMODE_DISABLE или SPI_TIMODE_ENABLE.
• CRCCalculation и CRCPolynomial: во всех микроконтроллерах STM32 SPI периферия может аппаратно генерировать CRC контрольную сумму. Значение CRC может передаваться последним байтом в режиме передачи или автоматическая проверка на ошибку CRC может быть произведена с последним принятым байтом данных. Значение CRC вычисляется с использованием нечетного программируемого многочлена на каждом бите. Вычисление происходит на определяемом параметрами CPHA и CPOL фронте тактовой частоты каждой выборки. Вычисленное CRC проверяется автоматически в конце блока данных. Когда появляется ошибка между вычисленным значением CRC от принятых данных и CRC, переданной от передающего устройства, устанавливается состояние ошибки. CRC не доступно в режиме работы SPI с DMA в циклическом режиме. Для более подробной информации рекомендуется ознакомиться с референс мануалом на конкретный микроконтроллер.

Как обычно, для конфигурации SPI мы используем функцию:

HAL_StatusTypeDef HAL_SPI_Init (SPI_HandleTypeDef * hspi);

которая принимает в качестве входного параметра указатель на объект структуры SPI_HandleTypeDef, рассмотренной выше.

GPIO.H

У выводов контроллера есть несколько режимов работы. Они задаются в регистрах GPIOx_CRL ( для выводов от 0 до 7 ) и GPIOx_CRH ( для выводов от 8 до 15 ). На каждый вывод в этих регистрах отводится по 4 бита, которые и задают режим работы. Чтобы не вспоминать каждый раз какие биты нужно прописать на каком месте для определенного режима, удобно переписать все возможные комбинации в макроопределения, что я и сделал. В последствии эти константы будут передаваться в методы для задания режима.

Далее по коду объявляем класс GPIO. Конструктор класса принимает ссылку на порт (GPIOA, GPIOB и т.д.) и сохраняет ее в приватной переменной GPIOx. Это нужно для того, чтобы при создании объекта и вызове его методов, методы знали с каким портом работать.

После конструктора следуют публичные методы класса, образующие интерфейс.

• pinConf ( uint8_t pin_nomber, uint8_t pin_mode ) принимает номер вывода порта и режим работы, который задается макроопределениями в начале файла.

• setPin( uint8_t pin_nomber ) устанавливает вывод в 1. Принимает номер пина порта.

• resetPin( uint8_t pin_nomber ) сбрасывает вывод. Принимает номер вывода.

• getPin ( uint8_t pin_nomber ) возвращает состояние вывода порта (читает регистр IDR)

CPUのみを使う場合

1. 不要ファイルの除外
   下記ファイルをコンパイル対象から除外する。
   (他の.cファイルをインクルードするだけのファイル。コンパイル対象とすると2重定義でエラーになる。)
   — Source/BasicMathFunctions/BasicMathFunctions.c
   — Source/CommonTables/CommonTables.c
   — Source/ComplexMathFunctions/ComplexMathFunctions.c
   — Source/ControllerFunctions/ControllerFunctions.c
   — Source/FastMathFunctions/FastMathFunctions.c
   — Source/FilteringFunctions/FilteringFunctions.c
   — Source/MatrixFunctions/MatrixFunctions.c
   — Source/StatisticsFunctions/StatisticsFunctions.c
   — Source/SupportFunctions/SupportFunctions.c
   — Source/TransformFunctions/TransformFunctions.c

When using only CPU

1. Exclude unnecessary files
   Exclude the following files from compilation.
   (Just include other .c files. Duplicate definitions result in an error at compile.)
   — Source/BasicMathFunctions/BasicMathFunctions.c
   — Source/CommonTables/CommonTables.c
   — Source/ComplexMathFunctions/ComplexMathFunctions.c
   — Source/ControllerFunctions/ControllerFunctions.c
   — Source/FastMathFunctions/FastMathFunctions.c
   — Source/FilteringFunctions/FilteringFunctions.c
   — Source/MatrixFunctions/MatrixFunctions.c
   — Source/StatisticsFunctions/StatisticsFunctions.c
   — Source/SupportFunctions/SupportFunctions.c
   — Source/TransformFunctions/TransformFunctions.c

Mail Queue¶

Import programcmsis_rtos_mail — main.cpp

00001 #include "mbed.h"
00002 #include "cmsis_os.h"
00003 
00004 typedef struct {
00005   float    voltage; 
00006   float    current; 
00007   uint32_t counter; 
00008 } mail_t;
00009 
00010 osMailQDef(mail_box, 16, mail_t);
00011 osMailQId  mail_box;
00012 
00013 void send_thread (void const *args) {
00014     uint32_t i = 0;
00015     while (true) {
00016         i++; 
00017         mail_t *mail = (mail_t*)osMailAlloc(mail_box, osWaitForever);
00018         mail->voltage = (i * 0.1) * 33; 
00019         mail->current = (i * 0.1) * 11;
00020         mail->counter = i;
00021         osMailPut(mail_box, mail);
00022         osDelay(1000);
00023     }
00024 }
00025 
00026 osThreadDef(send_thread, osPriorityNormal, DEFAULT_STACK_SIZE);
00027 
00028 int main (void) {
00029     mail_box = osMailCreate(osMailQ(mail_box), NULL);
00030     osThreadCreate(osThread(send_thread), NULL);
00031     
00032     while (true) {
00033         osEvent evt = osMailGet(mail_box, osWaitForever);
00034         if (evt.status == osEventMail) {
00035             mail_t *mail = (mail_t*)evt.value.p;
00036             printf("\nVoltage: %.2f V\n\r"   , mail->voltage);
00037             printf("Current: %.2f A\n\r"     , mail->current);
00038             printf("Number of cycles: %u\n\r", mail->counter);
00039             
00040             osMailFree(mail_box, mail);
00041         }
00042     }
00043 }

[Repository ‘/users/mbed_official/code/rtx/docs/tip/structos__mailQ__def.html’ not found]

Задний план

Ранее у меня были CMSIS и CMSIS-DSP, работающие в Keil uVision, но учитывая ограничение кода в 32k, которое довольно быстро выводит меня за предел оценки. В связи с этим я пытался включить CMSIS-DSP в Atollic TrueStudio, но это, казалось бы, сложно выполнить: для начала имеется ограниченная документация, доступная по CMSIS-DSP, и тем более для реализации в Atollic TrueStudio.

Некоторые родственные ресурсы могут быть найдены в Atollic TrueSTUDIO руководстве пользователя , а также StackOverflow тема # 1 и StackOverflow тему # 2 . Большинство других связанных тем, которые я смог найти, просто относятся к использованию Keil uVision или Руководству пользователя без дополнительной помощи.

Atollic TrueStudio включает встроенный диспетчер пакетов, в котором базовая CMSIS доступна для загрузки, но не предоставляет эту возможность для пакета CMSIS-DSP.

Попытка решения

Я попытался вручную загрузить соответствующий пакет CMSIS (STM32Cube_FW_F4_V1.24.0) и поместить соответствующий пакет DSP в файловую структуру проекта. Затем это позволяет использовать функции DSP, такие как или, которые также могут быть вызваны с использованием функции автозаполнения и, таким образом, распознаются IDE.

Однако этот процесс также вызывает множество ошибок, поскольку включенные функции не могут распознать свои зависимости заголовков (например, ). Меня сбивает с толку то, что main.c может распознать команду, но включенные функции — нет, но я, тем не менее, пытаюсь исправить это, добавив CMSIS DSP во включенные каталоги (можно найти в ‘Свойства сборки -> C / C ++ Сборка -> Настройки -> Настройки инструмента -> Компилятор C -> Каталоги`). Однако это также не решает проблему.

Interrupt Service Routines¶

The same CMSIS-RTOS can be used in ISR. The only two warnings are:

• Mutexes can not be used.
• Wait in ISR is not allowed: all the timeouts in method parameters have to be set to 0 (no wait).

Import programcmsis_rtos_isr — main.cpp

00001 #include "mbed.h"
00002 #include "cmsis_os.h"
00003 
00004 osMessageQDef(queue, 5, message_t);
00005 osMessageQId  queue;
00006 
00007 DigitalOut myled(LED1);
00008 
00009 void queue_isr() {
00010     osMessagePut(queue, (uint32_t)2, 0);
00011     
00012     myled = !myled;
00013 }
00014 
00015 void queue_thread(void const *args) {
00016     while (true) {
00017        osMessagePut(queue, 1, 0);
00018        osDelay(1000);
00019     }
00020 }
00021 
00022 osThreadDef(queue_thread, osPriorityNormal, DEFAULT_STACK_SIZE);
00023 
00024 int main (void) {
00025      queue = osMessageCreate(osMessageQ(queue), NULL);
00026     
00027     osThreadCreate(osThread(queue_thread), NULL);
00028     
00029     Ticker ticker;
00030     ticker.attach(queue_isr, 1.0);
00031     
00032     while (true) {
00033         osEvent evt = osMessageGet(queue, osWaitForever);
00034         if (evt.status != osEventMessage) {
00035             printf("queue->get() returned %02x status\n\r", evt.status);
00036         } else {
00037             printf("queue->get() returned %d\n\r", evt.value.v);
00038         }
00039     }
00040 }

No wait in ISR

When calling an rtos object method in an ISR all the timeout parameters have to be set to 0 (no wait): waiting in ISR is not allowed.

Generate CMSIS Pack for Release

This GitHub development repository contains already pre-built libraries (stored in Git-LFS) of various software components (DSP, RTOS, RTOS2).
These libraries are validated for release. Git-LFS needs to be installed to retrieve the actual binary files, please see https://git-lfs.github.com/.

To build a complete CMSIS pack for installation the following additional tools are required:

• doxygen.exe Version: 1.8.6 (Documentation Generator)
• mscgen.exe Version: 0.20 (Message Sequence Chart Converter)
• 7z.exe (7-Zip) Version: 16.02 (File Archiver)

Using these tools, you can generate on a Windows PC:

• CMSIS Documentation using the batch file gen_doc.sh (located in ./CMSIS/Doxygen).
• CMSIS Software Pack using the batch file gen_pack.sh (located in ./CMSIS/Utilities).
  The bash script does not generate the documentation. The pre-built libraries for RTX4 and RTX5
  are not included within this repository.

The file ./CMSIS/DoxyGen/How2Doc.txt describes the rules for creating API documentation.

Packages¶

Обзор продуктовых линеек

STM32L

Семейство STM32 имеет широкий ассортимент изделий, различающихся по объему памяти, производительности, потреблению энергии и другим характеристикам.

Серии STM32F-1, STM32F-2 и STM32L полностью совместимы. Каждая из серий имеет десятки микросхем, которые можно без труда поменять на другие изделия. STM32F-1 была первой линейкой, ее производительность была ограничена. Из-за этого по характеристикам контроллеры быстро догнали изделия семейства Stellaris и LPC17. Позднее была выпущена STM32F-2 с улучшенными характеристиками – тактовая частота достигала 120 МГц. Отличается высокой процессорной мощностью, которая достигнута благодаря новой технологии производства 90 нм. Линейка STM32L представлена моделями, которые изготовлены по специальному технологическому процессу. Утечки транзисторов минимальны, благодаря чему приборы показывают лучшие значения.

Важно отметить, что контроллеры линейки STM32W не имеют pin-to-pin совместимости с STM32F-1, STM32F-2 и STM32L. Причина заключается в том, что линейку разрабатывала компания, которая предоставила радиочастотную часть

Это наложило ограничения на разработку для компании ST.

STM32F100R4

Микросхема STM32F100R4 имеет минимальный набор функций. Объем флэш памяти составляет 16 Кбайт, ОЗУ – 4 Кбайт, тактовая частота составляет 12 МГц. Если требуется более быстрое устройство с увеличенным объемом флэш-памяти до 128 Кбайт, подойдет STM32F101RB. USB интерфейс имеется у изделия STM32F103RE. Существует аналогичное устройство, но с более низким потреблением – это STM32L151RB.

Похожие записи:

Как выставить зажигание с помощью стробоскопа? Сигнализация действия защиты и автоматики Подключение потолочного светильника со светодиодами Книги по ардуино Правильная пайка проводов паяльником Птф солярис