标签: microsoft

我有一台低配版的 Surface Pro 6，128GB + Intel 酷睿 i5 第八代。对 Intel 低压版酷睿产品线熟的同学应该知道，Intel 第一次在酷睿第八代低压处理器（也就是型号末尾都带 U 字母的）上将核心数目升级到了四核，以前都是双核。而酷睿八代 CPU 的问世，很大程度上似乎是为了应对 AMD Zen 的来袭。 在市场宣传上，酷睿八代还是相当成功的。基本上酷睿八代超级本（本文只讨论低压版酷睿八代）都获得了不错的名声，也包括 Surface Pro 6。网上的绝大部分基准测试成绩，八代酷睿都比七代有着质的飞跃，毕竟核心数目都翻番了——也算是“一屁股坐在牙膏管上”的操作了，这好像还是要感谢 AMD 的。 不想看这么多文字的同学，可以直接转到本文最末看结论。 图片来源：我的 instagram :) 不过讲真的，Surface Pro 6 酷睿 i5 版的使用体验并不算好——一般在低压超级本上，我以前始终觉得酷睿 i5/i7 在性能表现上差不到哪儿去，尤其在低压 i5、i7 超级本的价格差别还那么大的情况下。如果我们不算 binning process 导致 i5/i7 有着体质上的差异，以及一些看起来对一般人并没有什么用的“高级”特性，针对超级本的低压版 i7 似乎也就比 i5 略高点儿频率（cache 差别什么的也并不大）。现在看来，我这个观念是错误的，至少在微软这里是完全错误的。 实际情况是，Surface Pro 5、6、7 这三代产品的酷睿 i5 版（分别对应 Intel 酷睿七代、八代、十代），都采用被动散热，也就是无风扇的设计（i7 版是有风扇的）。我觉得在行业内也就微软有这种“魄力”了。不过至少通过对它们的了解和研究，可发现无风扇酷睿低压本（非超低压）的实际性能情况，大致是什么样。因为温控、散热设计对性能有着很直接、显著的影响。 主观体验 聊主观体验的话，其实就不光是处理器的问题了，理论上我应该谈“系统性能”。比如说 Surface Pro 6 低配版选择的闪存比较寒碜，加上 LPDDR3，其存储性能本身就不会很好看，这些实际上都对系统性能成绩造成了比较大的影响。就 NoteBookCheck 的 PCMark 系统性能来看，低配版 Surface Pro 6 的系统性能得分和 Pro 5 差不多 ，主要源于其存储性能实在太烂。不过我不想聊系统性能，我们就单纯说说 CPU。所以主观体验这部分其实不靠谱，各位权当看看。 如果只说体验的话，我日常用 Photoshop 和 Lightroom 作图调色比较频繁，Surface Pro 6 酷睿 i5 版在应付这两个软件时已经十分力不从心。起初我一直觉得这件事很不可思议，八代酷睿怎么应付不了 PS 和 LR？所以我怀疑是软件版本问题（或 GPU 加速什么的不生效），后来我发现不管我换用哪个版本，在这台超极本上用 PS 和 LR，就是感觉会慢半拍。LR 的使用体验尤其糟糕，就是调某一种色彩的饱和度、色相、亮度都会感觉到迟滞。以前那些七代酷睿本上都没发生过这种事。 这是我用 Surface Pro 6 在中秋节那天做的图，这张图做到 20 分钟时，屏幕已经比较烫手 我手上主要在用的是两台本子，一台是 Surface Pro 6，还有一台是公司发的 ThinkPad X390（酷睿 i7-8565U）。这两台设备看起来都是八代超级本，而且就这两款设备发售同期，Surface Pro 6 价格也比较感人：于情于理，Surface 也应该和同期八代超级本性能相近，或者至少差别不大吧。但就实际体验部分来看，ThinkPad X390 的 PS 和 LR 使用体验真的甩 Surface Pro 6 九条街，前者在这些软件内的常规操作基本没什么卡顿的情况发生。 这就真的让我很不爽了，因为这种体验差距是能确确实实感受到的。大家同样是八代本，凭什么 ThinkPad X390 就出色那么多？ 如果我们单从处理器来看，它们的主要区别在我看来就是有没有风扇的问题，Surface Pro 6 的酷睿 i5 版是没风扇的，ThinkPad X390 有风扇——而且风扇还经常转。在酷睿 i 系列本子上不用风扇的，在行业内估计也是屈指可数的。我这两台设备实际的处理器型号为： - Surface Pro 6： 酷睿 i5-8350U（Kaby Lake Refresh），1.7GHz 主频，3.6GHz 睿频，6MB L3 Cache；LPDDR3 8GB 双通道；UHD Graphics 620（300-1100MHz） - ThinkPad X390： 酷睿 i7-8565U（Whiskey Lake），1.8GHz 主频，4.6GHz 睿频，8MB L3 Cache；DDR4-2400 8GB；UHD Graphics 620（300-1150MHz） 貌似看这个配置表，我这“主观体验”对比未免也太不客观了。的确，这两个超级本的处理器架构代号都不一样。不过 Whiskey Lake 相比 Kaby Lake Refresh 的主要差别在于，Whiskey Lake 采用改良版的 14nm++ 制造工艺，提供了更高的频率，其余各部分其实是差不多的，貌似还有外围支持的一些小差异。 似乎就存储性能表现，以及处理器频率、L3 Cache 来看，ThinkPad X390 更优的软件使用体验也算必然。只是我没想到两者的差距会这么大，毕竟也算是同期的八代超级本。就我自己看来，这种差异可以认为是散热机制造成的，Surface Pro 6 的无风扇设计导致其性能孱弱，并影响到了用户体验（实际情况或许还要复杂一些）。散热机制差异对性能的影响，超过了上述配置参数差异的影响。下面我们来“片面”地看看，无风扇设计究竟造成了多大的影响。 这三代无风扇设计的 Surface 前文就提到了，Surface Pro 5、6、7 这三代的酷睿 i5 版都采用无风扇设计。就我的理解来看，这应该并非是微软对自己系统设计有多自信，而是在理念上期望打造一款安静的无风扇平板电脑（而且温度控制需要比一般笔电更低，毕竟它身兼“平板”属性，需要经常与手亲密接触）。它在定位上更偏向便携、轻薄、移动、安静。只不过 Surface Pro 就平板定位来看，真的不轻，我自己觉得就现阶段来看，它完全没有追求“便携、轻薄”的资格。 而且主观体验可补充的是，Surface Pro 6 的温控机制虽然在笔记本中算是比较保守的，但如果你有用 Surface Pen 作图的习惯，在 Photoshop 里面作图，手指和屏幕亲密接触，依然能十分明确地感受到这设备“温暖”得可以：时刻提醒你，这根本就不是一台平板，哪有这么“温暖”的平板啊？所以我觉得，在这一点追求上，Surface 是失败的。或者说，我觉得 Surface Pro 没必要追求这个。 我们来看下，如果只对比这三代产品，其 CPU 性能表现的差异。这里援引 NoteBookCheck 的 CineBench R15 多轮跑分，如下图所示。我将 Surface Pro 5、6、7 的酷睿 i5 版跑分标识出来了。 来源：NoteBookCheck 首先简单谈一谈 CineBench R15 是个什么测试：这个测试基于动画软件 CINEMA 4D 3D 内容创作，可用于衡量 CPU 和 GPU 性能。CPU 测试场景包含 28 万个多边形，GPU 测试基于 OpenGL ——渲染大约 100 万多边形、高分辨率纹理和各种特效。测试中，CineBench 会动用全部系统处理能力，来渲染一个 3D 场景，该场景由各种算法构成，对所有可用处理器核心构成压力测试。CPU 测试场景包含大约 2000 个对象，采用形状、模糊反射、面积光源、阴影、反锯齿等效果。GPU 测试部分就不说了，也不是本文要探讨的重点。 Intel 似乎一直认为 CineBench 是一个“unrepresentative”的测试 ，其实我也这么觉得。不过 NoteBookCheck 的这项对比最为直观，我就拿过来用了。 如果我们只用 Surface Pro 自家产品对比，这三代的性能提升还是显著的。而且同样是无风扇，Surface Pro 的性能还是比 Surface Go 高出一大截的——这里没有给出 Surface Go 的成绩，这款设备的 CineBench R15（多线程）跑分稳定在 160 分左右。Surface Pro 6 的酷睿 i5 CPU（酷睿 i5-8250U）性能提升相比 5 还是相当显著的，就 CineBench 来看，其成绩在长时间跑分后的稳定状态位于 440 分上下；而 Surface Pro 5 （酷睿 i5-7300U）是不到 230 分——持续性能提升超过 90%（相比 Surface Pro 5 有风扇的 i7 版提升约 27%）。Surface Pro 7 的酷睿 i5 版（酷睿 i5-1035G4）持续性能跑在 500 分上下，这个提升幅度算是尚可，不过比我想象得要差。 实际上，从这个曲线也反映了这三代设备的一个共性，最初几轮跑分成绩明显比较高，尤其是第一轮跑分成绩，完全不输给那些带风扇同配的超级本，但在跑到大约第五、第六轮的时候，性能开始直线下滑。主要是因为功耗与温控限制，致设备可持续的频率比峰值状态下的频率低很多。Surface Pro 6、7 这两台四核设备的性能损失尤为显著。 在 NoteBookCheck 的测试中，CineBench R15 测试项，Surface Pro 6 在最初的几秒到几十秒时间里，处理器（酷睿 i5-8250U）频率可以跑到 3.4GHz，很快会降至 2.8GHz；到第四轮测试时，频率降到 2.6GHz；后续则维持在 2GHz。TDP 功耗从最初的 22W 降到 16.5W，并在第六轮测试时降到大约 10W。温控机制会在 CPU 达到 70℃ 时做出限制，最终稳定在 62-64℃（有风扇的酷睿 i7 版则可以让温度推升到明显更高）。 这里值得一说的是 Surface Pro 7 的这颗酷睿 i5，乃是十代酷睿中的 Ice Lake（Ice Lake-U）——而不是 14nm 的 Comet Lake，即采用 Intel 最新的 10nm 制程，而且是新架构，是 Intel 目前最先进的 CPU 产品了。Intel 的十代酷睿有两个系列，分别是持续改良版 14nm 的 Comet Lake 和 10nm 的 Ice Lake；前者是老架构、改良版工艺，后者是新架构、新工艺。当然我们不能认为 10nm 的 Ice Lake 就一定更好，这一点还会在后文中提及。但十代酷睿实际上相较八代酷睿，仍可以认为是一次较大幅度的跨越，因为八代酷睿实则并不像很多媒体渲染得那么好，这一点还将在后文中提及。 Surface Pro 7 的 CineBench R15 成绩最初可以达到 685 分这样的高分，但在后续循环测试中，性能致持续稳定状态则损失了大约 27%。当然我们不能说峰值性能是没有意义的，因为应用运行的很多情况需要的就是短时间内的性能，所以睿频性能的短时突发量还是有价值的。但面对一些高负荷的长时间持续负载时（比如解压大文件、视频 encode 等），Surface Pro 7 也显然没有那么香——毕竟它的 i5 版也没有风扇。 单 CineBench 一项测试其实很难说明问题，不过 AnandTech、NoteBookCheck 这些媒体针对的测试项目不多，而且少有像上面这样的长时间持续性能测试——像 GeekBench 这种短时间内做大量项目测试的基准测试工具，其参考价值有多少是值得多加思索的。AnandTech 测试了更多系统性能项目，如果我们只看较短测试周期的结果，八代酷睿的多核、多线程测试成绩显著领先于七代，比如 x264 转换这种任务；而 web 测试成绩则比较一般。AnandTech 有在评论中提到，Surface Pro 6 无风扇版的 PL2 值被限制在大约 23W，而更多八代酷睿低压本的短时间睿频功耗可以达到 30W——这个说辞应该不狗准确，这还会在后文中提到。 另外 Surface Pro 7 的十代酷睿 i5，表现比我预想的要糟糕，即便它相较同样没风扇的 Surface Pro 6 八代酷睿 i5 已经有不错的提升了。 当对比其他有风扇的设备时 那么这些没风扇的低压超级本，在和有风扇的设备比较时，性能大致是个什么水平呢？这本身就比较考验 OEM 厂商的系统设计水平，比如散热、温控机制等；笔记本的内部设计需要考虑与权衡的因素还很多，不只是性能和效率。实际可参照的设备很多，我们主要来看看不带风扇的 Surface Pro 与微软自家有风扇的 Surface Pro 酷睿 i7 版，以及 Surface Laptop，还有 ThinkPad 的差异。 在展开以前，就只说 Surface Pro 7 的酷睿 i5 版，具体型号 i5-1035G4。这里简单介绍一下这颗 CPU，我原本真的十分看好这次的 i5 版 Surface Pro。Ice Lake 架构（Sunny Cove 架构），10nm 制程，四核八线程，1.1-3.7GHz。Intel 宣称 Ice Lake 有 18% 的 IPC 提升（应该是相比 Comet Lake）。不过大概是因为 Intel 的 10nm 工艺还不成熟，所以 Ice Lake-U 具体到 CPU 的频率普遍都不及 14nm 的 Comet Lake 和 Whiskey Lake。 其他参数包括 6MB L3 Cache；集成核显 Iris Plus——48 EU，300-1050MHz。另外 Surface Pro 7 采用的内存是 LPDDR4x，1866.7MHz，双通道——存储性能理论上也应该是显著优于 Surface Pro 6 的。 可惜它没有风扇，如果和有风扇的超级本比起来，用 NoteBookCheck 的话来说 ，Surface Pro 7 无法维持住睿频太长时间，其多线程性能在最糟糕的时候和酷睿 i5-8350U 类似（参考对象应该是惠普 Elite x2 这种带风扇的超级本），最好时与酷睿 i7-8650U 差不多（对比对象是 Surface Pro 6 带风扇的酷睿 i7 版）。其实总结一下，可理解为 无风扇的 Surface Pro 7 与有风扇的八代低压超级本，持续性能差不多。 但也不能就此给所有无风扇的 Surface Pro 定性。比如 Surface Pro 5 的酷睿 i7 版，也就是有风扇的版本，CineBench R15 无论跑多少轮，成绩都比不上 Pro 6 的无风扇版。这还是要归功于酷睿八代核心数量翻番。处理器本身的提升也是十分重要的。 下面的对比可能不够科学，因为实际的持续性能表现还受制于设备尺寸、外部 ID 设计——这是本文没有考虑进去的；但我向来就是这么的随性。来看一个比较杂的 CineBench R15 性能对比。 这张图加入了 Surface Laptop 2、Dell XPS 13、ThinkPad X390、ThinkPad T490s 这些相对传统的八代酷睿超级本。不难发现，即便是相同的 CPU（这组对比中以酷睿 i5-8265U、8250U 为主），不同的设计可达成的性能表现也是不一样的。这里表现比较好的 ThinkPad T490s（黄色） 能够与 Surface Pro 6（品红色）、Surface Pro 7（深红色）产生很好的对比。要知道 Surface Pro 7 已经搭载了十代酷睿，但持续性能表现却落后于绝大部分八代酷睿超级本。而 Surface Pro 6 则实至名归地在八代超级本中 CineBench R15 测试成绩垫底。 不夸张地说，无风扇设计的 Surface Pro，相比同代有风扇设计同配超级本，平均的持续性能差距可以达到 20-35%，相较一些系统设计十分出色的 14 寸超级本，持续性能差距可达 40%。 留意到 NoteBookCheck 在评测中也提到，"A laptop with ideal cooling is way out of the Surface Pro 6 (2018) i5’s league as the latter was only around 65% as fast." 比如说，ThinkPad T480s（14 寸超级本，酷睿 i5-8250U）在持续负载中就比无风扇的 Surface Pro 快了 35%；即便是更小 12 寸的 ThinkPad X280（酷睿 i5-8250U）在持续性能上也高出约 20%。 没风扇果然是不行的。不过这里还是再次提醒一下，我没有研究过 CineBench R15 内部的具体测试流程，及其测试数据规模，虽然网上说它是个偏 CPU 的测试，但既然作为软件跑在最上层，它一定和整个系统相关；所以还是需要考虑 CPU 以外的其他配置。这样一来，整个系统的对比会比较复杂。 参照下更多酷睿十代（以酷睿 i5-1065G7 为主）低压本的性能表现，如下图。仅供参考——因为这里不同的笔记本在定位、设计上差异甚大，最顶部的 Surface Laptop 3 之所以能有这么好的表现，与其 15 寸的尺寸也有关。NoteBookCheck 目前数据库的十代酷睿测试数据似乎还不够多，所以横向对比的参考价值可能并不大；毕竟 Surface Pro 7 的 i5-1035G4 在规格上还是比表中的 1065G7 要弱一些的。 “真男人时间”短 针对本文开头部分所说，我用的这两台笔记本（ThinkPad X390 i7版/Surface Pro 6 i5版），用 AIDA64 看下这两台设备的 CPU 相关信息。这里我比较关注的是 CPU PL1、PL2 参数（下图中的 CPU Power Limit 1/2）。这两个值表示的是长时睿频功耗上限、短时睿频功耗上限，及其相应的持续时间。这个值与 OEM 厂商自己的设计相关。 ThinkPad X390 ThinkPad X390 这台设备（接 AC 电源、高性能模式下）的 PL2 短时睿频 TDP 设定在 51W，睿频可持续时间 28 秒；长时也有 25W。好像很多酷睿 i7-8565U 都采用类似的设定。这在低压本中仍是十分激进的值，虽然前文也把 X390 归类在超级本中，但实际上这台设备在厚度等 ID 设计上都算不上轻薄。可类比小米 Pro 这种八代本长时睿频 TDP 设定在 44W。 这种本子在一个较短时间内允许 CPU 不受性能约束，尔后便会做限制；44W、51W 这种值都是短时间内当标压设备在用了。这个“短时间”在很多场景下，仍对体验十分有帮助。 不过这几个参数只具有参考价值，因为实际能否达到设定的这些值及最高频率，还与设备的温控机制相关。从我自己的测试来看，ThinkPad X390 实则远远达不到这个程度（不过我做测试十分随意，可能某些变量没有控制到位），默认情况下可在一小段时间内坚挺在 29W 上下（一轮跑差不多在这个功耗下坚持半分钟），频率 3.10 GHz 左右，但 X390 似乎很容易撞温度墙，轻轻松松达到 100℃ 时便会立刻回退至后续长时间的 25W，且温度似乎始终都比较高——只不过在设计上并不影响体验。很多时候，往往 PL2 功耗冲高后，由于温度也会快速上升，最高性能状态也根本就坚持不了 厂商设定的值，有时或许连 10 秒都撑不到——睿频、TDP 极限可坚持的时间，就是所谓的“真男人时间”了。 Surface Pro 6 低配版，需要注意的是，我运气比较好，我买到的 SP6 用的是酷睿 i5-8350U，略好于市面上流通的 8250U Surface Pro 6 在 AIDA64 中查看的这个值 PL2 是 35W，持续时间 2.00 秒？Max Turbo 全核 36x。我自己尝试跑 CineBench R20，并用 XTU 观察数值变化，只跑一轮，Package TDP 坚持在 25W 的时间还算是比较久的，后续功耗限制（DPTF？）后终维持在 17-18W 的水平。这对于一台被动散热设备而言已经相当不错了。尝试用 XTU 把 PL1 设为 35W，则在一轮 CineBench R20 全程，TDP 维持在 25W，温度在 73 ℃上下浮动（室温 15℃ 左右）；长时间的 17-18W，温度在 65℃ 附近浮动。（不过貌似旧版的 Intel XTU 有点小问题，这组数据可能不准确） NoteBookCheck 反复跑 CineBench R15 测试十几二十轮是很有价值的。尤其在 Surface Pro 酷睿 i5 版这类被动散热设备上，前面几轮可以表现出比较好的成绩；但在温度和功耗达到一定值以后，被动散热的效率不高，真男人时间也不再。所以其持续性能会有一个较大幅度的损失。 实际从市面上绝大部分八代超级本的表现来看，在实现时，大部分超级本的“真男人时间”都比较短。而且更悲惨的是，PL1 标定的长时睿频功耗（我手上的 ThinkPad X390 是 25W，Surface Pro 6 也是 25 W）也未必能达到。能够坚守 15W 的八代超级本似乎就不多。Surface Pro 6 在多轮 CineBench R15 测试下最后降到 10W 及以下。 很多拥有主动散热的八代超级本，最终也都达不到 15W 长时睿频，主要原因是其散热设计不过关： Intel 首次在八代酷睿低压 CPU 中将核心数量翻番，对散热设计原本就提出了新的挑战。从笔吧评测室更早的测试来看 ，全力跑 CineBench R11.5/R15 的单线程测试时，酷睿八代 CPU 整体功耗就可能达到或超过 15W——一个核心满载就已经撞功耗墙了；多核心同时跑的频率情况即可想而知。 所以在一大批同系列八代超级本上，酷睿 i5 与 i7 版的持续性能几乎没什么差距，尤其很多 OEM 厂商还在沿用七代本的散热设计方案，则睿频真男人时间极短，过后就是持续降频，甚至在绝大部分情况下都达不到标称最高频率。于是持续高负载时，由于散热设计不过关，导致 i7 的高频能力根本无处发挥。可以想见，即便微软有着十分强大的系统设计能力，Surface Pro 6 的酷睿 i5 板去掉风扇以后，还怎么能撑得起场面。 不过在 i7 版配置上采用风扇，实则的的确确拉开了 i5 与 i7 配置的性能差距，这一点从前面 Surface Pro 的 CineBench R15 持续跑分就能看得出来。让 i5 与 i7 拉开性能差距的方式还果然是与众不同啊，说笑… 另外还说明，不同 OEM 厂商对待八代超级本做设计的认真程度，是可以反映到最终产品的性能表现上来的，ThinkPad （T 系列与 X 系列）属于八代低压本中的佼佼者，即便我也没有测试手头这台 ThinkPad X390 i7 版的真男人时间，以及睿频 TDP 是否如标称这般（以及续航测试在此也显得很要紧）。 十代酷睿，用被动散热会怎样？ 我手上没有 Surface Pro 7，所以并不了解这台设备的情况。从 NoteBookCheck 的测试来看，Surface Pro 7 无风扇的酷睿 i5 版最初跑 CineBench R15 可以飙到 685 分（多核），这个成绩事实上比 Surface Pro 6 的有风扇酷睿 i7 版都还要好；比 Surface Pro 6 无风扇的酷睿 i5 版有 17% 的领先优势。但后续测试由于没有风扇，持续降频，成绩下滑幅度大约有 30%，最终如果就 CineBench R15 测试来看，Surface Pro 7 酷睿 i5 版在持续性能上相比 Surface Pro 6 酷睿 i5 版领先优势不到 15%。而且比 Surface Pro 6 的有风扇酷睿 i7 版弱了将近 13%。 目前网上似乎还没有针对 Surface Pro 7 酷睿 i7 版相对系统的测试数据，所以有无风扇对十代酷睿（Ice Lake-U）造成的影响似乎没有十分直观的比较对象。若以联想 Yoga C940（酷睿 i7-1065G7）这款设计相对比较平庸的十代超级本来对比，则 C940 相比 Surface Pro 7 无风扇 i5 版，有大约 24% 的持续性能优势（但这个对比并不科学，因为 CPU 并非同款），市面上某些 Comet Lake 十代本在绝对性能上差不多也是这样的领先幅度。 PCMark 10 测试，来源：NoteBookCheck PCMark 8 测试，来源：NoteBookCheck 不知该说 Surface Pro 7 无风扇版在系统设计上有退步，还是无风扇的 Surface Pro 6 实际已经达成被动散热的最优设计。无论如何，这次的 Surface Pro 7 在 CPU 持续性能提升幅度上都算是比较有限的。但如果我们这里做个导购建议，则因为 Surface Pro 6 的系统性能实在十分糟糕（如前文所述，存储性能差），PCMark 10 这类测试综合成绩还不如 Surface Pro 5，那么 Surface Pro 7 无风扇 i5 版的可购买推荐指数依然是比较高的。它在 PCMark 10 的综合得分与 Surface Book 2 差不多，甚至还与 Surface Laptop 3 锐龙版差不多，比 Surface Pro 6 带风扇的 i7 版都有 15% 的成绩优势。 不过我总体觉得，PCMark 10/8 可能仍无法代表 Surface Pro 7 的日常使用体验，这里也不清楚 NoteBookCheck 在进行 PCMark 10/8 测试时具体是怎么跑的。所以也在这里给各位作参考吧。 如前文所述，酷睿十代包括了两个版本，分别是改进版 14nm 工艺，架构不变（Skylake）的 Comet Lake；以及采用 Intel 最新 10nm 工艺，架构变为 Sunny Cove 的 Ice Lake。这里不再具体谈十代酷睿的具体表现，不过就已上市 Comet Lake-U 的超级本来看，Comet Lake 架构没变、工艺也基本没变的情况下，其实际表现比八代的 Whiskey Lake 虽无同频性能的太大提升，但同频功耗降低不少；在相同散热条件下，Comet Lake-U 能够提升 15-20% 的性能 。 就这方面的表现来说，Comet Lake 似乎是对 14nm 四核低压处理器的一次完善和补足，或者说可能在八代酷睿低压 CPU 核心和线程数目翻番显得过于匆忙时，在十代 Comet Lake 身上完成了一次比较出色的修正，让四核低压 CPU 真正步入成熟。（本文未探讨六核低压 CPU） 不过去年更新的 Surface 系列采用的十代酷睿并非 Comet Lake 版，而是 Ice Lake 版——也就是新工艺、新架构的版本，听起来好像更美好了。但前文就提到了，可能是 Intel 的 10nm 制程还没有那么成熟（后续我打算把 WikiChip Fuse 针对 Intel 10nm 工艺的文章翻译过来），虽然 Intel 宣称 Ice Lake 有 18% 的 IPC 提升，但市面上的 Ice Lake CPU 在最高频率方面不及 Comet Lake。 来源：笔吧评测室 从笔吧评测室的测试数据来看 ，3.5GHz 的 Ice Lake-U 差不多等于 4GHz 的 Comet Lake-U。实际上如果对比同频功耗，Ice Lake 是略高一点的，但 Ice Lake 的同频性能也更高。按照同性能来比较功耗，Ice Lake 还是胜出的（Uncore 以及核显的功耗会明显更高，此处 Uncore 也因为有了四个 Thunderbolt 3 原生支持故功耗更高）。 来源：笔吧评测室 以功耗为尺度做衡量，则在 PL1/PL2 为 15W/25W 的超级本上，Ice Lake 的性能会略低于 Comet Lake；但达到 35W 及更高时就会超越。就这个角度来看，Surface Laptop 3 采用 Ice Lake 应该还是个相当不错的选择；但 Surface Pro 7 的无风扇酷睿 i5 版也选择 Ice Lake，实际就有那么点小问题了。 但就上面我援引的各种数据来说，Surface Pro 7 无风扇酷睿 i5 版在 CPU 性能方面比 Surface Pro 6 高出 14-17% 之间（峰值和持续性能），这实际完全符合在相同散热设计下，十代酷睿（Comet Lake-U）比八代酷睿（Whiskey Lake-U）强约 15% 的预期，而 Ice Lake 在较低功耗设定下的性能相较 Comet Lake 没有优势，所以 Surface Pro 7 的表现完全符合预期。或者说 Surface Pro 6 可能已经在12寸设备上做到了被动散热的最优设计，Surface Pro 7 则延续了这一传统。 当然，在 Surface Pro 体系内，无风扇的被动散热大概的确做得不错，只是被动散热一定意味着性能会打折扣。 另外这里再分享一篇我觉得很有意思的文章，AnandTech 前不久参加 CES 2020 的 Intel 的主题演讲 。Intel 在会上对比了自家低压 Comet Lake/Ice Lake 与 AMD Ryzen Mobile 3000 系列，表明自家产品性能、特性领先多少。不过这不是重点，实际上这个对比结果也没什么奇怪的，从 Surface Laptop 3 的酷睿版和锐龙版比较，就能看出在低压版 CPU 的这一局，Intel 还是有相当优势的。 不过在这个对比中， AnandTech 发现，Intel 分别发布了两张 PPT，一张对比 Comet Lake 与 Ryzen Mobile 3000，另一张对比 Ice Lake 与 Ryzen Mobile 3000。三个对比对象分别是酷睿 i7-10710U、酷睿 i7-1065G7，以及 AMD Ryzen 7 3700U。而自家 Comet Lake 与 Ryzen Lake 却没有直观对比。AnandTech 觉得十分好奇，于是他们将两张 PPT 上的成绩放到了一起，一次来比较十代酷睿的两个版本究竟表现如何，如下图所示。 来源：Intel via AnandTech Intel 宣称这些测试项是最能代表“真实环境的测试”。不过在包括 PCMark 10、WebXPRT 在内的测试中，Comet Lake 在前四项测试中都胜出，浏览器测试（PCMark10 Edge）基本是平手；WebXPRT 浏览器测试两者得分也相近，Ice Lake略胜。Office 真实测试也是对半开，Word 测试互有胜负（PPT PDF 导出测试，Comet Lake 的优势似乎还不小）——比较奇特的是这里的 Powerpoint 转为 1080p 视频测试，日常不知道有谁会这样操作；Photoshop 测试完全打平；至于 Topaz Labs AI 测试，这应该属于小众测试——而且 Intel 还和这家软件供应商合作进行了 GPU 加速（说好的真实环境测试呢？）。 总结一下上表的对标情况。Comet Lake 的这枚六核心的酷睿 i7-10710U 可以达到 4.7GHz 的睿频，而代表 Ice Lake 的四核酷睿 i7-1065G7 最高频率限制在 3.9GHz。即便后者 IPC 有 18% 的优势，也足以被频率和核心数差异抵消。比如 Office 负载，i7-10710U 可以同时开 12 个线程，这其实还是有很大优势的。 所以就现阶段来看，如果单论性能，则在具体的 CPU 产品上，Comet Lake 仍是更加成熟的选择——即便它采用的是旧架构和旧工艺。另外 Ice Lake 引入了一些消费用户暂时不怎么用得到的东西，比如说 AVX-512 指令原生支持——在现有某些特定冷门项目上，Ice Lake 估计可以获得更好的成绩。这么看来，如果真的说“真实环境测试”，则 Comet Lake 也是优选。虽然这种局面大概是 Intel 不怎么愿意看到的。 最后展望一下今年的 Surface Pro：其实去年发布的 Surface Pro X 真的挺好看，我倒是不在意设备厚不厚，而在意 Surface Pro 的屏幕太小了；Surface Pro X 就弥补了这个短板，屏占比增大了，屏幕变大了。无奈 Surface Pro X 是台 Arm 设备，知乎有几篇谈 Pro X 使用体验，以及 x86/x64 转 Arm64 效率的测试文章，至少现在 Arm 平台的 Windows 本体验是真的不好的。 我觉得很有理由相信，x86 平台的 Surface Pro 在屏幕、外观方面也会有类似 Surface Pro X 这样的升级，或许 Surface Pro 8 身上就能看到。还有一点，AMD 在前不久的 CES 大会上发布了 Ryzen 4000 系列 APU，这仍然会对低压超级本市场产生一次性能、效率上的冲击。Intel 计划中的 Tiger Lake 在路上。不确定 Surface Pro 8 能否赶得上。其实感觉这两年由于 AMD 的搅动，即便“摩尔定律放缓”，桌面 CPU 市场也焕发了一波生机。2020 年的 Surface Pro 或许会具有极大的吸引力。 最后的最后，总结一下本文的一些推论： 1. 无风扇设计的 Surface Pro 在持续性能上，会明显弱于同时代同配置的其他主动散热超级本；持续性能差距可以达到 20-35%。 2. Surface Pro 的酷睿 i5 版与 i7 版性能差别会比较大，这和其他品牌超级本的情况很不一样； 3.微软可能已经在 Surface Pro 被动散热设计上做到了最优化； 4.Surface Pro 6 相比 Pro 5 实现了一次性能飞跃； 5.Surface Pro 7 无风扇酷睿 i5 版的升级还是相当值得的，尤其系统性能提升比较大； 6.即便十代酷睿的 Ice Lake 用上了更好的工艺、更新的架构，但 Comet Lake 仍然拥有更出色的成熟性，和更实用的性能； 7.未来的 Surface Pro 8 可能相当值得期待，或许 Surface Pro 8 可以实现性能与外观（屏幕尺寸）的双重飞跃。 这里再多说一句，虽然本文花了比较多的篇幅在说被动散热的 Surface Pro 相比同配置超级本性能更孱弱，但我从未对于购买 Surface Pro 无风扇版的设备后悔——只不过我更加认识到 Surface Pro 的 i5 和 i7 版价格差别较大还是有原因的。对于无风扇设计，微软大约也有自己的想法。毕竟移动、安静本身就需要付出代价，就好像超级本的性能远弱于游戏本——但价格却依然可能很高，这是一样的道理，看你愿意为何种元素买单罢了。 ---- 注：有热心市民提醒，NoteBookCheck 的测试没有交代测试具体环境，尤其是室温：室温实际对于持续性能影响也很大。在看本文时，请留意此信息的缺失！所以 20-35% 这一数字值得商榷。 我猜 NoteBookCheck 应该有相应的文档来解释测试环境，但我太懒了，不想去看了，有兴趣的同学自己可以去翻一翻。 参考来源及推荐阅读： Microsoft Surface Pro 6 (2018) (i5, 128 GB, 8 GB) Convertible Review - NoteBookCheck Intel’s Confusing Messaging: Is Comet Lake Better Than Ice Lake? - AnandTech Microsoft Surface Pro 7 Core i5 Review: More Like a Surface Pro 6.5 - NoteBookCheck 美丽的谎言——8代Intel低压4核性能测试 - 笔吧评测室 Intel 10代酷睿移动版性能测试(一)—— CometLake-U 4核 - 笔吧评测室 intel 10代酷睿移动版性能测试(三)—— IceLake-U 核心篇 - 笔吧评测室

1).  简介 在这篇博文中，我将介绍 IoT 停车演示系统以及其所用到的技术。我会阐述如何使用 Azure IoT Hub 在 Azure服务和设备之间发送消息，就像我们的演示系统那样。针对演示中用到的ARM系统模块，我也会做简单的介绍，但是主要还是专注于 Azure IoT Hub 以及如何方便地收发消息。如果你想更了解多关于 Azure IoT Hub 的信息，请点击 这里 。   在我们的演示系统有多个设备，例如： ./ 停车场 1（名为 Stretnor） ./ 停车场 2（名为 heater Parkhouse） ./ 公告显示（每个停车场独立设备）   每个停车场包含以下多个设备：   ./ 闸门控制器（Toradex  Colibri T30  ARM计算机模块系统（基于nVidia Tegra 3）运行 Win10 IoT） ./ 停车控制器（Toradex  Colibri VF50  运行ARM计算机模块系统（基于NXP Vybrid）Windows Embedded Compact 2013） ./ 支付终端（ Apalis iMX6  ARM计算机模块系统（基于NXP iMX6）运行 Linux 和 Qt） ./ 公告显示（ Colibri iMX6  ARM计算机模块系统（基于NXP iMX6）运行 Windows Embedded Compact 2013）   正如你在上面图片中看到的，所有的通信消息通过 Azure IoT Hub 发送至应用服务进行处理。你也注意到我们在 Azure 运行了网页和数据库，但是这个篇博文只介绍 Azure IoT Hub 部分。   2). IoT  停车场演示系统消息流 由两个基本的事件会触发设备和 IoT Hub 之间的消息流。 a). 第一个事件是当有车辆抵达闸门（参考下图）： 当车辆抵达闸门时，闸门控制器会扫描车牌，向 IoT Hub（1）发送消息。在应用服务确认数据后，会向闸门控制器发送消息，开启闸门（2）。与此同时，指示停车位的消息也会发送至停车控制器（3）。停车控制器会开启红色 LED 灯闪烁，表示该停车位即将被占用。支付终端也将会收到消息。这个消息包括车牌号和抵达时间（4）。同时，公告显示器收到关于该区域里所有停车位的信息（5）。 当车辆停在停车位时，停车控制器停止红色 LED 灯闪烁，向 IoT Hub 发送车辆已经停靠的消息（6）。此时，闸门控制器被告知关闭闸门（7）。   b). 第二种事件是车辆离开停车位： 当车辆离开停车场的时候，司机首先需要支付停车费。在支付终端上，司机选择他自己车辆的车牌后支付。请求支付的消息发送至 IoT Hub（1）。应用服务计算价格，并发送到支付终端（2）。当支付终端接收付款后，发送支付成功的消息至 IoT Hub（3）。应用服务把车辆即将离开停车场的送消息发送到停车控制器（4）。停车控制器开始闪烁绿色 LED 灯。当车辆从停车位上离开后，IoT Hub 收到车辆已经离开的消息（5）。停车控制器打开出口闸门。在一段时间后，闸门关闭，一个指示停车位空闲的消息发送到 IoT Hub。之后，公告显示上也更新所有停车位的信息（6）。   3).  例程应用 在下面的例程中，我将向你演示如何方便地于 Azure IoT Hub 通信。你需要基本的 C# 知识来理解这个例程。如果你想要编译应用，请使用 Visual Studio 2015。 你同样也需要 Azure 账户来运行例程。你可以创建一个免费的 Azure IoT Hub，并在你的 Azure IoT Hub 上创建设备。使用 device explorer 完成这些任务。在 这里查看 device explorer 文档。 这里我将演示一个小的服务器应用，从 IoT Hub 获取消息并处理。代码是很简单的，并不适用于生产环境。这仅仅是向你介绍如何方便地同 Azure IoT Hub 通信。在这个代码里，我们只接收来自设备的信息，并将新的消息发送至同一个设备。 你需要使用你的连接字符串来修改服务器端的代码。 ----------------------- private const string CONNECTION_STRING = ""; ----------------------- 正如你在代码中看到的一样，我只调用了 TDXServerEmulator 类中的 connect 方法 ----------------------- TDXServerEmulator ServerEmulator = new TDXServerEmulator(); ServerEmulator.Connect();  -----------------------   这会处理接收和响应消息。 为了使用客户端，你需要 Azure IoT 的 URL 替换成你自己的。Device.cs. ----------------------- const string iotHubUrl = ""; ----------------------- 在客户端代码中，创建新的 Device 对象，注册 OnMessageReceived 事件。这能够使你的设备收到来自 Azure IoT Hub 的所有消息。 ----------------------- Device client1 = new Device("", ""); client1.OnMessageReceived += Client1_OnMessageReceived; client1.Start(); ----------------------- 接下来，你可以运行例程。两个终端串口会在程序执行之后出现。你需要等待服务器应用连接。 在服务器连接后，你可以在应用中选择 “Send Hi” 。 在上面的图片中，你可以看到客户端发送“Hi”。服务器接收到来自客户端的消息后，用“Hi from IoT Hub” 消息作为响应。 就像你在代码中看到的一样，同 Azure IoT Hub 通信和发送消息是很容易的。对于复杂的应用，还有许多可以改进的地方，这当然也会使得代码变得更加复杂。 通过以上的代码和解释，你应该可以使用 Azure IoT Hub 开发简单的应用。所有  Toradex ARM计算机模块  均支持 Azure IoT Hub。你可以在 这里了解 Toradex 模块的支持类型。你也可以下载 WinCE 和 Linux SDK。

By Toradex Leonardo Graboski Veiga 1).  简介 物联网（Internet of Things）概念的本质其实就是关于发送数据到网络，所以称为云服务。随着时代发展和技术进步，人们可以使用尺寸更小功耗更低的电子设备并很容易的连接到云端，不过有一个问题却始终困扰着电子工程师们：如何使用这些获取的数据？而这正是物联网的主题。 在 Microsoft主页 上面有一些实际的应用例子来展示IoT的应用：一个电梯公司通过物联网来改善并提供预先维护；一个工业自动化公司通过物联网深入了解油气产业供应链，同时提供预先维护；还有一个公司通过IoT预测驾驶人员行为然后优化汽车利用。在读完这个系列文章后，我们期待读者可以拥有足够的知识和工具去部署应用来深度检视同时优化整个系统 – 不仅仅是积攒了一堆数据，而是从中获取了有用的结果！ Azure 是Microsoft提供的云服务平台，提供了多种应用如数据库，虚拟机，应用服务，机器学习，数据流分析，媒体和CDN服务，大数据解决方案，以及包括IoT Hub的其他众多应用。就其提供的大量应用本身已经是使用Azure服务的很好理由，但Microsoft更进一步通过和Amazon Web Services的 对比 来进一步证明其方案是更好的 – 和前面相反，这是一个通过用户和时间来确认的强有力宣言。另外，高安全性，易于整合以及容易上手也是选择Azure服务的另一个理由。 本系列文章通过开发一个IoT应用，从读取现场传感器数据，展示数据到获取商业智能（BI）。所使用的用来连接传感器以及上传数据到云端的平台： Azure IoT certified partner  Toradex 的 Colibri VF61 计算机模块 +  Iris Carrier Board 。应用程序获取传感器数据然后上传到来自Microsoft Azure云解决方案的一个叫做Azure IoT Hub的IoT服务，然后就可以被各种所需要的Microsoft Azure服务来处理。这部分内容将在本系列文章的第二部分着重讲解，在此我们主要关注在如何配置Azure IoT Hub以及上传数据到它上面。 我们选用的IoT环境为模型车监控。为了演示方便，将Toradex平台和传感器置于遥控模型汽车内，如下图1所示；而图2则给出的目标应用的框图。   图1 ：遥控汽车   图2 ：应用框图 我们所选用的应用编程语言为Javascript 配合Node***: 一个服务器端(本文中即Toradex嵌入式系统)基于Chrome V8 引擎编译的Javascript解释器。这个选择是考虑到Azure IoT Hub SDKs 可以提供的开发库。但是需要注意的是现在IoT Hub SDKs正处于频繁更新中，每一次更新都会有些改变（至少Node相关），所以在使用前需要考虑清楚。本文所使用的Azure IoT Node包版本为1.0.1。 整个环境的搭建，从开发嵌入式系统应用，到配置Azure来获取数据我们分为3个主要步骤，下面会分别介绍： ./  配置Azure 环境 ./  添加设备并发送信息到IoT Hub ./ Toradex 嵌入式系统应用开发   2).  配置 Azure 环境 首先需要创建一个新的Azure账户：从Azure 网站可以申请30试用的免费账户。然后就可以使用账户里一定数目的信用额度来免费部署应用使用Azure 服务；同样，IoT Hub也有一个用于开发的包含有限资源的免费版本，且不受试用期限制。关于价格和IoT Hub的详细信息，请见 这里 。 设置好Azure账户后，需要创建IoT Hub。用新创建的Azure账户登陆Azure portal，选择 +New Internet of Things Azure IoT Hub。新的IoT Hub配置界面如下图3所示，“Pricing and scale tier”选项需要选择“Free”；然后在“Resource Group”选项创建一个新的资源组，另外“Location”选项需要和后面部署的服务保持一致；“Name”可以自由设定，而“IoT Hub Units”和”Device-to-cloud“选项在免费版本中则无法修改。点击“Create”后，服务就被部署了，这个过程可能需要几十秒时间。   图3 ：从Azure Portal 创建IoT Hub 上面操作完成后，可以看到IoT Hub已经出现在控制台，也就是 Azure Portal主页 。点击后，如下图4所示页面会打开：里面包含“Essentials” 是如IoT Hub地区等基本信息；“Usage”是提供给系统管理员注册设备数目以及从设备发送信息数量的反馈信息；“Monitoring”是显示收到信息数量。   图4 ：IoT Hub  主面板 仍然在IoT Hub主面板上，为了让其他应用也可以访问服务，”Settings“选项卡里面的“Shared access policies“选项需要被选中。在新打开的” Shared access policies“选项卡中，点击“iothubowner”规则选项，这个包含了本IoT Hub所有可能的权限。如下图5所示，“iothubowner”选项卡会打开，然后复制”Connection string – primary key”对应的内容留作后用：这个是下一步用于管理和监控这个IoT Hub服务的钥匙。   图5 ：获取iothubowner connection string   3).  添加设备并发送信息到 IoT Hub 现在云端设置已经完成，我们需要在开发主机上面安装 iothub-explorer 工具来添加设备到IoT Hub，另外如果开发主机是Windows的话，也可以选择 Device Explorer 工具。鉴于本文所使用的开发主机系统为Ubuntu 14.04，我们采用iothub-explorer。需要注意所需Node版本为0.12.x或以上（根据说明如需全部功能工作需要4.x或以上版本），但目前apt-get工具只能安装0.10.x版本。为了解决这个问题，需要先后安装Node Version Manager（NVM）和Node 版本0.12.9. 然后在终端中使用NPM（Node Package Manager）来安装iothub-explorer。 --------------------- $ npm install iothub-explorer@latest --------------------- 然后可以运行iothub-explorer help参数来查看使用方法 --------------------- $ iothub-explorer help --------------------- 根据上面命令的打印结果，iothub-explorer 包含有create和monitor事件参数。首先，我们配合上面图5中获取的connection string使用iothub-explorer工具来创建一个设备“tdx_iot_car”。注意“--connection-string”参数用来显示设备connection string （和图5中获取的IoT Hub connection string不同），这个也需要保存下来用来连接这个新创建的设备到IoT Hub，是的可以使用Colibri VF61应用来发消息到Hub。 --------------------- $ iothub-explorer "HostName=toradex.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=putyoursharedaccesskeyfromtheconnectionstringhere" create tdx_iot_car --connection-string Created device tdx_iot_car - deviceId:                   tdx_iot_car generationId:               635931262207620183 etag:                       MA== connectionState:            Disconnected status:                     enabled statusReason:               null connectionStateUpdatedTime: 0001-01-01T00:00:00 statusUpdatedTime:          0001-01-01T00:00:00 lastActivityTime:           0001-01-01T00:00:00 cloudToDeviceMessageCount:  0 authentication: SymmetricKey:       primaryKey:   somesharedaccesskeyreturned       secondaryKey: somesecondaryaccesskeyreturned - connectionString: HostName=toradex.azure-devices.net;DeviceId=tdx_iot_car;SharedAccessKey=somesharedaccesskeyreturned ---------------------   4). Toradex 嵌入式系统应用开发 现在来设置 Colibri VF61  计算机模块 +  Iris 载板 。本文中使用Toradex发布的预编译Linux image（ Colibri_VF_LinuxConsoleImageV2.5 ），如何刷写image到模块请参考 这里 。然后请参考下面步骤安装Node***, NPM 包和git – 安装过程需要一些时间，尤其是curl步骤。 --------------------- # opkg update # opkg install nodejs # opkg install tar # curl -L https://www.npmjs.com/install.sh | sh # opkg install git --------------------- 本文所展示的例程（send_data***）相关packages installer和node文件存放于 这里 ，可以通过下面命令将其clone到目标板上面并安装node packages --------------------- # git clone https://github.com/leograba/azure-iot-car.git # root@colibri-vf:~# cd azure-iot-car # root@colibri-vf:~# npm install --------------------- 现在我们可以在目标板上面运行例程向IoT Hub发送数据，但有几点需要解释下：例程使用HTTP协议通讯，但AMQP和MQTT协议也是支持的；变量“connecionString”数值必须和上面用iothub-explorer工具创建新设备时候所保存下来string一致： --------------------- var connectionString = "HostName=toradex.azure-devices.net;DeviceId=tdx_iot_car;SharedAccessKey=somesharedaccesskeyreturned" --------------------- Setinterval()循环函数随机产生数值发送到IoT Hub, 用来模拟传感器数据，如温度，声纳传感器距离数据，加速度和陀螺仪传感器，一些gps坐标数据和来自目标板的时间日期等。如何从真实传感器获取数据将在这个系列文章的下一篇进行说明。JSON Stringify() 函数用来产生一个JSON编码数据串，然后封装于Message object用于发送。下面是一个JSON格式数据串示例： --------------------- {"ObjectName":"toradex2", "ObjectType":"SensorTagEvent", "temp":24.889683, "acceleration: {"accel_x":10.018892,"accel_y":0.039468,"accel_z":-0.081328}, "gyroscope": {"gyro_x":-0.0532362,"gyro_y":-0.01597086,"gyro_z":0}, "distance":0.17017, "boardTime":1458064972706} --------------------- 正常情况下，在程序运行时候sendEvent()函数里面的callback函数不应打印任何串口输出。下面是在Colibri VF61上面运行程序并正常工作时候的串口打印输出： --------------------- # node send_data*** sending message to the IoT Hub sending message to the IoT Hub sending message to the IoT Hub sending message to the IoT Hub sending message to the IoT Hub sending message to the IoT Hub sending message to the IoT Hub sending message to the IoT Hub --------------------- 为了确保数据被收到，在Azure Portal IoT Hub面板会显示每天的消息计数，同时监控图表上面会有尖峰显示，如下图6所示。需要注意这些信息大概需要几十秒才会在portal上面显示出来。   图 6:  在Azure Portal 中确认数据被收到 另外，也可以使用iothub-explorer工具通过“monitor-event”参数配合device id来查看发送到IoT Hub的数据流，不过需要Colibri VF61程序要同步运行，而通过Azure Portal查看则不需要。下面图7展示了iothub-exploer收取目标板发送数据情况，上面是具体监测数据命令： --------------------- $ iothub-explorer "your_iothub_connection_string" monitor-events yourdevice ---------------------   图7 ：用iothub-explorer 收取目标板发送数据   5).  总结 Microsoft Azure网站上面提供了很多文档用于帮助用户开发更复杂和稳固的应用。参考这些文档可以从中获取更多有用信息，如创建一个设备，或者从Hub获取设备发送的数据是可以通过编程来完成的。另外，在接下来的文章中我们将侧重连接真实传感器到Colibri VF61 + Iris载板，并传输真实传感器数据到IoT Hub, 这个也可以用作其他Azure 服务来给设备部署应用提供深度检视或变量操控。 我们希望通过本文可以让用户了解并最终使用Toradex 嵌入式系统方案配合Auzre IoT Hub服务，然后从中获益。同时，我们也想在这里感谢来自巴西的Grupo Viceri团队在Azure and Business Intelligence上面的丰富经验最终促成了这个IoT Car 项目。 本文最初发表于Embarcados.com， Portuguese，详见这里。

Toradex日前宣布已经加入Microsoft Azure Certified for Internet of Things (IoT), 以便为客户快速开发和部署IoT解决方案提供一套验证了的软硬件平台。Microsoft Azure Certified for IoT 授权允许Toradex和客户建立联系，并提供一个设备和平台的生态系统，最终快速实现产品量产。 Toradex公司致力于基于计算机模块和载板架构的可靠且紧凑的嵌入式计算平台解决方案，广泛应用于各种工业领域如工业自动化，医疗，汽车，机器人等。Toradex所提供的模块化产品使客户可以快速可靠的部署一个从前期方案验证到最后产品量产都适用的平台解决方案而无需重新设计计算平台，这样既减少了开发风险同时又加快了量产进度。 “Microsoft Azure Certified of IoT 证实了我们有能力给客户IoT项目提供一个验证了的包含硬件和操作系统的平台方案，无需大量兼容性相关定制工作使Toradex可以快速帮助客户实现IoT项目”来自Toradex CEO，Stephan Dubach。 “Microsoft Azure Certified of IoT，借助于这些全球领先的合作伙伴可信赖的技术方案，可以帮助我们更快实现IoT规模化部署的承诺” 来自Microsoft GM of Data Platform and IoT，Barb Edson。 IoT项目的复杂度使得客户需要花较长时间去寻找并连接合适的设备或传感器到云端，而如果选择一个合适的经过Azure IoT认证的合作伙伴平台方案则可以大大缩短项目开发周期并有效降低开发风险，因为这个方案已经被验证过可以非常好的配合Azure IoT Suit工作。   经Azure IoT授权的Toradex产品列表如下：   Azure IoT相关上手指南和SDK介绍请见 这里 ，另外Toradex近期也会举办一次网络研讨会“Getting Started with Azure IoT on Devices”，请从 这里 注册参加。   关于 Toradex ： Toradex 是一家领先的 ARM 系统模块厂商，其模块可以广范用于嵌入式产品应用领域。通过采用 Freescale® i.MX 6 Vybrid™, NVIDIA® Tegra 以及其他先进的处理器，系统模块产品系列在价格、性能、功耗和接口方面提供丰富的选择。 凭借超过 10 年的长产品生命周期、终生免费的产品维护、可扩展性能的引脚兼容产品系列、直接高级技术支持和价格透明的在线销售，Toradex 在嵌入式计算市场脱颖而出。成立于 2003 年，总部位于瑞士霍尔夫，Toradex 公司网络已经遍布全球，在美国、越南、中国、印度、日本和巴西均设有办事处。更多的信息，请访问： https://www.toradex.cn。

Microsoft Lumia 950 XL，作为一款基于WIN10，支持USB TYPE-C接口并能够基于USB PD协议输出DP高清视频的手机。我们看到的，不仅仅是一款手机，而是微软帝国再次崛起的前兆。通过USB TYPE-C DOCKING，win10手机，可以接上显示器以及无线键鼠，秒变PC。WIN10作为一个跨平台，云支持的操作系统，为移动终端和PC提供了一致的体验，真正实现了个人智能终端的一体化。在此，我们先看看Apple在2015年初随macbook一同推出的一款配件—TYPE-C DOCKING。     001.png (16.15 KB, 下载次数: 0) 下载附件 半小时前 上传     图1 APPLE官方TYPE-C DOCKING 在TYPE-C接口出现以前，这类产品，通常被叫做HUB，而DOCKING与hub的不同，主要体现在，hub是用作信息分发，DOCKING则是一个补给站，除了分发USB、音视频信息，还能够带来电能补充、网络接入等，此外，TYPE-C独有的ALT MODE还能够通过自定义引脚电气特性带来更多的可能。我们可以想象一下DOCKING与手机结合之后所产生的后果。手机通过TYPE-C DOCKING接上充电器、HDMI显示器、无线键鼠之后与PC无异。WIN10以及类似的跨平台操作系统，为用户带来手机、PAD与PC应用的无缝衔接。当然，更长远来看，无线HDMI/USB数据传输技术以及无线充电技术的普及将会取代TYPE-C接口，让有线接口的时代彻底终结。 下面让我们来看看TYPE-C DOCKING技术实现的具体细节，以更好的理解整个过程(以LDR6023  USB PD控制芯片的控制策略为例)。 情况一，只有一个DOCKING配件插入电脑，没有电源及HDMI显示终端插入。这种情况最为简单，配件将与传统的HUB完全一致，从主机获取电源和USB数据。此时，我们插入一个TYPE-C接口的电源到DOCKING。 DOCKING的主控芯片LDR6023在检测到正确的外接电源之后，需要把供电角色切换过来，通过USB PD通信协议向主机发送Power role Swap命令，把自己变为电源(SRC)，而主机变为负载(SNK)。切换成功之后，LDR6023会在适配器和电脑之间，来一个PD信息透传，即把适配器的Source_cap(电源功能能力，通常为电源适配器支持的若干级电压和电流信息)广播信息传递给主机。主机接收到这个信息后，从中选择一档适合自己的电压，并发送Request数据包。DOCKING收到数据包后，传递给电源。电源收到后，调整自己的输出电压至主机请求的值。这样就完成了DOCKING在电源传输方面对电源和主机之间的透传。     002.png (83.42 KB, 下载次数: 0) 下载附件 半小时前 上传     图2 APPLE MACBOOK与DOCKING的供电协商过程(由LDR-PD01抓取) 情况二，TYPE-C电源先插上DOCKING，然后DOCKing插入到主机，这种情况下，DOCKING一插进来已经是SRC，即供电端。但是，这种情况下，USB数据分发功能将无效(因为SRC默认为DFP即HOST角色，导致了主机不认为DOCKING是一个UFP即Device)，为了让主机把数据传输过来，DOCKING需要通过USB PD命令向主机发出Data Role Swap请求。主机接收到这个请求之后，会切换自己的数据角色，转为DFP即HOST，则从主机到DOCKING的数据通路就被打通了。 情况三，在外接电源和主机，并正常工作的情况下，电源突然被拔出。这种情况是非常糟糕的，因为一旦掉电之后，DOCKING就需要在有限的时间之内，快速的通过POWER ROLE SWAP命令向主机申请电源供应，重新回到情况一的状态。 在以上三种情况中，只要HDMI接口有显示终端接入，都将会触发DOCKING向主机申请VDM通信，并进入ALT MODE，在这种模式下，USB TYPE-C接口的6根pin，将会被定义为DP数据及控制信号传输通路(注意，并不影响另外6根线进行USB 3.0和USB2.0的数据输)。     003.png (33 Bytes, 下载次数: ) 下载附件 半小时前 上传     图3 苹果官方DOCKING与MACBOOK之间的ALT MODE协商(由LDR-PD01抓取) 从以上过程我们可以看出DOCKING是一种非常贴心的外设，能够让消费者体验多种使用模式切换的无缝衔接，未来将会衍生很多应用场景。PAD，NOTEBOOK都可能会退化成手机的DOCKING，即，可以通过TYPE-C接口，或者无线接口成为手机的显示终端、输入工具以及充电补给站。当然作为手机配件来说，苹果的这款DOCKING显得太过臃肿，我们可以通过一些技术，设计一些非常小巧的DOCKING，例如下图：           图4 业界最小的DOCKING适用于手机可以按此板开模 这款乐得瑞科技利用LDR6023设计出来的全球最小体积的USB TYPE-C DOCKING，就代表了TYPE-C手机时代的DOCKING潮流。