.png)
STMCU小助手
发布时间：2022-10-6 22:43
|
SYSTEM文件夹介绍 SYSTEM文件夹里面的代码由正点原子提供，是STM32H7xx系列的底层核心驱动函数，可以用在STM32H7xx系列的各个型号上面，方便大家快速构建自己的工程。 SYSTEM文件夹下包含了delay、sys、usart等三个文件夹。分别包含了delay.c、sys.c、usart.c及其头文件。通过这3个c文件，可以快速的给任何一款STM32H7构建最基本的框架，使用起来是很方便的。 本章，我们将向大家介绍这些代码，通过这章的学习，大家将了解到这些代码的由来，也希望大家可以灵活使用SYSTEM文件夹提供的函数，来快速构建工程，并实际应用到自己的项目中去。 12.1 deley文件夹代码介绍 delay文件夹内包含了delay.c和delay.h两个文件，这两个文件用来实现系统的延时功能，其中包含7个函数：
前面4个函数，仅在支持操作系统（OS）的时候，需要用到，而后面3个函数，则不论是否支持OS都需要用到。 在介绍这些函数之前，我们先了解一下编程思想：CM7内核和CM3/CM4内核一样，内部都包含了一个SysTick定时器，SysTick 是一个24 位的向下递减的计数定时器，当计数值减到0 时，将从RELOAD 寄存器中自动重装载定时初值。只要不把它在SysTick 控制及状态寄存器中的使能位清除，就永不停息。SysTick在《STM32H7xx参考手册_V7（英文版）.pdf》里面基本没有介绍，其详细介绍，请参阅《STM32H7编程手册.pdf》第212页，4.4节。我们就是利用STM32的内部SysTick来实现延时的，这样既不占用中断，也不占用系统定时器。 这里我们将介绍的是正点原子提供的最新版本的延时函数，该版本的延时函数支持在任意操作系统（OS）下面使用，它可以和操作系统共用SysTick定时器。 这里，我们以UCOSII为例，介绍如何实现操作系统和我们的delay函数共用SysTick定时器。首先，我们简单介绍下UCOSII的时钟：ucos运行需要一个系统时钟节拍（类似 “心跳”），而这个节拍是固定的（由OS_TICKS_PER_SEC宏定义设置），比如要求5ms一次（即可设置：OS_TICKS_PER_SEC=200），在STM32上面，一般是由SysTick来提供这个节拍，也就是SysTick要设置为5ms中断一次，为ucos提供时钟节拍，而且这个时钟一般是不能被打断的（否则就不准了）。 因为在ucos下systick不能再被随意更改，如果我们还想利用systick来做delay_us或者delay_ms的延时，就必须想点办法了，这里我们利用的是时钟摘取法。以delay_us为例，比如delay_us（50），在刚进入delay_us的时候先计算好这段延时需要等待的systick计数次数，这里为50480（假设系统时钟为480Mhz，因为systick的频率等于系统时钟频率，那么systick每增加1，就是1/480us），然后我们就一直统计systick的计数变化，直到这个值变化了50480，一旦检测到变化达到或者超过这个值，就说明延时50us时间到了。这样，我们只是抓取SysTick计数器的变化，并不需要修改SysTick的任何状态，完全不影响SysTick作为UCOS时钟节拍的功能，这就是实现delay和操作系统共用SysTick定时器的原理。 下面我们开始介绍这几个函数。 12.1.1 操作系统支持宏定义及相关函数 当需要delay_ms和delay_us支持操作系统（OS）的时候，我们需要用到3个宏定义和4个函数，宏定义及函数代码如下：
以上代码，仅支持UCOSII和UCOSIII，不过，对于其他OS的支持，也只需要对以上代码进行简单修改即可实现。 支持OS需要用到的三个宏定义（以UCOSII为例）即：
宏定义：delay_osrunning，用于标记OS是否正在运行，当OS已经开始运行时，该宏定义值为1，当OS还未运行时，该宏定义值为0。 宏定义：delay_ ostickspersec，用于表示OS的时钟节拍，即OS每秒钟任务调度次数。 宏定义：delay_ osintnesting，用于表示OS中断嵌套级别，即中断嵌套次数，每进入一个中断，该值加1，每退出一个中断，该值减1。 支持OS需要用到的4个函数，即： 函数：delay_osschedlock，用于delay_us延时，作用是禁止OS进行调度，以防打断us级延时，导致延时时间不准。 函数：delay_osschedunlock，同样用于delay_us延时，作用是在延时结束后恢复OS的调度，继续正常的OS任务调度。 函数：delay_ostimedly，则是调用OS自带的延时函数，实现延时。该函数的参数为时钟节拍数。 函数：SysTick_Handler，则是systick的中断服务函数，该函数为OS提供时钟节拍，同时可以引起任务调度。 以上就是delay_ms和delay_us支持操作系统时，需要实现的3个宏定义和4个函数。 12.1.2 delay_init函数 该函数用来初始化2个重要参数：fac_us以及fac_ms；同时把SysTick的时钟源选择为外部时钟，如果需要支持操作系统（OS），只需要在sys.h里面，设置SYS_SUPPORT_OS宏的值为1即可，然后，该函数会根据delay_ostickspersec宏的设置，来配置SysTick的中断时间，并开启SysTick中断。具体代码如下：
可以看到，delay_init函数使用了条件编译，来选择不同的初始化过程，如果不使用OS的时候，只是设置一下SysTick的时钟源以及确定fac_us值。而如果使用OS的时候，则会进行一些不同的配置，这里的条件编译是根据SYS_SUPPORT_OS这个宏来确定的，该宏在sys.h里面定义。 SysTick是MDK定义了的一个结构体（在core_m7.h里面），里面包含CTRL、LOAD、VAL、CALIB等4个寄存器。 SysTick->CTRL的各位定义如图12.1.2.1所示： 
图12.1.2.1 SysTick->CTRL寄存器各位定义 SysTick-> LOAD的定义如图12.1.2.2所示： 
图12.1.2.2 SysTick->LOAD寄存器各位定义 SysTick-> VAL的定义如图12.1.2.3所示： 
图12.1.2.3 SysTick->VAL寄存器各位定义 SysTick-> CALIB不常用，在这里我们也用不到，故不介绍了。 HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);这句代码把SysTick的时钟选择为内核时钟，这里需要注意的是：SysTick的时钟源自HCLK，假设我们外部晶振为8M，然后倍频到480MHZ，那么SysTick的时钟即为480Mhz，也就是SysTick的计数器VAL每减1，就代表时间过了1/480us。 在不使用OS的时候：fac_us，为us延时的基数，也就是延时1us，Systick定时器需要走过的时钟周期数。 当使用OS的时候，fac_us，还是us延时的基数，不过这个值不会被写到SysTick->LOAD寄存器来实现延时，而是通过时钟摘取的办法实现的（前面已经介绍了）。而fac_ms则代表ucos自带的延时函数所能实现的最小延时时间（如delay_ostickspersec=200，那么fac_ms就是5ms）。 12.1.3 delay_us函数 该函数用来延时指定的us，其参数nus为要延时的微秒数。该函数有使用OS和不使用OS两个版本，这里我们首先介绍不使用OS的时候，实现函数如下：
这里就是利用了我们前面提到的时钟摘取法，ticks是延时nus需要等待的SysTick计数次数（也就是延时时间），told用于记录最近一次的SysTick->VAL值，然后tnow则是当前的SysTick->VAL值，通过他们的对比累加，实现SysTick计数次数的统计，统计值存放在tcnt里面，然后通过对比tcnt和ticks，来判断延时是否到达，从而达到不修改SysTick实现nus的延时。对于使用OS的时候，delay_us的实现函数和不使用OS的时候方法类似，都是使用的时钟摘取法，只不过使用delay_osschedlock和delay_osschedunlock两个函数，用于调度上锁和解锁，这是为了防止OS在delay_us的时候打断延时，可能导致的延时不准，所以我们利用这两个函数来实现免打断，从而保证延时精度。 再来看看使用OS的时候，delay_us的实现函数如下：
这里就正是利用了我们前面提到的时钟摘取法，ticks是延时nus需要等待的SysTick计数次数（也就是延时时间），told用于记录最近一次的SysTick->VAL值，然后tnow则是当前的SysTick->VAL值，通过他们的对比累加，实现SysTick计数次数的统计，统计值存放在tcnt里面，然后通过对比tcnt和ticks，来判断延时是否到达，从而达到不修改SysTick实现nus的延时，从而可以和OS共用一个SysTick。 上面的delay_osschedlock和delay_osschedunlock是OS提供的两个函数，用于调度上锁和解锁，这里为了防止OS在delay_us的时候打断延时，可能导致的延时不准，所以我们利用这两个函数来实现免打断，从而保证延时精度！同时，此时的delay_us，，可以实现最长2^32/fac_us，在480M主频下，最大延时，大概是8.9秒。 12.1.4 delay_ms函数 该函数是用来延时指定的ms的，其参数nms为要延时的毫秒数。该函数有使用OS和不使用OS两个版本，这里我们分别介绍，首先是不使用OS的时候，实现函数如下：
该函数其实就是多次调用delay_us函数，来实现毫秒级延时的。我们做了一些处理，使得调用delay_us函数的次数减少，这样时间会更加精准。再来看看使用OS的时候，delay_ms的实现函数如下：
该函数中，delay_osrunning是OS正在运行的标志，delay_osintnesting则是OS中断嵌套次数，必须delay_osrunning为真，且delay_osintnesting为0的时候，才可以调用OS自带的延时函数进行延时（可以进行任务调度），delay_ostimedly函数就是利用OS自带的延时函数，实现任务级延时的，其参数代表延时的时钟节拍数（假设delay_ostickspersec=200，那么delay_ostimedly (1)，就代表延时5ms）。 当OS还未运行的时候，我们的delay_ms就是直接由delay_us实现的，OS下的delay_us可以实现很长的延时（达到204秒）而不溢出！，所以放心的使用delay_us来实现delay_ms，不过由于delay_us的时候，任务调度被上锁了，所以还是建议不要用delay_us来延时很长的时间，否则影响整个系统的性能。 当OS运行的时候，我们的delay_ms函数将先判断延时时长是否大于等于1个OS时钟节拍（fac_ms）,当大于这个值的时候，我们就通过调用OS的延时函数来实现（此时任务可以调度），不足1个时钟节拍的时候，直接调用delay_us函数实现（此时任务无法调度）。 12.1.5 HAL库延时函数HAL_Delay 前面我们在7.4.2章节介绍stm32h7xx_hal.c 文件时，已经讲解过Systick实现延时相关函数。实际上，HAL库提供的延时函数，只能实现简单的毫秒级别延时，没有实现us级别延时。我看看HAL库的HAL_Delay函数原定义：
HAL库实现延时功能非常简单，首先定义了一个32位全局变量uwTick，在Systick中断服务函数SysTick_Handler中通过调用HAL_IncTick实现uwTick值不断增加，也就是每隔1ms增加uwTickFreq，而uwTickFreq默认是1。而HAL_Delay函数在进入函数之后先记录当前uwTick的值，然后不断在循环中读取uwTick当前值，进行减运算，得出的就是延时的毫秒数，整个逻辑非常简单也非常清晰。 但是，HAL库的延时函数有一个局限性，在中断服务函数中使用HAL_Delay会引起混乱(虽然一般禁止在中断中使用延时函数)，因为它是通过中断方式实现，而Systick的中断优先级是最低的，所以在中断中运行HAL_Delay会导致延时出现严重误差。所以一般情况下，推荐大家使用ALIENTEK提供的延时函数库。 HAL库的ms级别的延时函数__weak void HAL_Delay(uint32_t Delay)；它是弱定义函数，所以用户可以自己重新定义该函数。例如：我们在deley.c文件可以这样重新定义该函数：
12.2 sys文件夹代码介绍 sys文件夹内包含了sys.c和sys.h两个文件，主要实现下面的几个函数，以及一些汇编函数。
配置章节内容。 接下来我们重点看一下sys_cache_enable函数和sys_qspi_enable_memmapmode函数。 12.2.1 Cache使能函数 STM32H7自带了指令Cache（I Cache）和数据Cache（D Cache），使用I/D Cache可以缓存指令/数据，提高CPU访问指令/数据的速度，从而大大提高MCU的性能。不过，MCU在复位后，I/D Cache默认都是关闭的，为了提高性能，我们需要开启I/D Cache，在sys.c里面，我们提供了如下函数：
该函数，通过调用SCB_EnableICache和SCB_EnableDCache这两个函数来使能I Cache和D Cache。不过，在使能D Cache之后，SRAM里面的数据有可能会被缓存在Cache里面，此时如果有DMA之类的外设访问这个SRAM里面的数据，就有可能和Cache里面数据不同步，导致数据出错，为了防止这种问题，保证数据的一致性，我们设置了D Cache的强制透写功能（Write Through），这样CPU每次操作Cache里面的数据，同时也会更新到SRAM里面，保证D Cache和SRAM里面数据一致。关于Cache的详细介绍，请参考《STM32F7 Cache Oveview》和《Level 1 cache on STM32F7 Series》（见光盘：8，STM32参考资料 文件夹）。注意：F7和H7这部分知识是通用的，所以参考F7的这两份文档即可，H7的这两个资料暂时没出来。 这里SCB_EnableICache和SCB_EnableDCache这两个函数，是在core_cm7.h里面定义的，我们直接调用即可，另外，core_cm7.h里面还提供了以下五个常用函数： 1，SCB_DisableICache函数，用于关闭I Cache。 2，SCB_DisableDCache函数，用于关闭D Cache。 3，SCB_InvalidateDCache函数，用于丢弃D Cache当前数据，重新从SRAM获取数据。 4，SCB_CleanDCache函数，用于将D Cache数据回写到SRAM里面，同步数据。 5，SCB_CleanInvalidateDCache函数，用于回写数据到SRAM，并重新获取D Cache数据。 在Cache_Enable函数里面，我们直接开启了D Cache的透写模式，这样带来的好处就是可以保证D Cache和SRAM里面数据的一致性，坏处就是会损失一定的性能（每次都要回写数据），如果大家想自己控制D Cache数据的回写，以获得最佳性能，则可以关闭D Cache透写模式，并在适当的时候，调用SCB_CleanDCache、SCB_InvalidateDCache和SCB_CleanInvalidate DCache等函数，这对程序员的要求非常高，程序员必须清楚什么时候该回写，什么时候该更新D Cache！如果能力不够，还是建议开启D Cache的透写，以免引起各种莫名其妙的问题。 12.2.2 QSPI_Enable_Memmapmode函数 该函数有三个作用： 1，初始化QSPI接口，并使能内存映射模式； 2，初始化外部SPI FLASH，使能QPI（QSPI）模式。 3，设置QSPI FLASH空间的MPU保护。 其代码如下：
以上代码，可以分为4个部分解读： 第一部分，初始化QSPI相关GPIO及QSPI接口。 第二部分，设置QSPI FLASH进入QSPI模式，并设置相关参数，这里使用的是直接操作寄存器的方式，并没有的调用任何函数，目的就是简化代码。这部分代码的详细理解，读者可以参考我们后续的QSPI实验（实验24 QSPI实验）的相关介绍。这里只需要直接调用就好。 第三部分，设置STM32H750的QSPI的内存映射模式，从而可以执行外部SPI FLASH的代码。 第四部分，设置QSPI FLASH空间的内存保护。 为了简化sys_qspi_enable_memmapmode函数，我们很多操作都做了精简处理，所以理解起来会有一定困难，如果实在看不懂，可以绕过这个，先学习后面的知识点，回头再来学习该函数的具体实现。 需要注意的是：在sys_qspi_enable_memmapmode函数之前的所有代码，必须不能放到外部QSPI FLASH，因为在该函数之前，STM32H750都是无法访问外部QSPI FLASH的，所以如果遇到一些代码启动不了的情况，请重点怀疑是不是在该函数之前，就调用了QSPI FLASH的程序？如果有，需要将这部分代码放到该函数之后才行！或者将这部分代码放内部FLASH运行（方法见3.2.8节）。 函数/指令地址，我们可以通过仿真，看反汇编窗口（Disassembly），会有地址显示，从而快速找到问题。 12.3 usart文件夹代码介绍 该文件夹下面有usart.c和usarts.h两个文件。在我们的工程使用串口1和串口调试助手来实现调试功能，可以把单片机的信息通过串口助手显示到电脑屏幕。串口相关知识，我们将在第十七章讲解串口实验的时候给大家详细讲解。本节我们只给大家讲解比较独立的printf函数支持相关的知识。 12.3.1 printf函数支持 在我们学习C语言时，可以通过printf函数把需要的参数显示到屏幕上，可以做一些简单的调试信息，但对于单片机来说，如果想实现类似的功能来用printf辅助调试的话，是否有办法呢？有，这就是这一节要讲的内容。 标准库下的printf为调试属性的函数，如果直接使用，会使单片机进入半主机模式（semihosting），这是一种调试模式，直接下载代码后出现程序无法运行，但是在Debug模式下程序可能正常工作的情况。半主机是ARM目标的一种机制，用于将输入/输出请求从应用程序代码通信到运行调试器的主机。例如，此机制可用于允许C库中的函数（如printf()和scanf()）使用主机的屏幕和键盘，而不是在目标系统上设置屏幕和键盘。这很有用，因为开发硬件通常不具有最终系统的所有输入和输出设备，如屏幕、键盘等。半主机是通过一组定义好的软件指令（如SVC）SVC指令（以前称为SWI指令）来实现的，这些指令通过程序控制生成异常。应用程序调用相应的半主机调用，然后调试代理处理该异常。调试代理（这里的调试代理是仿真器）提供与主机之间的必需通信。也就是说使用半主机模式必须使用仿真器调试。 如果想在独立环境下运行调试功能的函数，我们这里是printf ，printf对字符ch处理后写入文件f，最后使用fputc将文件f输出到显示设备。对于PC端的设备，fputc通过复杂的源码，最终把字符显示到屏幕上。那我们需要做的，就是把printf调用的fputc函数重新实现，重定向fputc的输出，同时避免进入半主模式。 要避免半主机模式，现在主要有两种方式：一是使用MicroLib，即微库；另一种方法是确保ARM应用程序中没有链接MicroLib的半主机相关函数，我们要取消ARM的半主机工作模式，这可以通过代码实现。 先说微库，ARM的C微库MicroLib是为嵌入式设备开发的一套类似于标准C接口函数的精简代码库，用于替代默认C库，是专门针对专业嵌入式应用开发而设计的，特别适合那些对存储空间有特别要求的嵌入式应用程序，这些程序一般不在操作系统下运行。使用微库编写程序要注意其与默认C库之间存在的一些差异，如main()函数不能声明带参数，也无须返回；不支持stdio，除了无缓冲的stdin、stdout和syderr; 微库不支持操作系统函数；微库不支持可选的单或两区存储模式；微库只提供分离的堆和栈两区存储模式等等，它裁减了很多函数，而且还有很多东西不支持。如果原来用标准库可以跑，选择MicroLib后却突然不行了，是很常见的。与标准的C库不一样，微库重新实现了printf，使用微库的情况下就不会进入半主机模式了。Keil下使用微库的方法很简单，在“Target”下勾选“Use MicroLib”即可。 
图12.3.1.1 MDK工程下使用微库的方法 在keil5中，不管是否使用半主机模式，使用printf,scanf,fopen,fread等都需要自己填充底层函数，以printf为例，需要补充定义fputc，启用微库后，在我们初始化和使能串口1之后，我们只需要重新实现fputc的功能即可将每个传给fputc函数的字符ch重定向到串口1，如果这时接上串口调试助手的话，可以看到串口的数据。实现的代码如下： /* 重定义fputc函数, printf函数最终会通过调用fputc输出字符串到串口
上面说到了微库的一些限制，使用时注意某些函数与标准库的区别就不会影响到我们代码的正常功能。如果不想使用微库，那就要用到我们提到的第二种方法：取消ARM的半主机工作模式；只需在代码中添加不使用半主机的声明即可，对于AC5和AC6编译器版本，声明半主机的语法不同，为了同时兼容这两种语法，我们在利用编译器自带的宏__ARMCC_VERSION判定编译器版本，并根据版本不同选择不同的语法声明不使用半主机模式，具体代码如下：
使用的上面的代码，Keil的编译器就不会把标准库的这部分函数链接到我们的代码里。如果用到原来半主机模式下的调试函数，需要重新实现它的一些依赖函数接口，对于printf函数需要实现的接口，我们的代码中将它们实现如下： /* 不使用半主机模式，至少需要重定义
———————————————— 版权声明：正点原子 |
经验分享 | STM32H723 SPI 通讯异常排查：实时观察窗口的 “隐形干扰” 解决方案
经验分享 | STM32H7 SPI NSS 脉冲模式灵活应用：解决外置 ADC 通信干扰问题
经验分享 | STM32H7 双核调试配置：STM32CubeIDE 下 M7+M4 协同调试实操
经验分享 | STM32H7 TouchGFX 花屏速解：更换 HyperRAM 后 latency 值适配实操
经验分享 | STM32H743 BDMA+LPTIM+LPUART应用演示
经验分享 | STM32H7Sx MCE 加密解密：外部存储安全防护全解析
如何在STM32和Arduino上实现卷积神经网络
详解STM32单片机的堆栈
STM32 开发者指南：ST.com 全新 MCU 产品阵容视觉布局深度解析
STM32和Arduino对比，谁更耐打？
微信公众号
手机版
