flash_acr_latency

关于flash_acr_latency的理解

这个问题网上查了很多资料，但是我感觉都写的不是很清楚。下面我就结合我个人搜集到的资料，再结合个人的理解来认识一下这个参数，但是可能我所的完全是错的，如果说有更多的看法，欢迎指出，我的目的就是为了引出最正确的理解，对这个参数。

首先来看看关于内部flash所涉及的时钟树部分：

在官方手册中有关latency的理解如下：

在配置系统时钟之前，通常需要先调整latency,然后再改变系统时钟，不然可能会出现flash读写问题。

个人想到一个问题是：

如果在改变系统时钟之前，调整了这个latency,那么出现的问题是什么呢？

这个调整了的latency与原先的系统时钟不匹配了，难道不会出现flash读写问题吗？

后面还要执行设置系统时钟的语句，肯定要访问flash，这不就矛盾了吗？

所以说到底怎么回事：

官方文件的意思是为了维持读flash的控制信号，所以需要设置。

控制信号无非就是高低电平，由若干个时钟周期组成，当你系统的时钟改变了。比如频率变高，控制信号按照我的理解应该是 维持一定的电平长度，那么需要的时钟周期数变多。

所以产生控制信号读flash的中，有一个等待完成的电平，也是由若干个时钟周期组成。

那么当频率变高时，就需要增加等待的状态，来维持那个电平信号。

按照这个思路推测，等待时间长一点是没关系的。等待时间短就可能时序产生错误，等待时间长一点，无非就浪费一点时间。

还是能保证时序的正确。

如果以上推测成立，那么得出的结论如下：

1）0<时钟频率=<24M HZ 时，三个等待状态都可以选择。

2）24<时钟频率=<48HZ时，二个状态可以选择，即one wait state或者two wait state

3） 48<时钟频率=<72HZ时，只能是two wait state

4） 如果时钟频率是从大往小了 调，那么就是必须先调整时钟频率，然后再调latency。

一句话总结就是，如果时钟频率较低，可以容忍较大latency,如果时钟频率较高，绝不能容忍较低是latency。

以上就是个人的猜测，可能就是完全是胡说八道，如果知道更好的理解的，十分欢迎指出来。

如何证明这个结论呢？

1)做实验，我暂时没去做，实验的过程想大致就是，配置一个系统时钟，然后设置不同的latency，然后看程序是否能正常运行。

如果能正常运行，那么读flash是没问题的。

2）第二个就是官方的HAL库的配置例程，他的代码时如何写的呢？这也是我想法的来源，当时看这个代码时就思考为什么其这么写。

没有比ST官方自己更了解自己芯片的了。

我们来看一下其代码：（直接跳到最后面看）

HAL_StatusTypeDef HAL_RCC_ClockConfig(RCC_ClkInitTypeDef  *RCC_ClkInitStruct, uint32_t FLatency)
{
   
  uint32_t tickstart;

  /* Check Null pointer */
  if (RCC_ClkInitStruct == NULL)
  {
   
    return HAL_ERROR;
  }

  /* To correctly read data from FLASH memory, the number of wait states (LATENCY)
  must be correctly programmed according to the frequency of the CPU clock
    (HCLK) of the device.
    为了能正确的阅读数据从FLASH内存，等待状态的数量（延迟）必须被正确编程，根据设备的CPU时钟频率（HCLK）
    */
//如果在工具链中定义了该宏
#if defined(FLASH_ACR_LATENCY)
  /* Increasing the number of wait states because of higher CPU frequency
  如果延迟大于当前寄存器的延迟
  */
  if (FLatency > __HAL_FLASH_GET_LATENCY())
  {
   
    /* Program the new number of wait states to the LATENCY bits in the FLASH_ACR reg