XXXARM软件设计及调试记录：串口IAP、串口DMA传输、内部RTC时钟、外部flash读写

说明：
本篇记录使用的硬件平台是某国产407芯片，完美兼容stm32f407，故设计中参考的大部分甚至绝大部分的知识点都是来源于原子哥。部分外设原子哥没用到的，也会参考原子哥写的类似外设驱动，进行修改、调试。

2022.7.18 串口IAP

查看关于利用串口/网口进行程序升级的功能，简单起见，使用串口IAP。

2022.7.19

疫情封闭回来，编译工程，出现了keil5编译程序出错：runtime error R6002 -floating point support not loaded，这个错误，很合适宜，似乎电脑也被新冠病毒入侵了，经过各种办法，时钟无法解决，最终还是重装软件解决的。
关于生成bin文件，按照原子哥的步骤，只需在Options for Target→User 选项卡，在 After Build/Rebuild 栏，
勾选 Run #1，并写入：
C:\Keil_v5\ARM\ARMCC\bin\fromelf.exe --bin -o …\OBJ\CAN.bin …\OBJ\CAN.axf，编译即可。
今天经过漫长的调试串口过程，主要调试了串口连接，一直以为板子是接了232转换芯片，搞半天是直接从单片机引出来的，然后仿真器也时不时的连接不上芯片，提示intenel command error，拔掉再插上就好，然后换个工程烧录，也行，这个没搞明白是硬件的问题还是软件的问题。这个是以前没遇见过这么频繁的出现，国产芯片不好用。
把原子哥的IAP工程，拿过来，稍微做了一下修改，进行串口升级，成功了，也揭开了困扰我多年的串口下载程序的困惑问题，原来是这样的，不过这个IAP工程，只是最基本的，想将他应用在工程上，还需要修改。
在使用串口上位机发送bin文件的时候，注意要使用hex发送，并且在发送的过程中，不要再额外进行串口的收发动作，否则可能会导致接收的bin文件不完整。
在更新flash 的过程中，也要注意不要同时在进行flash的读或写，否则会打乱程序更新的节奏，导致更新不成功。
目前做的IAP工程是分成了两个小程序，一个是纯boot，一个是纯APP。在APP里面留了一条指令，用来进行升级使用，测试了几次挺稳定。暂时就把这个小程序保存起来，等到项目完成后，再移植进去。

明天需要搞一下串口的DMA数据传输，本来想用中断，但是工程需要使用5路串口，怕来不及进行数据处理，调试一下使用DMA传输数据，看看是否能够在同时进行通信的时候，数据不会有丢失的可能。

2022.7.20 串口DMA传输

经过仿照原子哥的程序，将DMA的接收数据完成了，不过目前和原子哥的一样是查询状态查看完成接收的，下面要修改成中断状态的。现在还只是实现了一路的串口数据接收，最终要实现5路的，但是只有两个DMA控制器，最后如果5路数据同时进来，恐怕还是得有数据丢失。
中断的配置记录：NVIC的配置，接收使用循环模式接收，存储器改为非增量模式，使能数据传输完成中断，使能串口的DMA接收，之后就能成功的进入DMA的中断了，但是中断虽然进去了，传输的数据却不对了，正在查找原因。（存储器改为增量模式）
后来还是改变了直接使用DMA的思路，在csdn上看了多位大佬的方法，感觉这种还不错，https://blog.csdn.net/m0_64354650/article/details/125686328?spm=1001.2014.3001.5501
使用了串口的空闲中断，妙啊！在空闲中断中
多谢！
串口数据只使用了接收功能，发送还需要在另外使用别的方法。
今天是算调通了DMA的传送，明天要调试两路串口的dma数据传输的稳定性。后天应该要研究一下项目中数据的存储逻辑。再然后是准备IIC/SPI的驱动。

2022.7.21 串口DMA传输

今天调试了两路串口的DMA数据传输，（设置同一路串口DMA一样），没问题，明天有时间搞搞三路同时传输。
今天晚上又搭建了一下modbus协议处理的框架，简单测试了一下，可以使用，明天下载个modbus的软件，专门测试一下。
后天单位要搬家了，不知道明天有没有时间测了，客户的探头估计后天也就寄过来了，下周又要搞5000A，估计下周没时间搞这个项目了，下下周放高温假了，但由于疫情原因，放不放是未知数了。
硬件上还要添加一个外部sram，这个之前没搞过，也不知道好不好搞。
加油弄！
收拾东西，准备搬家！

2022.8.1 内部RTC

竟然距离上次整整10天了，时间过的真快！
上次过后经历了做5000A、出差，导致上周没有进行这个项目工作。
今天主要是梳理了一下接下来需要做的工作，今天拿到了一块开发板，下面就是在这个上面实验了，今天实现了内部RTC的读写。（当然都是拷贝的原子哥的）。用这个时钟的主要功能是记录数据的存储时间。
明天搞一下吧，明天要把这个存储逻辑基本框架搭建处理了，不然时间会紧张，因为下周又要休高温假了。

2022.8.2外部flash读写

今天上午是理解了原子哥的flash读写实验，下面就开始基于这个例程进行项目使用，也就是根据实际应用进行修改了。原子哥是每次写之前都对其进行了擦除操作，而实际中由于写入次数非常多，大致1s一次了，所以不能每次都进行擦除操作，必须计算好，将一个扇区写满后，下次再来写的时候再进行擦除动作。
经过咨询有经验的前辈，到晚上终于调试出来一版可以轮训存储与查询的程序。不过如果存储的范围过大的话，可能查询起来比较耗时间，等到把存储需求都确定下来后，计算一下最大存储时的查询耗时，如果不满足要求的话，看看查询的时候是否使用一些算法来进行查询，比如二分法。
现在是相当于底层驱动都有了，明天需要做的事情就是要把存储逻辑设计好，如果明天顺利的话，后天就要设计计算哪些存储变量了。这两部分搞完的话，存储这部分应该没有问题了。再后面就可以搞一下网络、填充modbus协议了。

2022.8.3

今天又将存储数据，查询数据进行了优化，将昨天存在的bug进行了修复。具体的bug大概是记不清了，下次再遇到bug应该记下来，不然解决了就忘了。
今天实现的是存储数据及断电重启后如何进行断电之前的操作查询。
由于设备设计使用20年，根据条件进行了计算，初步是划分16MB的空间供1小时内的每秒钟存数据使用。但是如果是16MB的空间，当写到后部的时候，断电重启查找会比较耗时，所以又设置了一个扇区专门用来10min存一次数据时间及存储地址。这样在断电的时候最多只需要查询10min的数据就可以了，当然，如果这样还时间长的话，那可能后面要设计成5min。有昨天打下的存储数据逻辑基础，今天也是把这个弯弯绕绕理清，写了一版程序，发现可以将存储数据及读取数据做成复用函数。
今天没有设计成功，原因是在测试中发现，判别10min间隔的地方出了问题，考虑情况太少，导致判别出错，这个已经找到了一个例程，待明天研究研究，修改修改，将其思想用到项目中来。
按照这个计划，明天上午 应该是能搞定存储数据的第一部分了，万里长征开头难，有了第一步的基础，下面在去做出错时前后半小时的数据存储，及每小时存储一次，等等各种逻辑应该要好做一些了，争取明天把这些逻辑搞定吧。再将函数复用整理好，不然时间一长就不想整理了。

2022.8.15

竟然12天没有记录了！！！
到今天已经完成了1s存储数据的开发，10min存储数据的开发，报警数据的存储（无断电重启的情况发生,断电重启的情况没有设计，估计实际用不到，但大致和1s的流程一致）,还有1h的历史数据量没有开发，这个需要用户代码，所以暂时保留。下面考虑到数据量过大，需要使用DMA的发送与接收。接收实现了，开始实现发送，现在是协议和存取数据双腿前进，时间快到月底了，得加紧弄了，争取这周完成工作！但这周的事情还是挺多的，估计悬了。但下周要开始调试了，所以这周得拼了。