原创 功能手机方案不同生产批次间可能的差异

功能手机方案不同生产批次间可能的差异

开始正文前, 首先我们尝试对手机方案或者说平台, 与传统的嵌入式项目进行一番对比. 这类对比绝对不是浪费时间, 考虑到两者之间巨大差异-- 从开发认知程度的强烈不同, 将深刻影响我们对项目的认识, 规划, 预测, 以及理解, 甚至最终的项目成败.

(一) 传统的 embedded project, 我们常常遵循着: 需求归纳, 电路设计, 布局拉线, 固件编写, 样板调试, 测试修改等基本步骤.

Firmware 架构的设计, 视设计功能需求的多寡, 以及在系统中占据的重要抑或辅助的角色而有所不同, 大致上都可以归纳为三类:

1. 仅是 superloop+isr 核心的架构

2. 在 superloop 中设计的简单 tasks 调度系统(它不能被称为 OS, 因为这类简单的调度系统往往没有优先级, 且不具备几乎是最重要的 tasks或者说线程的 stack 分配).

3. embedded OS(最出名可能应属 source 开源-- 但仍有版权的 uC-OS). 顺便提一下, 这里我们可以看到, 我们操作的微控对象, 业界都称为 uC, "micro Controller". 但在中国大陆, "单片机"成为取代的专业术语. 这个"单片机"术语将 uC 的广域范畴, 转换成了相当局限性的工程工艺范畴. 这个转化虽然明显降低了初学者对新领域的畏难心态, 但也限制了初学者的想象力, 它将"无形"的"微控"的领域强调, 转化成"有质"的形体可见类似"车间或库房物品"的概念描述. 似不妥当 -- 题外话.

4. 新项目的代码几乎从 zero 堆积, 即便是引入的 OS -- 他们也往往是开源的, 并有大量电子材料甚至各种厚厚的技术讨论实体书籍协助的.

(二) 手机方案则有明显不同, 如果可以给它贴标签的话, 面对可能内容多达数个G 的"原材料", 那么"外来的", "庞大的", "资料不全的", 似可作为显著的标签标识.

手机平台方案的特点:

1. 信息闭环的: 

理想的MCU, 原厂应以较完备的状态出货. 而实际不同的生产批次, 往往将随着不断解决市场反馈, 或前期批次测试中的出现问题而不断进步.  因此, 即时更新的 ERRATA SHEET 将是重要的.

但正为我们电子工程师谙知, 功能机智能机方案几乎是一个信息闭环. 一方面手机IC以极大的发货量, 以及比较状态下的相对较廉价横扫市场;  另一方面, 方案解决商强调针对特定目标客户群体的服务, 或集中提供某类客户所谓 turnkey 的方式最终实现内部配置资源的最大化. 这一般将导致: 信息收集的困难, 专业讨论的困难, 专案进度的困难, 获取工具的困难. 

2. 体量庞大的:

上一个我们自行完成的工程全编译的文件有多少个? 如果在 windows 平台上的某款电子产品的辅助配置应用工具开发产品中, 我们回答可能是数十个. 如果是过去我们完成的 uController 的案子 , 那么我们的回答参与全编译的文件可能是十数个. 那么回到我们自问自答的环节, 在假设中的功能机的方案中, 当完成全编译后, 记数参与编译的源文件总和有多少呢? -- 答案是数千个. 随方案提供商与平台有所不同. 

无论如何, 我们这里能够给出一个估算的量级: 基带 4bands 的 2G 手机功能机方案平台上, 给出的参与全编译的源文件至少 >1,000pcs; 参与编译的 .mak 文件至少有数十pcs.

3. 工程师不友好的: 

如从影响工程师的技术能力进步的角度考虑, 那么值得吐槽的方向可以列举两个: 

(1) IC更新换代速度快导致专业技能淘汰加速: 

让我们回到 NXP 的技术巡演会现场, 我们可能被类似"每款MCU型号至少10年承诺不退市"的话语激励; 画面一转, 有幸与手机方案原厂的 sales 面对时, 我们却往往会面对"一年至少3款"的产品 miletones 惶然. 这很可能意味着已知工程技术知识的迅速淘汰(尤其当该技术新进展新努力构建在某困难迁移之平台上时). 那么随之而来的现状往往就现实而残酷, 或许工作2年后, 所致力的平台被淘汰 --新案子来临时, 可能原团队成员与一名新晋入职工程师的技术起步, 并无特别不同. 

(2) turnkey 的幸与不幸: 

完成平台的全编译, 容易带我们进入一种虚幻的感觉: 此刻似如同一枚大厂的产品leader, 手下包含数个全球的研发测试团队, 且市场多半已经有了先行者的比较实践. 很快下一刻, 这种虚幻成就感会随着第一个简单开发任务而破碎 -- 在缺乏资料没有支持的环境下, 哪怕我们自行调出了第一个 uart 功能的例程, 都值得欢呼雀跃 -- 你没有看错, 在其他任何一款公开发布并售卖的 uController 上, 实现 uart 就这么简单任性. 但是在未知的海量文件集合中, 在没有合适的文档支持下, 取得任何一个小小的进展(哪怕是简单的 uart)都意味着更多的工程努力. 更糟的是, 我们有时候往往不在意我们是否能够功能实现, 而在意我们本应如何实现, 实现验证哪些理论认知. --好吧, 我们通过不停阅读源代码, 抽丝剥茧, 拙劣模仿, 也实现了某种类似功能. 可深层点想想, 这有什么重要意义? -- 提升了我们对 system 的认知? 提升了我们对 uart 通讯原理认知? 提升了我们工程师的系统整合经验? 然而并未有. 至于幻想核心代码不被隐藏, 幻想 OS 的  tasks 分配表格被贴心的文档详细讲解... 那到不如自己准备一盆冷水好好清醒一下...

(三) 不同的项目方式的魔幻比喻

假设我们生活在魔幻世界, 电子工程师类比为魔法使用者. 

那么, 构建在 turnkey 方案上努力的工程师, 就是传统的魔法师: 探讨魔法本质变得不是那么重要, 而尝试体会身边的元素存在, 并接触9层魔网. 从魔网中以精神力的代价, 获取魔网中贮存的魔法的释放. 就很类似手机平台开发, 或在任何外来的平台基础开发的工程师.  明显的, 手机平台的魔法材料准备之众多, 魔法阵之庞大, 暗示着平台开发工程师接触的, 虽然谈不上是传奇魔法或者禁咒魔法, 至少也排除了低环级别, 摸到了高阶魔法的大门.

而其他嵌入式开发的电子工程师, 则明显可归类于术士, 选民之类的施法者. 他们不依赖魔网的存在, 而通过血脉的影响, 或单纯后天的努力, 探索自然之奥秘, 拼装元素之组合, 并自行设计魔法阵或辅助工具, 有目的有计划的, 无中生有般的形成魔法.

两类工程的方向与方式, 有着明显不同与区别, 在这个比喻中, 甚至可以归类为两类不同的群体. 如果考虑到开发者可能对本领域的执着与沉迷 -- 那么至少, 充分认识 turnkey 平台架构的开发本质, 以及其与普通 embedded 项目的经验比较: 可推测这应能给行业初入者, 在项目选择上与项目计划上, 提供相当程度的辅助认识指导.

回到主题, 尽管缺乏相应支持, 通过比较测试, 对手机功能机平台不同批次的芯片进行多番比较, 如果我们以 MTK 6261D 为例:

1. 不同批次之间的内置的 flash 品牌与型号可能不同:

不同批次间, 可能存在 GigaDevice GD25LQ32 -> Winbond SF_W25Q32JV 的区别. 特别通过 Vsf 的电压的比较, 从 1.8V -> 3V. LSA0 信号拉低与否, 测试不再影响 Vsf 的电平配置.

2. 休眠方式不同:

不同的批次, charger mode 下可能保持 unsleep mode; 也可能进入 sleep(进入 Sleep mode 后, 明显平台消耗的电流 -10mA左右).

如果在前者平台上完成​​设计, 那么可能需要主动使用 usr app, 在 charger mode 下保持对系统的唤醒.

3. Sleep mde 下能否保持固定的 Timer:

这个经验则并非来源我们的测试, 而是参与的网络讨论. 根据我们的经验, 对提问者进行了善意的提示, 而回答让人吃惊. 如果我们没有理解错误, 这种差异明显来源于不同生产批次的不同特性:

(1) 进入 Sleep mode 后,  基于 26MHz system OSC 的 timer 会不定期且变慢, 且 timer 间隔时间不可控. 我们测试最慢可能达到 *2 的效果. 似有印象某资料提及, 不定期的 26MHz 的不定期激活, 完全取决于 GSM RF 时隙需求.

(2) 系统提供了 32KHz clock source, 即 gpt timer 给准确的定时. 在我们的测试中, 我们明确获知: gpt timer 将导致 system 无法 sleep. 但讨论者的回应是, 获得了 gpt timer 但是同时system sleep 至 1mA 左右. 假设这个讨论无误, 那么我们可能有两个结论: 首先, 平台资料有误并在不同的发布中可能被修正. 其次, 这可能是不同生产批次的 IC 的特性? 

由于资料的缺乏, 我们更多的讨论都几乎基于猜测:

使用了 32KHz 的 gpt timer, 为何系统还能够进入 sleep mode? 如果 32KHz 是 26MHz 分频得到, 停振系统 26MHz 又如何保证 32KHz 的振荡源? 出于疑惑我们重新检查了 datasheet, 确认没有外部 RTC 的晶体接入Pins, 也不存在外部 RTC source 的接入Pin. 经过几次论坛讨论, 我们的共识是: 32Khz 振荡源应集成在 MT6261 内部, 主要的作用可能服务于休眠状态状态下准确定时. 至于为何某些方案下无法实现 gpt timer 应用时 system sleep. 可能存在某平台编译开关, 将内部 32KHz 振荡源开启(而不是通过 26Mhz 系统OSC分频); 另一可能, 则不同生产批次下, 硬件构架的微小差异. 同样的, 缺乏 ERRATA 我们也无法确认这个猜测.

4. 总结:

功能手机平台, 存在着不同生产批次下的可能特性差异. 这种不同, 可能源于内部硬件架构的微小差异; 也可能源于高度集成与整合的软硬件平台, 某些编译开关随硬件批次的编号不同, 而选择了编译内容的不同. 无论上上述猜测中的那种, 很可惜都缺乏相应资料实证. 因此, 建议是每个生产批次, 都应完成相应的测试比对工作.