企业官网建设流程全解析

1. 项目概述：为什么Arduino需要多任务处理？

如果你玩过一阵子Arduino，尤其是做过一些稍微复杂的项目，比如同时控制几个传感器、驱动电机、刷新显示屏，还要响应按键，那你大概率会遇到一个头疼的问题：代码写着写着就变成了一团乱麻。主循环loop()里塞满了各种delay()和状态判断，一个传感器卡住了，整个系统都得停下来等它。这感觉就像你一个人要同时接电话、回邮件、泡咖啡，结果哪件事都做不好，手忙脚乱。

这时候，多任务处理的概念就该登场了。简单说，就是让一个处理器核心“看起来”能同时做多件事。在资源丰富的电脑或手机上，这很常见。但在像Arduino UNO（基于ATmega328P，仅2KB RAM，32KB Flash）这样的微控制器上，实现真正的多任务一度被认为是“不可能”或“过于奢侈”的。然而，随着项目复杂度提升，我们确实需要一种更优雅的方式来组织代码，让不同功能模块（任务）独立运行、互不阻塞。

FreeRTOS正是为此而生的解决方案。它是一个迷你的、开源的实时操作系统内核，专门为微控制器设计。它提供了任务创建、调度、同步通信等核心机制，让你能在Arduino上以“任务”为单位编写程序。每个任务就像一个独立的小程序，拥有自己的执行流程和栈空间，由FreeRTOS内核负责在它们之间快速切换，营造出“并行”执行的假象。

所以，这个项目的核心价值在于：将你从单线程、阻塞式的编程泥潭中解放出来，用更清晰、更健壮、更易于维护的多任务架构来构建复杂的Arduino应用。无论你是想做一个能边跑边避障还能传数据的机器人，还是一个需要实时响应多种输入交互的智能装置，掌握FreeRTOS都将让你的开发能力提升一个维度。

2. FreeRTOS核心概念与Arduino适配解析

在动手写代码之前，我们必须先理解几个FreeRTOS的核心概念，以及它们是如何在资源受限的Arduino上工作的。这能帮你避开很多初学者的坑。

2.1 任务（Task）：你的代码执行单元

在FreeRTOS中，任务是最基本的执行单元。你可以把它理解为一个永不退出的函数。每个任务通常包含一个无限循环，在里面执行特定的功能。例如，一个任务专门读取温度传感器，另一个任务负责刷新OLED屏幕。

创建任务时，你需要告诉内核两件关键的事：

1. 任务函数：即任务具体要执行的代码。
2. 栈深度：这是为任务分配的私有内存空间，用于存储局部变量、函数调用地址等。这是在Arduino上使用FreeRTOS最需要精打细算的地方！ATmega328P总共才2KB RAM，每个任务都需要独立的栈。栈给小了，任务运行时会崩溃（栈溢出）；给大了，又浪费宝贵的内存，可能导致系统无法启动。

一个常见的经验值是，对于简单的任务（比如翻转一个LED灯），栈深度可以设为128字（注意，FreeRTOS中通常以“字”为单位，在8位AVR上1字=1字节，所以128字≈128字节）。对于稍复杂的任务（涉及字符串处理、浮点运算等），可能需要256字或更多。没有绝对标准，需要通过测试和监控来调整。

2.2 调度器（Scheduler）：大脑和指挥家

调度器是FreeRTOS内核的核心，它决定在任何给定的时刻，哪个任务可以占用CPU。Arduino上最常用的调度策略是抢占式调度。

抢占式意味着高优先级的任务可以打断（抢占）正在运行的低优先级任务。每个任务在创建时都会被赋予一个优先级（通常0为最低，数字越大优先级越高）。调度器永远让处于“就绪”状态的、优先级最高的任务运行。如果两个任务优先级相同，则采用时间片轮转调度，每个任务运行一个固定的时间片（如portTICK_PERIOD_MS定义的时间）后，切换到同优先级的另一个任务。

这种机制保证了关键任务（如紧急停止信号处理）能得到即时响应。但这也带来了新的挑战：资源共享问题。如果两个任务同时操作同一个全局变量或硬件外设（如串口），就会产生数据错乱。这就需要用到同步机制。

2.3 同步与通信机制：任务间的协作桥梁

FreeRTOS提供了丰富的工具来让任务安全地协作：

• 队列（Queue）：这是任务间传递数据最安全、最常用的方式。你可以把它想象成一个管道，任务A把数据“送”进管道，任务B从管道另一头“取”走数据。队列本身是线程安全的，内核会处理所有的互斥操作。非常适合用于传感器数据采集任务与数据处理任务之间的通信。
• 信号量（Semaphore）：主要用于同步和资源计数。二进制信号量常用于互斥锁（Mutex）功能，保护共享资源（如SPI总线）。当一个任务要使用SPI时，它先“获取”信号量，用完后“释放”。其他任务在获取前必须等待，这样就避免了冲突。
• 软件定时器（Software Timer）：允许你创建周期性的或一次性的定时回调，这些回调函数在守护任务（Timer Service Task）的上下文中执行。这比在loop里用millis()做非阻塞延时更清晰、更省心。

在Arduino环境中，这些机制尤为重要，因为很多硬件资源（如串口、I2C、SPI）是唯一的，必须被妥善管理。

2.4 Arduino上的FreeRTOS库：我们用什么？

最主流的选择是FreeRTOS库，你可以通过Arduino IDE的库管理器直接搜索安装。这个库已经为AVR架构（如UNO、Mega）做了很好的适配和封装。安装后，它会提供一系列熟悉的Arduino风格API，同时底层仍然是标准的FreeRTOS。

注意：安装FreeRTOS库后，你的程序入口将不再是setup()和loop()。setup()和loop()会被库内部实现为一个默认的、优先级为1的任务。通常，我们会在setup()里初始化硬件，然后创建自己的任务，之后loop()任务可能会被挂起或用于低优先级工作。更好的做法是，完全忽略loop()，将所有功能都在自己创建的任务中实现，这样架构更清晰。

3. 实战：从零构建一个多任务Arduino项目

理论说得再多，不如动手做一遍。我们来实现一个经典场景：一个任务以1秒间隔读取模拟温度传感器（如LM35），另一个任务以2秒间隔控制LED闪烁，同时，当温度超过阈值时，LED需要从常态闪烁变为快速报警闪烁。这里还需要一个任务来通过串口打印状态。我们将使用队列传递温度数据。

3.1 环境准备与任务设计

首先，在Arduino IDE中安装FreeRTOS库。然后，我们规划三个任务：

1. vTaskSensor：优先级2，每1000ms读取一次模拟引脚A0的电压值，转换为温度，并发送到队列。
2. vTaskLED：优先级1，常态下每2000ms翻转一次LED。它会从队列接收温度数据，如果温度超限，则切换至快速闪烁模式（每200ms翻转），持续5秒后恢复常态。
3. vTaskSerial：优先级1（与LED任务相同），每1500ms从队列中尝试读取温度数据并打印到串口，同时打印系统运行时间。

共享资源：

• 队列：一个用于传递整数类型温度数据的队列。
• LED引脚：数字引脚13（板载LED）。
• 串口：用于打印，需要确保打印操作不被其他任务打断，我们使用信号量保护。

3.2 代码实现与逐行解析

#include <Arduino_FreeRTOS.h> #include <queue.h> #include <semphr.h> // 定义引脚和参数 #define TEMP_SENSOR_PIN A0 #define LED_PIN 13 #define TEMP_THRESHOLD 30 // 温度阈值，单位可自定义（这里假设ADC值对应） #define QUEUE_LENGTH 5 // 队列长度 #define ITEM_SIZE sizeof(int) // 队列项大小（温度值，int类型） // 声明全局句柄 QueueHandle_t xTemperatureQueue; SemaphoreHandle_t xSerialSemaphore; // 任务函数原型 void vTaskSensor(void *pvParameters); void vTaskLED(void *pvParameters); void vTaskSerial(void *pvParameters); void setup() { // 初始化串口，用于调试 Serial.begin(9600); while (!Serial); // 等待串口连接，实际产品中可去掉 // 初始化硬件引脚 pinMode(LED_PIN, OUTPUT); pinMode(TEMP_SENSOR_PIN, INPUT); // 创建二进制信号量，用于保护串口打印（初始值为1，表示可用） xSerialSemaphore = xSemaphoreCreateBinary(); xSemaphoreGive(xSerialSemaphore); // 初始化时给出信号量 // 创建队列，用于传递温度数据（整数） xTemperatureQueue = xQueueCreate(QUEUE_LENGTH, ITEM_SIZE); if (xTemperatureQueue == NULL) { Serial.println("错误：队列创建失败！"); while(1); // 死循环，停止执行 } // 创建传感器任务 xTaskCreate( vTaskSensor, // 任务函数指针 "Sensor", // 任务名称（字符串，用于调试） 128, // 栈深度（字）。对于简单的ADC读取，128通常足够。 NULL, // 传递给任务函数的参数 2, // 优先级（2，较高，保证数据及时采集） NULL // 任务句柄指针（此处不需要） ); // 创建LED控制任务 xTaskCreate( vTaskLED, "LED Ctrl", 128, // 栈深度 NULL, 1, // 优先级（1，低于传感器任务） NULL ); // 创建串口打印任务 xTaskCreate( vTaskSerial, "Serial Out", 192, // 栈深度稍大，因为涉及字符串格式化 NULL, 1, // 优先级（1，与LED任务相同） NULL ); // 删除由Arduino框架创建的默认loop任务，以释放其占用的栈空间。 // 我们的所有功能都已由自定义任务实现。 vTaskDelete(NULL); } // Arduino的loop函数现在已无用，留空即可。 void loop() { // 此函数内不应写任何代码，任务调度已由FreeRTOS接管。 } // 任务1：读取传感器 void vTaskSensor(void *pvParameters) { (void) pvParameters; // 显式声明未使用参数，避免编译器警告 int iTemperatureRaw = 0; for (;;) { // 无限循环，等价于 while(1) // 1. 读取模拟值（这里简化处理，实际需根据传感器型号转换） iTemperatureRaw = analogRead(TEMP_SENSOR_PIN); // 2. 发送到队列。 // 参数：队列句柄，数据地址，等待时间（若队列满，等待10个时钟节拍） if (xQueueSend(xTemperatureQueue, &iTemperatureRaw, pdMS_TO_TICKS(10)) != pdPASS) { // 发送失败（队列满）。在实际项目中，这里可能需要记录错误或丢弃最旧数据。 // 获取信号量以安全使用串口（仅用于调试错误） if (xSemaphoreTake(xSerialSemaphore, portMAX_DELAY) == pdTRUE) { Serial.println("警告：温度队列已满，数据丢失！"); xSemaphoreGive(xSerialSemaphore); } } // 3. 任务延时，让出CPU控制权。使用FreeRTOS的延时函数。 // vTaskDelay() 的参数是“时钟节拍”数。pdMS_TO_TICKS是一个宏，将毫秒转换为节拍数。 // 注意：configTICK_RATE_HZ 在FreeRTOSConfig.h中定义（通常为1000Hz，即1ms一个节拍）。 vTaskDelay(pdMS_TO_TICKS(1000)); // 延时1000毫秒 } } // 任务2：控制LED void vTaskLED(void *pvParameters) { (void) pvParameters; int iReceivedTemp = 0; bool bAlarmMode = false; TickType_t xAlarmEndTime = 0; const TickType_t xAlarmDuration = pdMS_TO_TICKS(5000); // 报警持续5秒 const TickType_t xNormalInterval = pdMS_TO_TICKS(2000); const TickType_t xAlarmInterval = pdMS_TO_TICKS(200); TickType_t xLastToggleTime = xTaskGetTickCount(); TickType_t xCurrentInterval = xNormalInterval; for (;;) { // 1. 尝试从队列接收温度数据（非阻塞方式） if (xQueueReceive(xTemperatureQueue, &iReceivedTemp, 0) == pdPASS) { // 成功收到数据 if (iReceivedTemp > TEMP_THRESHOLD) { bAlarmMode = true; xAlarmEndTime = xTaskGetTickCount() + xAlarmDuration; xCurrentInterval = xAlarmInterval; // 立即切换一次LED状态，让响应更及时 digitalWrite(LED_PIN, !digitalRead(LED_PIN)); xLastToggleTime = xTaskGetTickCount(); // 重置计时 } } // 2. 检查报警模式是否应结束 if (bAlarmMode && (xTaskGetTickCount() >= xAlarmEndTime)) { bAlarmMode = false; xCurrentInterval = xNormalInterval; } // 3. 基于当前间隔时间，执行LED闪烁逻辑（非阻塞延时方式） if ((xTaskGetTickCount() - xLastToggleTime) >= xCurrentInterval) { digitalWrite(LED_PIN, !digitalRead(LED_PIN)); xLastToggleTime = xTaskGetTickCount(); } // 4. 短暂延时，让出CPU。即使使用非阻塞计时，也建议添加一个小延时，避免任务独占CPU。 vTaskDelay(pdMS_TO_TICKS(10)); } } // 任务3：串口打印 void vTaskSerial(void *pvParameters) { (void) pvParameters; int iReceivedTemp = 0; char cBuffer[50]; // 用于格式化的缓冲区 for (;;) { // 1. 尝试从队列接收数据 if (xQueueReceive(xTemperatureQueue, &iReceivedTemp, 0) == pdPASS) { // 2. 获取信号量，保护串口操作 if (xSemaphoreTake(xSerialSemaphore, pdMS_TO_TICKS(100)) == pdTRUE) { snprintf(cBuffer, sizeof(cBuffer), "时间: %lu ms, 温度ADC: %d", millis(), iReceivedTemp); Serial.println(cBuffer); xSemaphoreGive(xSerialSemaphore); // 释放信号量 } } else { // 队列为空，打印系统运行状态 if (xSemaphoreTake(xSerialSemaphore, pdMS_TO_TICKS(100)) == pdTRUE) { snprintf(cBuffer, sizeof(cBuffer), "时间: %lu ms, 状态: 运行中...", millis()); Serial.println(cBuffer); xSemaphoreGive(xSerialSemaphore); } } // 3. 任务延时 vTaskDelay(pdMS_TO_TICKS(1500)); } }

3.3 关键代码解析与避坑指南

1. vTaskDelete(NULL)：在setup()末尾，我们删除了调用vTaskDelete的任务自身，即Arduino创建的默认loop任务。这是一个释放内存的好习惯，因为我们已经用自定义任务完成了所有工作。如果不删除，这个空任务会白白占用128字节（默认值）的栈空间。

2. 队列操作与超时：

   • xQueueSend和xQueueReceive的第三个参数是“阻塞超时时间”。这里我们用了pdMS_TO_TICKS(10)和0。
   • 在发送任务中，我们设置了一个很小的超时（10ms）。如果队列满，任务会等待最多10ms，如果仍无法发送，则返回错误。这避免了任务因队列满而无限期阻塞，导致系统“卡死”。
   • 在接收任务中，我们使用了0，即非阻塞模式。立即返回，有数据就取，没有就跳过。这保证了任务不会因为等待数据而错过其他工作（如定时打印状态）。

3. 信号量保护串口：串口Serial是一个共享资源。如果多个任务同时调用Serial.print()，输出信息会交织在一起，难以阅读。我们创建了一个二进制信号量xSerialSemaphore作为互斥锁。任何任务在打印前必须先“获取”（Take）这个信号量，打印完后“释放”（Give）。这样确保了同一时刻只有一个任务能使用串口。

4. 非阻塞的LED闪烁逻辑：在vTaskLED中，我们没有用vTaskDelay来控制闪烁间隔，而是使用了基于xTaskGetTickCount()的时间戳比较。这是因为LED任务需要同时响应队列数据（温度报警）和定时闪烁。如果使用阻塞延时，在延时期间就无法处理新到来的温度数据，报警响应会有延迟。这是一种常见的“状态机”加“非阻塞计时”的设计模式，在实时系统中非常有用。

5. 栈深度估算：代码中为vTaskSerial任务分配了192字的栈，因为它内部使用了snprintf函数，这个函数在格式化字符串时可能需要较多的栈空间。如果栈分配不足，程序可能会运行不稳定或崩溃。调试栈溢出是FreeRTOS开发中的常见工作，你可以使用uxTaskGetStackHighWaterMark()函数来监控任务运行后剩余的最小栈空间，从而优化栈大小。

4. 高级技巧与深度优化

当你的项目越来越复杂，仅仅创建任务和队列可能不够。下面是一些进阶实践。

4.1 监控系统状态与调试

FreeRTOS提供了丰富的API用于运行时监控：

• uxTaskGetNumberOfTasks(): 获取当前任务数量。
• vTaskList(): 获取所有任务的详细状态列表（名称、状态、优先级、栈高水位线等）。注意：此函数会输出一个长字符串，非常消耗栈和内存，在Arduino UNO上使用需极其谨慎，最好仅在调试时启用，并为其分配足够大的缓冲区。
• 栈高水位线（Stack High Water Mark）：这是最重要的调试信息。它告诉你任务运行过程中，栈空间最多被使用了多少。用法如下：

  UBaseType_t uxHighWaterMark; uxHighWaterMark = uxTaskGetStackHighWaterMark(NULL); // NULL表示当前任务 // 将这个值打印出来。它越接近你创建任务时分配的栈深度，说明栈空间越紧张。 // 理想情况下，应该留有10%-20%的余量。

  我个人的习惯是在每个任务的循环末尾，周期性地打印高水位线（在项目稳定后关闭），从而精确地为每个任务分配合适的栈大小，避免内存浪费或溢出。

4.2 优化内存与性能配置

Arduino UNO的RAM是最大的瓶颈。你需要精细地调整FreeRTOSConfig.h文件中的配置（该文件通常在库的安装目录下，你也可以在项目文件夹中放一个副本进行覆盖）。关键配置项包括：

• configTOTAL_HEAP_SIZE：定义FreeRTOS动态内存堆的总大小。所有任务栈、队列、信号量等都从这里分配。对于ATmega328P，建议设置在1KB到1.5KB之间，需要为全局变量和程序栈留出空间。
• configMINIMAL_STACK_SIZE：定义空闲任务的最小栈深度。不要设得太小。
• configUSE_PREEMPTION：启用抢占式调度。
• configUSE_IDLE_HOOK：如果启用，你可以在空闲任务中放入低功耗代码（如SLEEP_MODE_IDLE），这在电池供电项目中非常有用。
• configUSE_MALLOC_FAILED_HOOK：启用内存分配失败钩子函数。一旦内存分配失败（如创建任务、队列时），会调用这个钩子函数，方便你及时发现内存耗尽问题。

一个重要的经验：修改配置后，如果编译通过但程序行为异常或无法启动，首先怀疑是堆大小configTOTAL_HEAP_SIZE设置过大，挤占了其他变量空间。可以尝试逐步调小这个值。

4.3 中断服务程序（ISR）与FreeRTOS API的协作

在Arduino中，硬件中断（如外部引脚中断、定时器中断）很常见。在FreeRTOS环境下，从中断服务程序（ISR）中调用FreeRTOS的API（如发送数据到队列、给出信号量）需要特别注意。

FreeRTOS提供了以FromISR结尾的API专供ISR中使用，例如xQueueSendFromISR、xSemaphoreGiveFromISR。绝对不要在ISR中使用普通的xQueueSend或vTaskDelay！

ISR应该尽可能短小精悍，只做最紧急的处理（如标记标志位、读取数据），然后通过FromISRAPI唤醒一个高优先级的任务去处理后续逻辑。这被称为“延迟处理”模式，是保持系统响应性的最佳实践。

例如，一个旋转编码器的中断服务程序：

void isrEncoder() { BaseType_t xHigherPriorityTaskWoken = pdFALSE; // 读取编码器状态... // 发送事件到队列（从ISR） xQueueSendFromISR(xEncoderQueue, &encoderEvent, &xHigherPriorityTaskWoken); // 如果需要，进行上下文切换 portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }

4.4 应对复杂场景：任务状态机与事件驱动

对于有复杂逻辑的任务（比如一个连接Wi-Fi、处理协议、控制硬件的任务），单纯的一个大循环会很难维护。这时可以将任务内部设计成一个状态机。

每个状态对应一个函数，任务主循环根据当前状态变量调用相应的状态处理函数。状态之间的转换由事件触发，事件可以来自队列（其他任务发送）、信号量（资源就绪）或定时器。

这种“事件驱动状态机”的架构，能让复杂任务的逻辑变得异常清晰，易于调试和扩展。例如，一个网络任务的状态可以是：IDLE,CONNECTING,WAITING_FOR_RESPONSE,PROCESSING_DATA,ERROR。每个状态处理完特定事件后，就切换到下一个状态。

5. 常见问题排查与实战心得

即使理解了原理，实际开发中还是会遇到各种问题。下面是我踩过的一些坑和解决方法。

5.1 系统启动失败或运行不稳定

• 症状：程序上传后，板子无反应，或运行一段时间后死机。
• 排查步骤：
  1. 检查栈溢出：这是头号杀手。使用uxTaskGetStackHighWaterMark检查所有任务的栈高水位线。如果某个任务的返回值非常小（比如小于20），说明栈深度严重不足，需要增加。
  2. 检查堆大小：在FreeRTOSConfig.h中减小configTOTAL_HEAP_SIZE。过大的堆会侵占其他全局变量或导致内存碎片，引发不可预知的崩溃。从1024（1KB）开始尝试，逐步调整。
  3. 检查中断冲突：FreeRTOS使用一个硬件定时器（通常是Timer1）作为系统时钟节拍源。确保你的代码没有复用或修改这个定时器。同时，避免在中断服务程序中执行耗时操作。
  4. 简化测试：注释掉所有自定义任务，只创建一个最简单的闪烁LED任务，看系统能否稳定运行。然后逐个添加任务和功能，定位问题模块。

5.2 队列或信号量操作失败

• 症状：xQueueSend经常返回errQUEUE_FULL，或者信号量无法正确同步。
• 解决方案：
  • 队列满：增加队列长度，或者提高数据消费者任务（接收方）的优先级，确保它能及时取走数据。也可以考虑在发送方实现“丢弃最旧数据”的策略（使用xQueueOverwrite函数，如果队列满则覆盖最旧项）。
  • 信号量死锁：最常见的原因是任务“获取”了信号量后，由于某种错误（如提前返回、遇到条件分支）没有“释放”。确保每个Take都有对应的Give，并且放在finally块或函数退出前。使用互斥量（Mutex）时更要小心，同一任务不能重复获取同一个互斥量。

5.3 任务优先级设置不当导致系统“卡死”

• 症状：低优先级任务永远得不到执行，或者高优先级任务独占CPU。
• 经验法则：
  • 事件触发型任务优先级应高：例如，响应外部中断、处理紧急警报的任务。
  • 计算密集型任务优先级应低：例如，复杂的数据滤波算法。如果它的优先级太高，会阻塞其他任务。
  • 同等优先级任务应合作：如果多个任务优先级相同，它们会分时运行。确保每个任务中都调用了vTaskDelay()或类似函数主动让出CPU，否则同优先级任务会独占CPU直到时间片用完（如果使能了时间片调度）。
  • 避免优先级反转：假设低优先级任务L持有一个互斥锁M，中优先级任务M正在运行，高优先级任务H需要锁M。此时H会被阻塞，等待L释放M。但L因为优先级低于M，永远无法被调度运行，从而H也永远等不到锁。解决方案：使用“优先级继承”互斥量。FreeRTOS的互斥量（xSemaphoreCreateMutex）默认支持优先级继承，当高优先级任务等待低优先级任务持有的互斥量时，内核会临时提升低优先级任务的优先级，使其能尽快运行并释放锁。

5.4 资源冲突与硬件外设管理

Arduino的硬件外设（UART, I2C, SPI）不是线程安全的。即使你在软件层面用信号量保护了Serial.print()，底层硬件缓冲区仍然可能被同时访问而损坏。

最佳实践是：为每个硬件外设创建一个专属的“驱动任务”。所有其他任务如果需要使用该外设，都通过队列向这个驱动任务发送请求（包含操作类型、数据、返回队列等）。驱动任务顺序地处理这些请求，一次只执行一个硬件操作。这彻底消除了资源冲突的可能性，虽然增加了一些通信开销，但带来了极高的稳定性和可维护性。对于SPI这类对时序敏感的总线，这种方法尤其有效。

最后，我想分享一个最深刻的体会：在Arduino上使用FreeRTOS，本质上是在极致的资源约束下进行软件架构设计。它迫使你思考每一个字节的RAM、每一个时钟周期。这个过程虽然充满挑战，但一旦你驾驭了它，就能构建出结构清晰、响应迅速、可靠性远超传统loop+delay模式的复杂嵌入式系统。从简单的多任务闪烁LED开始，逐步增加队列、信号量，再到状态机和事件驱动，每一步的实践都会让你对并发编程和实时系统有更扎实的理解。这不仅仅是让Arduino代码跑得更快，更是思维模式的升级。