SDRAM有一个用for循环进行的延时特别慢有谁遇到过这个问题吗

/* Insert 100 ms delay */
把这个 for 循环换成 rt_hw_us_delay，延时 100 ms。
这个for 延时跟主频有很大关系。主频高了速度快，主频低了速度就慢。。。

这不是我写的代码，这个代码是 RTT 官方提供的。

    /* Configure a clock configuration enable command */
    Command->CommandMode           = FMC_SDRAM_CMD_CLK_ENABLE;
    Command->CommandTarget         = target_bank;
    Command->AutoRefreshNumber     = 1;
    Command->ModeRegisterDefinition = 0;
    /* Send the command */
    HAL_SDRAM_SendCommand(hsdram, Command, 0x1000);
    /* Insert 100 ms delay */
    /* interrupt is not enable, just to delay some time. */
    for (tmpmrd = 0; tmpmrd < 0xffffff; tmpmrd ++)
        ;
    /* Configure a PALL (precharge all) command */
    Command->CommandMode            = FMC_SDRAM_CMD_PALL;
    Command->CommandTarget          = target_bank;
    Command->AutoRefreshNumber      = 1;
    Command->ModeRegisterDefinition = 0;
    /* Send the command */
    HAL_SDRAM_SendCommand(hsdram, Command, 0x1000);
我把循环在HAL_SDRAM_SendCommand(hsdram, Command, 0x1000);之前再添加一次，速度正常。
把循环在HAL_SDRAM_SendCommand(hsdram, Command, 0x1000);之后，HAL_SDRAM_SendCommand(hsdram, Command, 0x1000);之前再添加一次，新添加的循环也很慢。
把循环在HAL_SDRAM_SendCommand(hsdram, Command, 0x1000);之后再添加一次，新添加的循环速度正常。。。

我的工程开了 模拟 i2c，如果把 i2c 关掉，所有循环的速度正常。

感觉这个问题有点莫名其妙。

我知道不是你写的。按我说的操作，改一下就固定延时了。
你在哪个阶段初始化 sdram ？不会是某个线程吧？有线程调度了之后时间肯定不固定啊。
如果初始化实机比较早，i2c 可能还没启动，也不会影响到sdram的初始化配置。这里你的处理可能有问题。
因为 i2c 是软件模拟的，它在线程里初始化注册都不影响。

用不了 rt_hw_us_delay 函数，这是系统启动阶段就调用了的，这时候所有中断都被屏蔽了。
目前我还什么代码都没写，就只是在系统中配置了开启 SDRAM，然后生成代码就会把 drv_sdram.c 添加到工程，全都是系统自己的代码。
如果我开启 i2c，工程中就会添加 drv_soft_i2c.c ，这时候 sdram 中的那个循环就超级慢。
问题是这个循环只有放在那里运行才慢， 我把这个循环复制到前面去也正常，复制到后面去也正常。
我复制两份，放在如下图的位置上

中间的循环是原来的，前后的都是新增加的。 就是中间的慢 （10s+），前后的都很快 （毫秒级）。

仔细看函数名，这个延时是不依赖 systick 中断的，有空看看我的第二篇文章。
添加 drv_soft_i2c 文件也不一定有代码执行，你别说的这么鬼，配置 sdram 能影响到主频？

你说的换个延时函数我试了下，确实可以。 但根本原因没找到，为什么这里会导致代码执行突然变慢，后面再发送 FMC_SDRAM_CMD_PALL 命令后，代码执行又正常了。
这里我也不清楚问题出在哪里，只能怀疑是给 SDRAM 发送 FMC_SDRAM_CMD_CLK_ENABLE 后可能影响到了时钟，看这个命令的意思应该是开启 SDRAM 的时钟。
但是不开启 i2c 就全都正常速度执行，所以又不像是对 SDRAM 的操作影响到了时钟。
区别在于添加了更多的代码之后，循环代码的位置变了一些，

我的板子是 H750，内部只有一个跳转boot，应用程序都在 QSPI FLASH。
然后我把代码改成片内运行，开启 i2c 的时候，同样会有循环那里慢一下，但是大概只有 2秒钟（ QSPI 运行有十多秒）。 关闭 i2c，循环那里毫秒级就过去了。
主要还是想弄懂为啥那个地方会执行慢，就怕后面还有其他地方突然执行慢，又不知道原因，那就很麻烦了。 趁着现在刚开始，代码还很少。

我怀疑，要么是有个中断频繁触发，要么你的 INIT_BOARD_EXPORT(rt_hw_sdram_init); 这句是 INIT_APP_EXPORT(rt_hw_sdram_init);

暂时找到了原因，我更新了 rtthread 的版本，然后就出了这个问题。

从下面的红框，更新到了最新版。
回退到下面这个版本后问题解决了。
至于其中的真正原因估计要比较这两个版本的区别才能知道了。

还是不对，改回旧版本了，添加 i2c 没出错了，但是再添加 nand 又出错了。一样的现象，跑到那个循环就要耗时特别久， 去掉 nand 就好了。 无语了

系统性问题，我只能告诉你，你看到的执行满的地方仅仅是问题暴露点儿，不是问题根源。
这个问题需要你从 0 开始把系统捋一遍。

最终确定了问题。
1、要开启 ICache，不然在莫名其妙的地方就会有代码执行超慢的问题。
2、要开启并设置好 MPU，不然访问某些硬件外设时会有异常。

我也发现这个问题，这个问题你后来是怎么处理的，为什么会慢慢呢？理论 应该很快就执行完了，但是这里非常慢慢？现象和你的一样一样！能不能告知一下？

配置好 MPU。

我的代码是在 QSPI 中直接运行的，代码小的时候，可能就只需要内核加载一次，然后运行没啥问题。
代码增加到一定量之后，一次加载不完了，当运行到没有加载的代码块时，就需要再次加载。
如果没有配置 MPU，运行就会很慢。
这个问题后面解决了，没有来更新。原因就是上面描述的。
使用 QSPI 运行代码时，一定要把 QSPI 的地址范围配置好 MPU。