[技术问答] 新唐 MA35D1 的高运算性能,如何应对高吞吐量仓储场景?

[复制链接]
313|51
波尔街道的松柏 发表于 2026-6-25 15:40 | 显示全部楼层
MA35D1 多核架构与强劲算力,可并行处理扫码、传感、通信多路数据。依托高速接口对接物流设备,实时解析海量采集信息。搭配网络模块保障数据高速转发,任务分时调度提升吞吐效率,稳定支撑仓储高频数据交互与设备联动。
波尔街道的松柏 发表于 2026-6-27 15:42 | 显示全部楼层
MA35D1 多核架构算力充足,可并行处理扫码、传感器、网络等多路数据。依托高速通信接口实现海量数据转发,合理划分任务负载提升吞吐。搭配硬件加速模块简化运算,保障仓储设备高频交互、实时调度,稳定承载高并发业务。
kkzz 发表于 2026-6-14 11:48 | 显示全部楼层
A35 与 M4 之间的 IPC 通信如果设计不当,会成为新瓶颈。
adolphcocker 发表于 2026-6-14 12:37 | 显示全部楼层
绝不能让负责实时控制的 M4 核心去等待 A35 的运算结果。
xiaoyaodz 发表于 2026-6-14 16:26 | 显示全部楼层
用 Cortex‑A35 做流水线分类与决策
sanfuzi 发表于 2026-6-14 17:42 | 显示全部楼层
如何通过多核分工提升实时性?              
febgxu 发表于 2026-6-15 19:52 | 显示全部楼层
M4内核负责高频实时数据采集              
pl202 发表于 2026-6-15 20:35 | 显示全部楼层
为了避免 A35 和 M4 之间的数据传输成为瓶颈,MA35D1 提供了高效的内部通信机制。
pentruman 发表于 2026-6-18 12:04 | 显示全部楼层
双核通过 mailbox / 共享内存解耦
lihuami 发表于 2026-6-18 13:48 | 显示全部楼层
A核只跑分类推理,不碰图像解码和渲染,算力全部留给算法,延迟降低40~60%。
alvpeg 发表于 2026-6-18 15:38 | 显示全部楼层
传统方案需要外扩串口芯片+CAN控制器,PCB复杂、延迟增加。MA35D1原生全集成,节省3~5个扩展芯片,延迟降低一个数量级。
robincotton 发表于 2026-6-18 16:05 | 显示全部楼层
可以算出最大允许延迟?              
sdlls 发表于 2026-6-18 17:40 | 显示全部楼层
硬件加速对延迟有何具体优化?              
ulystronglll 发表于 2026-6-18 18:26 | 显示全部楼层
A35内核专注复杂视觉识别与逻辑处理
51xlf 发表于 2026-6-19 12:21 | 显示全部楼层
高频场景下,如果每一个物体都触发一次 NPU 推理,NPU 的启动开销会累积。
jimmhu 发表于 2026-6-19 13:03 | 显示全部楼层
M4 维护一个“待分拣环形队列”,只根据当前编码器的实时位置与队列中的预设位置进行比对。
mikewalpole 发表于 2026-6-19 15:12 | 显示全部楼层
仓储分拣通常需要接入大量的传感器和执行机构。
dspmana 发表于 2026-6-19 15:37 | 显示全部楼层
在 A35 端,图像数据搬移是产生延迟的隐形杀手。MA35D1 内置了 2D 图形加速器 (GE) 和 NPU,必须榨干其性能。
zerorobert 发表于 2026-6-19 19:01 | 显示全部楼层
即使 A35 侧的 Linux 系统因为网络波动或数据库写入出现短暂卡顿,M4 核的实时数据采集也不会受到任何影响
nomomy 发表于 2026-6-19 21:02 | 显示全部楼层
用 Cortex‑M4 保 I/O 时序与执行确定性
您需要登录后才可以回帖 登录 | 注册

本版积分规则

快速回复 在线客服 返回列表 返回顶部
0