1. 项目概述一份持续生长的嵌入式实战笔记如果你点开了这篇文章大概率和我一样正走在嵌入式开发这条“痛并快乐着”的路上。我是Xwave一个在嵌入式行业摸爬滚打了十多年的老码农。这个专栏不是什么教科书也不是速成指南它是我个人学习、项目踩坑、技术复盘的真实记录一个会“持续更新”的实战笔记库。我打算把这里当成一个技术沙盘从最基础的STM32点灯到复杂的Linux驱动、C框架设计再到FreeRTOS的内核剖析所有我重新梳理、实践验证过的知识点都会以最直白、最“接地气”的方式记录下来。嵌入式这个领域太广了广到让很多新手感到迷茫是该先学51单片机还是直接上STM32Linux和RTOS到底该选哪个C语言学到什么程度才能玩转C这些问题我都经历过。所以这份笔记的核心目标很明确构建一条清晰、可执行、有深度的嵌入式学习与实践路径。它不是碎片的博客而是一个有主线、有递进的知识体系。我会围绕嵌入式Linux应用/驱动开发和基于STM32的RTOS实时系统这两大核心支柱展开所有内容都源于我实际的项目需求和个人技术债的偿还。你可以把它看作一个资深同行的工作日志里面没有浮夸的理论只有实打实的代码、配置、调试过程和那些只有踩过坑才知道的“潜规则”。2. 学习路线与核心技能树拆解在开始记录具体的技术点之前我们必须先有一张地图。嵌入式开发不是学会某个芯片或某个操作系统就万事大吉了它是一个软硬件结合、对系统理解要求极高的领域。盲目学习只会事倍功半。基于我多年的招聘和团队培养经验我梳理了一条我认为比较合理的进阶路线并标注了每个阶段需要攻克的核心技能。2.1 初级阶段单片机与C语言筑基这个阶段的目标是建立对嵌入式系统最基础的感知——如何让一块芯片听你的话。不要好高骛远扎实是关键。核心平台选择STM32为什么是STM32而不是51或Arduino对于有志于从事工业级开发的同行来说STM32是一个完美的起点。它拥有现代ARM Cortex-M内核、丰富的外设ADC, DAC, TIM, I2C, SPI, CAN等、成熟的生态HAL库、LL库、丰富的第三方组件以及海量的社区资源。从STM32入手你学到的编程思维和调试方法可以直接迁移到更复杂的平台。我建议从一颗经典的STM32F103C8T6俗称“蓝桥杯”或“最小系统板”开始成本极低资料极多。核心语言C语言绝对核心嵌入式开发的灵魂是C语言。这个阶段你不仅要会语法更要理解其如何在资源受限的MCU上工作。重点包括指针与内存管理这是区分“学过C语言”和“会用C语言做嵌入式”的分水岭。必须彻底理解指针、数组、结构体、内存地址的概念搞懂栈Stack、堆Heap、静态区的区别。位操作直接操作寄存器是嵌入式编程的日常。熟练掌握与、或|、非~、异或^、左移、右移是基本功。模块化编程与头文件编写学会将不同功能如LED、按键、UART封装成独立的.c和.h文件理解头文件守卫#ifndef...#define...#endif的作用这是构建大型工程的基础。实操起点从“寄存器开发”到“库开发”我强烈建议学习路径是直接使用标准外设库Standard Peripheral Library或HAL库进行开发。虽然“寄存器开发”能让你更贴近硬件理解更深刻但对于初学者而言其陡峭的学习曲线和繁琐的细节极易劝退。库函数封装了底层操作让你能快速实现功能建立正向反馈。当你能熟练使用库函数点灯、调试串口、读取按键后再回头去研究库函数是如何操作寄存器的这时你的理解会深刻得多。使用STM32CubeMX工具进行图形化配置能让你直观地理解时钟树、引脚复用并快速生成初始化代码效率倍增。2.2 中级阶段RTOS与硬件抽象层当你能熟练完成裸机无操作系统下的多任务调度通常用状态机或前后台系统时你会很快遇到瓶颈复杂的任务管理、实时性要求、资源同步问题。这时引入一个实时操作系统RTOS就变得非常必要。核心系统FreeRTOS在众多RTOS中FreeRTOS因其完全免费、开源、小巧、可移植性极高而成为事实上的行业标准。学习FreeRTOS不仅仅是学习几个API关键是理解多任务线程并发的思想。任务创建与管理理解任务函数、任务栈、任务优先级的概念。学会创建、删除、挂起、恢复任务。任务间通信这是RTOS的核心难点。必须掌握队列Queue、信号量Semaphore、互斥量Mutex、事件标志组Event Groups的使用场景与区别。例如用队列传递数据用二值信号量做任务同步用互斥量保护共享资源如全局变量、外设。内存管理理解FreeRTOS的heap_1到heap_5几种内存分配策略的适用场景这对于系统稳定性和效率至关重要。调试技巧学会利用FreeRTOS提供的跟踪工具如uxTaskGetStackHighWaterMark()来检查任务栈溢出这是项目中最常见的崩溃原因之一。开发环境实战Keil 5与STM32CubeMX集成很多新手在配置开发环境上就卡住了。我的建议是使用Keil MDK-ARM作为IDE配合STM32CubeMX进行图形化配置和代码生成。安装确保安装的Keil 5支持ARM Cortex-M系列并安装对应芯片的Device Family PackDFP。CubeMX配置在CubeMX中选型芯片配置时钟通常使用外部晶振通过PLL倍频到系统主频如72MHz for F103配置所需外设如GPIO、USART。中间件配置在“Middleware”选项卡中选择“FREERTOS”并配置其参数如总堆大小configTOTAL_HEAP_SIZE、任务优先级数量等。堆大小设置是关键太小会内存不足太大浪费资源初期可以设置较大值如20KB进行测试。生成代码选择“Toolchain / IDE”为MDK-ARM V5生成代码。用Keil打开生成的工程你会发现FreeRTOS的源码和配置文件FreeRTOSConfig.h都已集成好可以直接在main.c的StartDefaultTask里开始编写你的应用任务了。注意FreeRTOS的配置文件FreeRTOSConfig.h是定制系统的核心。你需要根据项目需求调整里面的宏定义例如是否使用互斥量、递归互斥量、软件定时器以及设置系统时钟节拍频率configTICK_RATE_HZ通常为1000Hz即1ms一个tick。2.3 高级阶段嵌入式Linux与C进阶当你的产品需要复杂的网络协议、图形界面、文件系统或大量数据处理时单片机RTOS的架构可能就力不从心了。这时你需要踏入嵌入式Linux的世界。核心平台嵌入式Linux板子像树莓派Raspberry Pi、友善之臂FriendlyARM的NanoPi系列或者更工业化的飞凌嵌入式Forlinx、迅为iTOP的开发板都是很好的选择。它们通常搭载ARM Cortex-A系列处理器可以运行完整的Linux发行版。核心技能栈Linux系统基础这不是指在PC上使用Ubuntu而是指在嵌入式目标板上操作。必须熟练通过串口或SSH登录掌握基本的Shell命令ls,cd,cp,mv,ps,top,grep,find等理解Linux文件系统结构会编写简单的Shell脚本。C现代编程在Linux应用层C因其强大的抽象能力和丰富的库支持而被广泛使用。你需要超越C with Class的层面理解面向对象设计封装、继承、多态以及设计模式如单例、工厂、观察者在嵌入式资源管理中的应用。资源管理RAII资源获取即初始化思想利用智能指针std::unique_ptr,std::shared_ptr自动管理内存避免泄漏。标准模板库STL熟练使用vector,map,string等容器和算法但要注意在极端资源受限的场景下评估其开销。C11/14/17新特性auto关键字、lambda表达式、移动语义等能极大提升代码效率和可读性。开发环境与调试交叉编译工具链在x86的PC上编译出能在ARM板上运行的程序。你需要安装并配置好如arm-linux-gnueabihf-g这样的工具链。VSCode配置VSCode通过安装“C/C”扩展和配置c_cpp_properties.json、tasks.json、launch.json可以成为强大的Linux C开发IDE实现代码提示、远程编译和调试。NFS挂载这是提升开发效率的神器。将Ubuntu主机的一个目录通过NFS网络文件系统共享并在开发板上挂载这个目录。这样你在主机上编译好的程序直接在开发板上就能运行无需反复烧写。命令大致如下主机IP: 192.168.1.100# 在开发板上执行 mount -t nfs -o nolock 192.168.1.100:/home/xwave/nfs_root /mntGDB调试学会使用GDB进行远程调试gdbserver在板子上gdb-multiarch在主机上是定位复杂问题的终极手段。3. 核心实战场景深度解析理论说得再多不如一行代码。下面我选取几个最具代表性的实战场景拆解其中的技术细节和避坑指南。3.1 场景一基于STM32与FreeRTOS的多传感器数据采集系统假设我们要做一个环境监测节点需要同时采集温度、湿度、大气压力并通过串口上报且按键可以切换显示模式。系统设计思路任务划分这是RTOS设计的第一步。我们创建4个任务Sensor_Task负责周期性地如每2秒读取I2C接口的SHT30温湿度和SPI接口的BMP280气压传感器。UART_Tx_Task负责将采集到的数据打包成特定格式如JSON并通过串口发送出去。Key_Scan_Task负责扫描按键检测按下事件。Display_Task根据当前模式由按键切换在OLED屏上显示不同的数据视图。任务间通信设计Sensor_Task采集到数据后通过一个队列Queue发送给UART_Tx_Task和Display_Task。队列能保证数据在生产者和消费者之间安全传递。Key_Scan_Task检测到模式切换键后通过一个二值信号量Binary Semaphore或直接设置一个全局事件标志通知Display_Task更新显示模式。传感器数据作为一个结构体被多个任务访问因此当Display_Task读取时需要用互斥量Mutex进行保护防止在读取过程中被Sensor_Task写入而破坏数据一致性。关键代码片段与解析// 定义数据包结构体 typedef struct { float temperature; float humidity; float pressure; TickType_t timestamp; // 使用系统节拍计数作为时间戳 } SensorData_t; // 创建队列和互斥量 QueueHandle_t xSensorDataQueue; SemaphoreHandle_t xDataMutex; void vSensorTask(void *pvParameters) { SensorData_t data; while(1) { // 读取传感器需实现I2C/SPI底层驱动 data.temperature SHT30_ReadTemp(); data.humidity SHT30_ReadHumidity(); data.pressure BMP280_ReadPressure(); data.timestamp xTaskGetTickCount(); // 获取互斥量保护数据写入如果DisplayTask正在读 if(xSemaphoreTake(xDataMutex, portMAX_DELAY) pdTRUE) { latestSensorData data; // 更新全局变量 xSemaphoreGive(xDataMutex); } // 发送数据包到队列等待10ms如果队列满 if(xQueueSend(xSensorDataQueue, data, pdMS_TO_TICKS(10)) ! pdPASS) { // 处理发送失败可能是队列满可记录错误或丢弃数据 printf([Error] Sensor queue full!\n); } vTaskDelay(pdMS_TO_TICKS(2000)); // 阻塞2秒 } } void vUARTTxTask(void *pvParameters) { SensorData_t rxData; char txBuffer[128]; while(1) { // 从队列接收数据无限期等待 if(xQueueReceive(xSensorDataQueue, rxData, portMAX_DELAY) pdPASS) { // 格式化数据为JSON字符串 snprintf(txBuffer, sizeof(txBuffer), {\temp\:%.2f,\humi\:%.2f,\pres\:%.2f,\tick\:%lu}, rxData.temperature, rxData.humidity, rxData.pressure, rxData.timestamp); // 调用串口发送函数需实现 UART_SendString(txBuffer); } } }避坑指南队列深度xSensorDataQueue的深度需要合理设置。如果UART_Tx_Task处理速度慢比如串口波特率低而Sensor_Task生产数据快队列太浅会导致数据丢失。可以通过uxQueueMessagesWaiting()监控队列使用情况来调整。互斥量持有时间在vSensorTask中获取互斥量xDataMutex后应尽快完成对共享资源latestSensorData的更新并释放。绝对不要在持有互斥量时进行vTaskDelay或任何可能引起阻塞的操作否则会导致Display_Task长时间无法获取互斥量系统响应变慢甚至死锁。栈空间分配每个任务创建时都需要指定栈深度configMINIMAL_STACK_SIZE的倍数。UART_Tx_Task中使用了较大的局部数组txBuffer因此需要分配比默认值更大的栈空间否则会导致栈溢出引发难以追踪的随机错误。务必使用uxTaskGetStackHighWaterMark()函数定期检查每个任务的栈高水位线。3.2 场景二嵌入式Linux应用开发与NFS挂载调试现在我们转向Linux环境。目标是开发一个运行在开发板上的C数据采集服务该服务从GPIO或ADC读取数据并通过TCP Socket上传到服务器同时提供一个简单的命令行交互界面。开发环境搭建主机Ubuntu目标板ARM Linux安装交叉编译工具链sudo apt-get install gcc-arm-linux-gnueabihf g-arm-linux-gnueabihf配置VSCode安装扩展C/C, CMake Tools如果使用CMake。创建c_cpp_properties.json指定交叉编译器的路径和头文件包含路径{ configurations: [ { name: Linux-ARM, includePath: [ ${workspaceFolder}/**, /usr/arm-linux-gnueabihf/include/** // 工具链头文件路径 ], compilerPath: /usr/bin/arm-linux-gnueabihf-g, cStandard: c11, cppStandard: c17, intelliSenseMode: linux-gcc-arm } ], version: 4 }创建tasks.json定义编译任务使用交叉编译器。配置NFS服务在Ubuntu主机上# 1. 安装NFS服务器 sudo apt-get install nfs-kernel-server # 2. 创建共享目录并修改权限 mkdir ~/nfs_share chmod 777 ~/nfs_share # 3. 编辑配置文件 sudo vim /etc/exports # 在文件末尾添加允许开发板所在网段访问 /home/xwave/nfs_share *(rw,sync,no_subtree_check,no_root_squash) # 4. 重启服务 sudo systemctl restart nfs-kernel-server在开发板上挂载NFS# 假设主机IP是192.168.1.100 mkdir /mnt/nfs mount -t nfs -o nolock 192.168.1.100:/home/xwave/nfs_share /mnt/nfs # 可以添加到/etc/rc.local实现开机自动挂载现在你在主机~/nfs_share下编译好的ARM程序就可以在开发板的/mnt/nfs目录下直接运行了。C服务程序核心框架示例// DataCollector.h #include string #include vector #include memory #include thread #include atomic #include mutex class Sensor { public: virtual ~Sensor() default; virtual double read() 0; virtual std::string name() const 0; }; class DataCollector { public: DataCollector(const std::string serverIp, int port); ~DataCollector(); void addSensor(std::unique_ptrSensor sensor); void start(); // 启动采集和上传线程 void stop(); // 停止服务 private: void collectionLoop(); // 采集循环 void uploadLoop(); // 上传循环 bool connectToServer(); std::vectorstd::unique_ptrSensor sensors_; std::thread collectionThread_; std::thread uploadThread_; std::atomicbool running_{false}; std::mutex dataMutex_; // 保护待上传数据队列 std::vectordouble latestReadings_; // ... 网络连接相关成员 };关键点解析RAII与智能指针DataCollector通过std::unique_ptrSensor管理传感器对象当DataCollector析构时所有传感器会自动释放无需手动delete避免了内存泄漏。线程安全采集线程collectionLoop和上传线程uploadLoop会并发访问latestReadings_。使用std::mutex进行保护确保数据一致性。std::atomicbool用于安全地控制线程启停。面向接口编程Sensor是一个抽象基类。你可以派生出GpioSensor、AdcSensor、I2cSensor等具体类。DataCollector只依赖Sensor接口从而与具体传感器解耦程序扩展性极强。注意在嵌入式Linux中直接操作GPIO或ADC通常需要通过sysfs接口如/sys/class/gpio或编写内核驱动。应用层程序可以通过open、read、write、ioctl等系统调用与这些接口交互。在编写GpioSensor这类具体类时需要封装这些底层文件操作。3.3 场景三VSCode高效配置与调试技巧工欲善其事必先利其器。一个高效的开发环境能极大提升生产力。下面以配置一个STM32基于ARM GCC和Linux C的混合项目为例。项目结构MyEmbeddedProject/ ├── firmware/ # STM32固件代码 │ ├── Core/ │ ├── Drivers/ │ ├── Middlewares/FreeRTOS/ │ └── Makefile # 使用ARM GCC编译 ├── linux_app/ # Linux应用代码 │ ├── src/ │ ├── include/ │ └── CMakeLists.txt └── .vscode/ ├── c_cpp_properties.json ├── tasks.json └── launch.json (用于Linux远程调试)tasks.json配置多任务{ version: 2.0.0, tasks: [ { label: Build Firmware (STM32), type: shell, command: make, options: { cwd: ${workspaceFolder}/firmware }, group: { kind: build, isDefault: true }, problemMatcher: [$gcc] }, { label: Build Linux App, type: shell, command: cd ${workspaceFolder}/linux_app mkdir -p build cd build cmake -DCMAKE_TOOLCHAIN_FILE../toolchain-arm.cmake .. make, group: build }, { label: Clean All, type: shell, command: cd ${workspaceFolder}/firmware make clean cd ${workspaceFolder}/linux_app rm -rf build, group: build } ] }通过这个配置你可以在VSCode中按CtrlShiftB直接编译STM32固件或者从命令面板运行Tasks: Run Task选择编译Linux应用。launch.json配置远程调试Linux App{ version: 0.2.0, configurations: [ { name: (gdb) Remote Debug Linux App, type: cppdbg, request: launch, program: ${workspaceFolder}/linux_app/build/my_app, // 本地编译出的程序路径 args: [], stopAtEntry: false, cwd: ${workspaceFolder}, environment: [], externalConsole: false, MIMode: gdb, miDebuggerPath: /usr/bin/gdb-multiarch, // 主机上的gdb miDebuggerServerAddress: 192.168.1.50:2000, // 开发板IP和gdbserver端口 setupCommands: [ { description: 为 gdb 启用整齐打印, text: -enable-pretty-printing, ignoreFailures: true } ] } ] }调试流程在开发板上进入程序所在目录NFS挂载目录启动gdbservergdbserver :2000 ./my_app在VSCode中切换到调试视图选择“(gdb) Remote Debug Linux App”配置点击运行。VSCode的GDB会连接到开发板的gdbserver然后你就可以像调试本地程序一样设置断点、单步执行、查看变量了。这比单纯打印日志高效无数倍。4. 常见问题与深度排查指南在嵌入式开发中90%的时间都在调试。下面是我总结的一些高频问题及其排查思路附上“三板斧”排查法。4.1 STM32FreeRTOS 系统不稳定随机死机这是最令人头疼的问题之一。原因可能多种多样但排查有固定套路。排查步骤第一板斧检查栈溢出最常见原因现象系统运行一段时间后或执行某个特定操作后死机行为不可复现。工具FreeRTOS的uxTaskGetStackHighWaterMark()函数。这个函数返回任务自创建以来其栈空间剩余内存的历史最小值。值越小说明栈使用越接近溢出。操作在每个任务的循环中定期打印或记录其高水位线值。void vMyTask(void *pvParameters) { UBaseType_t uxHighWaterMark; while(1) { // ... 任务逻辑 ... uxHighWaterMark uxTaskGetStackHighWaterMark(NULL); // NULL表示当前任务 if(uxHighWaterMark 100) { // 设置一个安全阈值比如100字节 printf(WARNING: Task %s stack low, remaining: %lu\n, pcTaskGetName(NULL), uxHighWaterMark); } vTaskDelay(pdMS_TO_TICKS(1000)); } }解决如果发现某个任务的栈高水位线持续很低比如小于50字节在任务创建时增大其栈深度usStackDepth参数。第二板斧检查堆空间不足现象动态创建任务、队列、信号量失败或malloc/pvPortMalloc返回NULL。工具FreeRTOS的xPortGetFreeHeapSize()函数。操作在系统运行的不同阶段启动后、创建完所有对象后、运行一段时间后打印剩余堆大小。printf(Free heap size: %lu bytes\n, xPortGetFreeHeapSize());解决如果堆空间持续减少且不恢复可能存在内存泄漏。检查是否创建了对象但未删除。如果总空间不足在FreeRTOSConfig.h中增大configTOTAL_HEAP_SIZE。第三板斧检查中断与任务同步问题现象在中断服务程序ISR中使用了非中断安全的API或在任务中访问共享资源未加保护。规则在ISR中只能使用以FromISR结尾的FreeRTOS API如xQueueSendFromISR,xSemaphoreGiveFromISR。访问全局变量、外设寄存器等共享资源时如果它在中断和任务中都会被访问必须使用临界区taskENTER_CRITICAL()/taskEXIT_CRITICAL()或信号量进行保护。排查仔细审查所有ISR和可能被多任务/中断访问的全局数据区。4.2 嵌入式Linux程序运行时出现“Segmentation fault”段错误通常是由于非法内存访问引起的。排查命令与思路使用gdb定位在编译时一定要加上-g选项保留调试信息。# 在开发板上如果程序崩溃生成了core dump gdb ./my_app core # 进入gdb后输入 bt (backtrace) 查看崩溃时的调用栈 (gdb) bt如果没有core dump可以gdbserver附加运行在VSCode中触发崩溃查看调用栈。常见原因空指针解引用最常见的错误。指针在使用前未初始化或已被释放。数组越界访问访问了超出数组声明大小的元素。栈溢出函数内定义了过大的局部数组或递归函数没有终止条件。使用已释放的内存delete或free后再次使用指针。多线程数据竞争多个线程同时读写同一内存区域未加锁导致数据混乱进而可能引发非法访问。预防与调试工具智能指针在C中使用std::unique_ptr和std::shared_ptr替代裸指针可以很大程度上避免内存泄漏和重复释放。静态分析工具如cppcheck可以在编译前检查出一些潜在问题。动态分析工具如Valgrind需在x86模拟或性能足够的ARM板上运行可以检测内存泄漏、非法读写等问题。valgrind --leak-checkfull ./my_app4.3 NFS挂载失败或访问缓慢问题表现在开发板上执行mount命令失败或挂载成功后在NFS目录下执行ls、运行程序等操作异常缓慢甚至卡住。排查与解决检查网络与防火墙确保主机和开发板在同一局域网能互相ping通。检查主机防火墙是否关闭或放行了NFS服务端口2049sudo ufw disable # 临时关闭Ubuntu防火墙生产环境慎用 # 或放行 sudo ufw allow from 192.168.1.0/24 to any port nfs检查NFS服务器配置确认/etc/exports文件配置正确特别是IP地址和权限部分。*(rw,sync,no_subtree_check,no_root_squash)中的*表示允许所有IP在内网开发中可以但生产环境应指定具体IP段。修改配置后必须重载服务sudo exportfs -ra # 重新导出所有目录 sudo systemctl restart nfs-kernel-server检查挂载参数-o nolock参数在大多数情况下是必须的用于禁用文件锁避免因锁服务问题导致的挂载失败或卡顿。如果版本不兼容可以尝试指定NFS版本如-o nfsvers3mount -t nfs -o nolock,nfsvers3 192.168.1.100:/home/xwave/nfs_share /mnt/nfs性能问题如果NFS操作异常慢可能是网络问题或服务器负载高。可以尝试使用-o soft参数允许在超时后返回错误而不是无限重试但这会降低数据一致性可靠性仅用于调试。mount -t nfs -o nolock,soft,timeo5 192.168.1.100:/home/xwave/nfs_share /mnt/nfs5. 进阶思考从应用到驱动从MCU到SoC当你熟练掌握了应用层开发后好奇心会驱使你向下探索。为什么open(“/dev/ttyS0”)就能操作串口GPIO的sysfs接口背后发生了什么这时你需要了解Linux驱动开发的基本模型。字符设备驱动框架浅析 一个最简单的字符设备驱动需要实现以下步骤分配设备号使用alloc_chrdev_region动态分配或register_chrdev_region静态注册一个主设备号。初始化cdev结构体cdev_init(my_cdev, my_fops);其中my_fops是file_operations结构体里面填充了驱动提供给应用层的函数指针如open,read,write,ioctl,release等。添加cdev到系统cdev_add(my_cdev, devno, count);。创建设备节点在/dev/目录下通过class_create和device_create自动创建设备文件节点如/dev/mydevice。应用层调用open(“/dev/mydevice”)时内核会根据设备号找到对应的cdev和file_operations然后调用你驱动里实现的.open函数。你在这个函数里可以初始化硬件、申请资源。随后的read,write等操作最终都会落到你实现的对应函数中在这些函数里你通过ioremap访问物理地址或者通过Linux内核提供的GPIO、I2C等子系统API来操作具体的硬件寄存器。这扇门后的世界非常复杂但也极其精彩。它让你真正理解“软硬件如何协同工作”。我建议的学习路径是先看懂一个简单的虚拟设备如mem内存设备的驱动源码然后尝试为一个已有的简单硬件比如一个LED编写驱动最后再挑战更复杂的设备。这份笔记的更新也会逐渐向这个深度迈进。记录的过程也是我重新梳理和巩固的过程。嵌入式开发没有终点每一个项目都是新的挑战每一个问题的解决都是经验的积累。希望我的这些笔记能成为你探索路上的一块垫脚石少走一些我当年走过的弯路。如果在实践过程中遇到任何问题欢迎在讨论区留言我们一起拆解共同进步。