屏幕要显示条码二维码，还得自己写生成算法吗？

适合：做收银秤、快递面单、仓储终端、设备标签的开发者——界面要出条码/二维码，又不想自己移植生成算法。

一、自己写条码生成，坑比想象多

屏幕上加个条码，看起来就是"画几道竖线"，真动手才发现全是规范细节：

• 每种码制一套规矩：起始符、终止符、校验位、条空宽窄比、左右静区，错一个细节，扫码枪就扫不出来——而问题往往到客户现场才暴露；
• CODE128、EAN13、CODE39 各自一套编码表，开源库移植到 MCU 上还要占 Flash、吃 RAM，兼容性得自己一个个扫码枪试；
• 二维码更麻烦，光 Reed-Solomon 纠错编码就够写一阵子。

对卖设备的公司来说，这些算法和主业没关系，纯属重复造轮子，还要长期背维护锅。

二、字库芯片的思路：条码算法内置在芯片里

高通字库芯片把条码生成直接做进了芯片：

• 支持的码制：EAN13（商品零售条码）、CODE39（43 个有效字符，物流仓储常用）、CODE128 A/B/C 三种起始模式（国标 GB/T 18347）——覆盖商品、面单、资产标签的主流场景；
• 调用方式：MCU 把条码的数字/字符发给芯片，芯片返回对应的条码图形数据，打点显示就行——校验位怎么算、条空怎么排，都不用你管；
• 上手成本：示例代码随资料包提供，把里面两个 SPI 收发函数换成自己的，再调一次 BAR_CODE_EAN13 / BAR_CODE39 / BAR_CODE128，几行代码出条码。

校验规则是芯片厂按国标做好的，扫码兼容性在量产里验证过——这部分风险从你这挪走了。

三、标准芯片和自定义芯片都能做，更推荐自定义

两条路都通：

需求固定 → 标准字库芯片。 比如设备就只出 EAN13 商品码，选带条码功能的标准型号，出厂固化好，焊上板、跑通 SPI 就能调，最省事。

更推荐 → 自定义字库芯片。 理由有两个：

1. 条码算法更全更新——码制支持和显示优化跟着自定义字库的软件体系走，更新快；
2. 条码和文字一颗芯片装下——界面本来就要显示汉字、外文，在 GT-HMI Designer2 里选配字库时顺手把条码勾上，不用为条码单独想办法。

GT-HMI Designer2 条码选配实操：字符集选「一维码」加入字库组，条码资源几乎不占容量

注意右下角的总容量：0.00KB——条码几乎不占存储空间，因为生成算法在芯片固件里，字库里只存图形资源。界面的文字、图标该怎么配还怎么配，条码是顺手送的。

四、二维码怎么办

二维码数据量大、带纠错，走软件控件更灵活：GT-HMI 自带二维码控件，在 GT-HMI Designer2 里从元件库拖进屏幕就出码，文本框填内容自动生成——版本 V3~V17 共 15 个规格（版本越高能装的内容越长），纠错等级最高 30%，前景色背景色都能改。支付码、设备绑定码、票务核验码都够用。

GT-HMI Designer2 二维码控件实操：拖入即出码，版本、纠错、颜色都在属性面板配置

控件的 API 细节（gt_qrcode_create、版本和颜色设置）不用记，文档站《GT-HMI Engine 用户手册》4.2 二维码控件一章里有完整示例，照着抄就行。

分工很明确：字库芯片管文字和一维码，二维码控件管 QR——两边都不用自己写生成算法。

五、一句话总结

条码显示的难点从来不在"画"，而在编码规范和扫码兼容性。一维码交给字库芯片内置算法（EAN13 / CODE39 / CODE128），二维码交给 GT-HMI 控件，你要做的只是把数字和文本发过去——省下来的时间，够你把主业功能多打磨两轮。

高通（GENITOP）始于 1992 年，深耕汉字信息处理与嵌入式 GUI 技术，字库覆盖全球 180+ 国家语言。