马上解决:
1.每一帧的前后必须有延迟时间(T1-T2-T3-T4) ,为什么不直接是个T ？
具体参考Modbus的本身协议。
2.P3,"通过DIII发送什么意思" ，P1，一个HA I/F适配器最多可以连接64台室内机和10台室外机，室内和室外意思？
空调本身分为室内机和室外机，DIII-net 是室内机室外机和适配器之间的网络体系，一台室外机可以对应多台室内机;且适配机最多支持64台室内机，和10台室外机。
3.P11的注意事项:“当保持寄存器的值发生改变时，HA I/F适配器会发送一条指令给VRV空调。
所以，当HA系统读取当前输入寄存器的状态时,HA系统必须更新保持寄存器
中的值。否则，HA系统的操作将会被忽略。”
读取一次，为什么还要设置一次？
暂时不需要完全去把逻辑做起来，移植FreeModbus只需要把操作实现，具体每个数据的含义不需要解析，郭博提示，猜测可能是确定数据被读出来了，读出来了，没有写入，此时stm32收到写入命令，那是不是系统就不理会了呢？具体的需要到现成进行测试(提前调试手段准备好)。
最终是，状态保持一直，但是设置的时候不太一样，空调20度 -> 手持机控制30 -> 如果此时设置20是不起作用的
4. 读取温湿度数值中延时Systick修改成其他的延时,除了等数据用rt_delay();
5. rt中机制采用信号量机制，后期可以考虑成email甚至是event机制
6. 大金空调中协议读取数据可以做成 数据组数+第一组首地址+第一组个数+第二组首地址+第二组个数+第n组首地址+第n组个数
7. finsh的调试可以使用起来，模拟中控发送数据过来，关于大金HA I/F适配器说明书中"当HA系统读取当前输入寄存器的状态时，HA系统必须更新保持寄存器中搞定值"，可以后期到控客进行调试(当然需要把所有的准备工作做好)
8. 系统的10ms为一个单位即72000个指令完成操作就不会被Systick中断，如何计算得到7W2千这个数值的？
9. 中断越短越好，尽可能减少其影响，一般来说中断执行的指令不会太耗时，究竟一条指令需要多久时间？
10. 系统可以设置成5种模式：(1).配置参数 485参数;(2).读取配置，大概10种，支持实时读取;(3).Poll;(4).push机;(5)ctrl机制; -> 协议已经修改好Modbus代理网关的协议
11. Modbus中数据的参数还可以设置成小数地址，或者32位地址，最好还是把Modbus协议重新梳理一下
12. Modbus中3000和40000地址通常对应什么地址？还有10000和20000地址通常对应什么？最后给出的128K是如何得出的？准备使用STM32F103ZET6+8M
13. 识别大金适配器的协议可以适当的考虑编写，并且适配器还可以考虑加入薄码开关对适配器类型的识别。 -> 最终采用主动按按键的方式进行未知定位
14. "网关代理"协议制定
15. 关于从机地址和起始地址和功能代码，特别是两个之间的组织关系需要理清楚
16. RT-thread OS 使用的systick作为系统时钟，平时我们在操作其他设备时，再用systick延时会不会有什么不好，答案是会，不知道具体是怎么回事的时候，就最好不用。要用，先把上面的看懂，也把OS这边使用systick的机制大体搞懂
17. excel中分类显示如何做(表格中有个下拉菜单可以选择)
18. 画程序流程图，方便代码的编写
19. 打印的时候如果存在连续的(至多5个),就打印在一行
egA: 如果reg是1,2,4,5,6,7
printf：
1,2 ++++
4,5,6,7 +++++
egB: 如果reg是1,2,3,4,5,6,7,9,10,11,12,13,14,15
printf：
1,2,3,4,5 ++++
6,7 ++++
9,10,11,12,13 ++++
14,15 +++++
20. 光照在某些情况下，出现读取错误(ERROR为2或者3)(当时一点点测试到了阳台就出现了，拔掉电源重新上电，不能解决)，这个问题必须要定位到！
待完善
1.定时上报数据可以修改成有变化(幅度可以为1或者0.1)再上传最新的值
2.串口DMA发送数据，可以想队列方式的发送出去吗，可以参考睿智的意见
3.理解基于Modbus协议的光照度变送器的操作手册，并手动操作一下
4.信号量连续发送两次,第一次还没有执行完，如何处理？
5.如何查看rt_thread串口收到的数据长度
6.串口操作buffer移植，RT_THREAD系统定时器操作使用
7.一个是fram中断，一个是delayTimeout，两个优先级，保证delayTimeout优先级低于fram的。
bug
1.
常用复制的：
传感器上的MAC 0x00 0x12 0x4B 0x00 0x08 0xC6 0xF3 0xEF
新红外码转发器红外上的MAC 0x00 0x12 0x4B 0x00 0x09 0x51 0xB3 0x8D
tail -f /var/log/user.log | grep HJ_Server
tail -f /var/log/user.log | grep --line-buffered HJ_Server | grep "4678"
tail -f /var/log/user.log | grep HJ_Server | grep "0x00 0x12 0x4B 0x00 0x08 0xC6 0xF3 0xEF"
tail -f /var/log/user.log | grep HJ_Server | grep "0x00 0x12 0x4B 0x00 0x09 0x51 0xB3 0x8D"
遇到的问题和解决方案
工作直接相关：
1. F051C8 仅 8K RAM , 程序编译之后已经 6-7K 了, 程序中如果malloc(1024), 容易出现问题
代码编写过程注意代码的编写风格，适当的动态分配内存减小RAM的消耗
2. 数据存储和现有的4455协议冲突
采用两个req+UDP+endreq方式简单方便的达到数据存储和上传的功能
3. 上传和下载过程中同时申请内存，内存明显不够
每个时刻仅保持一种功能的存在
4. 制定的底层通信协议过于繁琐
按位来对设备进行操作
5. 数据通信的过程中数据的变化，对代码的修改工作量较大
采用动态数据长度的修改，适合各种长度变化，增加代码的通用性
6. 设备的工作的过程中，针对于出现问题不方便判断
错误码详细分类，快速定位问题的出现位置
7. 数据交互过程中类tcp协议过于繁琐
采用简单的类udp方案传输数据
8. 上传数据的过程中，数据包含无效字节
去除无效字节合理分配内存
9. 下载红外码过程中，通信不协调，通信速率低
加入超时回包结束此次通信过程
10.CRC调试计算麻烦
采用在线计算器，简单快捷高效
11.数据通信过程中，没有req,直接start，FD问题等各种异常分支考虑不全
不同的异常分支回复相应的错误码，更容易定位问题
12.查看传感器采集数据类型不合理，以及数据存储理解错误
采用u32格式，数据存储的详细分析
13.上传和下载过程，参数固定，适应性差
把部分接口做成相对通用的
14.传感器数据处理过程中buf、pop、push架构繁琐
采用官方的数据结构，简单快速
15.Zigebee透传功能时思路混乱，通信流程不清晰
暂时忽略组网部分，只修改组网之后的代码，先简后繁提高工作效率
16.STM32F103传感器模块,MCU从串口获取数据的过程中，如果传输过程中数据长度发生错误，导致MCU进入短期不可控制
接收数据过程中，加入4MS空闲状态判断，按照每一帧发送给uart_handle函数的方案，有效的处理错桢的问题
17.传感器代码结构不合理
加入根据接入传感器的类型不同，代码自适应传感器，有dev概念，模块化开发构思和架构分层方法的实现
18.分析红外码不合理
采用逻辑分析仪分析具体的逻辑波形
工作间接相关：
1. 数据结构不理解，无法理解程序执行流程
详细分析通过一个函数，操作一个结构体，实现对应函数功能，模块化概念，降低代码维护和代码跟踪问题
2. 公司产品功能的不清晰
分析现有产品，分析后期产品的可拓展的空间，分析代码严谨代码风格的必要性
3. 调试工具不会使用，不知道如何调试
尽量隔离其他人员的协助，自己对设备进行调试，加入固定mac的过滤，方便定位问题和代码的跟踪
4. 下行协议不理解，tag和OPCODE的错误认识
详细分析下行协议，理解协议结构方便功能的实现
5. rt-thread系统调试finsh组件不会使用
演示使用方法，和注意事项，包括如何对代码进行跟踪