完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
|
开启了 SDRAM 后，在 drv_sdram.c 的 SDRAM_Initialization_Sequence 函数中有一个用 for 循环进行的延时： 这个延时之前是正常的，在一次修改配置后突然这里变得特别慢，跑完这个循环要 10s+。改回去之前的配置也还是慢，不清楚具体原因。 但是过了这里之后，速度就正常了。 我把这个循环复制到 main 函数中，速度正常，很快就过了。 有谁遇到过这个问题吗？ 
0
|
|
相关推荐
13个回答
|
|
|
/* 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 就好了。 无语了
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
我也发现这个问题，这个问题你后来是怎么处理的，为什么会慢慢呢？理论 应该很快就执行完了，但是这里非常慢慢？现象和你的一样一样！能不能告知一下？
|
|
|
|
|
|
配置好 MPU。
我的代码是在 QSPI 中直接运行的，代码小的时候，可能就只需要内核加载一次，然后运行没啥问题。 代码增加到一定量之后，一次加载不完了，当运行到没有加载的代码块时，就需要再次加载。 如果没有配置 MPU，运行就会很慢。 这个问题后面解决了，没有来更新。原因就是上面描述的。 使用 QSPI 运行代码时，一定要把 QSPI 的地址范围配置好 MPU。 |
|
|
|
|
你正在撰写答案
如果你是对答案或其他答案精选点评或询问，请使用“评论”功能。
590 浏览 0 评论
AI模型部署边缘设备的奇妙之旅：如何在边缘端部署OpenCV
2241 浏览 0 评论
tms320280021 adc采样波形，为什么adc采样频率上来波形就不好了？
1233 浏览 0 评论
1788 浏览 0 评论
1464 浏览 0 评论
74814 浏览 21 评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1822
评论
淘帖
3747
