Fatfs是嵌入式上常间的文件系统， 其源文件结构上如下图所示：
该文件系统模块，支持FAT12/FAT16/FAT32。通常配置FATFS时，
需要设置簇大小（cluster size）。
fatfs文件系统上布局
Fatfs模块默认不支持对复制文件的共享控制，仅当文件的打开方式为只读模式，才允许共享控制， 禁止以写入模式对文件进行复制打开，而且打开的文件不允许被重命名和删除，否则会破坏卷的FAT 结构。
不同卷的文件操作是可以重入的，并且可以同时工作，同一个卷是不可重入的，但是可以利用 _FS_REEN
dynamic_cast主要是针对多态场景（虚函数）。运行时会进行类型检查，所以dynamic_cast判断一下 转换是否成功，再进行下一步操作。
//基础控件类
class UiElement{
public:
virtual void handle_msg(string &msg) = 0; //消息改成引用模式
virtual ~UiElement(){}
};
//具体文本类
class TextElement : public UiElement{
public:
void hstatic_cast:在编译时进行静态类型转换，不进行运行时检查，适用于非多态类型转换有效。 dynamic_cast:运行时通过RTTI（运行时类型信息），验证对象实际类型，确保转换的合法性，主要确保 多态类型的安全机制。
对于常见的向上类型转换（本身安全，例如：父类指针指向子类对象），但是对于向下转型， static_cast 不安全，需要手动进行验证，但是对于dynamic_cast就是安全且自动检查的， 可以判断出，转换是否有效。
static_cast，支持基本的类型转换，类继承层次的上行转换，但是无法处理多态类型的交叉转换。（零运
以Kicad绘制全志F1c200s开发板为例子,包含原理图绘制+PCB设计，
电路主要涵盖：电源电路，主芯片电路，音频电路，lcd接口，摄像头接口等。
主要是原理图+PCB图，当然生成的话会有gerber图纸+BOM器件清单（对于正规生成，尽量要标识清楚器件详情规格）。
因为使用过程中，可能遇到，输入法兼容性问题导致卡死。 KiCad跟微软拼音有冲突，如果不用微软拼音，直接卸载掉就好。如果要用，就设置为兼容以前的模式。
Linux上部分接口名字很类似，但是涉及到的内容有不一样，这样导致这些接口 使用的场景差异（底层实现上也是有差异的），比如一些gpio的一些操作，devm_ 接口的操作等等。
GPIO子系统中将操作分为：普通（原子）操作 和 cansleep操作。 本质上是为了适配不同硬件访问方式 和不同使用上下文，差异上：
gpio_get_value： 硬件访问方式，直接访问GPIO寄存器（内存映射IO），它是原子操作（禁用本地中断）， 支持中断上下文，可也以用于进程上下文，速度快，比如一些片上SOC内置（如ARM GPIO控制器）。 gpio_g
条件变量是一种线程同步机制，其核心作用是允许线程在特定条件未满足时进入休眠状态， 并在条件满足时被其他线程唤醒继续执行，通过“等待-通知”模式实现线程间的协调， 避免了忙等待（即不断轮询检查条件）带来的资源浪费，从而提高程序效率。 基于linux环境下或者windows的mingw环境（posix接口）。
我们主要分析pthread_cond_wait()的使用
先以示例代码进行展示，使用方式
pthread_mutex_lock(&mutex); // [1] 消费者加锁成功
while (queue_empty之前也提及到死机，由OOPS导致的，当然也有由于死锁导致的panic，分析途径都是一样的，主要是配置如何检测。
在实际使用中，主要是由于相互请求对方的锁，导致线程卡死。 配置参考：
Kernel hacking → Lock debugging (spinlocks, mutexes, etc.)
CONFIG_LOCKDEP=y #追踪锁的依赖关系，定位死锁路径
CONFIG_DETECT_HUNG_TASK=y #检测hung task（卡死的线程）触发panic
CONFIG_PAINC_ON_HUNG_TASK=y #检测到hung task后触发keLinux开发过程中，难免遇到死机问题，死机问题主要分层两类死机:
Kernel Oops:内核执行非法操作（如空指针、数组越界），触发软中断，但可能未完全死机 较低 输出 Oops: 日志，含寄存器、栈回溯
Kernel Panic:致命错误（如内核死锁、中断风暴），系统无法继续运行，触发重启 较高 输出 Panic: 日志，含触发原因（如 BUG: soft lockup）
在实际Linux驱动开发过程中，需要对Linux编译进行配置，开启必要的选项，比如要生成带调试符号的内核（或者ko模块），要开启CONFIG_FRAME_POINTER 如果没有开启，会导
在实际linux驱动开发过程中，解决设备树节点对应的驱动初始化依赖问题，使用component框架是比较常见 的方法，component框架核心是将存在依赖的驱动，拆分成“组件”， 由核心层统一管理初始化顺序， 确保被依赖组件，先完成初始化，再初始化依赖组件。
component框架通过“匹配” + “聚合”机制工作，其工作机制流程如下：
每个驱动模块都注册成一个“component”，并声明自己的匹配原则（比如非常常见的设备树compatible属性）。
所有匹配到的component会被聚合到一个“Master（
主要是描述一下linux驱动中，使用的设备树解析API，在实际使用中，设备树节点，翻译为platform_device的过程中，会主动翻译 我们常见的内容，部分客制化内容，需要我们手动进行翻译解析。 主要了解内容概述：
- 1.哪些资源自动解析，比如寄存器地址、中断、时钟、DMA等等。
- 2.非标准资源，怎么使用ofproperty 接口解析。
- 3.分清楚物理地址，虚拟地址，内核操作虚拟地址，如何将物理地址、硬件中断转化为虚拟地址、软中断号。
备注： Open Firmware 开源固件，体现到linux开发上，主要是设备树（Device Tree）机制。