基于MSP432与CC3120的嵌入式Wi-Fi通信实战：RTOS集成与系统设计-平芜编程栈

1. 项目概述与核心价值

最近在做一个基于TI MSP432的智能小车项目，核心需求是让小车能通过Wi-Fi实时上报传感器数据，并接收来自云端的控制指令。这听起来像是很多物联网（IoT）项目的标准配置，但真动手把Wi-Fi模块、实时操作系统（RTOS）和微控制器（MCU）这三者揉在一起，跑通一个稳定可靠的通信链路，里面门道可不少。我选用的硬件平台是TI的机器人系统学习套件（TI-RSLK），主控是MSP432P401R，Wi-Fi模块是CC3120。这套组合在TI的生态里非常经典，资料也多，但官方例程往往只展示了“如何点亮”，离“如何用好”还有一段距离。经过几周的折腾，从SPI通信调不通、RTOS任务卡死，到最终实现稳定的TCP长连接和数据收发，我积累了不少一线实战经验。这篇文章，我就来详细拆解基于MSP432与CC3120的Wi-Fi通信，并深入探讨如何引入RTOS来管理这种复杂应用。无论你是正在学习嵌入式网络通信的学生，还是面临类似产品开发的工程师，希望这些踩过的坑和总结的思路能让你少走弯路。

这个项目的核心，是解决嵌入式设备“最后一公里”的网络接入问题。Wi-Fi几乎是目前消费级和多数工业级物联网设备接入局域网和互联网的首选，因为它普及度高、带宽足、无需额外网关。但把Wi-Fi集成到资源有限的MCU上，挑战在于网络协议栈的复杂性和对实时响应的要求。CC3120这类模块的好处在于它内置了完整的TCP/IP协议栈和Wi-Fi驱动，相当于把复杂的网络处理任务从主MCU卸载了，主MCU只需要通过SPI总线给它发命令、收数据就行，大大降低了开发难度。而RTOS的引入，则是为了应对多任务管理：Wi-Fi连接管理、数据收发、传感器采集、逻辑控制、人机交互（比如LCD显示）这些任务需要并行且可靠地运行。没有RTOS，用裸机前后台系统也能做，但状态机将会异常复杂，且任何一个任务的阻塞都可能影响整个系统的实时性。因此，“MSP432 + CC3120 + RTOS”构成了一个非常典型的嵌入式Wi-Fi物联网节点解决方案，其设计思路和调试方法具有普适性。

2. 硬件平台与核心组件解析

2.1 MSP432P401R微控制器选型考量

为什么选择MSP432P401R作为主控？在项目初期，我也对比过其他ARM Cortex-M4内核的芯片。MSP432的核心优势在于其极低的运行和待机功耗，这对于电池供电的移动机器人或物联网传感节点至关重要。它拥有48MHz的主频、256KB的Flash和64KB的RAM，对于运行一个轻量级RTOS（如TI-RTOS或FreeRTOS）并处理中等复杂度的应用逻辑是足够的。更重要的是，TI为其提供了非常完善的软件生态，包括DriverLib硬件驱动库、Grace图形化配置工具（虽然新项目更推荐直接使用SDK），以及与我们项目强相关的SimpleLink MSP432 SDK。这个SDK已经深度集成了对CC3120等连接设备的支持，提供了从底层SPI驱动到上层Socket API的一整套软件框架，能极大加速开发进程。

在实际使用中，需要特别注意其外设资源的分配。CC3120通过SPI接口与MSP432通信，且对SPI的时序和速率有特定要求。MSP432有多个SPI模块（例如EUSCI_A和EUSCI_B系列），我们需要选择一个支持主模式、且时钟频率能满足CC3120要求的模块（CC3120最高支持20MHz SPI时钟）。通常，我们会使用EUSCI_B模块，因为它支持更灵活的时钟配置。在硬件连接上，除了SPI的四个标准信号线（CLK, SIMO, SOMI, CS），CC3120还需要一个中断信号线（HOST_IRQ）来异步通知MSP432有数据或事件需要处理，以及一个复位信号线（nRESET）。合理分配这些GPIO引脚，并确保它们在软件初始化时被正确配置，是硬件驱动层稳定的基础。

2.2 CC3120 Wi-Fi模块的关键特性与工作模式

CC3120是TI SimpleLink系列中的一款专用Wi-Fi网络处理器。把它理解为一个“黑盒子”可能更直观：盒子内部集成了完整的Wi-Fi射频前端、MAC、TCP/IP网络协议栈、TLS/SSL安全引擎，甚至还有一个轻量级的HTTP服务器。我们的MSP432作为主机（Host），只需要通过SPI这个“窗口”向盒子内部发送命令（例如“连接某个Wi-Fi网络”、“建立一个TCP连接”、“发送这些数据”），然后接收盒子的回应和数据即可。这种架构将复杂的、实时性要求高的射频处理和协议解析与主应用逻辑分离，主MCU得以解放出来专注于业务功能。

CC3120支持多种工作模式，我们需要根据应用场景选择：

Station (STA) 模式：这是最常用的模式。设备作为客户端，连接到现有的无线路由器（AP）。我们的智能小车项目就采用此模式，接入实验室或家庭的Wi-Fi，从而接入互联网。
Access Point (AP) 模式：模块自身作为一个热点，让其他设备（如手机）直接连接进来。适用于需要快速配网或点对点直连的场景。
P2P (Wi-Fi Direct) 模式：支持设备间直接通信，无需路由器。对于大多数物联网应用，STA模式是首选。CC3120在STA模式下，支持WPA2个人级和企业级安全认证，确保了连接的安全性。

模块的初始化流程需要严格遵循。它内部运行着一个独立的ARM Cortex-M3核心和专属的ROM、RAM，因此上电后需要主机通过SPI为其加载服务包（Service Pack）。这个服务包包含了固件补丁、网络协议栈的更新和新的功能特性。TI会不定期更新服务包，在开发时务必使用SDK中提供的最新版本，这能解决很多已知的稳定性和功能性问题。加载服务包是一个相对耗时的过程（可能几百毫秒），在软件设计中必须等待其完成，并且要正确处理加载过程中的SPI通信和可能出现的错误。

2.3 SPI通信接口的深度配置与调试

SPI是主机与CC3120之间唯一的命令和数据通道，其稳定性和效率直接决定了整个Wi-Fi通信的性能。CC3120的SPI接口工作在Motorola SPI模式0（CPOL=0， CPHA=0）或模式3（CPOL=1， CPHA=1）下，具体需参考数据手册。通常采用模式0。时钟极性（CPOL）和相位（CPHA）配置错误是导致通信完全失败的最常见原因之一。

在MSP432端配置SPI主设备时，有以下几个关键参数需要仔细设置：

时钟频率：CC3120支持最高20MHz。为了通信稳定，尤其是在布线不是非常理想的情况下，我通常会从较低频率开始，例如4MHz或8MHz，待通信稳定后再尝试提升。过高的频率可能导致信号完整性问题。
数据位宽：必须设置为8位。
字节序：通常为MSB（最高有效位）在前。
片选（CS）信号管理：CC3120要求片选信号在每次SPI传输（一个命令或数据块）期间保持低电平，在一次完整传输结束后拉高。必须使用GPIO手动控制CS引脚，而不是依赖SPI模块的自动片选功能，因为CC3120的协议帧格式决定了传输长度是变化的。

CC3120的SPI通信协议是面向数据包的，而不是简单的字节流。每个数据包都有一个固定的头部（Header），包含了数据包的类型（命令、数据、事件等）和长度信息。主机在发起任何操作前，必须先读取头部，解析出后续需要读取或写入的数据长度。这个“先读头部，再根据长度处理数据”的流程，是驱动层代码的核心逻辑。如果头部读取错误（比如SPI时序不对），后续所有操作都会乱套。

实操心得：SPI调试的“三板斧”
逻辑分析仪是必备工具：没有逻辑分析仪，调试SPI通信就像盲人摸象。我用的是Saleae Logic，它能清晰抓取CLK、MOSI、MISO、CS四条线上的波形，直观地显示出发送的每一个字节。当通信失败时，首先抓取上电后最初的几次SPI交互，对比CC3120数据手册中的初始化序列，检查每个字节是否正确。
从最简单的“读ID”命令开始：不要一上来就尝试连接Wi-Fi。CC3120有一个读取设备ID和芯片版本的基本命令。先实现这个命令的发送和响应解析，如果能正确读回预期的ID（例如0xDEADBEEF），就证明最底层的SPI物理层和链路层协议是正确的。
注意中断引脚（HOST_IRQ）：CC3120通过拉低HOST_IRQ引脚来通知主机有事件（如连接成功、收到数据、错误等）需要处理。主机端必须将此引脚配置为下降沿触发的外部中断。在中断服务程序（ISR）中，通常只设置一个标志位，然后在主循环或RTOS任务中查询这个标志位并进行详细的事件处理。避免在ISR中进行复杂的SPI通信。

3. 实时操作系统（RTOS）的引入与任务设计

3.1 为什么需要RTOS？

在裸机系统中，我们通常用一个主循环（while(1)）轮询各个模块的状态，并用中断处理紧急事件。当只有Wi-Fi通信时，这种模式或许还能应付。但我们的智能小车系统至少包含以下任务：读取红外传感器/编码器、控制电机PWM、刷新LCD显示、处理Wi-Fi连接与数据收发、解析云端指令、进行路径规划或避障决策。这些任务对实时性的要求不同（电机控制要求最高，Wi-Fi数据重传允许一定延迟），执行周期也不同。如果用轮询，很难保证高优先级任务得到及时响应；如果用中断嵌套，程序逻辑会变得极其复杂且难以维护。

RTOS通过提供任务（Task）、信号量（Semaphore）、消息队列（Queue）、事件标志组（Event Group）等机制，完美地解决了这些问题。每个任务可以看作一个独立的、无限循环的函数，拥有自己的栈空间和优先级。RTOS内核（Scheduler）负责根据优先级和调度策略（如抢占式调度）来决定哪个任务在何时运行。当一个任务等待某个资源（如等待Wi-Fi连接成功的事件）时，它可以主动让出CPU，让其他就绪的任务运行，从而高效利用CPU资源。

在本项目中，我选择使用FreeRTOS，因为它开源、免费、生态庞大，且TI的SimpleLink SDK对其有很好的集成支持。SDK中的网络驱动和Socket API本身就已经设计为在RTOS环境下工作，很多函数提供了阻塞（Blocking）和非阻塞（Non-blocking）两种模式，方便在任务中调用。

3.2 系统任务划分与优先级设计

合理的任务划分是系统稳定运行的基石。以下是我为智能小车设计的任务结构，优先级从高到低排列：

任务名称	优先级	主要功能	触发/唤醒方式	说明
Motor_Ctrl_Task	5 (最高)	读取编码器反馈，计算PID，更新电机PWM	定时器中断通过队列发送目标速度	运动控制要求最高的实时性，必须能抢占其他任务。
Sensor_Scan_Task	4	周期扫描红外传感器、超声波等	定时器事件或固定延时	获取环境信息，为避障和决策提供数据。
WiFi_EventHandler_Task	3	处理CC3120的中断，解析网络事件	CC3120的`HOST_IRQ`外部中断	负责底层的网络事件（连接、断开、收到数据等），并通知上层应用任务。
Data_Transmit_Task	2	打包传感器数据，通过Socket发送	消息队列（来自Sensor任务）或定时	将数据发送到云端服务器。
Command_Parse_Task	2	从Socket读取数据，解析云端指令	消息队列（来自WiFi Event任务）	解析指令，并通过队列发送给控制任务。
LCD_Display_Task	1 (最低)	刷新屏幕，显示状态、IP地址、数据等	固定延时或事件标志	人机交互，实时性要求最低。

设计思路解析：

高优先级给硬实时任务：电机控制直接关系到小车的平衡和运动精度，必须赋予最高优先级，确保任何情况下都能及时响应。
专设事件处理任务：将CC3120的中断处理与复杂的网络协议处理解耦。在HOST_IRQ的ISR中仅发送一个二值信号量（xSemaphoreGiveFromISR），WiFi_EventHandler_Task则等待这个信号量（xSemaphoreTake）。一旦等到，该任务就去读取CC3120的事件队列，并根据事件类型（如连接成功、收到TCP数据）向其他任务（如Data_Transmit_Task）发送消息队列。这种方式避免了在ISR中执行冗长的SPI操作，符合RTOS的最佳实践。
数据流与任务间通信：Sensor_Scan_Task将采集到的数据放入一个队列，Data_Transmit_Task从该队列取出数据并发送。Command_Parse_Task将解析后的控制指令放入另一个队列，Motor_Ctrl_Task从中读取。这种生产者-消费者模型通过队列实现，解耦了数据生产和消费的速率，且队列本身提供了安全的线程间通信机制。
低优先级任务不阻塞高优先级任务：LCD刷新等操作比较耗时，但又不紧急。将其设为最低优先级，保证了系统在高负载时，关键的网络和控制任务依然能获得CPU时间。

3.3 内存管理与栈空间分配

在RTOS中，每个任务都有自己的栈。栈溢出是RTOS系统中最隐蔽、最难调试的故障之一，它会导致内存损坏，引发各种看似毫无关联的随机错误（如任务卡死、信号量异常）。

栈大小估算经验：

Wi-Fi相关任务：由于SimpleLink SDK内部函数调用层次较深，且会处理网络数据包，WiFi_EventHandler_Task和Data_Transmit_Task需要较大的栈空间。我通常从1024字（对于32位系统是4096字节）开始。可以使用FreeRTOS提供的uxTaskGetStackHighWaterMark()函数在运行时监测任务栈的历史最小剩余空间，据此进行精确调整。
控制与传感器任务：逻辑相对简单，栈深度不大，256-512字通常足够。
LCD任务：如果使用了图形库，可能需要较大栈空间，需根据库的要求配置。

动态内存分配：FreeRTOS的队列、信号量等对象创建时默认使用动态内存（pvPortMalloc）。在资源紧张的MSP432（仅64KB RAM）上，必须谨慎。我强烈建议在项目开始时，就通过修改FreeRTOSConfig.h中的configTOTAL_HEAP_SIZE来定义一块固定大小的堆内存，并使用heap_4.c内存管理方案（它能够合并相邻空闲块，减少碎片）。然后，统计系统中所有创建的队列、任务、信号量等对内存的消耗，确保总需求小于堆大小。更好的做法是，对于生命周期贯穿整个应用的对象，尽量使用静态分配（xQueueCreateStatic），这样更可控。

4. SimpleLink SDK驱动集成与Wi-Fi连接实战

4.1 SDK架构与移植要点

TI SimpleLink SDK为MSP432+CC3120提供了分层清晰的软件架构：

驱动层（Driver）：最底层，直接操作SPI和GPIO硬件，实现与CC3120的物理通信。SDK已经提供了spi.c和gpio.c等驱动实现，我们通常只需要根据自己板子的引脚连接，修改platform.h或board.h中的引脚映射定义即可。
网络核心服务层（Networking Core Services）：这一层实现了与CC3120通信的协议，包括命令发送、��件处理、内存管理（sl_Common）等。它是SDK的核心，我们一般不需要修改。
Socket API层：提供标准的BSD Socket风格API，如sl_Socket(),sl_Connect(),sl_Send(),sl_Recv()等。这是我们应用程序主要交互的接口，使得网络编程与在PC上非常相似。
应用层（Application）：我们的用户代码就写在这一层，调用Socket API实现业务逻辑。

移植的关键步骤：

引脚配置：在platform.h中，正确定义SPI_MOSI,SPI_MISO,SPI_CLK,SPI_CS,HOST_IRQ,nRESET等引脚对应的MSP432 GPIO端口和引脚号。
SPI实例配置：指定使用哪个SPI模块（如EUSCI_B0_BASE），并配置时钟频率。确保与CC3120的硬件连接一致。
中断配置：将HOST_IRQ引脚对应的GPIO中断服务程序绑定到SDK提供的GPIO_IRQHandler函数上。
系统时钟与延时：实现SDK要求的sl_DeviceGetHwVersion()、sl_DeviceGetFamilyId()以及延时函数（_SlDrvDelay()）。这些函数通常需要根据MSP432的时钟系统来实现，确保延时准确。

4.2 Wi-Fi连接与Socket通信全流程

下面以一个典型的TCP客户端连接云服务器的流程为例，结合代码片段讲解：

// 1. 初始化SimpleLink驱动（必须在所有任务创建之前调用） int32_t ret = sl_Start(NULL, NULL, NULL); if (ret < 0) { // 处理错误：检查电源、SPI连接、服务包加载 printf(“[ERR] sl_Start failed: %ld\n”, ret); while(1); } // 2. 配置Wi-Fi为Station模式，并设置连接策略（快速连接或智能配置） SlWlanCfgBasic_t cfg = {0}; cfg.SsId = (signed char*)“Your_SSID”; cfg.Password = (signed char*)“Your_Password”; cfg.SsIdLen = strlen(“Your_SSID”); cfg.PasswordLen = strlen(“Your_Password”); cfg.SecurityType = SL_WLAN_SEC_TYPE_WPA_WPA2; // 根据你的路由器安全类型设置 ret = sl_WlanSetMode(ROLE_STA); ret |= sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_OPT_CONN_POLICY, 0, (uint8_t*)&cfg); // 注意：sl_WlanSet用于配置策略，实际连接由驱动自动管理。 // 3. 等待连接成功（在WiFi_EventHandler_Task中处理） // 该任务会等待来自CC3120中断的信号量，然后调用sl_WlanGetNetworkList等函数获取事件。 // 当检测到事件 `SL_WLAN_EVENT_CONNECT` 且状态为 `SL_WLAN_CONNECTED` 时，表示连接成功。 // 此时可以获取IP地址：sl_NetCfgGet(SL_IPV4_STA_P2P_CL_GET_INFO, ...); // 4. 创建Socket（在Data_Transmit_Task中） SlSockAddrIn_t serverAddr; int sock = sl_Socket(SL_AF_INET, SL_SOCK_STREAM, SL_IPPROTO_TCP); if (sock < 0) { /* 处理错误 */ } serverAddr.sin_family = SL_AF_INET; serverAddr.sin_port = sl_Htons(8080); // 服务器端口 serverAddr.sin_addr.s_addr = sl_Htonl(SL_IPV4_VAL(192,168,1,100)); // 服务器IP // 5. 连接服务器 ret = sl_Connect(sock, (SlSockAddr_t *)&serverAddr, sizeof(serverAddr)); if (ret < 0) { // 连接失败，检查网络、服务器状态、防火墙 sl_Close(sock); vTaskDelay(pdMS_TO_TICKS(5000)); // 延迟后重试 // 通常需要重连逻辑 } else { printf(“[INFO] Connected to server!\n”); } // 6. 发送数据 char txBuffer[128]; sprintf(txBuffer, “{\”sensor\”:\”temp\”,\”value\”:%.2f}”, readTemperature()); ret = sl_Send(sock, txBuffer, strlen(txBuffer), 0); if (ret < 0) { // 发送失败，可能是连接已断开 // 需要关闭socket，并触发重连流程 } // 7. 接收数据（在Command_Parse_Task中） char rxBuffer[256]; ret = sl_Recv(sock, rxBuffer, sizeof(rxBuffer)-1, 0); if (ret > 0) { rxBuffer[ret] = ‘\0’; // 解析rxBuffer中的JSON或自定义协议指令 // 将解析后的指令通过队列发送给Motor_Ctrl_Task } else if (ret == 0) { // 连接被对端正常关闭 } else { // 接收错误，处理断连 } // 8. 连接断开处理与重连机制 // 在sl_Recv或sl_Send返回错误，或WiFi事件任务收到断开事件时，需要关闭socket。 sl_Close(sock); // 然后进入重连循环，可以等待一段时间后，从步骤4重新开始。 // 重连逻辑应该放在一个独立的状态机中，避免阻塞其他任务。

关键点与避坑指南：

sl_Start的调用时机：必须在RTOS调度器启动（vTaskStartScheduler()）之前调用。因为SDK内部会初始化一些全局资源和中断，这些操作不适合在任务上下文进行。
连接策略：sl_WlanSet配置的是连接策略，真正的连接过程是由CC3120内部的网络处理器自动完成的。连接成功后，会通过SL_WLAN_EVENT_CONNECT事件通知主机。
阻塞与非阻塞Socket：sl_Connect,sl_Send,sl_Recv默认是阻塞的。在RTOS任务中，阻塞调用会导致任务挂起，等待操作完成，这通常是可接受的，因为它会让出CPU给其他任务。但需要设置合理的超时（通过sl_SetSockOpt设置SO_RCVTIMEO和SO_SNDTIMEO），防止因网络故障导致任务永久挂起。
错误处理：每一个Socket API调用后都必须检查返回值。负值表示错误，具体的错误码可以通过sl_Error宏获取。健全的错误处理（如关闭socket、延迟重试）是保证网络应用长期稳定运行的关键。

5. 系统集成调试与稳定性优化

5.1 联合调试方法与工具

当Wi-Fi、RTOS、控制逻辑集成在一起后，调试变得更具挑战性。以下是我常用的方法：

分段调试，逐层打通：
- 第一步：验证裸机SPI。在不启动RTOS的情况下，用最简单的while循环程序，测试能否通过SPI正确读取CC3120的ID。确保硬件连接和底层驱动无误。
- 第二步：验证RTOS基本功能。创建两个简单的任务，互相通过队列发送字符串并打印到串口。确保RTOS移植正确，任务调度和通信正常。
- 第三步：集成SimpleLink SDK。在RTOS启动前调用sl_Start，然后创建一个任务，尝试连接Wi-Fi并获取IP。此时先不进行传感器和控制。
- 第四步：逐步添加其他任务。先加数据发送任务，再加控制任务。每加一个，都充分测试。
利用串口打印日志：这是嵌入式调试的生命线。需要实现一个线程安全的printf函数（例如通过信号量保护串口发送资源），并在关键位置（任务入口/出口、函数调用前后、错误发生处）添加日志。日志内容应包括任务名、时间戳和关键变量值。
使用FreeRTOS的跟踪工具：
- uxTaskGetStackHighWaterMark：如前所述，用于优化栈大小。
- vTaskList和vTaskGetRunTimeStats：这两个函数可以将所有任务的状态、优先级、运行时间百分比等信息格式化为字符串，通过串口打印出来。这是分析系统负载、发现“饥饿”任务（永远得不到运行）的利器。启用它们需要在FreeRTOSConfig.h中配置configUSE_TRACE_FACILITY、configUSE_STATS_FORMATTING_FUNCTIONS和configGENERATE_RUN_TIME_STATS。
网络调试助手：在PC端使用网络调试助手（如NetAssist、SocketTool）创建一个TCP服务器，让设备连接并发送数据。这样可以清晰地看到设备发送的原始数据，并可以手动发送指令给设备，验证数据收发链路。

5.2 常见问题与稳定性陷阱

系统运行一段时间后死机或重启
- 可能原因1：栈溢出。这是最常见的原因。使用uxTaskGetStackHighWaterMark检查所有任务的栈使用情况，尤其是Wi-Fi和LCD任务。
- 可能原因2：堆内存耗尽或碎片化。如果动态创建了很多对象（如每次连接都创建新的Socket结构），可能导致内存不足。尽量使用静态分配，或确保对象被正确销毁。
- 可能原因3：中断服务程序（ISR）处理时间过长。特别是在HOST_IRQ的ISR中��了太多工作。务必遵循“快进快出”原则，只发信号量，复杂处理交给高优先级任务。
- 可能原因4：优先级反转。如果高优先级任务等待一个被低优先级任务占有的资源（如互斥锁），而该低优先级任务又被中优先级任务抢占，就会导致高优先级任务被无限期阻塞。合理使用互斥锁的优先级继承机制（在FreeRTOS中创建互斥锁时设置configUSE_MUTEXES和优先级继承属性）。
Wi-Fi频繁断开重连
- 可能原因1：信号强度弱。CC3120的sl_WlanGetNetworkList可以扫描并获取信号强度（RSSI）。确保设备处于路由器信号覆盖良好的位置。
- 可能原因2：路由器设置问题。有些路由器的“节能模式”或“无线隔离”功能可能导致连接不稳定。尝试关闭这些功能。
- 可能原因3：电源噪声。Wi-Fi模块在发射数据时电流会瞬间增大，如果电源电路滤波不好，可能导致电压跌落，引起模块复位或工作异常。确保电源引脚有足够容值的钽电容和陶瓷电容（如100uF + 0.1uF）进行去耦。
- 可能原因4：软件重连机制过于激进。网络短暂波动是正常的，如果一检测到断开就立刻重连，可能加重网络负担。建议加入指数退避的重连策略，例如第一次断开等1秒重连，第二次等2秒，第三次等4秒，最大间隔到60秒，连接成功后重置等待时间。
数据发送延迟大或吞吐量低
- 可能原因1：Socket发送缓冲区设置过小。可以通过sl_SetSockOpt调整SO_SNDBUF选项。
- 可能原因2：任务优先级设置不合理。如果数据发送任务的优先级太低，可能会被其他任务长时间阻塞。适当提高其优先级。
- 可能原因3：SPI时钟频率过低。在确保信号完整性的前提下，尝试提高SPI时钟频率（如到10MHz或16MHz），这是主机与CC3120之间的数据通道瓶颈。
- 可能原因4：频繁的小数据包发送。TCP协议有Nagle算法，可能会合并小包，但也可能增加延迟。对于实时性要求高的数据，可以考虑使用UDP协议，或者禁用Nagle算法（设置TCP_NODELAY选项）。

5.3 低功耗设计考虑

对于电池供电的小车，功耗至关重要。MSP432和CC3120都提供了丰富的低功耗特性。

MSP432：在RTOS的IDLE任务钩子函数（vApplicationIdleHook）中，可以调用PCM_gotoLPM0()等函数进入低功耗模式。当有任何中断（包括RTOS的系统节拍定时器中断）发生时，MCU会自动唤醒。
CC3120：支持多种低功耗策略（Policy）。例如，可以设置为在空闲一段时间后自动进入低功耗模式（SL_WLAN_LOW_POWER_POLICY）。当主机有数据要发送时，CC3120会自动唤醒。需要根据数据收发的频率来权衡功耗和响应速度。
系统级策略：当小车静止且无网络通信需求时，可以让Data_Transmit_Task和Command_Parse_Task挂起（等待一个长超时的信号量或事件），同时让MCU和Wi-Fi模块进入低功耗模式。当传感器检测到运动或定时器超时后，再唤醒整个系统进行数据上报。

经过以上从硬件选型、驱动开发、RTOS设计到系统调试的全流程实践，一个基于MSP432和CC3120的稳定、高效的Wi-Fi物联网节点就构建完成了。这套方案不仅适用于智能小车，稍加修改便可应用于智能家居设备、环境监测传感器、远程控制器等各种场景。核心在于理解SPI通信的可靠性是基石，RTOS的任务划分与通信是骨架，而SimpleLink SDK提供的Socket API则是让应用快速上层的血肉。最后，充分的测试和严谨的错误处理，是项目从“能跑”到“好用”的关键一跃。