2、HMI硬件架构对比:各品牌HMI的CPU架构、内存管理、存储方案差异分析
做HMI移植,第一关就是硬件。
你想想看,同一个界面,在威纶通上跑得飞起,换到昆仑通态上就卡成PPT。为什么?
说白了,底层硬件架构不一样。
我这些年经手过不下20个品牌的HMI,从几百块的国产屏到几万块的西门子高端屏,拆开看过之后,发现门道其实就那几个。今天我把它们掰开揉碎了讲给你听。
2.1 CPU架构:ARM、Cortex-A、RISC-V,谁才是主流?
先说结论:目前HMI市场,Cortex-A系列是绝对主力。
ARM Cortex-M?那是给微控制器用的。HMI要跑图形界面,要处理触摸事件,M系列那点算力根本不够看。我见过一些低端HMI用Cortex-M4,刷个页面都要半秒,用户体验极差。
| 架构 | 代表芯片 | 常见品牌 | 我的评价 |
|---|---|---|---|
| Cortex-A7/A8 | 全志F1C200s、瑞芯微RK3128 | 昆仑通态、威纶通(低端) | 够用,但别指望跑复杂动画 |
| Cortex-A35/A53 | 瑞芯微RK3566、全志V3s | 显控、步科(中端) | 性价比之选,我项目里用得最多 |
| Cortex-A72/A76 | 瑞芯微RK3588、树莓派CM4 | 西门子、倍福(高端) | 性能过剩,但发热是个问题 |
| RISC-V | 赛昉JH7110、博流BL606 | 极少数国产新品牌 | 未来可期,现在别碰 |
重点来了:移植时最头疼的不是CPU性能,而是指令集差异。
比如你在ARM上编译好的Qt库,换到RISC-V上得重新编译。而且RISC-V的浮点运算单元(FPU)实现各家不同,我踩过这个坑——同样的算法,在赛昉芯片上算出来的结果和ARM上差了几个毫秒。
我个人习惯是:优先选Cortex-A35或A53。为什么?
- 生态成熟,Linux内核支持好
- 第三方库多,OpenGL ES、Qt、LVGL都能跑
- 功耗控制不错,不用加散热片
至于RISC-V,嗯,我建议你再等两年。现在它的工具链还不够完善,我在一个预研项目里试过,光是搭交叉编译环境就花了两天。你想想看,项目工期那么紧,谁耗得起?
2.2 内存管理:DDR3、DDR4、LPDDR,别搞混了
HMI的内存管理,说白了就两件事:容量和带宽。
容量决定了你能开多少个窗口、放多少张图片。带宽决定了界面切换是否流畅。
我遇到过最离谱的事:某品牌HMI标称512MB内存,实际可用只有384MB。为什么?因为剩下的128MB被系统固件占用了,而且你还没法释放。这就是典型的内存碎片化问题。
| 内存类型 | 典型容量 | 带宽 | 常见场景 |
|---|---|---|---|
| DDR3 | 128MB - 512MB | 800-1600 MT/s | 低端HMI,跑简单界面 |
| DDR4 | 512MB - 2GB | 1600-3200 MT/s | 中高端HMI,跑Qt或Web界面 |
| LPDDR4 | 1GB - 4GB | 3200-4266 MT/s | 高端HMI,跑3D或视频 |
我的经验:移植时一定要确认目标平台的内存对齐策略。
比如ARM Cortex-A默认是4字节对齐,但有些RISC-V芯片要求8字节对齐。不对齐的话,访问速度会下降30%以上。我曾经因为这个原因,一个页面加载时间从200ms飙到了350ms。
还有一个坑:缓存一致性。
HMI里经常有DMA操作,比如从SD卡读取图片到内存。如果CPU缓存和DMA操作的内存区域不一致,你读到的数据就是错的。我调试过一个bug,花了两天才发现是缓存没刷新——从那以后,我每次做DMA操作都会手动调用dcache_flush。
// 示例:ARM Cortex-A上刷新缓存
// 移植到RISC-V时,这个函数名可能不一样
void flush_dcache(void *addr, size_t len) {
// 在ARM上:
__builtin_arm_drainwb();
// 在RISC-V上可能是:
// __asm__ volatile("fence.i" ::: "memory");
// 一定要查芯片手册!
}
2.3 存储方案:NAND Flash、eMMC、SD卡,谁更靠谱?
存储方案这块,水最深。
HMI的存储主要分三块:系统固件、用户工程、运行日志。不同品牌对这三块的处理方式天差地别。
- 威纶通:系统固件放NAND Flash,用户工程放SD卡或U盘。好处是用户数据坏了不影响系统,坏处是SD卡容易松脱。
- 昆仑通态:全部放eMMC。好处是集成度高,坏处是一旦eMMC坏了,整机报废。
- 西门子:系统固件放NOR Flash,用户工程放CF卡。嗯,你没看错,还在用CF卡,工业级的稳定性确实好。
注意:NAND Flash有坏块管理问题。
我曾经在一个项目里,HMI运行了半年后频繁死机。查到最后发现是NAND Flash的坏块越来越多,文件系统崩溃了。从那以后,我坚持用eMMC——它自带坏块管理和磨损均衡,省心很多。
存储方案对比表:
| 存储介质 | 读写速度 | 寿命(擦写次数) | 我的建议 |
|---|---|---|---|
| NOR Flash | 读快写慢 | 10万次 | 只适合放启动代码 |
| NAND Flash | 中等 | 1万-10万次 | 需要做坏块管理,不推荐 |
| eMMC | 快 | 3万-5万次 | 首选,省心 |
| SD卡 | 取决于等级 | 1万-10万次 | 适合做扩展存储,别放系统 |
移植时要注意什么?
我总结了三句话:
- 文件系统要统一:有的用FAT32,有的用ext4,有的用YAFFS。移植时一定要确认目标平台支持什么文件系统。
- 分区表要兼容:比如威纶通用的是MBR分区表,而西门子用的是GPT。你从威纶通移植到西门子,分区表得重做。
- 日志写入策略:HMI经常要写运行日志,如果频繁写入,NAND Flash很快就挂了。我建议用环形缓冲区,只保留最近1000条日志。
最后说一句:硬件架构的差异,说白了就是生态壁垒。
ARM生态最成熟,你遇到问题网上随便一搜就有答案。RISC-V虽然开源,但工具链、驱动、中间件都还在完善中。如果你做的是商业项目,老老实实用ARM。如果是预研或学习,可以玩玩RISC-V。
嗯,今天就先聊到这。下一章我们讲操作系统移植,那才是真正让人头秃的部分。