各种各样的调试方式中，如果使用的HyperFlash，推荐使用HyperFlash，几乎跟芯片自带Flash调试没区别，简单省事

eric2013

官方的例程中提供了各种各样的调试方法，容易眼花缭乱，不知道选择那个好。


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

weiyuliang

硬汉开始做1052的技术支持了啊

alexyzhov

关掉D-ache测试sdram，我手上两个设计的RT都是写50Mbyte/s左右。如果测出200M，应该是测成了Cache的速度。

eric2013

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都是松松的。

alexyzhov

eric2013 发表于 2018-5-6 10:28
确定只有这么高么，那F429外接SDRAM都可以严重吊打，回头我也测试下，现在还在倒腾各种基础问题。

下 ...

考虑了Cache的影响吗？D-Cache是必须关掉的，不然其实就真的是在测Cache(TCM)的速度。。
如果打开Cache，RT 200Mbyte/s

eric2013

alexyzhov 发表于 2018-5-6 10:33
考虑了Cache的影响吗？D-Cache是必须关掉的，不然其实就真的是在测Cache(TCM)的速度。。
如果打开Cache ...

看我楼上完整的回复，刚刚重新编辑了下。
F429没有Cache，就是个普通单片机。

alexyzhov

eric2013 发表于 2018-5-6 10:28
确定只有这么高么，那F429外接SDRAM都可以严重吊打，回头我也测试下，现在还在倒腾各种基础问题。另外DCa ...

我感觉不是SEMC的问题，而是SDRAM的问题。因为我配置过SEMC接近到200M的时钟，SEMC也能正常工作。SDRAM的各个操作时序都是按照手册上的minimum tolerence设置的。

test data

可以见到读写速度随着SEMC频率的提升，饱和的过早了。以至于到横轴的最后端，频率的提高都几乎没任何作用了。。

当然，我这没有示波器，不能实际抓波形出来看。此处是用断点配合内核CCTIMER1做的计时，最后几个时间一模一样，我也是有点奇怪。

PS. 写入的数据量是2Mbytes，被测试的SDRAM空间用MPU配置了none shareable, none cacheable

alexyzhov

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设计，用于数据加速。

eric2013

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

alexyzhov

eric2013 发表于 2018-5-6 11:02
那个是正常的突发模式，从F1开始，那个FSMC总线就支持的。而且F429突发仅仅支持单数据的读突发，写是没有 ...

学习了

我也再抽空研究下SEMC，虽然配置里添加了Burst相关的数据，但感觉对地址的直接操作，似乎并没有利用burst的特性。总之确实有点过慢了，不符合RT的性能定位。

alexyzhov

eric2013 发表于 2018-5-6 11:02
那个是正常的突发模式，从F1开始，那个FSMC总线就支持的。而且F429突发仅仅支持单数据的读突发，写是没有 ...

非常尴尬，没想到for的影响有这么大。

1. #pragma unroll = 1024
   
2. for(i = 0; i < (SDRAM_SIZE / sizeof(pattern)); i++)
   
3. {
   
4.     *write_uint32++ = pattern;
   
5. }

复制代码

我修改了之前的写入测试代码，将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)

TCM测出的速度

eric2013

alexyzhov 发表于 2018-5-6 14:27
非常尴尬，没想到for的影响有这么大。

非常感谢测试。

RT1050看来在图形性能上干不过F429了，有些差距。当前是需要Cache或者TCM的配合才有200MB，而且DMA2D也不支持。

alexyzhov

eric2013 发表于 2018-5-7 01:23
非常感谢测试。

RT1050看来在图形性能上干不过F429了，有些差距。当前是需要Cache或者TCM的配合才有20 ...

这样做主要是为了避免取指延迟造成的影响，测出来的尽可能是纯接口的速度。如果用eLCDIF或者DMA，我想应该能更大限度地发挥接口的速度。毕竟16位接口，性能受限

eric2013

alexyzhov 发表于 2018-5-7 08:18
这样做主要是为了避免取指延迟造成的影响，测出来的尽可能是纯接口的速度。如果用eLCDIF或者DMA，我想应 ...

后出32位SDRAM接口或者一步到位，支持DDR就给力了。

DMA无法加速，DMA只能一定程度上降低CPU利用率。

非常感谢你的测试