各种各样的调试方式中，如果使用的HyperFlash，推荐使用HyperFlash，几乎跟芯片自带Flash调试没区别，简单省事
官方的例程中提供了各种各样的调试方法，容易眼花缭乱，不知道选择那个好。1、经过这两天的调试，如果使用的是HyperFlash做外部flash，推荐使用HyperFlash调试下载即可，这样就跟是STM32几乎是没区别的了，而且调试速度也跟的上。也不用担心擦写次数，操作个2-3年基本是没问题的。
2、后面程序也直接在HyperFlash运行，无需加载到SDRAM，因为HyperFlash的读速度超快，可以达到332MB/S。而SDRAM工作在166MHz下，不考虑读写时序延迟和充电的理论最大值是332MB/S，实际速度应该是200MB/S左右（具体速度待我后面实测）。
3、而且最重要的一条是后面还要使用SDRAM做LCD显存，GUI动态内存，如果将程序也加载到里面跑，对于16带宽的SDRAM，性能比较捉急。如果后期RT型号支持32位带宽SDRAM或者DDR会好很多。
下面是JLINK调试下载HyperFlash的方法，适用于我们的i.MX- X1板子。
http://www.armbbs.cn/forum.ph ... 6488&extra=page%3D1
下面是CMSIS-DAP调试下载HyperFlash的方法，适用于我们的i.MX- X1板子。
http://www.armbbs.cn/forum.ph ... 6480&extra=page%3D1
硬汉开始做1052的技术支持了啊 关掉D-ache测试sdram，我手上两个设计的RT都是写50Mbyte/s左右。如果测出200M，应该是测成了Cache的速度。 alexyzhov 发表于 2018-5-6 01:33
关掉D-ache测试sdram，我手上两个设计的RT都是写50Mbyte/s左右。如果测出200M，应该是测成了Cache的速度。
确定只有这么高么，那F429外接SDRAM都可以严重吊打，回头我也测试下，现在还在倒腾各种基础问题。另外DCache仅仅是影响下所刷程序的速度，瓶颈还是SEMC接口。
下面是我之前测试的F429外接32位带宽SDRAM，还有让其他网友也做过测试，论坛有好多帖子，上100MB都是松松的。
32位SDRAM写速度狂飙300MB/S，读速度90MB/S
http://www.armbbs.cn/forum.ph ... highlight=300MB%2FS
这样的话，RT的速度的确捉急啊，另一个比较有力的测试是使用外部SDRAM刷800*480*2的图片，SDRAM同时做LCD显存和emWin动态内存，刷图片依然可以做到50MB左右的写速度。
刷800*480*2的图片仅需15ms，显存也要占用将近一半的SDRAM带宽。所以上100MB都是松松的。
eric2013 发表于 2018-5-6 10:28
确定只有这么高么，那F429外接SDRAM都可以严重吊打，回头我也测试下，现在还在倒腾各种基础问题。
下 ...
考虑了Cache的影响吗？D-Cache是必须关掉的，不然其实就真的是在测Cache(TCM)的速度。。
如果打开Cache，RT 200Mbyte/s
alexyzhov 发表于 2018-5-6 10:33
考虑了Cache的影响吗？D-Cache是必须关掉的，不然其实就真的是在测Cache(TCM)的速度。。
如果打开Cache ...
看我楼上完整的回复，刚刚重新编辑了下:handshake。
F429没有Cache，就是个普通单片机。 本帖最后由 alexyzhov 于 2018-5-6 11:05 编辑
eric2013 发表于 2018-5-6 10:28
确定只有这么高么，那F429外接SDRAM都可以严重吊打，回头我也测试下，现在还在倒腾各种基础问题。另外DCa ...
我感觉不是SEMC的问题，而是SDRAM的问题。因为我配置过SEMC接近到200M的时钟，SEMC也能正常工作。SDRAM的各个操作时序都是按照手册上的minimum tolerence设置的。
可以见到读写速度随着SEMC频率的提升，饱和的过早了。以至于到横轴的最后端，频率的提高都几乎没任何作用了。。
当然，我这没有示波器，不能实际抓波形出来看。此处是用断点配合内核CCTIMER1做的计时，最后几个时间一模一样，我也是有点奇怪。
PS. 写入的数据量是2Mbytes，被测试的SDRAM空间用MPU配置了none shareable, none cacheable
本帖最后由 alexyzhov 于 2018-5-6 11:00 编辑
eric2013 发表于 2018-5-6 10:38
看我楼上完整的回复，刚刚重新编辑了下。
F429没有Cache，就是个普通单片机。
我查了一下arm的资料，cortex m3，m4确实没有自带cache的设计。但在具体的SoC设计中，可以由设计商自行添加，也就是说，m3/m4内核是支持cache的，只不过cache作为可选项，是弹性支持。
再搜索了一下具体的F429，发现其集成的m4确实也没有预留I-Cache和D-Cache。但我也发现，网络上有人提及FMC外设是自带Cache的，对连续数据块的预读和预取有很大的提升。Flash也有相关的cache和prefetch设计，用于数据加速。
alexyzhov 发表于 2018-5-6 10:55
我查了一下arm的资料，cortex m3，m4确实没有自带cache的设计。但在具体的SoC设计中，可以由设计商自行添 ...
那个是正常的突发模式，从F1开始，那个FSMC总线就支持的。而且F429突发仅仅支持单数据的读突发，写是没有突发，就是普通写入，之前我专门研究过：
http://www.armbbs.cn/forum.ph ... hlight=%CD%BB%B7%A2 eric2013 发表于 2018-5-6 11:02
那个是正常的突发模式，从F1开始，那个FSMC总线就支持的。而且F429突发仅仅支持单数据的读突发，写是没有 ...
学习了:handshake
我也再抽空研究下SEMC，虽然配置里添加了Burst相关的数据，但感觉对地址的直接操作，似乎并没有利用burst的特性。总之确实有点过慢了，不符合RT的性能定位。 本帖最后由 alexyzhov 于 2018-5-6 15:08 编辑
eric2013 发表于 2018-5-6 11:02
那个是正常的突发模式，从F1开始，那个FSMC总线就支持的。而且F429突发仅仅支持单数据的读突发，写是没有 ...
非常尴尬，没想到for的影响有这么大。
#pragma unroll = 1024
for(i = 0; i < (SDRAM_SIZE / sizeof(pattern)); i++)
{
*write_uint32++ = pattern;
}
我修改了之前的写入测试代码，将iar的优化等级设置为最高，只开启loop unrolling，并且将每个循环内容展开1024次(也就是说，展开后，一个循环写入1k*sizeof(uint32_t)=4 kBytes的数据)。
使用C-SPY macro，配合断点把CCTIMER1的计数给dump出来了：
测试速度为200MByte/s(程序存储在QSPIFlash中，开启I-Cache，关闭D-Cache)，但感觉这个成绩还是有问题，因为太接近Cache的速度了。晚上回来把程序下进SRAM里再试试。
后增：
将测试相关的代码ramfunc了一下，确保在TCM里执行。关闭了I-Cache和D-Cache。循环同样unrolling 1024次。测出的写入速度213Mbyte/s(SEMC时钟163Mhz，提高到166Mhz时写入速度216M/s)
alexyzhov 发表于 2018-5-6 14:27
非常尴尬，没想到for的影响有这么大。
非常感谢测试。
RT1050看来在图形性能上干不过F429了，有些差距。当前是需要Cache或者TCM的配合才有200MB，而且DMA2D也不支持。 eric2013 发表于 2018-5-7 01:23
非常感谢测试。
RT1050看来在图形性能上干不过F429了，有些差距。当前是需要Cache或者TCM的配合才有20 ...
这样做主要是为了避免取指延迟造成的影响，测出来的尽可能是纯接口的速度。如果用eLCDIF或者DMA，我想应该能更大限度地发挥接口的速度。毕竟16位接口，性能受限 alexyzhov 发表于 2018-5-7 08:18
这样做主要是为了避免取指延迟造成的影响，测出来的尽可能是纯接口的速度。如果用eLCDIF或者DMA，我想应 ...
后出32位SDRAM接口或者一步到位，支持DDR就给力了。
DMA无法加速，DMA只能一定程度上降低CPU利用率。
非常感谢你的测试:handshake
页:
[1]