Freertos学习笔记（一）-----FreeRTOS基本知识

RTOS “real time”（实时）指的是系统对外部事件能够在规定的、可预测的时间内作出响应。具体含义如下：

• 确定性（Determinism）：
  FreeRTOS强调事件响应的可预测性。无论系统有多少任务，关键操作（比如任务切换、中断处理）都能在已知的最坏情况下完成。这意味着开发者可以预估任务的最大响应延迟。
• 任务优先级与抢占：
  FreeRTOS支持任务优先级和抢占调度。高优先级任务可以在更低优先级任务运行时“打断”它们，确保对关键事件的及时响应。
• 响应时间：
  实时系统不是指“尽可能快”，而是“保证在规定时间内完成”。FreeRTOS允许你设置任务优先级和系统Tick周期，以满足你的应用对响应时间的要求。
• 中断延迟和任务切换时间：
  FreeRTOS内核设计关注中断延迟和任务切换时间的最小化，这使得在硬件产生中断时，系统能快速地完成处理。

相比较于裸机系统（Bare-metal system），RTOS（如FreeRTOS）能够更好地保证任务的实时响应，主要原因包括：

-任务优先级和调度机制
RTOS支持多任务并发运行，并为每个任务分配优先级。
高优先级任务可以抢占低优先级任务，确保关键任务及时响应。
裸机系统通常是顺序执行或者“超级循环”，无法保证高优先级任务能立即响应事件。

• 抢占式调度
  RTOS提供抢占式调度，任务一旦满足条件（如被中断唤醒），内核会立即切换到该任务。
  裸机系统中，任务切换完全依赖于代码结构和事件轮询，响应时间不可控。
  -可控的中断和延迟
  RTOS设计上最大限度地减少中断屏蔽时间和任务切换延迟，能精确预测最坏情况响应时间。
  裸机系统中，中断响应和处理容易被长时间运行的代码阻塞，延迟不可预测。
• 同步与通信机制
  RTOS内置信号量、消息队列等同步机制，保证任务间高效通信和资源互斥，避免死锁和响应失控。
  裸机系统通常依赖全局变量或简单标志，处理复杂同步场景容易出错。
• 任务独立性和模块化
  RTOS下每个任务独立，便于分工和维护，且不容易因单个任务失控影响整体系统实时性。
  裸机系统任务通常耦合在一起，某个环节出问题容易拖慢全局响应。

要将FreeRTOS应用到具备指纹识别和APP远程开锁功能的智能门锁中，可以按照以下步骤进行系统设计和实现：

1. 系统架构设计
   主要功能模块
   指纹识别模块
   无线通信模块（如Wi-Fi、蓝牙，用于APP远程操作）
   电机/继电器控制模块（驱动门锁）
   本地按键/显示模块（如键盘、OLED屏）
   电源管理与安全检测模块
   任务划分建议
   在FreeRTOS中，每个主要功能建议设计为独立的任务（Task）：

任务名称 功能描述 优先级建议
指纹识别任务 采集并处理指纹数据，判断是否解锁 高
无线通信任务 处理APP发来的开锁指令、状态同步 高/中
门锁控制任务 控制电机/继电器实现开锁、关锁 高
用户界面任务 处理本地按键、显示 中/低
安全检测与报警任务 监控非法操作、电池电量、异常报警 高
日志记录/数据管理任务 记录开锁记录，管理用户/指纹信息 低
2. FreeRTOS实际应用要点
任务调度
根据任务重要性合理分配优先级，确保指纹识别、远程指令处理等实时性高的任务优先执行。
使用消息队列（Queue）、信号量（Semaphore）等机制实现任务间通信与同步。
事件响应
指纹传感器中断触发时，用信号量唤醒指纹识别任务。
无线模块接收到APP指令时，发送消息到门锁控制任务。
资源管理
使用互斥锁（Mutex）保护共享资源（如SPI总线、Flash存储等）。
合理利用低功耗模式（如FreeRTOS tickless idle）延长电池寿命。
3. 示例任务分配（伪代码框架）
C
void FingerprintTask(void *params) {
for(;😉 {
WaitForFingerprintInterrupt();
if (MatchFingerprint()) {
xQueueSend(lockControlQueue, UNLOCK_CMD);
}
}
}

void AppRemoteTask(void *params) {
for(;😉 {
if (AppCommandReceived()) {
ParseAndSendCommandToLock();
}
}
}

void LockControlTask(void *params) {
for(;😉 {
if (xQueueReceive(lockControlQueue, &cmd, portMAX_DELAY)) {
if (cmd == UNLOCK_CMD) {
UnlockDoor();
}
// 处理其他命令
}
}
}
4. 特别注意事项
实时性：指纹识别和远程开锁响应需保证毫秒级响应，优先级需足够高。
安全性：保证通信加密、指纹和远程指令校验，防止非法操作。
可靠性：异常检测、掉电保护、日志记录，提升系统健壮性。
OTA升级：可考虑FreeRTOS下的安全固件升级机制。
5. 典型通信方式
APP通过Wi-Fi或蓝牙发送开锁指令到门锁主控MCU。
MCU通过FreeRTOS任务调度，接收指令、处理指纹比对、控制门锁动作。
总结：
利用FreeRTOS实现任务优先级管理、任务间通信、资源互斥等，可以显著提升智能门锁的实时性、可靠性和可维护性。开发中要关注关键任务优先级、通信安全、功耗优化等细节。

FreeRTOS 内核检测就绪任务并进行任务调度的核心机制如下：

1. 任务状态与就绪列表
   每个 FreeRTOS 任务都有状态：运行（Running）、就绪（Ready）、阻塞（Blocked）、挂起（Suspended）、删除（Deleted）。
   内核用多个“就绪列表（Ready List）”来管理所有处于就绪状态的任务。

每一个优先级对应一个就绪列表（链表或列表结构）。
处于就绪状态的任务会按照优先级加入对应的就绪列表。
2. 任务状态切换
当任务满足运行条件（如等待的事件发生、延时到期），会被从阻塞列表移到对应优先级的就绪列表。
如果任务因为等待事件或延时而暂停，则从就绪列表移到阻塞或延时列表。
3. 检测就绪任务的机制
FreeRTOS 用一个“优先级位图”快速标记哪些优先级上存在就绪任务。
这样可以高效地找到当前所有可运行任务中优先级最高的那一个。

例如，configMAX_PRIORITIES=8，则有8个优先级。
只要某优先级的就绪列表非空，对应位图就置位。
4. 内核调度入口
任务调度的入口通常有以下几种情况：

调用 taskYIELD() 主动让出CPU。
延时（vTaskDelay）、等待信号量等导致任务阻塞。
中断服务程序（ISR）中唤醒了高优先级任务。
系统时钟节拍（Tick）中断发生。
5. 调度器关键流程（核心函数）
vTaskSwitchContext()
这是FreeRTOS中任务切换的核心函数，主要做以下几步：

扫描优先级位图，从高到低找到第一个有任务的优先级。
取出该优先级就绪列表的第一个任务（轮转调度时可能轮换）。
设置 pxCurrentTCB 指针，指向新任务（TCB = Task Control Block，任务控制块）。
下次上下文切换时就恢复该任务的寄存器等上下文。
xTaskIncrementTick()
在每次系统Tick中断时调用：

更新延时任务，如果有任务延时到期，则重新放入就绪列表。
检查是否有更高优先级的任务就绪，如果有，则触发调度。
6. 上下文切换
在调度器决定切换任务后，会保存当前任务的CPU寄存器、堆栈等上下文，然后恢复新任务的上下文。
这个过程依赖于汇编实现的端口相关代码（port.c/portASM.S等）。
7. 调度算法
FreeRTOS 默认采用“优先级抢占式调度”。
优先级高的任务一旦就绪，立即调度运行。
同优先级任务采用时间片（Round Robin）轮换。
总结流程图
任务状态变化（如延时到期、中断唤醒）→
任务被放入对应优先级的就绪列表，并更新优先级位图 →
调度器通过优先级位图查找最高优先级就绪任务 →
pxCurrentTCB 指向该任务，完成上下文切换 →
新任务开始运行

Copilot said: 在FreeRTOS中，有以下几种常见情况会触发内核检查“哪些任务应当切换为就绪态”： — ### 1. 系统Tick中断（定时器中断） - 每当系统Tick（时钟节拍）中断发生时，内核会检查所有因延时（vTaskDelay、vTaskDelayUntil、vTaskSuspend等）或超时而处于阻塞态（Blocked）的任务。 - 如果有任务的延时到期，会将其从延时列表移到就绪列表，变为就绪态。 ### 2. 中断服务程序（ISR）事件 -
在FreeRTOS中，有以下几种常见情况会触发内核检查“哪些任务应当切换为就绪态”：

1. 系统Tick中断（定时器中断）
   每当系统Tick（时钟节拍）中断发生时，内核会检查所有因延时（vTaskDelay、vTaskDelayUntil、vTaskSuspend等）或超时而处于阻塞态（Blocked）的任务。
   如果有任务的延时到期，会将其从延时列表移到就绪列表，变为就绪态。
2. 中断服务程序（ISR）事件
   某些外部硬件事件（如串口接收、按键中断等）在ISR中通过给信号量、发送队列、通知任务等方式唤醒任务。
   被唤醒的任务会立即从阻塞态变为就绪态，通常优先级较高的任务会被立即调度。
3. 任务间同步或通信
   一个任务释放信号量（Semaphore）、互斥锁（Mutex）、向队列发送数据、发送任务通知等，这些操作可能唤醒正在等待这些资源的其他任务，使其进入就绪态。
   例如，Task A等待队列数据，Task B发送数据，Task A会被唤醒进入就绪态。
4. 任务主动让出CPU（taskYIELD）
   当前任务调用taskYIELD()，会触发一次调度，检查同优先级下是否有其他就绪任务（如时间片轮转）。
5. 任务被挂起/恢复（vTaskSuspend/vTaskResume）
   任务被挂起时从就绪态移出，被恢复时则重新进入就绪态。
6. 事件组（Event Group）等待事件
   任务等待事件组的某个事件位，当事件位在ISR或其他任务中被设置后，等待的任务会进入就绪态。
   总结
   只要有任务的阻塞条件被满足（如延时到期、获取到资源、中断触发、事件位被置位等），FreeRTOS内核就会将这些任务从阻塞队列移到就绪队列，变为就绪态。调度器会根据优先级和调度策略，决定是否立即切换到这些新就绪的任务上运行。

要掌握FreeRTOS，建议按照以下步骤系统性学习和实践：

1. 理论基础
   操作系统基础：学习任务、调度、中断、同步、临界区等基本概念。
   RTOS原理：了解什么是实时操作系统，RTOS特点及与裸机系统的区别。
2. 官方文档与资料
   FreeRTOS官方网站和文档：https://www.freertos.org/
   阅读“Getting Started”指南。
   学习API参考手册，理解每个函数的用法和参数。
   FreeRTOS书籍：
   推荐《Mastering the FreeRTOS™ Real Time Kernel》（官方免费电子书）。
   其他如《嵌入式实时操作系统FreeRTOS设计与实现》等。
3. 实践动手
   下载源码：从GitHub或官网下载FreeRTOS源码。
   移植与配置：在常见MCU（如STM32、ESP32、NXP等）上移植FreeRTOS，学会基本配置方法。
   实验例程：运行和理解FreeRTOS自带的演示工程（Demo），如任务切换、信号量、队列、定时器等。
4. 代码阅读与仿真
   阅读内核源码：重点关注tasks.c、queue.c、timers.c等核心模块。
   使用仿真器/调试器：结合硬件仿真工具（如Keil、IAR、J-Link、OpenOCD）调试FreeRTOS任务调度、断点跟踪、中断处理。
5. 深入学习
   高级特性掌握：如软件定时器、事件组、任务通知、内存管理等。
   调优和排查：学习如何分析任务堆栈溢出、优先级反转、死锁等问题。
   阅读社区和论坛：关注FreeRTOS社区、Stack Overflow、知乎等的高质量问答和经验分享。
6. 项目实战
   实际项目应用：用FreeRTOS做一个小型嵌入式项目（如智能灯、门锁、遥控器等）。
   持续总结：每做一个功能/模块，写总结笔记，整理经验教训。
7. 持续关注新版本和生态
   跟进FreeRTOS新版本特性和安全、网络等扩展库的学习。
   学习建议
   理论与实践结合，边学边做。
   多调试、多看源码，理解背后机制。
   善用官方论坛、GitHub Issue和社区资源，遇到问题及时查找资料。

=分割线=============

Q: xQueueReceive() 从列表中读取列表项，每一次就只读取 一个item 吗？ 那么queue在定义时候，就能清楚queue的item是什么类型？？？
A：是的，xQueueReceive() 每次只能从队列（queue）中取出一个队列项（item）。

你在调用时，会传入一个指向用于存放接收数据的缓冲区的指针，FreeRTOS会将下一个出队的item内容复制到这个缓冲区。
如果队列为空，xQueueReceive()可以选择阻塞一段时间，直到有数据到来或者超时。

在创建队列时（即调用 xQueueCreate() 时），就需要确定每个item的大小。

xQueueCreate() 的第二个参数就是每个队列项（item）的大小（以字节为单位），通常用 sizeof(类型) 来传递。例如：
C
xQueueHandle myQueue = xQueueCreate(10, sizeof(MyDataType));
这样，队列中的每个item都是 MyDataType 类型（或等同大小的结构体/数据）。
队列本身不关心 item 的具体类型，只关心大小。你必须保证发送（xQueueSend）和接收（xQueueReceive）时使用的类型一致，否则会出现数据解析错误。

xQueueReceive() ：从指定的queue读取item，并从queue里删除item

xQueuePeek() ：从指定的queue读取item，但不会从queue里删除item

而且queue 的lock机制是什么应用场景呢？

Q：freertos enter_critical()进入临界区是什么意思？？
Answer：在FreeRTOS中，enter_critical()（通常为taskENTER_CRITICAL()宏）进入临界区的意思是：
让接下来的代码片段在执行期间不会被中断打断，保证其原子性和数据一致性。这个代码片段是一段对共享资源（如全局变量、硬件寄存器等）进行操作的代码。如果多个任务或中断同时访问这些资源，容易发生数据竞争和不一致。
taskENTER_CRITICAL()的原理
其作用是暂时关闭CPU中断（通常是禁止中断），确保从调用点到taskEXIT_CRITICAL()之间的代码不会被任何中断服务程序打断。
这样就保证了这段代码的原子性和一致性，防止多任务/中断环境下的数据错误。

1. 数据类型与访问原子性
   如果全局变量的数据类型等于或小于MCU的总线/寄存器宽度（比如32位MCU上访问uint32_t、int32_t），单次读写通常是原子的，即读/写操作不会被拆分成多条指令，也不会被中断打断。
   例如：在32位MCU上对uint32_t类型变量的单次读写一般是原子的。
   如果变量类型大于MCU位宽（如uint64_t、结构体、数组），单次访问不是原子的，访问会被拆分成多条指令，这时就可能出现数据不一致。
2. 并发访问的情形
   即使是32位变量，若有多个任务或中断并发“读-改-写”（如a = a + 1），会先读，再算，再写，这个过程不是原子的，中间可能被打断，导致数据竞争和不一致。
   对所有涉及并发“读-改-写”操作的全局变量，都要加保护（如taskENTER_CRITICAL()或互斥锁）。
   只做单次原子读/写且没有并发“写”时，可不加保护。

除了全局变量和硬件寄存器，在FreeRTOS或任何多任务（多线程）并发环境下，还需要考虑以下资源的一致性和并发访问保护：

1. 动态分配的内存区
   比如堆（heap）空间：多个任务可能同时调用 malloc/free 或 pvPortMalloc/vPortFree，需要加锁保护，防止堆管理数据结构损坏。
2. 外设缓冲区或共享缓存
   例如：DMA缓冲区、环形缓冲区、通信协议帧缓存等。
   多个任务或中断可能读写同一个缓冲区，需保护。
3. 消息队列、信号量、事件组等RTOS内核对象的数据结构
   这些本身RTOS已实现保护，但如果你自己实现了类似结构，也要考虑并发一致性。
4. 文件系统与存储介质
   多任务同时访问文件、SD卡、EEPROM等，需要文件系统做同步保护，防止数据损坏。
5. 共享的通信接口
   如SPI、I2C、UART等总线：如果多个任务操作同一个外设（如同一I2C总线），需加互斥防止总线冲突。
6. 共享配置参数（如系统状态、配置表、标志位等）
   多任务可能会修改或读取同一组配置数据，必须保证一致性。
7. 计数器、统计信息、日志缓冲区
   例如：任务统计计数、错误计数、数据包计数等，需原子操作防止统计失真。
8. 自定义的全局状态机或协议状态变量
   比如多个任务协作管理某个业务状态，必须保证状态变迁原子性。
9. 外部总线或协议的控制结构体
   如CAN、Modbus、以太网等的协议控制块。
   总结
   所有被多个任务/中断并发访问且支持“读-改-写”操作的资源（无论变量、结构体还是硬件/内核对象），都必须考虑一致性和原子性保护。
   典型保护方式包括：临界区（关中断）、互斥锁（mutex）、信号量、专用同步API等。

中断优先级需要满足什么条件才可以调用Freertos 中的API 函数？

在FreeRTOS中，**只有优先级足够低的中断服务程序（ISR）**才可以安全地调用FreeRTOS的“FromISR” API函数（如xQueueSendFromISR()、xSemaphoreGiveFromISR()等）。
具体条件如下：

1. 中断优先级必须等于或低于 configMAX_SYSCALL_INTERRUPT_PRIORITY（数值上“更大”）
   FreeRTOS通过configMAX_SYSCALL_INTERRUPT_PRIORITY宏，限制了哪些中断可以安全调用FreeRTOS的API。
   只有中断优先级值 大于等于 configMAX_SYSCALL_INTERRUPT_PRIORITY 的中断，才可以调用FreeRTOS的API（注意：“优先级值”越大，实际优先级越低）。
   优先级值小于（更高优先级于）configMAX_SYSCALL_INTERRUPT_PRIORITY的中断，绝对不能调用任何FreeRTOS API！
2. 为什么？
   FreeRTOS的内核调度和临界保护依赖于中断优先级机制。
   高优先级中断（优先级值小）可以打断FreeRTOS的临界区，导致内核状态损坏。
   只有较低优先级（优先级值大，等于或大于 configMAX_SYSCALL_INTERRUPT_PRIORITY）的中断，才能被FreeRTOS禁用/管理，因此这些ISR可以安全操作FreeRTOS内核对象。
3. Cortex-M 系列设置举例
   NVIC中断优先级数值范围通常是 0（最高优先级）到 255（最低优先级）（实际位数由芯片实现决定，常见4位，优先级0~15）。
   比如：
   configMAX_SYSCALL_INTERRUPT_PRIORITY 设置为 5，则只有优先级值5、6、7、…15的中断，可以用FreeRTOS的FromISR API。
   优先级0~4的ISR不能调用任何FreeRTOS API。
4. 如何设置？
   在FreeRTOSConfig.h中定义：
   C
   #define configMAX_SYSCALL_INTERRUPT_PRIORITY (5 << (8 - __NVIC_PRIO_BITS))
   在中断初始化时设置合适的优先级：
   C
   HAL_NVIC_SetPriority(IRQn, 5, 0); // 5 >= configMAX_SYSCALL_INTERRUPT_PRIORITY
   总结
   中断服务函数内要调用FreeRTOS的API（尤其是FromISR系列），中断优先级必须等于或低于（数值上等于或更大于）configMAX_SYSCALL_INTERRUPT_PRIORITY。
   高优先级中断（数值小）绝不能调用任何FreeRTOS API！

taskENTER_CRITICAL() 仅能禁止（disable）优先级等于或低于 configMAX_SYSCALL_INTERRUPT_PRIORITY 的中断。
优先级高于（数值小于）这个门槛的中断不会被屏蔽，仍可打断临界区。
设计高优先级中断时，绝不能在这些ISR里调用任何FreeRTOS API，否则会破坏内核一致性！