【芯视野】Arm的物联网之“殇”

在2016年豪掷320亿美元收购Arm时自言“我下围棋的时候,都会预判7步之后的棋局。”的孙正义,恐不会料到仅4步(nian)之后Arm的运命会如此收场:将Arm以400亿美元转手英伟达。当初豪言壮语要在到来的万物互联的物联网时代续写Arm“芯传奇”的蓝图,就这么无情地被“雨打风吹去”。

而更唏嘘的是,此次世纪豪赌并不包含原来Arm旗下的物联网(IoT)业务。在 Arm内部的两大事业部中,IP 事业部负责与传统IP相关的业务,IoT事业部则将目光放在服务全球的IoT相关客户及合作伙伴上。此次英伟达承接的是Arm的“硬核”IP业务,而IoT事业部包括IoT平台和Treasure Data则已被重组剥离到软银成立的新实体,并没有入英伟达的“法眼”。

不禁要问,Arm的物联网雄心真的“折戟”了吗?

难以成全?

对于IoT业务的剥离,集微咨询高级分析师陈跃楠指出,Arm的IP业务毛利率曾高达93.56%,同时拥有极高的超过40%的市占率。因而,Arm剥离掉市场竞争激烈、应用场景复杂的IoT业务,借此完成战略转移,以助力Arm集中精力专注于发展核心IP业务,可提升在移动市场中的地位。相应地,软银亦可借此获得期望的交易筹码。

相形于“牵一发动全身”的IP业务,的确Arm的IoT业务显得不那么吃香,但Arm的IoT业务真的成为了一个“拖油瓶”吗?

要知道,Arm 自2013年就开始了物联网的布局。2018年,Arm花费6亿美元约合42亿元收购美国数据分析公司 Treasure Data 并孵化出 IoT平台Pelion,以壮大自身的实力。

彼时,市场也在为IoT摇旗呐喊。Gartner预测,2020年全球IoT设备数量将达到260亿个,IoT市场规模将达1.9万亿美元。

只是,IoT市场的光芒显然不是雨露均沾的。

从营收来看,Arm近几年的表现并不如想象中那么“得意”。全球智能手机销量增长放缓,叠加Arm在IP核和IoT市场过高的研发投入,Arm在2017年-2019年的营收分别为18.31亿美元、18.36亿美元和18.98亿美元,增长可谓微乎其微

而内外交困的软银,已没有更多时间让Arm的IoT业务打磨了。

模式难撑?

究竟是哪里出了“差池”?

一方面,IoT市场看似庞大,但仍未真正起势。半导体知名业内人士高时(化名)分析,物联网真正起来还需要时间,现有的IoT市场并不是说扫地机器人、音箱等装了Wi-Fi、蓝牙之后,控制变成Wi-Fi控制、营销变成Wi-Fi营销就成的,Arm在这一尚不成熟的市场亦难以拉升盘面。

此外,凭借着高性价比的IP授权和版税业务,Arm在移动端市场风生水起,但将以往的模式再成功“Copy”到IoT市场,却遭遇到“水土不服”的掣肘。

在IoT领域的竞争,显然是更高维度的较量。中国软件行业协会嵌入式系统分会副理事长何小庆提及,在IoT业务当中,不止是芯片的问题,还涉及操作系统和IoT云,面临的竞争压力巨大。对比之下,Arm在云层面并不占强,并且OS在国内影响力有限,在海外表现也一般,即便IP授权是强项,但也孤掌难鸣

高时也认为,在IoT打天下需要构建自己的强生态,比如建立通用的协议栈等。例如小米,从手机到终端各类产品,都可将协议植入进去,通过下载APP和连接Wi-Fi,家中关联小米生态圈的所有设备都能够连云。而在云生态构建层面,亚马逊、苹果,以及国内小米和阿里等实力强大,需要掂量它们在底层芯片层面的自定义权份量。

因而,Arm在IoT领域的话语权仅集中在芯片领域,要成为主导者显然太难。“谁来主导IoT最能解决用户和产业问题的产品定义,才能引领潮流。Arm只是IP厂商,它的角色已决定了它在IoT领域的从属地位。”高时分析说。

从IoT产业链价值分布看,应用层和平台层贡献最大的附加值,分别占到35%左右。可以说,在IoT体系中应用层和平台层的话语权重更高,相应地定制权也将自上而下来左右。

未来分野?

在被“剥离”之后,Arm在IoT领域的未来何去何从?

业界的观点已现分歧。何小庆认为,经过多年发展,RISC-V在技术、生态层面不断进阶,并且在IoT定制芯片方面发展较快,相对来说Arm的定制化还面临挑战。有数据佐证,据Semico Research 估计到2025年将有624亿颗RISC-V CPU芯片。

高时仍对Arm抱持信心。他说,从IoT来讲,基本上处理器都采用Arm的内核,短期内不会改变。因为在IoT这一碎片化的市场,需要更多生态链的支持。而中国IoT市场将独树一帜,蔚然成势,这就需要产业链环节多方参与,也更需要采纳和遵循共通的一些协议和规则。目前RISC-V的版本每家都不一样,那究竟以谁的为准?相对于Arm生态来说,RISC-V还有诸多方面尚待完善。

毕竟,Arm的先行优势依然显著。陈跃楠也表示,由于Arm本身的产业生态十分完善,而IoT巨量的终端接入能充分发挥Arm生态的作用。IoT业务有很大一部分是传统行业的数字化转型和升级,这需要巨量的IoT芯片,并且大部分传统行业芯片厂商已经适应了Arm的开发环境,同时低成本的终端迭代周期更短,用具有成熟的生态的Arm架构进行开发,能缩短产品上市周期,降低成本

“相信Arm会进一步利用这种优势,以半开源的策略抢占IoT市场份额,同时与英特尔、苹果以及国内的小米等企业加强合作,不断巩固自己的IoT产品生态。”陈跃楠仍看好Arm的表现。

无论如何,Arm属于软银的时代已然俱往矣。2016年孙正义感怀:“我把Arm视为我一生中最重要的交易。”但如今的孙正义恐只能对自己说,放手是我现在最重要的交易了。(校对/Sky)

传华为向联发科下了巨额芯片订单

来源:内容来自半导体行业观察综合,谢谢。

据台媒报道,华为不单与高通签订采购意向书,其实也和联发科签订了合作意向书与采购大单,且订单金额超过1.2亿颗芯片数量;假若以华为近两内预估单年手机出货量约1.8亿台来计算,联发科所分得到的市占率超过三分之二,远胜过高通。

过去华为的手机芯片几乎都源自海思,但在美国贸易战持续恶化,美国商务部对华为海思重重卡关之下,华为的手机只得对外采购芯片,而全球手机芯片厂也只剩下高通、联发科,甚至三星,也因此,近来华为转向多次找上联发科与高通商谈合作。

高通虽然在上周自行宣布与华为签订合作意向书,但业界与外资圈传出,其实华为也已经和联发科签订相同的合作意向书,尤其重点是,华为还与联发科签下超过1.2亿颗的芯片采购大单,实际上,在5G的世代,华为与联发科的合作,是比华为和高通的合作更加密切。

惟联发科向来不回应任何关于华为的讯息,在上周五的法说会上,针对华为议题,联发科财务长顾大为表示,联发科是家守法的公司,也不会针对单一客户做出回应。

而Digitimes Research的调查也指出,华为正在增加第三方供应商为其智能手机提供的移动应用处理器(AP)的比例,以减少其子公司HiSilicon Technologies的麒麟芯片的使用,以应对美国的贸易禁令。

他们表示,华为要保持产品竞争力,稳定的供应和盈利能力,必须对移动AP进行多次采购,而中国供应商可能会将1-2个供应商添加到其智能手机AP的供应商清单中。

虽然台湾联发科已经是华为的第三方5G AP供应商,但如果美国芯片制造商能够获得美国的许可以运送给华为,那么中国供应商也有可能从高通公司购买5G AP。

Digitimes Research进一步指出,自2020年第二季度以来,华为已增加了对联发科技中端天玑 800 5G SoC的购买,以生产其畅享和荣耀智能手机,并且也可能在2020年下半年和2021年开始购买联发科技的高端5G AP。

根据报告,三星电子和中国的紫光展锐可能也是华为5G AP的替代来源,但两家公司在向中国顶级智能手机供应商出售芯片方面将面临挑战。三星是华为在全球智能手机市场上的强大竞争对手,而展锐在技术开发方面仍落后于其他竞争对手。

外媒:联发科5nm处理器即将打入华为P50手机

据快科技报道,联发科前不久公布了Q2季度及上半年财报,营收及盈利都是大涨,创下了5年来最佳。在这背后,联发科获得华为的采购是个重要因素,这一次联发科还表态5nm芯片会尽快量产,外媒称联发科5G处理器将被纳入华为P50供应链中,这也是联发科芯片首次打入1000美元的高端市场。

联发科目前在华为的供应链中主要是低端产品,其中4G芯片供货比重在15%左右,不过今年底会提升到30%左右。

5G芯片方面,市场传闻高通也会恢复对华为的供应,不过联发科依然会是供应主力,今年5G芯片比重会从0提升到25%,明年有望提升到65%甚至75%。

受益于此,外资机构预计联发科5G芯片出货量将会从今年的5000万套提升到2021年的1.9亿套,同比大涨280%。

不仅总的销量大涨,联发科在高端手机市场也会迎来重大变化,其5nm 5G芯片将会进入华为明年上半年的旗舰机中,也就是华为新一代P50系列旗舰机。

如果成功打入P50供应链,那联发科5G芯片将首次有机会进入1000美元级别的手机中,这也是多年来联发科梦寐以求的。

此前华为P系列产品总经理王永刚公开透露的,P50已进入开发阶段,目前新机的开发一切顺利,不会因为外界的因素而陷入停滞。

联发科盈利创5年来最佳

联发科今天举行Q2季度说法会,公布了今年4-6月份的运营情况,营收676.03 亿新台币,环比增长11.1%,同比增长9.8%,税后净利润73.1亿新台币,环比、同比大涨25.9%、12.4%,盈利能力创下5年来最佳水平。

联发科上半年营收1284.66 亿新台币,同比增长12.4%,毛利率43.31%,年增1.96 个百分点,运营利率10.28%,年增2.13 个百分点,税后净利润131.14 亿新台币,同比增长33.33%,创下来8个季度以来的最好记录。

联发科表示,Q2及上半年的毛利率、盈利创下5年来最佳,主要受益于5G手机芯片,还有就是Wi-Fi、电源管理芯片等消费电子产品的营收增长。

虽然外发科没有提及具体的5G客户名单,不过今年除了传统客户OPPO、vivo、小米之外,华为加大采购联发科芯片也是个黑马性质的大事件,带动了联发科5G芯片出货量大涨。

不仅Q2季度大涨,联发科预计接下来的Q3季度业绩还会再创新高,营收增长22-30%,达到825-879亿新台币之间,毛利率41.5%到44.5%。

如何在鸿蒙系统中移植 paho mqtt去实现MQTT协议

MQTT 是当前最主流的物联网通信协议,需要物联网云平台,例如华为云、阿里云、移动OneNET都支持mqtt。而Hi3861则是一款专为IoT应用场景打造的芯片。本节主要讲如何在鸿蒙系统中通过移植第3方软件包 paho mqtt去实现MQTT协议功能,最后会给出测试验证。为后续的物联网项目打好基础。

友情预告,本节内容较多,源码也贴出来了,大家最好先看一遍,然后再操作一次。

3.9.1 MQTT介绍

MQTT 全称为 Message Queuing Telemetry Transport(消息队列遥测传输)是一种基于发布/订阅范式的二进制“轻量级”消息协议,由IB公司发布。针对于网络受限和嵌入式设备而设计的一种数据传输协议。MQTT最大优点在于,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。MQTT模型如图所示。

更多MQTT协议的介绍见这篇文章: MQTT 协议开发入门

3.9.2 移植 paho mqtt软件包

1. 下载paho mqtt软件包,添加到鸿蒙代码中

paho mqtt-c 是基于C语言实现的MQTT客户端,非常适合用在嵌入式设备上。首先下载源码:
https://github.com/eclipse/pa…

下载之后解压,会得到这么一个文件夹:

我们在鸿蒙系统源码的 third_party 文件夹下创建一个 pahomqtt 文件夹,然后把解压后的所有文件都拷贝到 pahomqtt 文件夹下,目录结构大致如下:

下一步,我们在pahomqtt 文件夹下面新建BUILD.gn文件,用来构建编译。其内容如下:

# Copyright (c) 2020 Huawei Device Co., Ltd.
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

import("//build/lite/config/component/lite_component.gni")
import("//build/lite/ndk/ndk.gni")

config("pahomqtt_config") {
    include_dirs = [
        "MQTTPacket/src",
        "MQTTPacket/samples",
        "//vendor/hisi/hi3861/hi3861/third_party/lwip_sack/include",
        "//kernel/liteos_m/components/cmsis/2.0",
    ]
}


pahomqtt_sources = [
"MQTTPacket/samples/transport.c",
"MQTTPacket/src/MQTTConnectClient.c",
"MQTTPacket/src/MQTTConnectServer.c",
"MQTTPacket/src/MQTTDeserializePublish.c",
"MQTTPacket/src/MQTTFormat.c",
"MQTTPacket/src/MQTTPacket.c",
"MQTTPacket/src/MQTTSerializePublish.c",
"MQTTPacket/src/MQTTSubscribeClient.c",
"MQTTPacket/src/MQTTSubscribeServer.c",
"MQTTPacket/src/MQTTUnsubscribeClient.c",
"MQTTPacket/src/MQTTUnsubscribeServer.c",
]


lite_library("pahomqtt_static") {
    target_type = "static_library"
    sources = pahomqtt_sources
    public_configs = [ ":pahomqtt_config" ]
}

lite_library("pahomqtt_shared") {
    target_type = "shared_library"
    sources = pahomqtt_sources
    public_configs = [ ":pahomqtt_config" ]
}

ndk_lib("pahomqtt_ndk") {
    if (board_name != "hi3861v100") {
        lib_extension = ".so"
        deps = [
            ":pahomqtt_shared"
        ]
    } else {
        deps = [
            ":pahomqtt_static"
        ]
    }
    head_files = [
        "//third_party/pahomqtt"
    ]
}

2. 让hi3861编译的时候,编译 paho mqtt软件包

打开vendor\hisi\hi3861\hi3861\BUILD.gn 文件,在lite_component(“sdk”) 中增加 “//third_party/pahomqtt:pahomqtt_static”,

修改后文件内容如下:

完成以上修改后,就可以开始编译了,然而很不幸的。。。你会发现好多编译报错。

不过没事,我们来一个一个解决。

3. 移植,修改编译报错

打开 third_party\pahomqtt\MQTTPacket\samples\transport.c 文件,这个文件也是我们主要移植的文件,我们需要实现 socket相关的操作,包括发送、接收数据。其实移植就3步。

(1)首先我们导入几个头文件

#include "lwip/ip_addr.h"
#include "lwip/netifapi.h"

#include "lwip/sockets.h"

(2)其次修改 transport_sendPacketBuffer 函数,内容修改后如下:

int transport_sendPacketBuffer(int sock, unsigned char* buf, int buflen)
{
    int rc = 0;
    rc = send(sock, buf, buflen, 0);
    return rc;
}

(3)后面编译的时候会报错说 close 函数不存在,我们修改 transport_close 函数,修改后内容如下:

int transport_close(int sock)
{
int rc;

    rc = shutdown(sock, SHUT_WR);
    rc = recv(sock, NULL, (size_t)0, 0);
    rc = lwip_close(sock);

    return rc;
}

(4)修改完 transport.c 文件后,大家编译的时候估计会遇到很多编译错误,都是某个局部变量未使用那种,大家可以修改就行。

类似于这样的,提示 buflen 未使用的错误,大家只需要在代码中随便写个buflen = buflen ; 即可。

3.9.3 编写测试代码

测试代码比较好写。主要是3个文件,内容我都贴出来了:

(1)BUILD.gn文件内容:

# Copyright (c) 2020 Huawei Device Co., Ltd.
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

static_library("mqtt_test_at") {
    sources = [
        "mqtt_test.c",
        "at_entry.c"
    ]

    include_dirs = [
        "//utils/native/lite/include",
        "//kernel/liteos_m/components/cmsis/2.0",
        "//base/iot_hardware/interfaces/kits/wifiiot_lite",
        "//vendor/hisi/hi3861/hi3861/third_party/lwip_sack/include",
        "//foundation/communication/interfaces/kits/wifi_lite/wifiservice",
        "//third_party/pahomqtt/MQTTPacket/src",
        "//third_party/pahomqtt/MQTTPacket/samples",
        "//vendor\hisi\hi3861\hi3861\components\at\src"
    ]
}

(2)at_entry.c文件主要是注册了一个AT指令,后面大家可以使用 AT+MQTTTEST 指令来测试MQTT功能。代码内容如下:

#include <stdio.h>

#include <unistd.h>

#include "ohos_init.h"
#include "cmsis_os2.h"

#include <unistd.h>

#include <at.h>
#include <hi_at.h>

#include "hi_wifi_api.h"


#include "mqtt_test.h"


void mqtt_test_thread(void * argv)
{
    argv = argv;

    mqtt_test();

}

hi_u32 at_exe_mqtt_test_cmd(void)
{
    osThreadAttr_t attr;

    attr.name = "wifi_config_thread";
    attr.attr_bits = 0U;
    attr.cb_mem = NULL;
    attr.cb_size = 0U;
    attr.stack_mem = NULL;
    attr.stack_size = 4096;
    attr.priority = 36;

    if (osThreadNew((osThreadFunc_t)mqtt_test_thread, NULL, &attr) == NULL) {
        printf("[LedExample] Falied to create LedTask!\n");
    }

    AT_RESPONSE_OK;
    return HI_ERR_SUCCESS;
}

const at_cmd_func g_at_mqtt_func_tbl[] = {
    {"+MQTTTEST", 9, HI_NULL, HI_NULL, HI_NULL, (at_call_back_func)at_exe_mqtt_test_cmd},
};

void AtExampleEntry(void)
{
    hi_at_register_cmd(g_at_mqtt_func_tbl, sizeof(g_at_mqtt_func_tbl)/sizeof(g_at_mqtt_func_tbl[0]));
}

SYS_RUN(AtExampleEntry);

(3)mqtt_test.c 文件则是编写了一个简单的MQTT测试代码

,具体代码讲解,后面会重新开一篇。其中测试用的mqtt服务器是我自己的服务器:106.13.62.194

大家也可以改成自己的,也可以直接用我个人的mqtt服务器。

#include <stdio.h>

#include <unistd.h>

#include "ohos_init.h"
#include "cmsis_os2.h"

#include <unistd.h>
#include "hi_wifi_api.h"
//#include "wifi_sta.h"
#include "lwip/ip_addr.h"
#include "lwip/netifapi.h"

#include "lwip/sockets.h"

#include "MQTTPacket.h"
#include "transport.h"

int toStop = 0;

int mqtt_connect(void)
{
    MQTTPacket_connectData data = MQTTPacket_connectData_initializer;
    int rc = 0;
    int mysock = 0;
    unsigned char buf[200];
    int buflen = sizeof(buf);
    int msgid = 1;
    MQTTString topicString = MQTTString_initializer;
    int req_qos = 0;
    char* payload = "hello HarmonyOS";
    int payloadlen = strlen(payload);
    int len = 0;
    char *host = "106.13.62.194";
    //char *host = "192.168.1.102";
    int port = 1883;


    mysock = transport_open(host, port);
    if(mysock < 0)
        return mysock;

    printf("Sending to hostname %s port %d\n", host, port);

    data.clientID.cstring = "me";
    data.keepAliveInterval = 20;
    data.cleansession = 1;
    data.username.cstring = "testuser";
    data.password.cstring = "testpassword";

    len = MQTTSerialize_connect(buf, buflen, &data);
    rc = transport_sendPacketBuffer(mysock, buf, len);

    /* wait for connack */
    if (MQTTPacket_read(buf, buflen, transport_getdata) == CONNACK)
    {
        unsigned char sessionPresent, connack_rc;

        if (MQTTDeserialize_connack(&sessionPresent, &connack_rc, buf, buflen) != 1 || connack_rc != 0)
        {
            printf("Unable to connect, return code %d\n", connack_rc);
            goto exit;
        }
    }
    else
        goto exit;

    /* subscribe */
    topicString.cstring = "substopic";
    len = MQTTSerialize_subscribe(buf, buflen, 0, msgid, 1, &topicString, &req_qos);
    rc = transport_sendPacketBuffer(mysock, buf, len);
    if (MQTTPacket_read(buf, buflen, transport_getdata) == SUBACK)     /* wait for suback */
    {
        unsigned short submsgid;
        int subcount;
        int granted_qos;

        rc = MQTTDeserialize_suback(&submsgid, 1, &subcount, &granted_qos, buf, buflen);
        if (granted_qos != 0)
        {
            printf("granted qos != 0, %d\n", granted_qos);
            goto exit;
        }
    }
    else
        goto exit;

    /* loop getting msgs on subscribed topic */
    topicString.cstring = "pubtopic";
    while (!toStop)
    {
        /* transport_getdata() has a built-in 1 second timeout,
        your mileage will vary */
        if (MQTTPacket_read(buf, buflen, transport_getdata) == PUBLISH)
        {
            unsigned char dup;
            int qos;
            unsigned char retained;
            unsigned short msgid;
            int payloadlen_in;
            unsigned char* payload_in;
            int rc;
            MQTTString receivedTopic;
            rc = MQTTDeserialize_publish(&dup, &qos, &retained, &msgid, &receivedTopic,
                    &payload_in, &payloadlen_in, buf, buflen);
            printf("message arrived %.*s\n", payloadlen_in, payload_in);

            rc = rc;
        }

        printf("publishing reading\n");
        len = MQTTSerialize_publish(buf, buflen, 0, 0, 0, 0, topicString, (unsigned char*)payload, payloadlen);
        rc = transport_sendPacketBuffer(mysock, buf, len);
    }

    printf("disconnecting\n");
    len = MQTTSerialize_disconnect(buf, buflen);
    rc = transport_sendPacketBuffer(mysock, buf, len);
exit:
    transport_close(mysock);

    rc = rc;

    return 0;
}


void mqtt_test(void)
{
    mqtt_connect();
}

mqtt_test.h文件内容:

#ifndef __MQTT_TEST_H__
#define __MQTT_TEST_H__

void mqtt_test(void);

#endif /* __MQTT_TEST_H__ */

到这里就完成了代码部分,可以开始编译了。

3.9.4 MQTT实验

这里我们需要先下载一个 Windows电脑端的 MQTT客户端,这样我们就可以用电脑订阅开发板的MQTT主题信息了。

电脑版的mqtt客户端下载链接: https://repo.eclipse.org/cont…

我们选择这一个:

弄完后打开软件,按图操作:

操作完后,我们把编译后程序烧写到开发板,输入如下串口指令,让开发板连接上网络,因为MQTT功能需要网络支持。输入如下串口指令:

AT+STARTSTA                                                       开启STA模式

AT+CONN="12-203",,2,"07686582488"               连接到路由器,注意wifi热点名和密码用自己的

AT+DHCP=wlan0,1                                              获取IP地址

AT+IFCFG                                                             打印查看IP地址

串口指令的应答应该如下:

成功连接上路由器后,请确保路由器是可以上网的。

然后我们输入我们的 MQTT测试的AT指令: AT+MQTTTEST

应该可以看到如下打印:

此时我们去查看 我们电脑端的MQTT客户端软件,可以看到右边已经有接收MQTT信息了,主题未 pubtopic,消息内容为 hello HarmonyOS ! ,说明实验成功。

3.9.5 总结

这一次的内容比较多,其中总结起来就4步:

(1)添加第三方软件包 paho mqtt,关于如何添加第3方软件包,我之前有一篇文章已经讲了。

可以参考:如何往鸿蒙系统源码中添加第三方软件包

(2)移植 paho mqtt

(3)编写测试代码,这里我们用的是注册AT指令的方式,方便大家使用AT指令测试。

(4)测试,这里用电脑装mqtt客户端程序,去验证。


作者:连志安
获取资源包请点击下方链接,跳转至原网站下载
转自https://harmonyos.51cto.com/posts/1384?jssq

云芯一号教程 – Zulip安装及配置教程

  Zulip是一款功能强大的开源群组聊天软件,采用Python编写,使用 Django 框架,支持Linux、Windows、Mac等平台,支持私人消息和群聊。Zulip还支持快速搜索、拖放文件上传、图像预览、电子邮件消息提醒等功能。
  Zulip配置服务器时,有两种方式:一种适用于部署在线上product环境下,一种适用于测试服务器。由于线上product环境需要域名证书,本教程中,按照测试服务器搭建。

1.系统配置
1.1 配置hosts文件
  Zulip需要将服务器的IP地址映射到域名,因此在服务器上修改hosts文件,自定义域名为zulip.ts。

  jishu@Jishu:~$ sudo vim /etc/hosts
  ...... 
  127.0.0.1  localhost
  127.0.0.1  Jishu
  #服务器ip地址映射为自定义域名
  192.168.1.4  zulip.ts

1.2 安装OpenSSL
  Zulip的安装命令格式如下:

  ./zulip-server-*/scripts/setup/install --certbot \
--email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

  安装命令中可以带两种参数:
  –cerbot:用于线上product环境搭建,需要有域名SSL证书;
  –self-signed-cert:用于测试服务器搭建,Zulip安装程序会生成只签名SSL证书,需要确保安装OpenSSL。

  jishu@Jishu:~$ sudo apt-get install openssl

1.3 安装PostgreSQL 10
  从Zulip的配置脚本中,可以看到Zulip不支持PostgreSQL 11以上版本,所以安装PostgreSQL 10。

  jishu@Jishu:~/zulip-server-2.1.7/puppet/zulip/templates/postgresql$ ls
  10  11  9.3  9.5  9.6
  #如果服务器已经安装其它版本的PostgreSQL,请先删除
  jishu@Jishu:~$ sudo apt-get purge postgre*
  jishu@Jishu:~$ sudo apt-get install postgresql-10   

  PostgreSQL的基本使用请参考”PostgreSQL指导安装及基础使用教程” 。

2.安装Zulip
2.1 下载Zulip安装包

  jishu@Jishu:~$ wget https://www.zulip.org/dist/releases/zulip-server-latest.tar.gz
  jishu@Jishu:~$ tar -xvf zulip-server-latest.tar.gz

  如果wget下载比较慢,也可以在Windows上用迅雷下载后scp拷贝到开发板中。

2.1 安装Zulip
  Zulip安装命令需要切换到root用户下执行。

  sudo -s 
  ./zulip-server-*/scripts/setup/install --self-signed-cert --email="注册的Email地址" --hostname=zulip.ts  

  安装过程需要下载很多依赖包,安装时间取决与Internet连接的速度。如果系统配置了pip的国内安装源,需要取消掉,否则会安装出错。

  安装中会出现如下错误:

  ......
  + ln -nsf /srv/zulip-venv-cache/826354bbbf28aa841c7cfbea5f493add062f946f/zulip-thumbor-venv /home/  jishu/tools/zulip-server-2.1.7/zulip-thumbor-venv
  + /home/jishu/zulip-server-2.1.7/scripts/lib/install-node

failed: Connection refused.

  ......

  查看出现错误处的代码,错误出在wget的连接失败。

  ......
  if [ -n "${CUSTOM_CA_CERTIFICATES:-}" ]; then
        wget_opts+=(--ca-certificate "${CUSTOM_CA_CERTIFICATES}")
  fi
  wget "${wget_opts[@]}" -O- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
  ......

  解决方法是到https://site.ip138.com网址上…,把ip配置到hosts文件中。

  jishu@Jishu:~$ sudo vim /etc/hosts
  ......
  127.0.0.1  localhost
  127.0.0.1  Jishu
  192.168.1.4  zulip.ts
  151.101.76.133 raw.githubusercontent.com

  重新执行安装命令后,等待Zulip安装完成。
  Zulip安装完成后,会出现如下提示:

  ......
  + su zulip -c '/home/zulip/deployments/current/manage.py generate_realm_creation_link'
  Please visit the following secure single-use link to register your 
  new Zulip organization:
      https://zulip.ts/new/6e593k2i8rguu0bx8x09md31

  在本机浏览器中访问该URL,进行账号的相关配置后,即可使用Zulip系统。
  在其它服务器上访问该URL时,需要把zulip.ts的映射关系写到该服务器的hosts文件中。

2.2 为Zulip配置电子邮件
  Zulip配置电子邮件后,即可发送邮件通知。

  jishu@Jishu:~$ sudo vim /etc/zulip/settings.py
  ......
  #EMAIL_HOST = 'smtp url'
  #EMAIL_HOST_USER = 'your email'
  #EMAIL_USE_TLS = True
  #EMAIL_PORT = 587

  在配置文件中找到并修改Email相关字段。

2.3 配置远程PostgreSQL服务器
  远程PostgreSQL服务器一般用于线上product环境,在配置文件中修改相关字段即可。

  jishu@Jishu:~$ sudo vim /etc/zulip/settings.py
  ......
  #REMOTE_POSTGRES_HOST = 'dbserver.example.com' 
  #REMOTE_POSTGRES_PORT = '5432'
  #REMOTE_POSTGRES_SSLMODE = 'require'

2.4 Zulip服务重启命令
  Zulip参数修改后,需要重启Zulip服务生效。Zulip重启命令如下:

  su zulip -c'/home/zulip/deployments/current/scripts/restart-server'

写在 Dubbo go 的第五年

作者 | 于雨

阿里巴巴云原生公众号后台回复“915”即可查看 dubbogo v1.5.1 项目管理图清晰大图!

引语

dubbogo 项目已进入第五个年头。

项目发展的前两年,我们把 hessian2 协议库、网络库和整体基础框架搭建一番。从 2018 年项目被 Dubbo 官方接纳开始,依托阿里平台,社区开始形成并快速发展。与社区同学们齐心合力之下,如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5.1 已经发布。

立项

一个项目整体必须提炼出核心目标,指明其存在的意义和价值。有了初心,项目发展过程中产生困惑时,才能明确答复 “我是谁?从哪里来?到哪里去”。

1. dubbogo

dubbogo 项目有其自身的 milestone 要求,大致规划了每个阶段的关键里程碑,在项目发展初期仅仅是实现 Dubbo 的某个功能,但在发展过程中会不断结合当下的技术发展潮流,不断修正其未来发展方向。

其发版计划是通过“开发当前版本、规划新版本、根据反馈修正新版本”的模式定义当前版本的开发内容和下一个版本的发展方向。每次发版后会根据社区使用反馈对下一代的发展目标进行修正。

站在吃瓜人的角度,或许可以说出 “dubbogo 不就是 dubbo 的 Go 语言版本嘛,照着抄就是了” 之类的论调。而参与过 dubbogo 项目跟着社区一路走来的人,就知道 dubbogo 并不简单定位于 Dubbo 项目的 Go 语言版本。

dubbogo 初心不变,不同时间对自身定位均有升级。我认为当前 dubbogo 的定位是:

  • 全面兼容 Dubbo;
  • 一个 Go 语言应用通信框架,充分利用作为云原生时代第一语言—Go 语言的优势,扩展 dubbo 的能力。

2. dubbo-go-proxy

dubbogo 项目初期目的是依靠 Dubbo 实现 “bridge the gap between Java and Go” ,目前 dubbogo 正与 Dubbo 齐头并进,已经达到项目立项的目标。有长期生命的通信框架,大概有 5 年的成长期和 5 年的稳定成熟期。目前的 dubbogo 处在成长期和稳定成熟期的过渡期,这意味着社区如果想保持发展态势,就必须开始走多元化道路,发展自己的生态了。

眼下 dubbogo 社区正在集中精力孵化一个新的项目—实现一个基于 dubbogo 的 HTTP 网关,项目的意义是:dubbogo 自身是一个流量控制中间件,在其上扩展项目,其方向很自然就是做一个 proxy/sidecar or gateway,且社区一直有网关这方面的需求。

项目目的如下:

  • 做一个具有生产使用意义的网关;
  • dubbo-go-proxy 验证 dubbogo 的能力,对 dubbogo 未来的进化指出新方向,共同进化;
  • 优化 dubbogo 的稳定性和性能。

团队

项目立项完毕后,就进入招兵买马阶段了。

1. 来源

dubbogo 社区发展初期,其关键成员都是通过提交 issue 或者 pr 的同学撩来的。通过这种方式撩来的同学因为志同道合,有极高的概率同社区一起走下来。dubbogo 社区的 core member 就是这样来的。

其次是与其他公司的合作。dubbogo 本身是一个有着极高生产环境需求的项目,在发展过程中依次与携程、涂鸦、斗鱼、虎牙、蚂蚁金服和阿里集团有过极深的合作,其间与携程的合作对 dubbogo 成型而言极为关键。

另一个途径是与其他社区合作。dubbogo 项目发展过程中,与以下社区合作过:

  • 与 MOSN 社区合作实现 Dubbo Mesh;
  • 与 sentinel 社区合作,在 Dubbo/Dubbo-go 完整接入 sentinel 的降级和限流方案;
  • 与 Apollo 社区合作,在 Dubbo-go 中实现远程配置下发;
  • 与 Nacos 社区合作,实现基于 Nacos 的服务发现。

与其他社区合作的好处是使得双方的项目都受益:扩展双方的能力和使用场景,其次是社区间人员的流动。在合作过程中,dubbogo 自身受益极大,目前有 4 个社区 committer 来自于其它社区。合作完成后并不意味着结束,而是一个新的双赢的开始:社区项目也是发展的,当一个项目有新特性时可以同时快速被另一个项目采用验证,对扩展开发者们的技术能力和人脉也是极为有利的,dubbogo 社区目前的好几个同学同时活跃在多个社区。

dubbogo 项目已经过了草莽阶段,形成了一个的 800 多人的社区群,所以 dubbogo-proxy 项目立项后,很快就在社区群内找到很多项目爱好者。

2. 成员的 qualification

项目发展初期有很多同学会 Java 不懂 Dubbo 不会 Go,最后都通过参与项目提升了自我的能力。当然有些人会担心项目代码的质量,但只要秉持 “Community Over Code” 这个 “Apache Way”,在发展过程中这些问题都不大。

2019 年时,参与 dubbogo 项目的成员中一部分同学平时的工作是进行业务开发,秉承着对中间件通信技术 “我是谁?我从哪里来?要到那里去” 的初心参与 dubbogo 的开发,无论是对 dubbogo 抑或是对其自身技术水平提升都产生了积极的影响。

dubbogo 社区对 dubbogo 发版时间有一定期限要求,所以对参与人员的时间投入也有一定的要求。每个版本的核心功能的 owner,需要保证在 deadline 期限内完成开发任务。

dubbogo 每个版本都有一个发版人,负责相应版本的任务拆分、发展跟踪、代码 Review 和最后的测试验收,这就要求发版人自身的技术水平和时间投入极高。目前 dubbogo 每个大版本的发版人都不是同一个人,每次 dubbogo 发版,都意味着每个发版人的体力和精力的极大付出。于某在此致敬历届发版人!

管理

项目立项后,就需要明确发展大方向、发展 milestone、版本规划、以及一段时间内的具体的开发规划。项目发展初期,Roadmap 可以不清晰,先摸着石头过河,在发展过程中逐步明确其内容。

1. 需求收集

dubbogo 项目发展初期,其目标仅仅是实现 dubbo 某个版本的功能, 所以其需求收集并不用花费很久时间。随着 2019 年 8 月份发布 v1.0 后,dubbogo 越来越多地被多家生产厂商投入生产使用环境中,目前其需求方来源如下:

  • 实现 dubbo 某个版本的功能;
  • 实际使用方的生产需求;
  • 为紧跟当下最近技术发展方向而进行的技术预演。

dubbogo 当前的 K8s 注册中心技术方案就是紧跟最新技术发展方向而进行预演的极好例证,其发展时间线如下:

  • 2019 年 7 月,随着阿里集团和蚂蚁金服在云原生方向的推波助澜,阿里 dubbo 开发团队并未给出可靠的技术方向,dubbogo 社区 core members 也都没有云原生方向的技术积累和相应人才,决定先开发一个基于 kube-apiserver 的注册中心,以进行技术储备;
  • 2019 年 8 月, 调研 dubbo 的 K8s 注册中心方案后,dubbogo 社区决定抛开它独立实现一个,争取以最低代价把 dubbo 应用迁移到 K8s 环境中运行起来,同时决定未来的发展方向是 dubbogo operator;
  • 2019 年 11 月,社区的王翔同学给出了初步实现,在 2020 年 1 月随 dubbogo v1.2 版本发布;
  • 2020 年 4 月,有用户要求在 K8s 环境中 consumer 可跨 namespace 访问 provider,相应实现在 2020 年 7 月随着 dubbogo v1.5 版本发布;
  • 2020 年 5 月,dubbogo 社区和 mosn 社区合作实现了 dubbo mesh;
  • 2020 年 6 月,社区意识到 kube-apiserver 是系统的运维态 IaaS 层的核心组件,不应该跨过 PaaS 层直接暴露给应用层,否则应用层使用不当或者框架自身的流量方面的 bug 把 kube-apiserver 打垮后将造成整个系统的 P0 级故障,dubbogo v1.6 应当给出 dubbogo operator 的具体实现;
  • 2020 年 7 月,dubbogo v1.5 发布后,社区已经知道完全可以把目前的 kube-apiserver 注册中心的实现独立成为一个 dubbogo operator,未来的方向是结合 Istio 拓展其灰度发布、限流、故障注入和配置动态下发能力。

至于 dubbo-go-proxy ,dubbogo 社区并不打算借鉴其他项目,完全依靠社区同学贡献各自想法后,进行项目需求收集。目前 dubbogo 社区已经收集完毕 dubbo-go-proxy 的项目需求方的意见,社区已有 5 位同学参与项目一期开发,预计 10 月份发布初版。

2. 项目管理

需求收集完毕,定义近期一段时间内的开发目标后,就进入了项目任务拆解和项目开发管理阶段。像 dubbogo 和 dubbo-go-proxy 这种后来者项目,处于追赶阶段,个人理解它们并没有所谓的后发优势,更没有特定的技术优势,能够做的就是快速迭代,缩短与竞品的差距。

dubbogo 要求接受开发任务的各个 feature owner 必须在某个 deadline 前完成相应的开发任务。当然,feature 的等级不同,非核心 feature 【如技术预演性的 feature】允许 delay,顺延发布也无不可。

我们在项目每个版本的需求收集阶段,会把爱好者统一拉入一个小群进行沟通交流。进入开发阶段时,由于项目时间 deadline 限定以及技术匹配度两项要求,每个版本就很自然能选出能够留下来参与项目开发的人。最终参与每个版本开发的人尽量不要超过 7 个人,否则沟通成本就会剧增。

下图是 dubbogo v1.5.1 的项目管理图(阿里巴巴云原生公众号后台回复“915”即可查看清晰大图)

其有任务分解、技术风险以及风险预案。

工具是生产力,目前以 dubbogo 项目开发进度跟踪工具使用 Github Projects。如上图,每个子任务进度,这个工具都会及时显示,相应的任务 owner 可以及时根据任务进度和 deadline ,调整开发计划。更进一步的好处是,没有人会对工具产生意见,摆脱“交通基本靠走,通讯基本靠吼”的沟通模式,减少版本发版人和 feature owner 之间的戾气。

3. 代码质量

开源项目的开发任务不仅仅是开发代码,也不意味着因为各个 owner 仅仅是业余时间参与开源项目就可以降低对代码质量要求。

工具就是生产力,合适的工具能够减少人工工作量和提升代码质量。dubbogo 在项目开发过程中的各个阶段都用到了如下工具:

  • auto-comment:contributor 提出 issue 或者 pr 后,可很方便地发出预先定制的评语;
  • hound:一个 Go 语言项目静态代码检测工具,自动 Review 代码;
  • travis:一个 Github 项目自动化测试工具,可自动执行代码单测和用户自定义的集成测试,并发出钉钉通知;
  • 人工 Review:dubbogo 社区要求每个 pr 至少有三个 committer 级别的人 Review 通过;
  • goreportcard:一个很好的 Github 项目静态代码检测工具;
  • gitee:作为国内一个比较强大的代码托管网站,免费为项目提供了一些代码安全和静态代码质量检测工具,dubbogo 也经常使用,受益良多;
  • 代码规范,社区内部有一份简单的代码规范,并随着项目发展不断完善。

展望

dubbogo 项目每次发完版本,发版人都会首先发出一份 “What’s New”,除了总结最新版本的特性外,还会总结其近期进展并对未来发展进行规划,以帮助项目爱好者和使用者了解其实现思路和使用方法。

dubbogo 自身还有很多缺点,如:

  • 网站建设和文档质量都有待改进;
  • API 用户友好度不够;
  • 配置文件过多且没有合理的文档说明导致入门门槛高;
  • 整体性能改进,很多地方可添加调用链的缓存以减小锁竞争;
  • 添加 prometheus 指标,继续提高 可观测性;
  • 在协议层面支持其他微服务框架,实现原生通信,以继续提升其互联互通性;
  • dubbo-samples 用例不够丰富,继续添加测试用例,以减小入门门槛;

希望借助社区之力,在 dubbogo 发展过程中消化并解决掉这些问题,dubbogo 社区【钉钉群号 23331795】与 dubbogo 同在。

作者简介

于雨,一个有十多年服务端基础架构研发一线工作经验的程序员,目前在蚂蚁金服可信原生部从事容器编排和 service mesh 工作。热爱开源,从 2015 年给 Redis 贡献代码开始,陆续改进过 Muduo/Pika/Dubbo/Dubbo-go 等知名项目。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

从云到端,谷歌的AI芯片2.0

得芯片者得天下。我们可以把这句话再延伸一下说,得AI芯片者得未来的天下。

对于智能终端厂商来说,能够自研SoC芯片似乎才是顶级实力的象征。众所周知,盘踞全球智能手机前三甲的三星、华为、苹果,无一例外都拥有自研的SoC芯片。

(2020智能手机芯片跑分数据TOP10)

现在,经历了多年的辅助AI芯片的经验积累之后,谷歌终于要入场智能终端的核心硬件——SoC处理器芯片了。

据外媒Axois报告,谷歌在自研处理器方面取得了显著进步,最近其自主研发的 SoC 芯片已经成功流片。

据悉,该芯片是谷歌与三星联合开发,采用5nm工艺制造,“2+2+4”三架构设计的8核CPU集群,以及搭载全新ARM公版架构的GPU,同时在ISP和NPU上集成了谷歌Visual Core AI视觉处理器。这让谷歌的终端芯片能够更好地支持AI技术,比如大幅提升谷歌助手的交互体验。

在上市计划上,谷歌的这一SoC处理器芯片预计将于率先部署在下一代Pixel手机以及谷歌笔记本Chromebook中。

谷歌的这一举动被视为对苹果自研处理器模式的靠拢,从“原生系统+最主流旗舰芯片”变为“原生系统+自研芯片”,谷歌的用意肯定不仅是想摆脱高通芯片的钳制,更重要的是想通过自研芯片实现更好的软硬件结合,使得安卓系统在自家硬件上发挥更大的性能优势。

我们其实知道,自研芯片并不能在硬件利润上带给谷歌更多的价值,其中最有价值的地方在于将谷歌AI上面的优势通过软硬件的结合,在智能终端上得到更好的应用。

我们也都知道,谷歌在AI芯片上入局最早,实力强劲。然而AI芯片的技术有多强,AI技术和芯片研发有哪些相互促进的关系?相信很多人还是不明就里的,而这正是我们接下来要去深入探究的。

从云端到终边端,谷歌AI芯片的进阶之路

在谷歌的TPU(Tensor Processing Unit,张量处理单元)处理器推出之前,大部分的机器学习以及图像处理算法一直都是跑在GPU与FPGA这两种通用芯片上面的。而提出了深度学习开源框架TensorFlow的谷歌则专门做出这样一款为TensorFlow算法设计的专用芯片。

TPU就这样诞生了,然而让TPU的声名远播却是在AlphaGo大战李世石的人机围棋赛。据说,当时谷歌为TPU其实下了另一盘大棋的。因为在挑战李世石之前,AlphaGo是跑在1202个CPU和176个GPU上面与棋手樊麾比赛的。这让看过对弈过程的李世石很有信心。然而在比赛前几个月,AlphaGo的硬件平台换上了TPU,这让AlphaGo的实力很快得到成长,后面的对战局势让李世石就吃尽了苦头。

(谷歌TPU芯片)

TPU是一种专用集成电路(ASIC),作为专门在谷歌云使用的AI芯片,其使命就在于加速谷歌人工智能落地的速度。在2017年谷歌公布的第二代TPU上,其浮点运算能力高达每秒180万亿次,既可以用于推理,也可以用做训练。而到了2018年的TPU3.0版本,其计算性能相比TPU 2.0提升八倍,可达每秒 1000 万亿次浮点计算。

此后,谷歌的AI布局逐渐走向边缘侧。在2017年的谷歌云服务年会上,正式发布其边缘技术,并推出了Google Edge TPU。

Edge TPU是谷歌专为在边缘运行TensorFlow Lite ML模型而设计的ASIC芯片。Edge TPU 可用于越来越多的工业使用场景,如预测性维护、异常检测、机器视觉、机器人学、语音识别,也可以应用于本地部署、医疗保健、零售、智能空间、交通运输等各个领域。

Edge TPU体型小、能耗低,因此只负责AI加速判别、加速推算,仅为加速器、辅助处理器的角色,可以在边缘部署高精度AI,是对CPU、GPU、FPGA 以及其他在边缘运行AI的ASIC解决方案的补充。

谷歌还在去年推出了基于Edge TPU芯片的等一系列开发硬件,以及本地化AI平台Coral,为边缘侧提供优质、易部署的AI解决方案。

尽管TPU和Edge TPU主要是对深度学习起到运算推理加速的辅助服务器,但我们仍然能够看到谷歌在AI芯片上的布局野心。从云端,到边缘端和手机智能终端,正是理解谷歌AI芯片的内在逻辑。

(Pixel Visual Core)

从2017年开始,谷歌就在智能手机上陆续推出了定制的摄像头芯片“Pixel Visual Core”和“Pixel Neuro Core”,并用在了 Pixel 2、Pixel 3 和 Pixel 4上。

Pixel Visual Core,是一种图像处理单元(IPU),也是谷歌自研的第一款移动芯片,专门用于加速相机的HDR+计算,其使用了机器学习和计算摄影,可以智能地修补照片不完美的部分,也使图像处理更加流畅和快速。这也是很多人说的谷歌手机的照片不是拍出来的,而是算出来的原因。

而到了去年,谷歌在Pixel 4上使用了Pixel Neural Core专用处理器来代替Pixel VIsual Core。神经网络算法可以使谷歌手机的相机镜头识别所拍摄的物体,然后既可以将数据交给图像处理算法去优化,也可以将数据输出给谷歌助手进行识别。同时,Pixel Neural Core也可以让谷歌助手进行更复杂的人机对话,还有进行离线的语音文本翻译。

如果谷歌不是有着TensorFlow、Halide以及编译器等AI算法和开发软件,谷歌的AI芯片的很多设计显然是无法发挥太大作用的。软硬件结合,才让谷歌的芯片设计走得更为彻底和硬气。

软硬兼融,谷歌AI芯片快速迭代的硬气底色

在互联网公司的造芯赛道上,谷歌无疑是跑在最前面的一家。

据报道,早在2006年,谷歌就考虑在其数据中心部署 GPU或者 FPGA,或专用集成电路。而由于当时没有多少要在专门硬件上运行的应用,因此使用谷歌大型数据中心的富余计算能力就能满足算力要求。

而一直到2013年,谷歌已经开始推出基于DNN的语音识别的语音搜索技术,用户的需求使得谷歌数据中心的计算需求增加了一倍,这让基于CPU的计算变得特别昂贵。因此,谷歌计划使用现成的GPU用于模型训练,而快速开发一款专用的集成电路芯片用于推理。

后来我们知道这一专用定制芯片就是TPU,而这一快速开发的周期仅仅是15个月。基于软件造芯,谷歌并非独一家,但相比亚马逊、Facebook来说,谷歌则一直有持续的芯片产品推出。谷歌能够如此快速且高频地进行“硬件”输出,那自然是有其“硬气”的原因的。

首先一定是战略上的重视。此前谷歌CEO皮猜就曾强调,谷歌从来不是为硬件而硬件,背后的逻辑一定是AI、软件和硬件一体,真正解决问题要靠这三位一体。

其次就是人才的重视。以当前谷歌这一消费端的SoC芯片为例。此前这一项目对外界来说早已是公开的“秘密”。从2017年底,谷歌就开始从苹果、高通、英伟达等公司高薪挖“角”,其中包括苹果A系列处理器著名的研发工程师John Bruno。但直到去年2月,谷歌才正式宣布在印度班加罗尔的组建了一支“gChips”芯片设计团队,致力于谷歌智能手机和数据中心芯片业务,未来还会在该地办新的半导体工厂。消费级芯片似乎只差临门一脚了。

当然,最重要的因素还在于谷歌在AI芯片上的创新优势。我们知道,AI芯片的研发,本身是一个周期长且耗费巨大资金的项目。芯片设计到成品的周期可能赶不上AI算法的发展进程。如何实现AI芯片的硬件设计与算法、软件的平衡,成为谷歌设计芯片的关键优势。

而谷歌提出的解决方案则更值得称道,那就是用AI算法设计AI芯片。

具体来说,AI芯片设计存在着以下难题。首先是,3D芯片的放置,在受限区域中跨层级配置数百到上千的组件,工程师们需要手动设计来进行配置,并通过自动化软件进行模拟和性能验证,这通常需要花费大量时间。其次是,芯片的设计架构赶不上机器学习算法或神经网络架构的发展速度,导致这些算法架构在现有的AI加速器上效果不佳。另外,尽管芯片的布局规划的设计进程在加快,但在包括芯片功耗、计算性能和面积等多个目标的优化能力上仍然存在限制。

为应对这些挑战,谷歌的高级研究科学家Mirhoseini和团队研究人员Anna Goldie提出了一种神经网络,即将芯片布局建模转化为强化学习问题。

与典型的深度学习不同,强化学习系统不会使用大量标记的数据进行训练。相反,神经网络会边做边学,并在成功时根据有效信号调整网络中的参数。在这种情况下,有效信号成为降低功率、改善性能和减少面积组合的替代指标。结果就是,系统执行的设计越多,其效果就会越好。

在对芯片设计进行了足够长时间的学习之后,它可以在不到24小时的时间内为谷歌Tensor处理单元完成设计,而且在功耗、性能、面积都超过了人类专家数周的设计成果。研究人员说,这一系统还向人类同行教授了一些新技巧。

最终,谷歌团队希望像这一AI系统能达到“在同一时间段内设计更多的芯片,以及运行速度更快,功耗更低,制造成本更低,外形体积更小的芯片”这一目标。

意在未来,谷歌SoC芯片集成的AI野心

这一次谷歌自研的终端处理器SoC芯片,其本质上还是谷歌AI芯片的延伸。

细心的人们应该已经发现,这次的SoC芯片并不是完全出自谷歌研发团队,而是选择了与三星展开了合作。从媒体的曝光看,谷歌这次的手机主控会采用5nm制程、Cortex-A78大核、核心数多达20个的新GPU,而这些恰好就是三星Exynos 1000的特征。所以,这款三星堆料的芯片,最主要的“谷歌元素”就是在ISP和NPU上应用了谷歌自家设计的AI芯片。

(谷歌Pixel5谍照)

这一选择自然有着谷歌充分的考虑和一些明显的优势,但也存在着一些不利的影响。

最直观的好处就是加快了谷歌的手机端SoC芯片的研制速度,降低对高通处理器的依赖,并可以迅速应用到下一代谷歌pixel手机上。

另外一个好处是,谷歌主导的芯片设计将使得谷歌像苹果一样建成自己的封闭系统。谷歌最硬核之处就在于拥有庞大的数据和AI算法。伴随着应用层面不断丰富的数据体验和AI体验,比如在飞行模式下实现语音实时转录文字的功能,手机的硬件性能以及系统的兼容支撑就可能成为智能手机的性能天花板。如何在安卓系统中将处理器性能发挥到最大,可能没有谁比谷歌更清楚了。

毕竟前面几款谷歌Pixel手机的市场表现都不温不火,尽管其在拍摄算法和AI助手等应用上面极具优势,但在终端的外观设计、屏幕、摄像头、电池等硬件配置上一直存在“短板”,难以和全球几家主流终端玩家的旗舰机型媲美。想必应用了最新一代的SoC芯片的新款Pixel机型的定价也将非常“高端”,但在硬件上的“偏科”,可能仍然会影响其整体的市场表现。

此外,由于这是一款全新的“非主流”芯片,也会对游戏、软件开发者而言,不再成为“软件开发样板机”的首选测试机型。

无论如何,这一集成了深度学习性能的SoC芯片,将为谷歌争夺未来的AI市场做好准备,帮助谷歌、在移动终端上将语音识别、图像处理等AI应用的性能发挥到极致,提早一步占领真正的智能终端的领导者位置。

无论怎样,谷歌的造“芯”举动,一定会对上游芯片厂商以及智能终端厂商带来正面冲击。如果通过“Whitechapel”证明了谷歌的“造芯”战略的成功,那么谷歌距离苹果的差距还有多少呢?

自研芯片、安卓系统叠加最新AI计算能力,如果再补足硬件配置的短板,那么谷歌极有可能打造一个安卓生态圈的软硬件完美适配的闭环系统。

最后,我们发现一个比较令人疑惑的细节。此次芯片的代号为“Whitechapel”,名为“白教堂”。如果熟悉英美剧的读者们,可能会看过一部名为《白教堂血案》的英剧。如果不是非要过度解读的话,我们可以理解为某位重要研发者喜欢这部惊悚悬疑剧,所以以此来命名。如果非要“过度”解读一下的话,谷歌可能是想用一个百年未解的“谜团”来预示着智能终端的AI应用的纷争的开场。

当然,这个答案也许还得等谷歌的新的Pixel手机上市才能揭晓。

Fluid- 让大数据和 AI 拥抱云原生的一块重要拼图

作者 | 顾荣、车漾、范斌

得益于容器化带来的高效部署、敏捷迭代,以及云计算在资源成本和弹性扩展方面的天然优势,以 Kubernetes 为代表的云原生编排框架吸引着越来越多的 AI 与大数据应用在其上部署和运行。然而,云原生计算基金会(CNCF)全景图中一直缺失一款原生组件,以帮助这些数据密集型应用在云原生场景下高效、安全、便捷地访问数据。

如何驱动大数据、AI 应用在云原生场景下高效运行是一个既有理论意义又具应用价值的重要挑战性问题:

  • 一方面,解决该问题需考虑复杂场景下应用协同编排、调度优化、数据缓存等一系列理论与技术难题;
  • 另一方面,该问题的解决能够有力地推动广阔云服务场景下的大数据、AI 落地应用。

为系统化解决相关问题,学术界和工业界密切合作,南京大学 PASALab 副研究员顾荣博士、阿里云容器服务高级技术专家车漾、Alluxio 项目创始成员范斌博士联合推动发起了 Fluid开源合作项目

Fluid 是什么?

Fluid 是一款开源的云原生基础架构项目。在计算和存储分离的大背景驱动下,Fluid 的目标是为 AI 与大数据云原生应用提供一层高效便捷的数据抽象,将数据从存储抽象出来,以便达到:

  • 通过数据亲和性调度分布式缓存引擎加速,实现数据和计算之间的融合,从而加速计算对数据的访问;
  • 将数据独立于存储进行管理,并且通过Kubernetes的命名空间进行资源隔离,实现数据的安全隔离;
  • 将来自不同存储的数据联合起来进行运算,从而有机会打破不同存储的差异性带来的数据孤岛效应。

通过 Kubernetes 服务提供的数据层抽象,可以让数据像流体一样在诸如 HDFS、OSS、Ceph 等存储源和 Kubernetes 上层云原生应用计算之间灵活高效地移动、复制、驱逐、转换和管理。而具体数据操作对用户透明,用户不必再担心访问远端数据的效率、管理数据源的便捷性,以及如何帮助 Kuberntes 做出运维调度决策等问题。用户只需以最自然的 Kubernetes 原生数据卷方式直接访问抽象出来的数据,剩余任务和底层细节全部交给 Fluid 处理。

Fluid 项目当前主要关注数据集编排和应用编排这两个重要场景。数据集编排可以将指定数据集的数据缓存到指定特性的 Kubernetes 节点;而应用编排将指定该应用调度到可以或已经存储了指定数据集的节点上。这两者还可以组合形成协同编排场景,即协同考虑数据集和应用需求进行节点资源调度。

为什么云原生需要 Fluid?

云原生环境与更早出现的大数据处理框架在设计理念和机制上存在天然分歧。深受 Google 三篇论文 GFS、MapReduce、BigTable 影响的 Hadoop 大数据生态,从诞生之初即信奉和实践“移动计算而不是数据”的理念。因此以 Spark,Hive,MapReduce 为代表的数据密集型计算框架及其应用为减少数据传输,其设计更多地考虑数据本地化架构。但随着时代的变迁,为兼顾资源扩展的灵活性与使用成本,计算和存储分离的架构在更新兴的云原生环境中大行其道。因此云原生环境里需要类似 Fluid 这样的一款组件来补充大数据框架拥抱云原生带来的数据本地性缺失。

此外,在云原生环境中,应用通常以无状态(Stateless)微服务化方式部署,并不以数据处理为中心;而数据密集型框架和应用通常以数据抽象为中心,开展相关计算作业和任务的分配执行。当数据密集型框架融入云原生环境后,也需要像 Fluid 这样以数据抽象为中心的调度和分配框架来协同工作。

针对 Kubernetes 缺乏对应用数据的智能感知和调度优化的问题,及以 Alluxio 为例的数据编排引擎存在难以直接管控云原生基础架构层的局限,Fluid 提出数据应用协同编排、智能感知、联合优化等一系列创新方法,并且形成一套云原生场景下数据密集型应用的高效支撑平台。

具体的架构参见下图:

演示

我们提供了视频的 Demo,为您展示如何通过 Fluid 提升云上 AI 模型训练的速度。在这个 Demo 中,使用同样的 ResNet50 测试代码,Fluid 加速和原生的 ossfs 直接访问相比,不论在每秒钟的训练速度,和训练总时长相比都有明显的优势,训练耗时缩短了 69%。

点击链接,即可查看视频 Demo:https://v.qq.com/x/page/t31488r2p2q.html

快速体验 Fluid

Fluid 需要运行在 Kubernetes v1.14 及以上版本,并且需要支持 CSI 存储。Fluid Operator 的部署和管理是通过 Kubernetes 平台上的包管理工具 Helm v3 实现的。运行 Fluid 前请确保 Helm 已经正确安装在 Kubernetes 集群里。你可以参照文档,安装和使用 Fluid。

欢迎加入与反馈

Fluid 让 Kubernetes 真正具有分布式数据缓存的基础能力,开源只是一个起点,需要大家的共同参与。大家在使用过程发现 bug 或需要的 feature,都可以直接在 GitHub 上面提 issue 或 PR,一起参与讨论。

另外我们有一个钉钉群,手机端钉钉点击超链即可加入,欢迎您的参与和讨论!

作者简介

顾荣  南京大学计算机系副研究员,研究方向大数据处理系统,已在 TPDS、ICDE、Parallel Computing、JPDC、IPDPS、ICPP 等领域前沿期刊会议发表论文20余篇,成果落地应用于中国石化、百度、字节跳动等公司和开源项目Apache Spark,获 2018 年度江苏省科学技术一等奖、2019 年度江苏省计算机学会青年科技奖,当选中国计算机学会系统软件专委会委员/大数据专委会通讯委员、江苏省计算机学会大数据专委会秘书长;

车漾  阿里云高级技术专家,从事 Kubernetes 和容器相关产品的开发。尤其关注利用云原生技术构建机器学习平台系统,是 GPU 共享调度的主要作者和维护者;

范斌 Alluxio 开源项目的管理委员会成员(PMC Member)和源码维护者(Maintianer)。加入 Alluxio 项目之前, 范斌就职于谷歌, 从事下一代大规模分布式存储系统的研究与开发。他于 2013 年获得卡内基梅隆大学(Carnegie Mellon University)计算机系博士学位,博士期间从事分布式系统的设计与实现,是 Cuckoo Filter 的作者。

“阿里巴巴云原生:关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

Arm技术文档分享-Cortex-A 系列处理器Cortex-A53文档(附PDF)

Cortex-A53相关文档

  • ARM Cortex-A 系列的Cortex-A53的 ARM 文档集
  • TARM Cortex-A 系列是一系列用于复杂操作系统和用户应用程序的应用程序处理器。Cortex-A 系列处理器支持 ARM、Thumb 和 Thumb-2 指令集。

————————摘自原文


Cortex-A53文档集:

Revision: r0p4

1.ARM Cortex-A53 MPCore Processor Cryptography Extension Technical Reference Manual
2.Arm Cortex-A53 MPCore Processor Technical Reference Manual
3.ARM Cortex-A53 MPCore Processor Advanced SIMD and Floating-point Extension Technical Reference Manual

Revision r0 revisions

4.Cortex-A53 MPCore Software Developers Errata Notice


附件包含文档如下:

1.cortexa53_mpcore_software_developers_errata_notice_v21
2.DDI0500J_cortex_a53_trm
3.DDI0501F_cortex_a53_cryptography_trm
4.DDI0502G_cortex_a53_fpu_trm


文章及附件来源于:
http://infocenter.arm.com/hel…

更多Arm技术文档资料下载请关注Arm技术文档分享专栏。

文件名 大小 下载次数 操作
DDI0501F_cortex_a53_cryptography_trm.pdf 267.78KB 16 下载
DDI0502G_cortex_a53_fpu_trm.pdf 391.65KB 14 下载
DDI0500J_cortex_a53_trm.pdf 5.25MB 18 下载
cortexa53_mpcore_software_developers_errata_notice_v21.pdf 1.03MB 12 下载

BERT的嵌入层是如何实现的?看完你就明白了

非常简单直白的语言解释了BERT中的嵌入层的组成以及实现的方式。
编译:ronghuaiyang
首发:AI公园公众号

介绍

在本文中,我将解释BERT中嵌入层的实现细节,即token嵌入、Segment嵌入和Position嵌入。

简介

这是一张来自论文的图,它恰当地描述了BERT中每一个嵌入层的功能:

与大多数旨在解决nlp相关任务的深度学习模型一样,BERT将每个输入token(输入文本中的单词)通过token嵌入层传递,以便将每个token转换为向量表示。与其他深度学习模型不同,BERT有额外的嵌入层,以Segment嵌入和Position嵌入的形式。这些附加的嵌入层的原因会在本文的最后变得清楚。

Token嵌入

目的

如前一节所述,token嵌入层的作用是将单词转换为固定维的向量表示形式。在BERT的例子中,每个单词都表示为一个768维的向量。

实现

假设输入文本是“I like strawberries”。下图描述了token嵌入层的作用:

在将输入文本传递到token嵌入层之前,首先对其进行token化。另外,在tokens的开始([CLS])和结束([SEP])处添加额外的tokens。这些tokens的目的是作为分类任务的输入表示,并分别分隔一对输入文本(更多细节将在下一节中介绍)。

tokens化是使用一种叫做WordPiece token化的方法来完成的。这是一种数据驱动的token化方法,旨在实现词汇量和非词汇量之间的平衡。这就是“strawberries”被分成“straw”和“berries”的方式。对这种方法的详细描述超出了本文的范围。感兴趣的读者可以参考Wu et al. (2016)和Schuster & Nakajima (2012)中的第4.1节。单词token化的使用使得BERT只能在其词汇表中存储30522个“词”,而且在对英语文本进行token化时,很少会遇到词汇表以外的单词。

token嵌入层将每个wordpiece  token转换为768维向量表示形式。这将使得我们的6个输入token被转换成一个形状为(6,768)的矩阵,或者一个形状为(1,6,768)的张量,如果我们包括批处理维度的话。

Segment嵌入

目的

BERT能够解决包含文本分类的NLP任务。这类问题的一个例子是对两个文本在语义上是否相似进行分类。这对输入文本被简单地连接并输入到模型中。那么BERT是如何区分输入的呢?答案是Segment嵌入。

实现

假设我们的输入文本对是(“I like cats”, “I like dogs”)。下面是Segment嵌入如何帮助BERT区分这个输入对中的tokens :

Segment嵌入层只有两个向量表示。第一个向量(索引0)分配给属于输入1的所有tokens,而最后一个向量(索引1)分配给属于输入2的所有tokens。如果一个输入只有一个输入语句,那么它的Segment嵌入就是对应于Segment嵌入表的索引为0的向量。

Position嵌入

目的

BERT由一堆Transformers 组成的,广义地说,Transformers不编码其输入的顺序特征。在这个博客文章:https://medium.com/@init/how-self-attention-with-relatedposition-representations-works-28173b8c245a 动机部分更详细地解释了我的意思。总之,有Position嵌入将允许BERT理解给定的输入文本,比如:

I think, therefore I am

第一个“I”不应该与第二个“I”具有相同的向量表示。

实现

BERT被设计用来处理长度为512的输入序列。作者通过让BERT学习每个位置的向量表示来包含输入序列的顺序特征。这意味着Position嵌入层是一个大小为(512,768)的查找表,其中第一行是第一个位置上的任意单词的向量表示,第二行是第二个位置上的任意单词的向量表示,等等。因此,如果我们输入“Hello world”和“Hi there”,“Hello”和“Hi”将具有相同的Position嵌入,因为它们是输入序列中的第一个单词。同样,“world”和“there”的Position嵌入是相同的。

合并表示

我们已经看到,长度为n的token化输入序列将有三种不同的表示,即:

  • token嵌入,形状(1,n, 768),这只是词的向量表示
  • Segment嵌入,形状(1,n, 768),这是向量表示,以帮助BERT区分成对的输入序列。
  • Position嵌入,形状(1,n, 768),让BERT知道其输入具有时间属性。

对这些表示进行元素求和,生成一个形状为(1,n, 768)的单一表示。这是传递给BERT的编码器层的输入表示。

总结

在本文中,我描述了BERT的每个嵌入层的用途及其实现。如果你有任何问题,请在评论中告诉我。

—END—

英文原文:https://medium.com/@init/why-bert-has-3-embedding-layers-and-their-implementation-details-9c261108e28a

推荐阅读

  • 33个常见NLP面试问题整理
  • NLP中各种各样的编码器

关注图像处理,自然语言处理,机器学习等人工智能领域,请点击关注AI公园专栏
欢迎关注微信公众号

搭建MAC系统下的Wi-Fi loT Hi3861鸿蒙开发环境

前言

周二就收到了Wi-Fi loT Hi3861的试用开发板,最近忙的一直没有时间开始研究,终于今天周六睡了一个大懒觉起来开始准备开发环境。

因为harmonyos目前只能使用ubuntu进行编译,刷写固件需要windows环境,而我习惯在mac下开发。这对入门者来说是第一个挑战,想要开始开发首先需要集齐三大操作系统?。。

还好在开发者群里有【乔大妈】大佬提供了mac下开发,编译,烧录的全套方案,这里就把整套环境的搭建流程记录下来,方便后来者快手上手。

搭建流程

整体来说,整套开发环境分为开发,编译,烧录三个阶段。所以这里就分别讲解这三个阶段下的环境搭建。

准备工作

首先需要确定你的工作目录(workspace),就是整个开发流程内所有文件的存放目录,同时也是使用docker时设置docker挂载的目录。

这里我以 ~/workspace/harmonyos 为例。

编码环境

代码编辑器推荐使用vscode

下载 Hi3861 源码 https://repo.huaweicloud.com/… 到 ~/workspace/harmonyos 目录下解压。

mkdir -p ~/workspace/harmonyos
cd ~/workspace/harmonyos
wget https://repo.huaweicloud.com/harmonyos/os/1.0/code-1.0.tar.gz
tar xvzf code-1.0.tar.gz

至此代码已经全部下载完毕并解压到~/workspace/harmonyos目录下了,直接用vscode打开项目即可。

编译环境

编译环境主要使用docker内的ubuntu,使用docker目录映射共享工作目录实现。

安装docker的流程这里不再赘述。

使用docker拉取fnndsc/ubuntu-python3 镜像文件。

docker pull fnndsc/ubuntu-python3

漫长的等待后,运行镜像,这里主要需要把docker内的/root目录和mac上工作目录进行映射。

docker run -it --name hm_build -v ~"/workspace/harmonyos":"/root" -d fnndsc/ubuntu-python3:latest

成功执行以后docker镜像已经在后台运行了,此时可以进入docker容器进行后续操作

docker exec -it hm_build /bin/bash -l

经过测试对比开发文档(链接)后,发现这个镜像的python模块已经集成了 setuptools和kconfiglib,所以需要依次安装pycryptodome,ecdsa,six

pip3 install pycryptodome
pip3 install six --upgrade --ignore-installed six
pip3 install ecdsa

然后安装scons。

apt-get install scons -y

安装gn

cd /tmp
apt-get install wget -y
get https://repo.huaweicloud.com/harmonyos/compiler/gn/1523/linux/gn.1523.tar
tar -xvf gn.1523.tar -C ~/
export PATH=~/gn:$PATH  

安装ninja

wget https://repo.huaweicloud.com/harmonyos/compiler/ninja/1.9.0/linux/ninja.1.9.0.tar
tar -xvf ninja.1.9.0.tar -C ~/
export PATH=~/ninja:$PATH

安装gcc_riscv32

wget https://repo.huaweicloud.com/harmonyos/compiler/gcc_riscv32/7.3.0/linux/gcc_riscv32-linux-7.3.0.tar.gz
tar -xvf gcc_riscv32-linux-7.3.0.tar.gz -C ~/
export PATH=~/gcc_riscv32/bin:$PATH

终于编译环境算是准备就绪了,不容易呀~~ 接下来是见证奇迹的时刻开始编译。

cd ~
python build.py wifiiot

祈祷吧,如果看到 BUILD SUCCESS ,恭喜你编译成功。

如果编译失败,可以尝试在docker内重新下载源码进行编译,编译成功的iot文件可以通过/root/传输到mac的工作目录内。

烧录环境

烧录主要是使用 crossover运行海思的烧录工具Hiburn进行烧录。

https://device.harmonyos.com/…


作者:LibiChai
想了解更多内容,请访问:
51CTO和华为官方战略合作共建的鸿蒙技术社区
https://harmonyos.51cto.com?jssq