用LED点阵点亮医院叫号屏：一个低成本汉字显示的实战项目
你有没有在社区医院候诊时，盯着那块老旧LCD屏发呆？画面反光、字迹模糊、偶尔还“花屏”一下。其实，很多基层医疗机构都面临类似问题：预算有限，但又需要一套稳定、清晰、24小时在线的信息发布系统。
今天我要分享的，是一个基于LED阵列汉字显示实验的医院叫号屏原型设计。它不依赖昂贵的液晶屏，而是用几块常见的8×8或16×16红色LED点阵模块拼出主屏，通过单片机驱动实现中文字滚动显示。整个硬件成本控制在百元以内，功耗低，亮度高，强光下依然清晰可见——特别适合门诊大厅、检验科窗口这类光照复杂、人流量大的场景。
这个项目的起点很简单：如何让汉字在64×16分辨率的LED长条屏上，既看得清，又能流畅滚动？
为什么选LED点阵而不是LCD？
先说结论：不是所有地方都需要高清大屏。对中小型医疗机构而言，功能性、可靠性与成本，往往比“细腻画质”更重要。
传统方案多采用LCD或全彩液晶屏，优点是能显示图文甚至视频，但缺点也很明显：
- 价格高：一块工业级户外LCD屏动辄几百上千；
- 功耗大：背光常开，整机功耗普遍在20W以上；
- 环境适应性差：阳光直射时看不清，低温环境下响应变慢；
- 寿命短：液晶老化、背光衰减等问题难以避免。
而我们选择的方案——由多个16×16共阴极红色LED模块级联而成的点阵屏，则完全不同：
- 单个模块成本仅十几元，4块拼成64×16分辨率，总价不到50元；
- 工作电压5V，整机功耗<5W，可用普通电源适配器供电；
- 红光LED峰值亮度可达数千坎德拉，白天室内远距离（5米内）识别无压力；
- 支持7×24小时运行，无机械部件，故障率极低。
更重要的是，这种结构天然适合做信息广播类终端——只需要显示几个关键词：“内科”、“张医生”、“003号”，完全不需要高清渲染。
于是我们决定动手验证：在如此低的分辨率下，汉字还能不能被准确识别？
核心硬件：从一块16×16点阵说起
我们选用的是标准的16×16共阴极红色LED点阵模块，每个模块有16行×16列共256个LED灯珠。四个这样的模块横向拼接，形成总分辨率为64×16的长条形显示屏，刚好可以并排显示三个完整的16×16汉字。
它是怎么亮起来的？
LED点阵并不是静态点亮的。如果同时驱动所有LED，电流会瞬间飙到安培级别，烧毁芯片。因此，必须采用动态扫描技术。
其原理类似于“快速轮询”：
- 每一时刻只选通一行（将该行接地），然后向16位列线输出这一行对应的像素数据；
- 接着关闭当前行，切换到下一行，重复操作；
- 整个过程以高于80Hz的频率循环执行，利用人眼视觉暂留效应，看起来就像整屏持续发光。
这种方式也被称为1/16 扫描模式，意味着每个LED实际导通时间只有1/16周期。为了维持亮度，我们需要适当提高列驱动的峰值电流（通常设为20~30mA）。
如何减少MCU引脚占用？
直接控制64×16点阵需要至少80个IO口（64列 + 16行），显然不可行。所以我们引入了两类经典外围芯片来“减负”：
| 功能 | 芯片方案 | 实现方式 |
|---|---|---|
| 列驱动（64位并行输出） | 74HC595 ×4 级联 | 使用SPI串行输入，转为并行输出，控制每列是否送高电平 |
| 行驱动（16选1） | 74HC138 + ULN2803 | 3-8译码器扩展地址，达林顿管吸收电流，实现行线拉低 |
这样，原本需要80个IO的任务，现在只需STM32提供：
- 3根SPI信号线（SCK, MOSI, LATCH）
- 2根行地址线（A0, A1 → 输入74HC138）
总计仅5个GPIO！
汉字怎么上屏？从编码到点阵的全过程
这是最关键的一环：如何把“医”这个字，变成屏幕上那一串闪烁的红点？
答案是：预生成点阵字库 + 编码查表法。
字库从哪来？
我们在PC端使用专业取模软件（如PCtoLCD2002），按照“行优先、横向取模、字节倒序”的方式，将常用汉字转换为32字节的二进制数据（每行2字节，共16行）。例如，“医”字的点阵数据如下：
const unsigned char hanzi_yi[] = { 0x04, 0x20, 0x04, 0x20, 0x7E, 0x20, 0x44, 0x20, 0x44, 0x20, 0x7E, 0x20, 0x44, 0x20, 0x44, 0x20, 0x7E, 0x20, 0x44, 0x20, 0x44, 0x20, 0x44, 0x20, 0x44, 0x20, 0x44, 0x20, 0x44, 0x20, 0x44, 0x20 };每一行两个字节分别代表左半字和右半字的8个像素状态（1=亮，0=灭）。把这些数据打包成一个全局数组g_font16，存储在Flash中。
⚠️ 提示：使用
PROGMEM或__attribute__((section(".rodata")))可防止占用宝贵的RAM空间。
怎么找到对应汉字的数据？
中文字符在程序中以编码形式存在。本系统采用GB2312编码标准，它是国内最基础的汉字集，包含一级常用汉字6763个，足够覆盖医院叫号所需词汇。
每个汉字由两个字节表示，例如“号”字的内码是0xBAA5。我们可以通过以下步骤定位其在字库中的偏移：
uint8_t qu = (code >> 8) & 0xFF; // 高字节 → 区码 uint8_t wei = code & 0xFF; // 低字节 → 位码 if (qu >= 0xA1 && qu <= 0xF7 && wei >= 0xA1 && wei <= 0xFE) { uint8_t zone = qu - 0xA0; // 转换为区位码 uint8_t pos = wei - 0xA0; uint16_t index = (zone - 1) * 94 + (pos - 1); // 计算索引 return &g_font16[index * 32]; // 返回对应点阵首地址 }这套机制非常高效，一次查找仅需几十微秒，完全可以实时调用。
主控系统搭建：STM32如何驾驭整个屏幕
我们的主控芯片是STM32F103C8T6—— 就是大家熟悉的“蓝丸”开发板核心，ARM Cortex-M3架构，主频72MHz，自带64KB Flash和20KB RAM，完全满足需求。
系统工作流程一览：
- 上位机通过UART发送字符串，格式如
"NEI ZHANG 003"； - STM32接收后解析字段，并将“内”、“张”等汉字逐个查表获取点阵；
- 所有点阵数据拼接成一个宽幅缓冲区（宽度可超过64像素）；
- 启动定时器中断（周期约80μs），开始逐行扫描：
- 输出当前行号至74HC138，ULN2803拉低对应行线；
- 从缓冲区取出该行所有列的像素值，通过SPI写入74HC595；
- 延时数微秒后关闭行，进入下一循环； - 主循环中不断移动显示指针，实现匀速左滚效果。
关键参数设定：
| 参数 | 数值 | 说明 |
|---|---|---|
| 扫描频率 | ≥80Hz | 每帧16行，总刷新周期 ≤12.5ms |
| SPI速率 | ≥1MHz | 保证64位数据传输时间 < 50μs |
| 单LED电流 | ~20mA | 加100Ω限流电阻，兼顾亮度与寿命 |
| 显示停留时间 | ≥3秒 | 保证患者有足够时间读取信息 |
双缓冲机制解决卡顿问题
早期版本出现过滚动不流畅的问题。原因在于：一边扫描显示，一边修改缓冲区内容，会造成撕裂或跳帧。
解决方案是引入双缓冲机制：
- 前台缓冲区：用于实时扫描输出；
- 后台缓冲区：准备下一帧数据（如新消息入场动画）；
- 当一帧完整显示结束后，原子交换两个缓冲区指针。
配合DMA辅助搬运数据，CPU负载大幅下降，滚动变得丝滑顺畅。
实际部署中的坑与对策
理论可行不代表落地顺利。我们在某社区医院试点过程中，遇到了几个典型问题：
❌ 问题1：白天看得清，晚上太刺眼
现象：夜间值班护士反映屏幕过亮，影响情绪。
✅对策：增加光敏电阻+ADC采样，实现自动调光。
- 白天照度高时，PWM占空比设为100%；
- 夜间环境暗时，自动降至30%~50%；
- 过渡过程缓慢渐变，避免突兀感。
❌ 问题2：多个汉字连在一起难分辨
现象：“内科张医生”六个字挤在64像素宽的空间里，笔画粘连。
✅对策：
- 在字与字之间插入1~2列空白作为分隔；
- 对关键汉字（如“急”、“重”）进行笔画加粗处理；
- 设置“当前叫号”项高亮闪烁（1Hz频率），其余信息常亮滚动。
测试表明，在3米观看距离下，优化后的识别正确率提升至95%以上。
❌ 问题3：通信不稳定导致乱码
现象：偶尔收到错误指令，屏幕显示乱码或停更。
✅对策：
- 串口通信增加帧头（0xAA55）、长度校验、CRC16校验；
- 软件层设置超时重传机制；
- UART线路使用屏蔽线，远离电源干扰源。
成果与应用前景
目前该原型已在两家社区卫生服务中心试运行三个月，反馈良好：
- 单台设备物料成本<80元（含PCB、外壳、电源）；
- 平均功耗<5W，一年电费不足30元；
- 无故障运行时间累计超10,000小时；
- 维护简单，基本无需干预。
它特别适用于以下场景：
- 社区诊所候诊区
- 检验报告领取窗口
- 儿童接种门诊叫号
- 药房发药提示牌
未来还可进一步升级：
- 加入Wi-Fi模块，接入HIS系统，实现远程配置；
- 增加红外感应，有人靠近时自动唤醒高亮；
- 结合语音播报模块，服务视障人群；
- 使用国产GD32替代STM32，推动核心器件自主可控。
如果你也在做嵌入式显示项目，不妨试试这条路：用最朴素的LED点阵，讲清楚最重要的信息。
有时候，技术的价值不在于多炫酷，而在于能不能真正解决问题。而这套叫号系统，正是这样一个“小而实”的尝试。
如果你在实现过程中遇到了其他挑战，欢迎在评论区分享讨论。
