阅读官方IO设备模型框架图后，有个疑惑：它具体指的是什么呢？如何对应到代码中去？这始终是一个困惑——让我感觉空落落的，悬在半空中。——近日，为了自我解惑，参照rtt源码和官方的IO设备模型框架图绘制了另一个图来解释和剖析官方的IO设备模型框图，姑且称之为IO设备模型框架补充图——端详良久，比较满意，终于自我解惑了。于是分享出来，希望给更多的人解惑。——对照该图，再看官方IO设备模型框图就能看懂了——感觉终于落地了，不再悬在半空中了——就像装了个望远镜，转了下按钮从而加深了景深。
1.官方IO设备模型框架图
rtt官方文档链接——《IO设备模型》
2.我绘的IO设备模型框架补充图
该图可以作为官方I/O设备模型框架图的补充图，两图对照看，就能很好理解官方的IO设备模型框架了。
2.1 补充图绘图要点
（1）类图结构（后续画图补上）。
类名（struct结构体名字）
中文类名
该类管理接口所在c文件
（2）类图里.c文件说明。
（a）IO设备管理层和设备驱动框架层的c文件名没有带路径，因为是rtt自己写好的。
IO设备管理层的c文件在rtt源码根目录src下，设备驱动框架层的c文件在rtt源码根目录components下找寻。
（b）设备驱动层的各类下面的c文件路径和名字只是个示意而已，不要当真——只是说“有”这个文件。——具体名字和路径由各BSP开发维护者自己定的。比如图中stm32的drv_usart.c所在路径是bsp/stm32/drv_usart.c，但实际路径（当前）是在rtt源码下的bsp/stm32/libraries/HAL_Drivers/drv_usart.c。比如有的bsp下起的名字不叫drv_usart.c而叫drv_uart.c等等——我建议最好大家遵循统一的命名规则，这样不会像现在这么混乱。
随着rtt源码的版本的变化，各bsp的驱动路径和名字可能会发生变化（一般很稳定）。所以如果按照图中的路径找不到就不要奇怪了。
（2）类图中的“xxx”说明。
（a）设备驱动框架层的“xxx”，是代表省略的rtt已经写好的各类，不再一一列出了——可以去rtt源码的components目录下找寻，比如components/drivers下有serial/i2c/spi/sensor/can等等。
（b）设备驱动层的“xxx”，第一个是代表省略的各BSP平台，不再一一列出了——可以去rtt源码的bsp目录下找寻，比如stm32/gd32/at32/avr32/k210等等。第二个代表的是省略的硬件模块，比如CAN/SPI/I2C等等。比如图中最后的类名叫“xxx xxx”，意思是说前一个“xxx
”代表bsp平台，后一个“xxx”代表硬件模块。
2.2 补充图解说官方IO设备模型框架图
该补充绘图，帮助你看懂并理解rtt官方的IO设备模型框架图：
（1）看补充图就能知道官方图的各层里面文字的背后代表了什么。
（2）各类继承和派生关系清楚明了。
（3）能看到面向接口编程的思想。子类受到父类接口的约束，子类想办法各自实现父类提供的统一接口。
（4）每类只有一套管理接口。
（5）从下往上不断抽象、统一和屏蔽硬件差异。
（6）OOPC的思想贯穿其中，细细品味。
（7）该补充图，横向看能看到分层思想，纵向看能看到各类派生继承关系。纵向看的话，每个类都实现该类的管理接口。比如从驱动层看起，stm32有的stm32串口设备类(stm32_uart)，那么该类就有驱动管理接口在stm32_usart.c中，同理gd32也一样。同理CAN、ADC等设备根据各个厂家都有其驱动的管理接口。在往上走，驱动框架层，那么这个就厉害了，不管下层是stm32、gd32还是别的平台的，把他们属于同一类的统一对接到上层。比如不管硬件是啥，stm32也好，gd32也罢，还是其他，只要都是串口设备的，都对接到rtt写好的serial.c（串口设备类rt_serial_device）——如图所绘，屏蔽了底层差异，体现了面向对象的抽象的威力。从驱动层到驱动框架层，由不同厂商的相同硬件模块创建了很多子类对象，然后对接到同一个父类接口上，多对一，体现面向对象的抽象的威力。再往上，从设备驱动框架层到IO设备管理接口这一层，又是多对一，又是再一次的屏蔽差异，再一次的抽象，最后统一操作了。
tips:
（1）给BSP新增设备驱动对接到rtt框架时，BSP开发者所做的工作就只是开发驱动层就行了。上面2层（驱动框架层和IO设备管理层）rtt都写好了，无需改动，除非发现BUG，或者新增设备类型（但这块就应该是rtt官方来实现了）。