性能提升 3 倍的树莓派 4,被爆设计缺陷!

原文链接:https://data.newrank.cn/m/s.html?s=NykqPTA9Li5J

640?wx_fmt=gif

【程序人生 编者按】「麻雀虽小,五脏俱全。」作为嵌入式开发者、创客,在 Raspberry Pi 4 隆重登场之际,你还能坐得住吗? 

640?wx_fmt=jpeg

整理 | 屠敏

出品 | CSDN(ID:CSDNnews)

一直以来,素有世界最小电脑之称的 Raspberry Pi(树莓派)是一种独特的存在。它不仅只有一块信用卡般的体积,还具备主机电脑所具备的功能,如运行 Linux、Windows IoT 系统或上网、打游戏、看视频等等。

近日,这个极受开发者追捧的树莓派迎来了最新一代的硬件与软件更新,即 Raspberry Pi 基金会于官网正式宣布 Raspberry Pi 4 Model B 的到来。这是一次全面的升级,单从性能上来看,Raspberry Pi 4 为大多数用户提供类似 PC 的性能级别,同时保留了经典的 Raspberry Pi 接口功能;另外再从价格来看,开发者喜大普奔,售价与此前相同,也是 35 美元(约人民币 240 元),同时 Raspberry Pi 4 还提供 1GB、2GB、4GB 内存容量选择,其中顶配需要 55 美元(约人民币 378 元)。

640?wx_fmt=png

接下来,我们将一睹 Raspberry Pi 4 的别样风采。


640?wx_fmt=png

Raspberry Pi 4 的蜕变


事实上,自 2012 年 2 月份初代 Raspberry Pi 诞生至今,它的外形并没有做过大幅度地调整,对此,Raspberry 官方也表示,一直在努力保持这种外观。不过相较于上一版,Raspberry Pi 4 还是对外形进行了少量的调整以适应一些新的功能。

硬件更新

640?wx_fmt=png

  • Raspberry Pi 4 采用了1.5GHz 四核 64 位 ARM Cortex-A72 CPU,型号为博通 BCM2711 Soc,对此,官方表示,这比上一代树莓派 3 Model B+ 性能提升近 3 倍

  • 功率改进:Raspberry Pi 4 的充电端口从曾经的 USB micro-B 变成了 USB-C 。因为这支持额外的 500mA 电流,这样即使在 CPU 负载过重的情况下,也能确保为下游 USB 设备提供完整的 1.2A;

  • 视频输出:为了适应现有电路板占地面积内的双显示输出,树莓派 4 用一对 D 型(微型)HDMI 连接器取代了 A 型(全尺寸)HDMI 连接器;

  • 全吞吐量千兆以太网和两个 USB 3.0 、两个 USB 2.0 端口:Raspberry Pi 4 千兆以太网 magjack 从右下方移动到电路板的右上方,大大简化了 PCB 布线。4 针以太网供电(PoE)连接器保留在同一位置,因此 Raspberry Pi 4 仍然与 PoE HAT 兼容。主 SoC 上的以太网控制器通过专用 RGMII 链路连接到外部 Broadcom PHY,从而提供全部吞吐量。USB 通过外部 VLI 控制器提供,通过单个 PCI Express Gen 2 通道连接,并提供总共 4Gbps 带宽,在四个端口之间共享。电路板右侧的所有三个连接器都在边缘上方延伸了一毫米,以简化外壳设计。在所有其他方面,连接器和安装孔布局保持不变,确保与现有 HAT 和其他附件兼容;

  • 双频 802.11ac 无线网络;

  • 蓝牙 5.0

  • 双显示器支持,分辨率高达 4K;

  • VideoCore VI 显卡,支持 OpenGL ES 3.x;

  • 支持硬件解码 4Kp60 的 HEVC 视频

  • 整体重量只有 46 克;

  • 在硬件配件上,官方还提供了一套完整配件,其中一个 4GB Raspberry Pi 4、键盘鼠标、入门教程、SD 卡、数据线等附件的套餐,也不过需要 120 美元(约人民币 820 元)。

软件更新

在软件方面,新一代的 Raspberry Pi 采用了 Debian 10 Buster 发行版系统。对此,树莓派高级软件工程师 Simon Long 表示,Raspberry Pi 4 一直致力于保持软件与旧硬件的向后兼容性,因此 Raspberry Pi 所有型号的标准 Raspbian 镜像都是基于最新版本的 Debian Linux——Buster。而这一新发行版系统带来了更加简单的现代化用户界面和更新的应用程序,包括 Chromium 74 Web 浏览器。 


640?wx_fmt=png

别太高兴,Raspberry Pi 4 被爆兼容性存在问题!


截止目前,这款既可以做游戏机,又能成为机器人的 Raspberry Pi 4 已让业界无数从业者为之欢呼:

“天啊!这是一次疯狂的升级,USB 3.0!千兆以太网!WiFi 802.11ac!BT 5.0!4GB RAM!4K!而且最多只要 55 美元!”

不过也就在一众用户满心欢喜入手 Raspberry Pi 4 之际,一位名为 Tyler Ward 的开发者发现,新一代的 Raspberry Pi 在 USB Type-C 的兼容性上存在问题。按常理来说,USB Type-C 端口上两个 CC 引脚中的每一个都应该获得自己的电阻器,但是 Raspberry Pi 4 中,其电路设计显示它们共用了一个电阻,而这样会直接导致了 USB-C 配件的不兼容。

针对这一问题,Raspberry Pi 联合创始人 Eben Upton 在接受外媒 TechRepublic 采访时承认,“带有电子标记线缆电缆的智能充电器会错误地将Raspberry Pi  4 识别为音频适配器附件,并拒绝向其供电。这一问题,我希望在未来的电路板中修复该问题。”


640?wx_fmt=png

Raspberry Pi 4 对物联网的影响


当前幸运的是,这个一问题带来的影响并不是那么广泛也可以有效规避。对此,Eben Upton 也给出了他建议的解决方案,即使用不带 e-mark 芯片的普通 USB-C 线缆来供电,如官方的 Pi 4 充电器。

其实,Raspberry Pi 4 的到来,不仅是业界的再一次技术迭代与进步,其独特的结构性能也将在万物互联时代为物联网,尤其是智能硬件的发展带来更有力的技术工具支撑。

犹记得两年前,笔者带着“作为开发者,想要物联网开发,是否需要首先学习学嵌入式?”的疑问请教了中国软件行业协会嵌入式系统分会副理事长何小庆。他在电话里耐心地解释道,“「想要物联网开发,首先要学习嵌入式」这个观点是正确的,嵌入式是物联网开发的基础,现在各大高校的自动化、计算机、电子信息等这些专业中,都有嵌入式的课程。也有不少学校开设了物联网专业,其中也有大量的嵌入式的课程。不过并不是所有的从事物联网系统开发应用的人都要懂嵌入式,因为物联网是一个系统,它有传感器、网关,即为就是我们计算的部分,它后面有手机 App、服务器,假如你正好是只是从事手机 App 开发的,或者服务器端开发的,那就不需要深入了解嵌入式系统的知识,你只要知道嵌入式的设备是如何跟你的手机和服务器进行通讯的,比如蓝牙通讯协议,你只要知道这些通讯协议基本原理就可以。”而作为从事硬件层面的开发者,嵌入式无疑是需要具备的基本技能。

Raspberry Pi 作为硬件条件较为成熟、软件资源较为完备、社区支持较为广泛的嵌入式开发板,无疑是嵌入式入门最为便捷的通道。而这也是为何 Raspberry Pi 每次的迭代都能引起国内外使用者的激烈探讨的原因:

@xorcist:

我一直在使用 RPI2 作为我的 HTPC / NAS。

使用 Pi 作为文件服务器可能有点不稳定。以太网控制器是 USB 控制器,既不是非常稳定,也不是非常好。专用链路上的新 PHY 可能是这一新版本的最大改进。考虑到高昂的许可证费用和一般的不确定性,HEVC 有点出乎意料。

@lbf-523:

刚买了 3B+ 的我眼泪掉下来。

@David Frantz:

过分关注向后兼容性可能是件坏事!我更愿意看到将该板放入 64 位 OS 中的计划。因为可能在 2-4 年之后,当 Pi 5 问世时,它就会有 6-8GB 的 RAM,到时候大多数用户只想要 64 位操作系统而自然没太多人关注 32 位支持。

@Jose:

虽然我同意有时需要保持向后兼容性,但这样做可能是一个灾难性的商业决策。软件开发是目前最昂贵的项目,没有人想重新编译和重新测试他们的应用程序,因为这需要花费金钱和时间。我相信 RPI 基金会正在通过保持一切向后兼容的措施来做正确的事情,直到出现 RPI 4 的 64 位杀手级应用程序。而且,无论如何,一定会有不少的 64 位 Linux 发行版能够很好地运行于 RPI 4 上。

最后,你打算或已经入手了 Raspberry 4 了吗?

参考:

https://www.raspberrypi.org/blog/raspberry-pi-4-on-sale-now-from-35/

https://arstechnica.com/gadgets/2019/07/raspberry-pi-4-uses-incorrect-usb-c-design-wont-work-with-some-chargers/

640?wx_fmt=png

640?wx_fmt=jpeg

 热 文 推 荐 

中国第一程序员,微软得不到他就要毁了他!

计算机密码发明者去世!曾获图灵奖、并启蒙 Unix 诞生!

“10 倍工程师”现实吗?不存在的!

北邮博导孙松林:5G 新物种开启新时代

344亿天价罚单也救不了Libra!

江湖又现中科大少年班的传说

面试官问我:你们的数据库是怎么架构的?

10分钟学会用Pandas做多层级索引

中国第一程序员,微软得不到他就要毁了他!

640?wx_fmt=gif点击阅读原文,输入关键词,即可搜索您想要的 CSDN 文章。

640?wx_fmt=png你点的每个“在看”,我都认真当成了喜欢
展开阅读全文

被误解的C++——C++的缺陷和D的缺陷

10-13

C++的缺陷和D的缺陷rnD语言,从字面上讲应当是在C/C++的基础上进了一位,其特性当然也进了一位。真是这样?也是,也不是。这得看你的出发点和价值观了。rnD的定位在于继承C/C++的优势,但却更加易学易用。这种定位招人喜爱。C/C++的致命伤就在难学难用上。(不少人认为C++难学易用,我也持这种观点。但是既然要拿来同D比较,那我也只能跳一回票。只此一次,下不为例)。rn我大致了解了一下D的特性,初步混了个脸熟。D差不多通过以下方式达到其目的的(如有错误或遗漏,请轻轻扔砖):rn1. 新的语法,消除了一些缺陷,比如C++模板的>>问题(对此我持保留意见,一会儿再探讨)。同时,也优化了编译,提高了编译速度;rn2. 将字符串、数组等内置,使其得到编译器的充分支持;rn3. 用module代替头文件,抛弃了来自远古时代的遗物;rn4. 用内置特性实现C++的一些库功能,比如traits;rn5. 使用gc方便内存管理。但保留RAII功能;rn6. 增加编译时计算支持。将C++部分通过模板实现的编译时计算放到内置特性中实现;rn7. 增加mixin等mp支持。rn限于我对D的了解,暂时只想到这些内容。总体上,可以认为,D的改进主要集中在将C++的很多由库实现转移到内置特性实现。内置特性的实现通常具有针对性,在语法上更简洁。此外,D也消减了一些不常用,但容易引起麻烦的特性。并且使一些特性自动化,以减少使用时的压力。rn但在我看来,D所做的,是好心没办好事。因为D并没有真正抓住C++的核心问题,也没有很好地认清C++成功的关键。D继承了C++大部分的特性,这表明它认可C++的强大。(不然它留那么多特性干什么)。但是却没有能够从C++身上吸取真正的教训。rn首先,C++的语法存在缺陷,Bjarne不止一次提到这个问题。根本原因可能是其语法是non-LR的。这个问题应该不难解决,我相信D已经解决了。但是,D大费周章地采用()和!()作为模板的操作符,似乎有欠妥当。首先,程序员的习惯,促使他们不容易接受这个新操作符;其次,()容易同函数参数产生混淆,不如<>来的直观;最后,过度放大<>存在的问题。<>的问题主要有两个,一个是同>>操作符冲突,这个问题在C++0x中已经解决。另一个是<3>4>问题,这种情况相对少见,而且可以利用<(3>4)>加以解决,并非关键性问题。为这些“鸡毛蒜皮”的问题而采用(),似乎不太值得。rn其次,C++的最初动机也就是提供“更好的C”。此后,随着需求的不断扩展,逐步加入了各种高级特性。也就是说,Bjarne在最初的那段时间里,并不是那么高瞻远瞩。尽管他为C带来了OOP这种新的编程范型,但是从最后的结果来看,他的思维似乎也不够大胆。因此,C++的很多特性配合不好,有拼凑的感觉。D则站在了巨人的肩膀上,自然有更好的基础,更容易避免C++身上发生过的问题。rn再来看D,目前所有的特性和能力,都没有超出原来C++的范畴,只是在其上做一些小修小补。从编程技术而言,相对C++没有显著的进步。不错,D在很大程度上简化了使用,但这是有代价的,它放弃了很多有用但难缠的特性。但这也会带来应用上的局限。rn对于系统编程的定位,D似乎把易用性放在了过高的位置。实际上,后面我们将看到,D的面前同样存在另一条路可走。这条路,可以在C++的基础上提供更好、更强大的特性,但却可以消除很多C++的不足(但不是所有的,很多问题算不上缺陷,只是某种强大功能的副作用。强大的功能人人都想要,对吧?那就忍着点吧)。rn再次,C++的很多问题来源于它逐步堆砌的特性。而且这些特性又是来源复杂,缺乏一致性。由此,很多first-class的概念被迫使用非first-class概念实现。rn在这方面,D则做得更糟。比如,D强化了gp,但却没有引入concept,将来是否会引入,尚不得而知。这使得D无法根本上消除gp中遇到的诸多问题。相反D试图通过static if、static dispatch(C++常用的手段)之类的second-class特性完成concept这种first-class的需求。显然没有从C++中获得教训。rnD象其他语言那样,把数组和字符串作为内置类型处理。在表面上,这是进步,用first-class的概念,用first-class的类型表示。但在我看来,这是一种倒退。说清这件事,就得看看什么是first-class的。传统上,类型分为内置类型和用户定义类型。而内置类型被界定为first-class的,得到编译器的优先照顾。然而,内置类型是否真的first-class呢?不,有比内置类型更first-class的,那就是类型。迷糊了?我慢慢说。rn无论内置类型,还是用户定义类型,都是类型。我们传统上将他们区别对待。实际上,划分内置类型和用户定义类型的一个理想上的标准是原子性,即如果一个类型,(在语义上)不能分割了,便作为一个内置类型处理。为了保持移植性,象int之类的类型,被作为原子类型,而不考虑它内部字节的排列。同样string和array也是如此。但是,在很多系统中,比如SQL,为了处理方便,很多非原子性的类型也作为内置类型处理,比如datetime。这就表明,现实中内置类型和用户定义类型并没有严格的界限。rnC++创建时有一个宗旨:让用户定义类型象内置类型一样处理。这句话是非常first-class的。也就是说,把所有类型一视同仁。如果能够做到,那么这门语言中,将只有类型这样一个first-class的概念,而不再分类。那这样得到的好处是什么呢?就是灵活性、扩展性、简洁性。rn下一个问题,哪种类型是最first-class的?在C++中,内置类型是最first-class的,D也是一样。但事实上,最first-class并非内置类型,而是字节。汇编语言中,所有类型都可以看作字节或字节序列。也就是说,任何类型,无论内置类型还是用户定义类型,都是由字节组成。在此基础上,我们便可以用字节定义类型的静态结构,包括内置类型。也就是说,在静态结构定义上,内置类型完全可以同用户定义类型同等处理。rn但是,内置类型和用户定义类型的行为是不同的,因为编译器并未把他们作为同一样东西处理。此时,我们便可以看到C++那句豪言壮语的作用了。当用户类型能够像内置类型一样的情况下,内置类型和用户定义类型将不做区分,完全可以一样处理。这便可以导致一个结果,就是所有类型,包括内置类型,都可以通过库而非编译器实现。于是,语言便可以扩展出丰富的“内置类型”。(呵呵,是不是有点metaprogramming的味道?DSL听了肯定高兴)。rnC++朝这个方向努力做了,实现了绝大部分目标,但也未能100%地实现。比如,智能指针尚无法做到象内置指针一模一样的行为。(C++0x引入三个cast操作符重载后,情况就会好很多)。rn这一点上D走出了一步,但却没能乘胜追击。D为所有类型,包括用户定义类型都定义了一组properties,用于获取类型的特性。在这一点上,所有的类型都一视同仁。但是,之后却依旧按传统将内置类型和用户定义类型隔离,并且将数组和字符串放回内置类型。再加上操作符重载上的一个明显退化,便坐失了统一类型处理的优势。rn操作符重载,是使用户定义类型得以同内置类型一样处理的关键。C++除了少数的几个操作符外,其余都可以重载。这带来了极大的灵活性,(尽管如此,也未能使所有类型统一处理),但也带来了一些麻烦。(操作符重载带来的语义上的问题,不应该由语言负责,除非不想获得操作符重载的好处,否则必须承担此中的风险)。D缩小了重载的范围,避免一些混淆,以达到简化学习和使用的目的。(C#也是如此,但我并没有看到有多大的效果,我们重载操作符通常都集中在某些常用的操作符上,多数的操作符重载不会成为困扰我们的原因)。rnD在操作符重载上的一个明显的变化,就是不使用操作符本身作为重载的定义,而是用等价的字符表示:rn//C++rnA operator+(A const&, int);rn//Drnclass Arnrn A opAdd(int v) …rn int opPos()…rn;rn这种方式存在它的好处,但同时也带来了不足。好处是可以明确地区分统一操作符在不同情况下的语义,看起来非常明确。但是,这种方式使用起来却不如直接使用操作符本身来的直观,使用者必须识别这些操作符和对应的函数,这增加了记忆的负担。而operator+则侧重于记忆少数规则,理解规则,便可以举一反三,快速运用到其他操作符上。同时增加的这些内置函数记号,消耗了宝贵的关键字。两者的是非得失,全凭使用者的喜好,算不上什么天大的问题。只是我更喜欢记忆规则,而不是具体的记号。rnD的操作符重载真正的问题在于取消了自由函数的重载形式。这样似乎简化了学习和使用,但实际上,只会把问题复杂化。成员型的操作符重载并非操作符最本质的形式。将操作符重载完全局限于成员函数,使得操作数无法交换。于是D通过允许定义opxxx_r()程序函数定义交换操作数的版本(复杂了吧)。对于另一个操作数类型,是否定义相应的操作符重载呢?这种方式迫使程序员不断地考虑这类问题。如果合作开发,那么必然增加了程序员间协调的负担。rn无论如何,二元操作符的形式更接近自由函数。用自由函数加以表达,更加直观和明确,而且更便于集中处理。[url=http://www.ddj.com/cpp/184401197]这篇文章[/url],很好地阐述了过多的成员函数对封装性产生的影响。成员函数的一个好处是可以访问非public成员,但就像其他成员函数一样,成员型的操作符削弱了类型的封装性。如果不访问非public成员,那么作为成员,没有任何意义。rn操作符重载是一个first-class的特性,但是D却使用了非first-class的形式表达。作为对C++操作符重载的简化,我认为合理的形式应当是:赋值操作符(=)、类型转换操作符,以及所有一元操作符,都采用成员的形式。二元以上的操作符都采用自由函数的形式。这样,规则并没有复杂多少,但却使得不同的操作符重载都能够以first-class的形式表示。rn在first-class特性的问题上,另一个问题是D引以为豪的traits。Traits是非常有用的东西,使我们静态地获取类型的特征。traits在C++中起了非常重要的作用。所不同的是,C++通过类库的形式提供traits,而D则采用编译器内置特性提供。相比之下,受制于语言本身的特性,类库的实现难以提供完全的类型信息。而编译器内置特性,可以提供更完全的内容。rn但是traits毕竟是非first-class的特性,C++0x通过引入first-class的concept,大大消除了对traits的依赖。具体的可以看[url=http://groups.google.com/group/pongba/browse_thread/thread/5a92c149969517f5]这里[/url],[url=http://groups.google.com/group/pongba/browse_thread/thread/d646c623d67a05dc]这里[/url]和[url=http://groups.google.com/group/pongba/browse_thread/thread/e553a21476ba2ebd]这里[/url]。而traits背后真正的机制则是reflection。在这里reflection是真正的first-class机制,而traits是缺乏reflection(编译时)的一种替代或模拟。rnD的问题在于,traits成为一种语言特性,当未来引入了concept和reflection之后,它将成为摆设,宝贵的语言特性资源被浪费。如果不引入concept和reflection,那么很多依赖于这些特性的问题无法得到解决,而traits也无法独立支撑这个局面。这会使D在这方面处于进退两难的境地。同样的问题也存在于mixin上。Mixin可以被看作一种Meta-Programming的机制,但并不完全,也非first-class特性。为真正解决现实中的问题,在GPL中引入Meta-Programming的需求越来越强烈。一旦引入真正的first-class的MP机制,那么mixin也会处于尴尬的地位。rn这些问题表明,设计D的出发点存在问题。D仅仅试图在C++的基础上简化学习和使用,而不是采取更加本质,更加根本,更加first-class的手段来彻底解决C++面临的问题。就是说D并非一种面向未来设计的语言,仅仅关注眼前的蝇头小利。这种思维上的局限性,很容易使D在未来同更强大的语言,不仅仅是未来的C++,竞争的时候,处于不利的地位。因为限制已经造成,围栏已经建好,再想扩展便会受到很大的限制。rn我还是那句话,如果D仅仅局限在修正C++的某些问题,那么说明它并没有从C++哪里吸取真正的教训。rn最后,D似乎并没有充分意识到灵活性和程序员的选择对系统开发的重要性。C++的机巧性、危险性很大程度上是被过度放大了。在现实的开发过程中,我们绝大部分的时间,实际上都在老老实实地使用C++的普通功能,(但请记住,是在高级特性的支援下,使用普通功能)。这些动作都是常规的,成熟的。至于那些复杂、危险特性,则很少使用。即便使用,也是由专人(受过训练的,有免疫能力的)集中运用。在这样一个大环境下,语言的灵活性相比那些很cool的功能而言,更加重要。比如,使用多继承的权利。rn多继承的主要问题在于钻石型继承带来的麻烦。但是,这种情况极少出现,通常也只在过度OO的设计中存在。在其他方面,多继承是非常容易处理和使用的。更重要的是,它是非常有用的,有时甚至是关键的(想想policy可以为我们消除多少类、继承和代码冗余,带来多大的灵活性)。为了一种很少出现的情况,把路整个地堵死,对于java这样的高层语言,或许可以忍受,但对于系统级的语言,是难以接受的。(至少对我如此)。更何况编译器可以准确地识别钻石型继承,并作出自动化处理(默认virtual继承),除非有特殊需要。rn系统级语言不仅仅要求能够完成程序。鉴于系统开发的广泛性、灵活性,以及扩展性要求,语言的灵活性和程序员的选择是非常重要的。作为高附加值的开发任务,系统开发对于语言的复杂性的容忍能力是非常强的。rnC++的问题是过于灵活,比如缺省情况下单参构造函数执行隐式类型转换,在应用中造成无数问题。一门新的语言完全可以通过合理地限制这种灵活性,消除问题。rn我并不是说,C++那些缺陷和复杂是正当的。我只是想表明,通过消减语言特性,抑制语言的灵活性,限制使用者的选择,不是简化语言使用的正当手法。一种系统语言,应当以更加根本(本质)的方式解决C++的问题。在这一点上,D做的并不是很好。当D只专注于宣扬C++的缺陷,以及它所给出的解决方案时,便注定它无法成为超越C++的语言。在我看来,它应当把更多的精力花在如何提供更多first-class特性上,而不是用来标榜自己的那一点点进步。rn 论坛

没有更多推荐了,返回首页