把行情监控塞进一颗MCU里头这事儿听起来有点拧巴——股票数据不都是Python脚本、云端API、树莓派干的活儿吗但偏偏有人就想在桌面上放这么一个小盒子不依赖电脑开机就能看几只看好的股票价格突破了阈值还能亮灯提醒。PIC32能不能干这事能但“能”和“好”之间隔着一大堆看不见的坑。这篇文章就把我实测下来从硬件选型、网络协议栈、HTTP请求到行情解析的完整方案写出来顺带把那些只有踩过才知道的坑一并交代清楚。1. 项目整体规划一颗MCU如何接管行情监控先说结论PIC32做实时股票监控是可行的而且做出来之后的使用体验比想象中要好得多。这里的“实时”要解释清楚它跟我们平时说的金融级毫秒级实时是完全两码事。个人场景下3到15秒刷新一次报价、价格突破阈值后一两秒内触发提示这就是完全够用的“实时”。过度纠结刷新速度反而会让自己陷入API限流和网络波动的泥潭。1.1 核心需求拆解动手之前先梳理需求不能上来就想着一口气全做。一个完整的PIC32行情监控设备按优先级拆解是这样的定时从免费行情API拉取报价快照关注最新价、涨跌幅、开盘价、成交量这几个核心字段。将解析结果输出到本地显示设备OLED、LCD都可以至少能看到价格和当日涨跌方向。设定价格上下阈值突破后触发本地告警LED闪一下就够后续可以扩展蜂鸣器。长时间无人值守运行不能因为网络抖动、API返回异常把自己搞死所以必须上状态机和看门狗。支持多只股票轮询比方说持仓里5只股每只都按顺序刷一遍。把需求写清楚之后就会发现这个项目的技术难点不在PIC32本身而在外部链路如何稳定地拿到数据、如何在有限内存里解析数据、如何在网络层不可控的情况下保持系统长期运行。这些恰恰是做嵌入式联网应用最值钱的经验。1.2 为什么不是Python脚本、不是树莓派做这个项目之前我大概率已经有一台跑着Python脚本的PC或者是树莓派为什么还要折腾PIC32这里头有非常实际的理由。先说PC方案。PC上写个Python脚本用requests拉一下API再用matplotlib画个图一个下午就能搞定。但PC的问题是它不可能为这个屏保级需求保持24小时开机而且真正的桌面使用场景里我不可能为了瞥一眼股票价格去碰鼠标唤醒屏幕。这个监控设备的定位是“独立仪表盘”它得自己长在桌子上永远亮着随时可看。再说树莓派。树莓派确实是干这个的常见方案Python生态齐全代码写起来飞快。但树莓派的劣势也很明显它本质上是一个吃SD卡的Linux小主机开机慢、要处理系统更新、断电有SD卡损坏风险而且整个设备功耗在5W左右为了显示几只股票的价格这个代价有点大。PIC32方案可以把整机功耗压到1W以内上电即启动没有操作系统层面的任何干扰跟一个电子表一样纯粹。对硬件爱好者来说给PIC32配对网络协议栈、调通API、写出一个没有操作系统的HTTP客户端这个过程本身就是做嵌入式软件最有价值的工作。2. 硬件选型与网络链路搭建2.1 选哪颗PIC32PIC32家族听起来挺大实际上在这个项目里可选的就几颗。PIC32MX系列、PIC32MZ系列、PIC32MZ DA系列它们的差异集中在主频、内存容量和图形外设上。我做这个项目用的第一块板子是PIC32MX795F512L这是Microchip以太网Starter Kit上的经典芯片主频80MHzFlash 512KBRAM 128KB内部集成10/100M以太网MAC。为什么这颗是首选因为它带以太网MAC只需要外接一颗PHY芯片比如LAN8720和RJ45座子就能实现有线联网。128KB的RAM对嵌入式场景来说已经相当充裕跑一个精简的HTTP客户端绰绰有余。如果你的目标是点亮一块屏幕而且想做得更有质感可以直接上PIC32MZ DA系列它继承了MZ的200MHz主频和高达32MB的外部DDR2控制器还集成了图形处理单元可以轻松驱动4.3寸甚至7寸的LCD屏做出来的就是完整的产品级UI。代价是BOM成本和PCB复杂度上升对初学者不太友好。如果预算紧张退一步用PIC32MX270F256B也行这颗片子1美元出头但没有以太网MAC只能走UART接串口WiFi模块。我建议没有特殊原因不要这么从低配开始因为后面你会发现调试的精力都花在通信链路上而不是业务逻辑上付出远大于省下的几块钱。2.2 联网方案以太网直连和串口WiFi怎么选PIC32联网有两条路以太网直连以及串口WiFi让模块代理所有网络数据。两条路我都走过结论非常明确如果你想真正学会用MCU做应用层开发以太网直连这条路更值得走如果你只想快速出结果串口WiFi更省心。以太网直连的链路是PIC32内部MAC 外部PHY TCP/IP协议栈。PIC32内部MAC负责以太网帧的收发TCP/IP协议栈跑在CPU上也就是说协议栈那部分CPU负载是逃不掉的。好处是一切透明你可以在代码里看到每一层发生了什么。坏处是一旦涉及到HTTPS你会发现内置协议栈对TLS的支持是硬伤这个问题在下文会专门讲。串口WiFi方案用的是ESP8266或者ESP32模块刷上AT固件之后PIC32只需要通过UART向模块发送AT指令设置好要访问的URL模块就自己去完成TCP连接、TLS握手、HTTP请求然后把收到的响应原样丢回串口。这个方案把最复杂的网络细节全部外包给了模块PIC32的代码量能砍掉一半内存压力也小得多。而且ESP8266模块自带TLS实现直接绕过PIC32做TLS的麻烦。我的建议是第一条路用来学习第二条路用来交付。如果这个项目要做成产品送人直接用串口WiFi方案省心如果是为了自己掌握网络栈原理那就好好折腾一遍以太网直连方案做完之后你对TCP/IP的理解会上升一整个台阶。3. 软件架构与实时性设计从HTTP请求到行情解析3.1 协议栈选择Harmony 3还是MLAPIC32的软件框架主要就两个选择老版的MLAMicrochip Libraries for Applications和现在主推的Harmony 3。新项目无脑选Harmony 3理由很直接MLA已经停止积极更新而Harmony 3是模块化配置架构用MCCMPLAB Code Configurator图形化配置外设和中间件生成代码之后再做少量业务逻辑填充即可。Harmony 3里做HTTP客户端需要添加这些核心模块TCP/IP Stack协议栈本体配置堆内存池、最大Socket数、收发Buffer大小。HTTP Client基于Socket的上层客户端负责构造请求、解析响应状态行和头部。平台驱动以太网PHY驱动、UART/SPI/I2C驱动按你选的显示和外设来。FreeRTOS可选裸机状态机也能做但如果你熟悉RTOS用FreeRTOS跑任务更省心。配置时有一个非常关键的参数接收Buffer大小。默认情况下TCP/IP Stack分配的是2KB左右这个值对HTTP响应来说完全不够。一次正常的Alpha Vantage返回JSON体积通常在4KB到8KB之间buffer太小会导致数据被截断。建议直接把buffer加大到16KB这在PIC32MX795上要占不少RAM但换来的是整个解析过程可以不依赖流式处理一次收完再解析代码简单得多。确保你有足够心理准备16KB的RAM在128KB总RAM中占比不低后续其他模块要精打细算。3.2 用字符串定位代替JSON库轻量解析实战如果这一步你直接说“那我移植个cJSON”我会立刻喊停。不是说cJSON不好而是在这个具体场景里它带来了完全不必要的复杂性。行情接口返回的是一个扁平JSON对象字段名是固定的没有复杂的嵌套数组。例如Alpha Vantage的GLOBAL_QUOTE接口返回结构里最核心的内容就是一个Global Quote对象里面是01. symbol、02. open、03. high、05. price这些带编号的字段。对付这种结构根本不需要构建一棵完整的JSON树用字符串定位就够了。具体做法是三步走在响应缓冲区里用strstr找到目标字段名比如05. price。从字段名尾部向右扫描跳过冒号和空白字符。如果是字符串值就读取引号内部内容如果是数字就直接用strtod或strtol转数值。下面是核心解析函数的示例/** * 在response中查找target字段并提取字符串值到output。 * 返回找到的值长度未找到返回-1。 */ static int extract_json_string(const char *response, const char *target, char *output, int output_size) { const char *pos strstr(response, target); const char *value_start, *value_end; int len; if (pos NULL) { return -1; } // 跳过字段名寻找冒号后面的第一个非空白字符 pos strlen(target); while (*pos ! \0 *pos ! :) { pos; } pos; while (*pos || *pos \t || *pos \r || *pos \n) { pos; } // 期望的是以双引号包裹的字符串 if (*pos ! ) { return -1; } pos; value_start pos; value_end strchr(pos, ); if (value_end NULL) { return -1; } len value_end - value_start; if (len output_size) { len output_size - 1; } memcpy(output, value_start, len); output[len] \0; return len; }这个函数看着简单但已经考虑了几个必须注意的边界情况字段不存在、冒号后是null、字符串没有终止引号。跑了个月之后我踩过最大的坑就是返回内容里出现null值比如停盘的股票某些字段就是null这会导致直接解引用崩溃。上面的代码里先判断是否以引号开头对null直接返回-1这个防御是必须的。多字段提取可以做一个字段映射表一次循环全部解析出来typedef struct { const char *json_key; char *output; int output_size; } key_map_t; const key_map_t fields[] { {\01. symbol\, symbol, sizeof(symbol)}, {\05. price\, price, sizeof(price)}, {\09. change\, change, sizeof(change)}, {\10. change percent\, change_pct, sizeof(change_pct)}, {\06. volume\, volume, sizeof(volume)}, };循环执行后所有字段都进入对应的输出缓冲后续再统一转成数值或整型做判断。这种做法的内存开销只有输出缓冲区本身的大小不涉及任何堆上动态分配长期跑不会有碎片问题。3.3 状态机调度让刷新任务不卡死系统MCU上拉取网络数据最怕的就是阻塞。如果代码在send或者recv那里死等整个系统就僵住了按键失灵、显示冻结、看门狗如果没在合适的地方喂狗还会复位。所以整个HTTP事务必须跑在一个状态机里任何一个状态都有超时出口。我的状态机设计如下STATE_IDLE空闲间隔计时到了就进入下一个状态。STATE_TCP_CONNECT调用TCP_SocketConnect建立连接等待连接事件。STATE_SEND_REQUEST发送HTTP请求头。STATE_RECV_RESPONSE循环接收数据直到收到Content-Length指定的字节数或者碰到Connection: close后服务器关闭。STATE_CLOSE关闭socket释放资源。STATE_PARSE_DISPLAY对缓冲区里的完整响应做解析刷新显示回到空闲状态。每个状态都带自己的超时时间。例如TCP连接最多等3秒接收阶段如果5秒没有新数据到达就强制关闭socket等待下一轮。整体最坏情况是一轮刷新最多花掉8秒不会卡死。喂狗的位置要特别注意。不要在接收循环内部喂狗因为如果网络栈因为异常情况陷入半死状态边收数据边喂狗会让看门狗认为系统还活着实际上任务已经完全没进展了。正确的做法是在每个状态机的状态切换点喂狗也就是说只有状态确实前进了才喂狗。这样一旦网络卡死状态机会在超时分支里走不下去看门狗就会在几秒后复位整个系统保证设备不会被一个坏的请求拖死。4. 核心代码实现与关键参数调优4.1 构造HTTP请求的细节行情API的请求不复杂但每个细节都不能错。以Alpha Vantage的GLOBAL_QUOTE接口为例一个完整请求头是这样的const char http_request[] GET /query?functionGLOBAL_QUOTEsymbolAAPLapikeyYOUR_KEY HTTP/1.1\r\n Host: www.alphavantage.co\r\n User-Agent: PIC32RM/1.0\r\n Connection: close\r\n \r\n;几个容易被忽略的点Host字段是必须的Connection: close意味着服务器在处理完请求之后主动关闭TCP连接这样我可以通过判断连接关闭来确认响应已经完整接收。User-Agent字段有些API网关会校验最好设置一个明确的标识。不同的API提供方放API Key的方式不一样。Alpha Vantage是放进URL查询参数Finnhub则要求放在请求头里GET /api/v1/quote?symbolAAPL HTTP/1.1\r\n Host: fimhub.io\r\n X-Finnhub-Token: YOUR_TOKEN\r\n写代码之前先看清楚API文档的鉴权方式否则会得到一个401或者403排查起来还挺费劲的。4.2 接收缓冲区与超时策略HTTP响应的体积是根据接口和标的数量变化的。一次只查一只股票的GLOBAL_QUOTE响应压缩前大概是4KB到6KB。如果用多标的批量接口响应会更大。我的建议是设一个16KB的静态接收缓冲区在RAM允许的范围内尽量大。如果你用的是PIC32MZ系列16KB完全不是问题如果是PIC32MX795128KB总RAM里分配16KB给网络缓冲区需要压缩一下其他模块的开销但完全值得。有人在论坛问为什么不用动态分配。理由很简单嵌入式设备的动态分配有两个问题一是分配出来的块无法预测二是一旦代码里出现内存泄漏唯一的表现就是系统跑几天后莫名其妙崩了。静态缓冲区虽然浪费一点但行为完全可控对于常年无人值守的设备来说稳定性比省几KB内存重要得多。接收逻辑的核心是判断“响应是否完整”。如果HTTP响应里带了Content-Length头那就按这个值等待指定字节数。如果服务器用的是Connection: close那么接收循环跑到socket返回“对端关闭”就是完整收尾的信号。实际写代码时两种情况都要处理以先满足的条件为准。4.3 阈值告警与显示逻辑价格解析出来后告警判断就是一个非常直观的比较double current_price strtod(price_str, NULL); double upper 180.00; double lower 160.00; if (current_price upper alarm_state ALARM_NONE) { // 突破上轨点亮LED闪烁 LED_On(); alarm_state ALARM_HIGH; } else if (current_price lower alarm_state ALARM_NONE) { LED_On(); alarm_state ALARM_LOW; } else if (current_price lower current_price upper) { // 回到区间内解除告警 alarm_state ALARM_NONE; LED_Off(); }这里我故意加了一个alarm_state变量目的是做滞回处理。如果没有这个状态记忆当价格恰好在上轨附近来回穿越时LED会疯狂闪烁。滞回区间的宽度根据股票波动率来设比如价格在170上下波动上下阈值设为171和169就可以避免反复触发。显示方面我一开始用的是1602字符LCD后来换成了128x64的SSD1306 OLED。OLED更小巧显示信息量也大一些。单屏可以同时显示四行AAPL 171.24 1.35 (0.79%) VOL 87.6M 2025-03-10 15:59这里有一个嵌入式显示的通病printf对浮点数的输出支持不好尤其在使用没有浮点mini lib的编译环境里%.2f有概率输出成空串。解决办法是不用浮点格式化把价格乘以100转成整数再拼字符串int price_cents (int)(current_price * 100 0.5); sprintf(line, %s %d.%02d, symbol, price_cents / 100, price_cents % 100);这样不但绕过了浮点输出问题还避免了浮点精度带来的显示误差。所有展示逻辑统一按这个思路处理显示层就非常干净。5. 实测数据与性能优化记录5.1 端到端延迟与刷新周期实测项目跑通之后我给整条链路做了个计时测试。方法很简单在状态机各个关键转换点翻转一个GPIO用逻辑分析仪抓波形能精确得到每段环节的耗时。在我家宽带的网络环境下一次完整的行情拉取链路耗时如下环节耗时TCP三次握手50ms ~ 200ms发送HTTP请求1ms以内服务器响应到首字节200ms ~ 600ms接收完整响应体4KB~6KB250ms ~ 800msJSON解析字符串定位法5ms以内OLED刷新显示20ms左右整体端到端耗时0.5s ~ 1.5s这个延迟对个人监控场景完全足够。所以最终刷新周期我设置在15秒一方面避开API的免费限流另一方面也足够察觉盘中价格变化。这里要解释一下“15秒刷新周期”和“实时性”的关系。对搞高频交易的人来说15秒肯定称不上实时但对个人看盘、设置到价提醒来说这只比即时延迟了不到一个刷新区间。而且免费API本身有每分钟调用次数限制你再怎么调快也没有意义。5.2 内存与代码体积分析代码体积也是值得记录的一项。我用的开发环境是MPLAB X IDE加Harmony 3优化级别选-Os。完成后的固件占用情况如下配置Flash占用RAM静态占用Harmony 3 TCP/IP HTTP Client OLED驱动286KB97KB去掉调试打印和部分组件231KB82KB加上cJSON完整解析测试对比18KB12KB在做这个项目之前很多人会低估Harmony 3的代码体积。256KB的Flash对PIC32MX795来说还能接受但如果你用低端PIC32MX型号Flash只有128KB那就得在协议栈配置上做很多精简了。这一步也是选型时必须考虑的因素选芯片不能只看主频和RAM要看整个软件框架跑下来的实际占用。5.3 实时性调优的三个技巧调优过程中有几个小技巧立竿见影记录下来第一个技巧是关闭TCP/IP协议栈里用不到的模块。Harmony 3的TCP/IP Stack功能很多DHCP、DNS、NTP、SNTP、SMTP这些默认模块会占资源。我对接的行情API使用静态IP和固定域名解析所以DHCP和DNS都不需要开。把SNTP也关掉因为这个项目的显示不依赖精确到秒的时钟同步。只保留基础TCP和HTTP Client协议栈的内存池占用立刻降了不少。第二个技巧是提高socket的接收窗口大小这直接影响大响应体的接收效率。TCP的流控依赖接收窗口窗口小会导致高频的ACK确认和重传等待窗口大则吞吐量明显提升。实测把接收窗口从2KB调到8KB后接收完整响应体的时间从1.5秒降到800ms左右效果非常直接。第三个技巧是解析阶段不要用阻塞式I/O配合DelayMs等待而是用非阻塞事件轮询。让解析函数一次处理尽量多的数据处理完立刻返回控制权给主循环。这样即使网络暂时不顺LED、按键、显示刷新这些功能也不会被拖住。6. 踩坑记录与问题排查速查表做这个项目遇到的最多的坑集中在协议栈配置、API调用限制和嵌入式环境下格式化输出。下面把我的排查经验整理成速查表列出的每一条都是实际遇到过的问题。6.1 HTTPSPIC32拉行情最大的拦路虎先说一个让我卡了整整两天的坑。行情API基本上都要求HTTPS而PIC32的老牌TCP/IP协议栈默认不启用TLS。直接用HTTP访问返回的要么是301跳转要么是400 Bad Request反正拿不到正常数据。这个问题的解法有三条路我全部验证过换用支持HTTP明文访问的接口。少数行情提供方为了兼容嵌入式IoT设备会额外提供HTTP明文接口例如部分加密货币行情API和某些特定数据源。适合快速验证用但不推荐作为长期方案。外置模块处理TLS。就是用前面说的ESP8266/ESP32通过串口代理数据模块负责TLS握手和HTTP请求PIC32只解析串口数据。这是目前我实测最稳、最省代码的方案。Harmony 3自带TLS加上wolfSSL。这条路理论可行Microchip官方也有例程但配置复杂度很高内存占用大PIC32MX系列跑起来比较勉强。如果你用PIC32MZ可以尝试但做好心理准备这是一个需要投入大量时间的事情。我在真实项目里最终选了“外置模块代理TLS”的方案因为业务核心在解析和展示没有必要把精力耗在TLS握手和证书管理上。6.2 API限流免费Key的隐藏限制免费行情API都有限流。Alpha Vantage个人免费Key的限流规则是每分钟最多5次请求。如果刷新间隔设为15秒每分钟刚好4次勉强够用。但如果你为了“看起来更实时”把间隔调到5秒一分钟12次马上就会触发限流。限流后API不会报HTTP错误码它会在JSON里返回一个Note字段内容是“API call frequency exceeded”之类的话。这个返回结构跟正常行情不一样如果解析程序不检查这个字段会把价格解析成错误值。我的代码里专门加了一段检查逻辑一旦发现响应里出现Note或者Error Message就跳过本轮解析等下一轮刷新。6.3 浮点格式化和时区换算的小坑早前提到printf浮点输出的坑在实际开发中确实浪费了我不少时间。嵌入式环境下默认的newlib nana格式不支持浮点%f会直接输出空串。解决办法就是整数化处理没有再纠结别的方案。另一个容易忽略的是API返回时间字段的时区。Alpha Vantage返回的是美东时间含夏令时。如果直接拿来显示跟本地时间差了好几个小时甚至日期都可能差一天。我的处理是重新走一遍本地RTC芯片的时间完全信任自己硬件时钟API里返回的latest trading day只用于判断是否为交易日。6.4 常见问题排查速查表现象可能原因解决办法HTTP请求后无响应socket卡住TCP连接建立失败或超时参数过小检查PHY芯片初始化、网线链路状态超时加到3秒JSON解析得到错误价格响应被截断或缓冲区溢出加大接收缓冲区到16KB检查Content-Length匹配价格偶尔变成负数或0解析时没检查null字段解析函数加引号检查遇到null返回-1并跳过系统运行几小时后死机动态内存泄漏或看门狗喂狗位置错误改用静态缓冲区喂狗放在状态切点而不是循环内HTTPS接口返回302或400TCP/IP栈未启用TLS直接访问HTTPS改用外置模块代理TLS或换HTTP明文接口刷新周期一短就无数据触发API限流返回Note字段拉长刷新间隔到12秒以上检测Note/Error Message字段LED告警在阈值附近频繁闪动缺少滞回区间引入alarm_state状态设置上下阈值缓冲区间串口屏或OLED信息乱码浮点格式化输出异常价格整数化用sprintf拼字符串项目做完之后的几点体会整个项目从画原理图到固件稳定跑通前前后后大概用了一个多月。现在这个小盒子就放在显示器底座上开机自动联网每隔15秒亮一次行情几只看好的股票有没有异动扫一眼就知道。它不会弹通知不会推送消息也不会一天到晚打断你。看盘这种行为本来就不该被手机上的即时推送牵着走。如果要对这个方案做个总结我只说三句经验第一MCU做联网应用网络链路比MCU本身复杂十倍别低估TLS和协议栈配置的难度第二嵌入式上解析HTTP响应能不动JSON库就不动字符串定位简单可靠第三一切操作都要挂在状态机上任何阻塞都会变成看门狗复位前的死局。做到这三点这个项目就成功了一半。后续我还会往这个设备上加双色OLED的K线缩略图显示和SD卡历史记录等做完了再继续补充分享。