WhyCan Forum(哇酷开发者社区)

最近在尝试ACM32F4遇到两个头大的问题，航芯的FAE估计不对个人服务，没通过只好靠自己尝试解决下。
1. CMSIS的pack内的SVD文件不带寄存器位描述，rust包无法获取到位级别，欢迎大家一起补充。
解决方案：使用svdtools对官方文件进行描述补丁，在使用svd2rust进行解析。
项目地址： https://github.com/shaoxi2010/acm32f4
点灯项目： https://github.com/shaoxi2010/acm32f4-rs
更新了基本库使用和ICACHE的反编译代码。
2. ACM32F4在文档内提到一个非常有意思的东西L1Cache，之前接触到的Cache都是在有MMU环境下，这个
不带MMU环境的Cache还是第一次见，故对其产生了研究兴趣，因为手册上没有任何地方提及到cache使用，
但在其accelerate.a中观察到其实现。
首先是当前能获取到信息：
1. L1Cache位于Bus matrix之上，也就是C-AHB连接到ICache，S-AHB连接到了DCache
2. AHB1 和 AHB2 的时钟频率一致且等于系统频率，且处理器可以以 180MHz 的系统频率无等待地访问 SRAM。
3. 并未提及eFlash和SRAM有相同访问周期，故可能有延迟。
4. 从库函数解析上看，也实现了clean、invalid方法，但是在enable时没看到DCache的逻辑。
根据上述信息可以得出几个推论：
1. 同周期访问SRAM不就是Cache的功能么，那么DCache应该不需要连接到SRAM，大概率是外部内存。
当然我也没看到哪里支持外部内存，可能是为后续产品实现准备的。
2. 不知道DCache实现了标记内存为写透还是缓存的模型，按照现有给出来的数据，SRAM等外设进行cache
感觉就是画蛇添足。感觉大概率也是外部存储区域会使用Cache，其他都不用来减少编码复杂度，期待FAE
解答下。
3. ICache部分看上去只能与ROM和eFlash相连了，这部分的Cache应能提高程序执行性能，并且并不会影响
到代码的复杂度，感觉就ACM32F4目前状态而言，打开ICache将优化指令访问性能，提高执行效率。
4. 根据前面的推导和猜测可以大致猜想到，ACM32F4的cache模型应该与stm32l5的模型非常近似，可能这就是
对标产品。不确定仅猜测，附上stm32l5对L1Cache的解释说明。
an5212-using-stm32-cache-to-optimize-performance-and-power-efficiency-stmicroelectronics.pdf

所有时钟保持下载默认状态下，不开启ICache下执行eFlash Checksum时间约10s，打开ICache后提升到约4s。
证明ICache对eFlash的程序访问提升还是相当明显的。项目工程就是点灯工程。
测试日志如下：

                                                                                                                                                
11:43:54.997 checksum code without cache :start
11:44:04.945 checksum code without cache:end 517fa2f0
11:44:04.945 checksum code with cache :start
11:44:08.556 checksum code with cache:end 517fa2f0
11:44:09.058 blink led!

3. 目前发现程序断电后，直接插入后执行时常和效率完全不匹配明显慢了很多，估计是时钟源变了，需要继续分析下。