小助手，最近暑假有很多空闲时间，不知道还有没有像去年IOT论坛活动送智慧路灯开发板的活动？

【功能模块】增加驱动导致系统无法起来, 报kernel crc校验错误【操作步骤&问题现象】1、在增加了一个按键驱动, 系统起不来并报kernel校验错误2、怀疑是tsv里设置boot的大小导致, 但算下来并没有超过规定的范围【截图信息】tsv文件env打印【日志信息】（可选，上传日志内容或者附件）

【功能模块】小熊派开发板BearPi+NB35-A通信模块【问题】其他板将数据（图片之类的）通过数据线传到小熊派开发板这里，请问怎么通过NB35-A将这些数据传到PC端或者云端

刚开始学，遇到了几个问题。1. IoT studio是不是下架了？是有个软件叫LiteOS studio吗？没看到下载链接啊，https://gitee.com/LiteOS/LiteOS_Studio/releases/这个链接没有.exe文件呢。2. 现在云平台没有应用开发了是嘛？只能看到产品开发。做智能路灯实验的时候，云平台能看到数据了，但没有找到设计应用界面的地方。那应用怎么开发呢？3. 用Keil生成的裸机工程和用 STM32CuebMX 生成的裸机工程，工程目录结构不一样吧？所以移植的时候，具体步骤也也会不一样吧？

传奇芯片架构师 Jim Keller 在芯片界一直是一位万众瞩目的人物。近日，他在一次会议上大胆放言，称其在离开前雇主 AMD 后，他的 K12 ARM CPU 项目被“愚蠢地取消”了。芯片架构界的传说：Jim KellerKeller 在芯片架构方面的成就无人能敌，在芯片架构设计上有着显赫的履历。在 40 年的工作经历中，他一次又一次创造了被认为是芯片行业中至关重要的领先产品。他曾经于苹果公司带领开发 A4 和 A5 芯片，帮助乔布斯摆脱了对芯片制造商的依赖，为苹果节省了几十亿美元。也同时曾于 AMD 担任 K7 处理器、K8 架构的设计师，帮助 AMD 击败了英特尔的 64 位安腾芯片，使得 AMD 第一次在服务器芯片领域站稳了脚跟，后又“二进宫”担任 Zen 芯片设计师。第二次离开 AMD 后，Keller 去了特斯拉，成为其自动驾驶芯片的打造者。然而这里依然不是他的最终归宿，2018 年，他又加入了世界上最大的处理器制造商英特尔，但也于2020年离职。Keller吐槽AMD取消 K12Keller 在 4 月的一次活动中发表了关于”计算的未来“的演讲。他表示，自己在 AMD 任职期间开发了 Zen 1 处理器架构，并参与了 Zen 2 和 Zen 3 项目。这意味着 Zen 3 可能是这段时期里经 Jim Keller 之手的最后一个设计。而 AMD 新团队正在折腾包括 Zen 4 在内的 5 个内部设计项目。图片来源：wccftech官网Keller 表示，在 AMD 二进宫期间，他和其团队成员注意到了 Arm 和 x86 处理器的缓存设计在执行单元等其他方面基本相同，两者之间唯一的区别是解码单元，因此他们决定在原定的 K12 ARM 新芯片上发力，尽管 AMD“愚蠢地取消了这个项目。”图片来源：wccftech官网Jim Keller 透露，K12 ARM CPU 项目实际上是在他离开 AMD 公司后，被某些产品经理给取消的。因为大多数产品经理都害怕改变，但作为一名架构师，Jim Keller 对此毫无畏惧，且他回忆起在 AMD 工作时都觉得相当有趣。如果有幸延续至今，基于 ARMv8-A 的处理器，有望随 Zen 项目一同到来、并专注于高能效的应用场景 —— 比如计算密集型服务器、嵌入式、以及半定制等细分市场。遗憾的是，AMD 最终选择了基于各种 Zen 核心架构的半定制服务器芯片路线 ，比如定于明年亮相的 Zen 4c 架构（主打计算密集型服务器市场），就会在 EPYC Bergamo 平台上首次亮相。那么，究竟是 Keller 的战略方向判断失误，还是 AMD 害怕做出改变，从而选择了保守的策略呢？各位看官，你怎么看？参考资料：https://www.theregister.com/2022/06/20/jim_keller_arm_cpu/原文链接：https://blog.csdn.net/csdnopensource/article/details/125392345

传感器相当于自动驾驶汽车的眼睛。通过传感器，自动驾驶汽车能够识别道路、其他车辆、行人障碍物和基础交通设施，在最小测试量和验证量的前提下保证车辆对周围环境的感知。 按照自动驾驶不同技术路线，传感器可分为激光雷达、传统雷达和摄像头三种。 激光雷达是被当前自动驾驶企业采用比例最大的传感器类型。谷歌、百度、优步等公司的自动驾驶技术目前都依赖于它，这种设备安装在汽车的车顶上，能够用激光脉冲对周围环境进行距离检测，并结合软件绘制3D图，从而为自动驾驶汽车提供足够多的环境信息。激光雷达具有准确快速的识别能力，唯一缺点在于造价高昂（平均价格在8万美元一台），导致量产汽车中难以使用该技术。 传统雷达和摄像头是传感器替代方案。由于激光雷达的高昂价格，走实用性技术路线的车企纷纷转向以传统雷达和摄像头作为替代，**从软件和车辆连接能力方面进行补偿**。例如著名电动汽车生产企业特斯拉，采用的方案就是雷达和单目摄像头。 其硬件原理与目前车载的ACC自适应巡航系统类似，依靠覆盖汽车周围360°视角的摄像头及前置雷达来识别三维空间信息，从而确保交通工具之间不会互相碰撞。 虽然这种传感器方案成本较低、易于量产，但对于摄像头的识别能力具有很高要求：单目摄像头需要建立并不断维护庞大的样本特征数据库，如果缺乏待识别目标的特征数据，就会导致系统无法识别以及测距，很容易造成事故的发生。而双目摄像头可直接对前方景物进行测距，但难点在于计算量大，需要提高计算单元性能。 双目摄像头： 

一、计算机网络结构大规模现代计算机网络：网络边缘、接入网络与网络核心1.网络边缘：连接到网络上的所有端系统（例如：连接到网络上的计算机、服务器、智能手机等）构成了网络边缘。2.接入网络：实现网络边缘与网络核心连接与接入的网络对于大规模、复杂的网络端系统相距遥远，这些端系统之间的网络连接和通信需要网络核心进行数据中继和转发。通常，网络核心是由运营商等企业运营的ISP网络，不能直接延伸到用户区域，例如：家中，用户就需要借助接入网络实现与ISP的连接。常见的网络接入技术：电话拨号接入（使用调制调节器）、非对称数字用户线路ADSL（常见，使用频分多路复用技术）、混合光纤同轴电缆HFC接入网络（电缆调制解调器，使用频分多路复用技术，独享式接入）、局域网（以太网、WIFi）、移动接入网络（个人设备接入网络。如：2G/3G/4G）3.网络核心：是由通信链路互连的分组交换设备构成的网络，作用是实现网络边缘中主机之间的数据中继与转发典型的分组交换设备：交换机、路由器二、数据交换技术1.计算机网络的目的：在网络边缘的主机之间实现相互的数据传输与信息交换2.数据交换网络：中间网络不需要关心传输数据内容，只是为这些数据从一个节点到另一节点，直至到达目的地，提供数据中继与交换的功能。交换节点：组成交换网络的节点通信子网：交换节点和传输介质的集合，即网络核心。3.数据交换是实现在大规模网络核心上进行数据传输的技术基础。常见的数据交换技术：①电路交换：电话网络是最早最大的电路交换网络。（例如：电话拨号呼叫过程）电路交换包括三个阶段：建立电路、传输数据、拆除电路。、缺点：信道容量与有效时间的浪费②报文交换：发送方把要发送的信息附加上发送/接收主机的地址以及其他控制信息，构成一个完整的报文，然后以报文为单位在交换网络的各个节点之间以存储-转发的方式传送，直至目的主机。缺点：不能满足实时通信速度要求、节点存储空间不够、输出链路被占用不能及时转发报文，使报文被丢弃。③分组交换：目前应用广泛的技术，分组交换将报文分割成较小的数据块，数据块加上地址、序号等控制信息构成数据分组，每个分组独立传输到目的地，目的地将分组重新组装，还原为报文。优点：交换设备存储容量要求低、交换速度快、可靠传输效率高、更加公平

1.插卡时，检测SD CARD TEST 显示SD does not exist2.继续使用liteOS studio开发后，现在协议栈无法打开，网络附着失败。是不是SD卡的原因？插卡的问题还是本身设备有问题？怎么检测，有什么解决办法吗？

请教一下，这两天在跑camera传感器可视化的样例，命令及日志如下：上机位 mviz MDCVision Image中没有 71这个topic，看日至我没看到那里错了，这个如果排查？我的上机位地址配置好的，摄像头配置文件按照弘景广电demo样例来的，应该没问题。运行及日至：root@mdchost:/home/mdc# /opt/platform/mdc_platform/script/camera_mviz_start.sh 71[Info ] Input instance: 71 2019/04/20 08:28:02.465686650 2019/04/20 08:28:02.453998440 000 CAMV CAMV info [camera mviz start]The MViz server address is parsed and the visualization client is created successfully.2019/04/20 08:28:05.578183330 2019/04/20 08:28:05.566393050 000 CAMV CM info [CM version is 3.10.6]2019/04/20 08:28:05.578269590 2019/04/20 08:28:05.566473540 001 CAMV CM info [CM configuration file path is /opt/platform/mdc_platform/manual_service/camera_mviz/etc/CameraMvizHostProcess/]2019/04/20 08:28:05.578591910 2019/04/20 08:28:05.566796900 002 CAMV CM info [RT_DDS_URI is set with RT_DDS_URI=/opt/platform/mdc_platform/manual_service/camera_mviz/etc/CameraMvizHostProcess/dds.xml]2019/04/20 08:28:05.578687000 2019/04/20 08:28:05.566890190 003 CAMV CM info [Custom qos profile does not exist, default qos profile will be used[userQosPath=/var/domainqos.xml, defaultQosProfile=/opt/platform/mdc_platform/manual_service/camera_mviz/etc/CameraMvizHostProcess/default_qos.xml, service=/HuaweiMDC/PlatformServiceInterface/CameraServiceInterfacePkg/CameraEncodedServiceInterface, instanceId=65535]]2019/04/20 08:28:05.578937260 2019/04/20 08:28:05.567140670 004 CAMV CM info [SOMEIP_CONFIG_FILE is set with SOMEIP_CONFIG_FILE=/opt/platform/mdc_platform/manual_service/camera_mviz/etc/CameraMvizHostProcess/vsomeip.json]2019/04/20 08:28:05.579490950 2019/04/20 08:28:05.567701590 005 CAMV CM info [Participant transport qos mask is 1]2019/04/20 08:28:05.581210480 2019/04/20 08:28:05.569415330 006 CAMV CM info [DDS start find service[serviceId=57344, instanceId=15176]]2019/04/20 08:28:05.581437740 2019/04/20 08:28:05.569641780 007 CAMV CM info [Participant transport qos mask is 1]2019/04/20 08:28:05.581808110 2019/04/20 08:28:05.570018370 008 CAMV CM info [Find maintaind service and create proxy successfully[instanceId=15176]]2019/04/20 08:28:05.582042010 2019/04/20 08:28:05.570249530 009 CAMV CM info [DDS start find service[serviceId=2433, instanceId=65535]]2019/04/20 08:28:05.583700570 2019/04/20 08:28:05.571907460 010 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=60620]]2019/04/20 08:28:05.584520440 2019/04/20 08:28:05.572726720 011 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=62836]]2019/04/20 08:28:05.585277550 2019/04/20 08:28:05.573483850 012 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=54288]]2019/04/20 08:28:05.586028450 2019/04/20 08:28:05.574234040 013 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=52436]]2019/04/20 08:28:05.586806870 2019/04/20 08:28:05.575012730 014 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=26369]]2019/04/20 08:28:05.587478350 2019/04/20 08:28:05.575683130 015 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=58344]]2019/04/20 08:28:05.588146600 2019/04/20 08:28:05.576352080 016 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=62056]]2019/04/20 08:28:05.588830820 2019/04/20 08:28:05.577036120 017 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=33436]]2019/04/20 08:28:05.589530580 2019/04/20 08:28:05.577738060 018 CAMV CM info [Create method client[serviceId=57344, instanceId=15176, methodShortName=MAINTAIND, entityId=54641]]2019/04/20 08:28:05.599859090 2019/04/20 08:28:05.588064910 019 CAMV CM info [DDS event does not use E2E protection[eventInfo=57344_15176_SwitchApplicationLatency]]2019/04/20 08:28:05.600124300 2019/04/20 08:28:05.588328460 020 CAMV CM info [Subscribe event 30161 service id: 57344 instance id: 15176 event shortName is MAINTAIND cachesize is 10]

1.时序数据库的定义时序数据是随时间不断产生的一系列数据，简单来说，就是带时间戳的数据。时序数据库 (Time Series Database，TSDB) 是优化用于摄取、处理和存储时间戳数据的数据库。此类数据可能包括来自服务器和应用程序的指标、来自物联网传感器的读数、网站或应用程序上的用户交互或金融市场上的交易活动。时序数据的主要数据属性如下：每个数据点都包含用于索引、聚合和采样的时间戳。该数据也可以是多维的和相关的；写多读少，需要支持秒级和毫秒级甚至纳秒级高频写入；查询通常是多维聚合查询，对查询的延迟要求比较高数据的汇总视图（例如，下采样或聚合视图、趋势线）可能比单个数据点提供更多的洞察力。例如，考虑到网络不可靠性或传感器读数异常，我们可能会在一段时间内的某个平均值超过阈值时设置警报，而不是在单个数据点上这样做；分析数据通常需要在一段时间内访问它（例如，给我过去一周的点击率数据）；虽然其他数据库也可以在数据规模较小时一定程度上处理时间序列数据，但 TSDB可以更有效地处理随时间推移的数据摄取、压缩和聚合。以车联网场景为例，20000辆车，每个车60个指标，假设每秒采集一次，那么每秒将上报20000 * 60 = 1200000指标值，即120W数据指标值每秒，每个指标值为16字节（假设仅包括8字节时间戳和8字节的浮点数），则每小时将产生64G左右的数据。而实际上每个指标值还会附带标签等额外数据，实际需要存储空间会更大。简而言之，时序数据库是专门用于存储和处理时间序列数据的数据库，支持时序数据高效读写、高压缩存储、插值和聚合等功能。2.时序数据库相关概念时序数据库是专门处理时序数据的数据库，因此其相关概念是和时序数据紧密联系的，下面是时序数据库的一些基本概念。* 度量 Metric：Metric 类似关系型数据库里的表（Table），代表一系列同类时序数据的集合，例如为空气质量传感器建立一个 Table，存储所有传感器的监测数据。* 标签 Tag：Tag 描述数据源的特征，通常不随时间变化，例如传感器设备，包含设备 DeviceId、设备所在的 Region 等 Tag 信息，数据库内部会自动为 Tag 建立索引，支持根据 Tag 来进行多维检索查询；Tag 由 Tag Key、Tag Value 组成，两者均为 String 类型。* 时间戳 Timestamp：Timestamp代表数据产生的时间点，可以写入时指定，也可由系统自动生成；* 量测值 Field：Field描述数据源的量测指标，通常随着时间不断变化，例如传感器设备包含温度、湿度等Field；* 数据点Data Point: 数据源在某个时间产生的某个量测指标值（Field Value）称为一个数据点，数据库查询、写入时按数据点数来作为统计指标；* 时间线 Time Series ：数据源的某一个指标随时间变化，形成时间线，Metric + Tags + Field 组合确定一条时间线；针对时序数据的计算包括降采样、聚合（sum、count、max、min等）、插值等都基于时间线维度进行；3.时序数据库的发展趋势时序数据库的发展趋势，可以从DB-engines（Knowledge Base of Relational and NoSQL Database Management Systems)获取获取到，下图是DB-engines收录的数据库近24个月的发展趋势，其中时序数据库的活跃度最高，且随时间呈现越来越活跃的趋势。下图是DB-engines收录的时序数据库的排名，其中排名最高的时序数据库是2013年开源的InfluxDB。时序数据库应用场景时序数据库的应用场景在物联网和互联网APM等场景应用比较多，下面是列举了一些时序数据库的应用场景，但不是全部：* 公共安全：上网记录、通话记录、个体追踪、区间筛选；* 电力行业：智能电表、电网、发电设备的集中监测；* 互联网：服务器/应用监测、用户访问日志、广告点击日志；* 物联网：电梯、锅炉、机械、水表等各种联网设备；* 交通行业：实时路况、路口流量监测、卡口数据；* 金融行业：交易记录、存取记录、ATM、POS机监测；

【功能模块】atlas200DK上的cameracapture【操作步骤&问题现象】1、调用cameracapture的cap.read返回的图片无法用于opencv及dlib库，使用print提示是acliite什么的object2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

摘要嵌入式系统是以应用为中心，以计算机为基础，软硬件可定制，适用于不同应用场合对功能、可靠性、成本、体积、功耗有严格要求的专用计算机系统。嵌入式系统已广泛应用于各种领域，如通信领域、工业控制、交通领域、医疗卫生、消费娱乐等。正如温湿度采集系统的设计,其包括了数据的采集过程、传输过程以及数据的处理过程是嵌入式系统在国家森林火灾的防范、大型粮库的温湿度控制以及家庭温湿度控制等方面的典型应用。由于传统的有线方式在数据的检测、采集、以及传输过程中需要大量的节点且这些节点不集中，因此需要大量布线.为了避免该问题本设计主要从无线传感方向进行改进，本设计对温湿度的读取是利用CC2530的I/O（P1。0和P1.1)模拟一个类IIC的过程，对光照的采集则使用内部的AINO通道。该系统使用CC2530读取温湿度传感器SHT10的温度和湿度数据，并通过CC2530内部的ADC得到光照传感器的数据。最后将采样得到的数据转换然后在LCD上显示。前言本设计是一种基于CC2530和数字温湿度传感器的温湿度采集系统。即该系统是采用Zigbee无线通信技术结合传感器，并通过运用Zigbee协议架构组建无线传感网络，来实现主从节点的数据采集和传输的。同时，需要在网络层通过AODV路由协议来进行节点间的连接以及数据的收发。总之，基于无线传感技术的无线网络传感器是一种将传感器、控制器、计算能力、通信能力完美的结合于一身的嵌入式设备。它们跟外界的物理环境交互,实时的采集信息,并且将收集到的信息通过无线传感器网络传送给远程用户。无线网络传感器一般是由一个低功耗的微控制器（MCU)和若干个存储器、无线电/光通信装置、传感器等组件所集成的，通过传感器、动臂机构、以及通信装置和它们所处的外界物理环境进行交互。由此而引入的无线传感网络更是一种开创了新的应用领域的新兴概念和技术,广泛被应用于医疗领域、大规模环境监测、智能建筑、战场监视、智能家装、工业自动化和大区域内的目标追踪等领域。如,在医院Zigbee网络可以帮助医生及时并准确的收集急诊病人的信息及相关度检查结果，从而快速准确的作出诊断;同时，对一些特殊的病人，可让其携带Zigbee终端而对其进行24小时的体温、脉搏控制.生命诚可贵，时间价更高!又如，在工业控制领域内，就可以很好的通过无线传感网络实现厂房内不同区域的温湿度的检测及控制,以及相关机器运转状况是否正常的有关信息,统计库存量，等等.总的来说，我们的工作及生活在无形的改变着，变得更精致更高效更美丽。而这无形中进行着的神奇改变的关键莫过于高端的技术——嵌入式系统开发技术及无线技术.一 基本原理1.1 温湿度数据采集原理温湿度探头直接使用IIC接口进行控制，本实验将使用CC2530 读取温湿度传感器SHT10的温度和湿度数据，并将采样到的数据转换然后再LCD显示。其中对温湿度的读取是利用CC2530的I/O（P1。0和P1.1）模拟一个类IIC得过程。其中该系统所使用的SHT10 是一款高度集成的温湿度传感器芯片， 提供全标定的数字输出。它采用专利的CMOSens 技术，确保产品具有极高的可靠性与卓越的长期稳定性。传感器包括一个电容性聚合体测湿敏感元件、一个用能隙材料制成的测温元件,并在同一芯片上，与 14 位的 A/D 转换器以及串行接口电路实现无缝连接。1。1。1SHT10 引脚特性1。 VDD，GND SHT10 的供电电压为 2.4～5.5V.传感器上电后，要等待 11ms 以越过“休眠"状态。在此期间无需发送任何指令。电源引脚（VDD，GND)之间可增加一个 100nF 的电容，用以去耦滤波.2. SCK 用于微处理器与 SHT10 之间的通讯同步。由于接口包含了完全静态逻辑,因而不存在最小 SCK 频率.3。 DATA 三态门用于数据的读取。DATA 在 SCK 时钟下降沿之后改变状态,并仅在 SCK 时钟上升沿有效.数据传输期间，在 SCK 时钟高电平时，DATA 必须保持稳定。为避免信号冲突，微处理器应驱动 DATA 在低电平。需要一个外部的上拉电阻（例如：10kΩ）将信号提拉至高电平。上拉电阻通常已包含在微处理器的 I/O 电路中。（1）向 SHT10 发送命令：用一组“ 启动传输”时序，来表示数据传输的初始化。它包括：当 SCK 时钟高电平时DATA 翻转为低电平，紧接着 SCK 变为低电平，随后是在 SCK 时钟高电平时 DATA 翻转为高电平。后续命令包含三个地址位（目前只支持“000”，和五个命令位。SHT10 会以下述方）式表示已正确地接收到指令：在第 8 个 SCK 时钟的下降沿之后,将 DATA 拉为低电平（ACK位).在第 9 个 SCK 时钟的下降沿之后，释放 DATA（恢复高电平）。（2）测量时序(RH 和 T)：发布一组测量命令（‘00000101’表示相对湿度 RH，‘00000011’表示温度 T）后，控制器要等待测量结束.这个过程需要大约 11/55/210ms，分别对应 8/12/14bit 测量。确切的时间随内部晶振速度，最多有±15％变化。SHTxx 通过下拉 DATA 至低电平并进入空闲模式,表示测量的结束。控制器在再次触发 SCK 时钟前，必须等待这个“数据备妥"信号来读出数据。检测数据可以先被存储,这样控制器可以继续执行其它任务在需要时再读出数据。接着传输 2 个字节的测量数据和 1 个字节的 CRC 奇偶校验. 需要通过下拉 DATA 为低电平,uC以确认每个字节.所有的数据从 MSB 开始，右值有效（例如：对于 12bit 数据，从第 5 个SCK 时钟起算作 MSB； 而对于 8bit 数据， 首字节则无意义）。用 CRC 数据的确认位，表明通讯结束。如果不使用 CRC—8 校验，控制器可以在测量值 LSB 后，通过保持确认位 ack 高电平， 来中止通讯.在测量和通讯结束后，SHTxx 自动转入休眠模式。（3)通讯复位时序：如果与 SHTxx 通讯中断，下列信号时序可以复位串口：当 DATA 保持高电平时，触发SCK 时钟 9 次或更多.在下一次指令前,发送一个“传输启动”时序。这些时序只复位串口，状态寄存器内容仍然保留。二 系统分析嵌入式温湿度采集系统是一种基于CC2530和数字温湿度传感器SHT10的温湿度采集系统。该系统采用Zigbee无线通信技术结合传感器，通过运用Zigbee协议架构组建无线传感网络，实现主从节点的数据采集和传输，以及一点对多点，两点之间的通信。并且也是基于Zigbee协议栈的中心节点和终端节点的协议传输，主要是从Zigbee协议栈网络层里AODV路由协议着手，在网络层通过AODV路由协议进行节点间的连接以及数据的收发。2.1具体步骤描述1、给智能主板供电（USB 外接电源或 2 节干电池）; 2、将一个无线节点模块插入到带 LCD 的智能主板的相应位置； 3、将温湿度及光电传感器模块插入到智能主板的传感及控制扩展口位置; 4、将 CC2530 仿真器的一端通过 USB 线（A 型转 B 型)连接到 PC 机，另一端通过 10Pin下载线连接到智能主板的 CC2530 JTAG 口（J203)； 5、将智能主板上电源开关拨至开位置。按下仿真器上的按钮,仿真器上的指示灯为绿色时，表示连接成功； 6、使用 IAR7。51 打开“…\OURS_CC2530LIB\lib10（HumiTempLight)\ IAR_files”下的HumiTempLight.eww 文件，下载运行程序; 7、观察 LCD 上温度、湿度和光照强度的变化； 8、用一个物体挡住光照传感器的光线，观察 LCD 上光照强度数据的变化; 9、向温湿度传感器吹一口气体，观察 LCD 上温湿度数据的变三 详细设计本设计是基于CC2530的温湿度数据采集系统设计。因此，其重点是温湿度数据采集设计的实现，主要可分为二大部分，一是实现无线传感的硬件模块;二是实现无线传感的软件支持,也就是基于Zigbee协议架构的编程.实现温湿度数据采集的硬件部分主要包括：无线传感基本结构、无线传感实现原理、本设计所使用的实验箱以及软件支持、常见的无线传感模块以及实现基于CC2530的温湿度采集系统节点模块设计。实现温湿度数据采集的软件部分主要包括：Zigbee协议栈整体架构、Zigbee协议栈网络层、AODV路由协议。3.1实现温湿度数据采集的硬件部分嵌入式温湿度采集系统设计的硬件部分可以大体有无线传感基本结构、无线传感实现原理、本设计所使用的实验箱以及软件支持、常见的无线传感模块以及实现基于CC2530的温湿度采集系统节点模块设计等组成.其具体内容如下：3.1.1无线传感基本结构及实现原理无线传感器网络在设计目标方面是以数据为中心的,在无线传感器网络中，因为节点通常运行在人无法接近的恶劣甚至危险的远程环境中，所以除了少数节点需要移动以外，大部分节点都是静止不动的。在被监测区域内,节点任意散落,节点除了需要完成感测特定的对象以外，还需要进行简单的计算,维持互相之间的网络连接等功能。并且由于能源的无法替代以及低功耗的多跳通信模式节，设计无线传感节点时，有效的延长网络的生命周期以及节点的低功耗成为无线传感器网络研究的核心问题，其无线传感节点模型如下图1—2所示。无线传感网络的建立是基于传感器加无线传输模块的,传感器采集的数据,简单处理后经过无线传输模块传到服务器或应用终端。目标、观测节点、传感节点和感知视场是无线传感器网络所包括的4个基本实体对象.大量传感节点随机部署，单个节点经过初始的通信和协商，通过自组织方式自行配置,形成一个传输信息的单跳链接或一系列无线网络节点组成的网络，协同形成对目标的感知视场。传感节点检测的目标信号经过传感器本地简单处理后通过单播或广播以多跳的方式通过邻近传感节点传输到观测节点。用户和远程任务管理单元则能够通过卫星通信网络或Internet等外部网络，与观测节点进行数据信息的交互。观测节点向网络发布查询请求和控制指令,接收传感节点返回的目标信息。3.1.2使用的实验箱以及软件支持物联网创新实验系统IOV—T—2530采用系列传感器模块和无线节点模块组成无线传感网，扩展嵌入式网关实现广域访问，可实现多种物联网构架,完成物联网相关的各种传感器的信息采集、无线信号收发、Zigbee网络通讯、组件控制全过程。该工具箱提供了无线传感网通信模块、基本的传感器及控制器模块、嵌入式网关、计算机服务器参考软件等。3.1.3实现温湿度采集系统节点模块设计实验系统包含4个无线传感网通信节点和一个无线网络协调器。其中具体情况如下：无线节点模块:主要有射频单片机构成，MCU是TI的CC2530，2。4G载频，棒状天线.传感器及控制模块：系列传感器模块，包括温湿度传感模块、继电器模块和RS232模块等，也可以通过总线扩展用户自己的传感器及控制器部件.电源板或智能主板：即实现无线节点模块与传感及控制模块的连接，又实现系统供电，目前主要有两节电池供电，保留外接电源接口，可以直接有直流电供电。3.2实现温湿度数据采集的软件部分实现温湿度数据采集的软件部分主要有Zigbee技术概述、Zigbee协议栈整体架构、Zigbee协议栈网络层、AODV路由协议等几部分组成。而Zigbee协议栈网络层主要包括: 网络层概述、网络层所实现功能、网络层中常用路由协议。AODV路由协议主要包括:协议概述、协议的基本原理、AODV路由协议消息控制帧。一下将是温湿度数据采集的软件部分各部分的具体介绍:3.2.1 ZIGBEE技术概述Zigbee技术的使用与发展很大程度上弥补了无线通信市场上低功耗、低成本、低速率的空缺。同时随着Zigbee技术的深入发展和应用,越来越多的注意力和研究力量将会转到应用的设计、实现互联互通测试和市场的推广等方面。Zigbee技术的关键点是发展一种易布建、低成本、低功耗的无线网络.Zigbee技术的应用前景非常好。Zigbee在未来的几年里将在工业无线定位、工业控制、消费电子、汽车自动化、家庭网络、楼宇自动化、医用设备控制等多个控制领域具有广泛的应用，特别是工业控制和家庭自动化，将会成为今后Zigbee芯片的主要应用领域。通常符合以下条件之一的应用，都可以考虑采用Zigbee技术：(1)网点多:需要数据采集或监控的网点多。(2）低传输量:要求传输的数据量不大且要求数据成本低。（3）可靠性高:要求数据传输可靠性、全性高。（4)体积小：设备体积很小，体积较大的充电电池或者电源模块不便放置.（5）电池供电。（6）覆盖量大:所需检测点监测点多，地形复杂，需要较大的网络覆盖面积.（7）现有移动网络的覆盖盲区.（8）遥测、遥控系统:使用现存移动网络进行的低数据量传输。（9）局部区域移动目标的定位系统：使用GPS效果差、成本高的。Zigbee无线传感网络是基于IEEE802。15。4技术标准和Zigbee网络协议而设计的无线数据传输网络，该网络主要应用在压力过程控制数据采集、流量过程控制数据采集、温度湿度监控、楼宇自动化、工业控制、数据中心、社区安防、设备监控、环境数据监控、制冷监控、仓库货物监控等方面.适用于蔬菜大棚温度、湿度和土壤酸碱度监控，钢铁冶炼温度控制，煤气抄表等各个领域。这种网络主要用于无线系统中短距离的连接，提供传感器网络接入，能够满足各种传感器的数据输出和输入控制的命令和信息的需求，实现系统网络化、无线化.Zigbee技术是一种应用于各种电子设备之间的无线通信技术，这种通信组网是基于中短距离范围内、低传输速率下的。根据Zigbee技术的本质，它具有下列特性:低功耗、高度扩展性、可靠性高等。3.2.2 ZIGBEE协议栈Zigbee协议栈由一组子层组成，每一层为其上层提供一定的特定服务：一个数据实体提供数据传输服务，一个管理实体提供管理、维护等服务。每个服务实体通过一个服务接入点(SAP）为其上层提供服务接口,并且每个服务接入点（SAP）提供了一系列的基本服务指令来实现相应的功能。Zigbee协议栈中包括应以下各个子层：（1)APP（Application Programming)：应用层目录，这是用户创建各种不同工程的区域，在这个目录中包含了应用层的内容和这个项目的主要内容,在协议栈里面一般是以操作系统的任务实现的。（2）HAL（Hardware (H/W） Abstraction Layer）：硬件层目录，包含有与硬件相关的配置和驱动及操作函数.ZigBee硬件层通过射频固件和射频硬件提供了一个从MAC层以硬件层无线信道的接口.在硬件层中，包含一个硬件层管理实体（PLME）,该实体通过调用硬件层的管理功能函数，为硬件层管理服务提供其接口,同时,还负责维护由硬件层所管理的目标数据库，该数据库包含有硬件层个域网络的基本信息。（3）MAC：介质接入控制子层，包含了MAC 层的参数配置文件及其MAC 的LIB 库的函数接口文件.实现的功能有：1、能产生网络信标。2、支持PAN的连接和断开连接。3、同信标保持同步。4、在对等的MAC实体之间提供一个可靠的通信链路.5、处理和维护GTS机制.6、信道接入采用CSMA—CA接入机制。7、支持设备的安全性。介质访问控制层（MAC)帧被称为MAC协议数据单元（MPDU)，其长度不超过127个字节.它具有四种不同的帧形式，即信标帧、数据帧、确认帧和命令帧。（4）MT(Monitor Test）：实现通过串口可控各层，与各层进行直接交互。（5）NWK(ZigBee Network Layer)：网络层目录，含网络层配置参数文件及网络层库的函数接口文件，APS 层库的函数接口。（6)OSAL（Operating System (OS） Abstraction Layer）：协议栈的操作系统。（7)Profile：AF（Application work） 层目录，包含AF 层处理函数文件.（8）Security：安全层目录，安全层处理函数，比如加密函数等。（9)Services:地址处理函数目录，包括着地址模式的定义及地址处理函数。(10）0Tools：工程配置目录，包括空间划分及ZStack 相关配置信息.（11)ZDO(ZigBee Device Objects）：ZDO 目录.(12）ZMac： MAC 层目录，包括MAC 层参数配置及MAC 层LIB 库函数回调处理函数。（13）ZMain:主函数目录，包括入口函数及硬件配置文件。（14）Output:输出文件目录,这个EW8051 IDE 自动生成的.3.2.3 ZIGBEE协议栈网络层ZigBee网络层必须提供一定的功能，其主要是提供一些必要的函数，以保证IEEE 802。15。4—2003ZigBee协议栈的MAC层能够正确操作，正常工作，并且为应用层提供一个合适的服务接口。为了和应用层通信，必须向其提供接口，网络层的概念包括了两个必要的功能服务实体。它们分别为数据服务实体（NLDE）和管理服务实体（NLME）。网络层数据实体（NLDE）通过网络层相关的数据库服务接入点(NLDE-SAP）提供数据传输服务,网络层管理实体（NLME)通过网络层相关的管理库服务接入点（NLME-SAP）提供网络管理服务，网络层管理实体利用网络层数据实体来获得一些网络管理任务，并完成一些网络的管理工作。并且，网络层管理实体还维护一个管理对象的数据库，叫做网络信息库（NIB）,网络层管理实体完成对网络信息库(NIB)的维护和管理。void main(） ｛ int tempera; int humidity； char s[16]; UINT8 adc0_value［2]； float num = 0; SET_MAIN_CLOCK_SOURCE(CRYSTAL）； // 设置系统时钟源为 32MHz 晶体振荡器 GUI_Init(）； // GUI 初始化 GUI_SetColor(1，0)； // 显示色为亮点，背景色为暗点 GUI_PutString5_7(25,6，"OURS-CC2530”); //显示 OURS—CC2530 GUI_PutString5_7(10，22,"Temp："）； GUI_PutString5_7(10,35,"Humi：”）; GUI_PutString5_7（10，48，"Light:")； LCM_Refresh(）； while（1） ｛ th_read（&tempera，&humidity）； //读取温度和湿度 sprintf(s， （char＊）”％d%d C", （(INT16）(（int）tempera / 10）), (（INT16)（（int）tempera ％ 10))); //将温度结果转换为字符串 GUI_PutString5_7(48,22，(char *）s）； //显示结果 LCM_Refresh(）; sprintf（s，（char*)"％d％d %％",（（INT16）((int）humidity / 10））, ((INT16）（(int)humidity % 10))）； //将湿度结果转换为字符串 GUI_PutString5_7(48,35，（char *）s）; //显示结果 LCM_Refresh(）;3.2.4AODV路由协议AODV自组织按需请求型距离向量路由协议（Ad Hoc On Demand Distance Vector,简称AODV）,AODV采用的是逐跳转发分组方式，在每个节点之间保存了路由请求和路由回答的结果,因此路由的头部不需要携带完整的路由信息，从而提高了协议的效率。算法旨在多个移动节点中建立和维护一个自启动的,动态的，多跳路由的专属网络。它是一种按需的改进的距离向量路由协议,具有按需路由协议的特点即在AODV路由协议中，网络中的每个节点在需要进行通信时才发送路由分组,而不会周期性地交互路由信息以得到所有其它主机的路由;同时具有距离向量路由协议的一些特点，即各节点路由表只维护本节点到其他节点的路由，而无需掌握全网拓扑结构。网络中连接的断开和异动都会影响网络的拓扑结构，AODV 使得移动节点能适时对这种变化做出响应。AODV 的操作是无自环的，并且由于解决了 Bellman—Ford“无穷计数”的问题，使得该算法在网络拓扑变化时能够快速收敛。当一个连接断开时，AODV 会告知所有受到影响的节点，这些节点会让用到这个连接的路由失效。AODV 的一个显著特点是它在每个路由表项上使用了目的序列号。目的序列号由目的节点创建,并且被包含在路由信息中,然后这些路由信息将被回发到所有向它发起请求的节点.目的序列号的使用确保了无回环，并且易于编程。如果到一个目的有两条路由可供选择，那么收到请求的节点将会选择序列号最大的那一条。此外，AODV另一个显著的特点是它加入了组播路由协议扩展，并支持QOS。它的缺点是：不支持单向信道,原因是AODV协议基于双向信道的假设工作，路由回答分组直接沿着路由请求的反方向回到源节点.1、Void AODV：:recv(Packet *p， Handler*） //判断是否是aodv包，是则调用函数recvAODV（p） if(ch-〉ptype（） == PT_AODV） { recvAODV(p)； //本节点产生的数据包,添加IP头 if（（ih—〉saddr(） == index) ＆& （ch—〉num_forwards（） == 0)) Add the IP Header //收到本节点发送的包，说明有路由环路,丢包 else if（ih->saddr（） == index） drop(p， DROP_RTR_ROUTE_LOOP); //本节点是中间节点 else ｛//TTL是分组最多能转发的次数 if（--ih->ttl_ == 0) drop（p， DROP_RTR_TTL)； //收到的不是广播分组,解析分组 if ( (u_int32_t)ih->daddr（) != IP_BROADCAST） rt_resolve(p); //转发 else forward(（aodv_rt_entry*） 0， p， NO_DELAY）； 2、void AODV：:rt_resolve(Packet *p) ｛ //查找是否有到目的节点的路由 rt = rtable。rt_lookup(ih—〉daddr()); //没有,则添加到该目的节点的路由，此时添加的路由是无效的 if（rt == 0） rt = rtable.rt_add(ih—>daddr()); //有效路由，则根据路由表中信息转发分组 if(rt->rt_flags == RTF_UP) forward（rt， p, NO_DELAY）; //如果本节点是该分组的源节点，说明没有到目的节点的路,此时发送RREQ找路 else if(ih—〉saddr（） == index) rqueue.enque(p); sendRequest（rt-〉rt_dst）; //链路中断，在维护中 else if (rt—〉rt_flags == RTF_IN_REPAIR） rqueue。enque（p)； // 本节点转发数据分组，但是不知道该到目的节点的路,发送RERR说明链路中断 3、else sendError（rerr, false); //添加到目的节点的路由，此时的路由不可用,是无效的 aodv_rt_entry ＊rt = rtable.rt_lookup(dst）; //不到发送RREQ的时间，注意文件开头的RREQ定时器,若没收到RREP，源节点需要定时发送RREQ if （rt->rt_req_timeout 〉 CURRENT_TIME) Packet:：free（(Packet ＊）p）; //AODV中多次发送RREQ，多次发送RREQ后仍找不到路，则丢包 if (rt-〉rt_req_cnt 〉 RREQ_RETRIES） rt—〉rt_req_timeout = CURRENT_TIME + MAX_RREQ_TIMEOUT； drop（buf_pkt， DROP_RTR_NO_ROUTE)； //余下部分是填充路由表以及RREQ分组的内容，不涉及实现的话不用了解，了解有一定难度,需要结合整个过程看 4、链路中断，需要发送RERR，通知所有受影响的节点，函数体关于填充RERR内容，不用细看void AODV：:sendError(Packet ＊p, bool jitter) ｛// 5、周期发送Hello分组，以检测邻节点的连通性void AODV:：sendHello() {// 6、根据包类型调用不同函数void AODV:：recvAODV(Packet ＊p） ｛// case AODVTYPE_RREQ recvRequest(p)； case AODVTYPE_RREP： recvReply（p); case AODVTYPE_RERR: recvError(p)； case AODVTYPE_HELLO: recvHello(p)； 7、收到RREQvoid AODV：：recvRequest(Packet ＊p) ｛// // I’m the source — I recently heard this request。则丢弃该RREQ if(rq-〉rq_src == index） Packet:：free（p)； if （id_lookup(rq->rq_src， rq-〉rq_bcast_id）) Packet:：free（p)； // ＊ Cache the broadcast ID ,用于判断是否已收到过该RREQ id_insert（rq—〉rq_src， rq-〉rq_bcast_id)； //查找是否有到源节点的路由，有则更新，无则添加a //＊ Find out whether any buffered packet can benefit from the * reverse route。缓存中是否有到源节点的数据分组，有，则建立好路由后开始发送数据 //查找是否有到目的节点的有效路由，有则向源节点回复RREP，没有则继续转发该RREQ,注意转发前需要更新RREQ中部分内容 8、void AODV：:sendReply（nsaddr_t ipdst， u_int32_t hop_count， nsaddr_t rpdst， u_int32_t rpseq， u_int32_t lifetime, double timestamp) { //填充RREP内容 9、void AODV:：recvReply（Packet *p) ｛ //查找是否有到目的节点的路由，没有则建立，否则更新 //如果是RREP的目的节点，即RREQ的源节点则建立到目的节点的路；否则根据路由表中到源节点的路由（此路由在发送RREQ过程中已建立）转发该RREP 10、收到RERR，查看有哪些路径受到中断链路的影响，更新RERR内容，并向受影响的节点发送该RERRvoid AODV：：recvError(Packet ＊p) ｛

小熊派开发板模组使用方法和注意事项

【功能模块】【操作步骤&问题现象】1、请问案例中的传感器通信协议在哪里2、我想以案例中的传感器通信协议为模板改写一个有机挥发物传感器的通信协议【截图信息】【日志信息】（可选，上传日志内容或者附件）

一、计算机网络结构大规模现代计算机网络：网络边缘、接入网络与网络核心1.网络边缘：连接到网络上的所有端系统（例如：连接到网络上的计算机、服务器、智能手机等）构成了网络边缘。2.接入网络：实现网络边缘与网络核心连接与接入的网络对于大规模、复杂的网络端系统相距遥远，这些端系统之间的网络连接和通信需要网络核心进行数据中继和转发。通常，网络核心是由运营商等企业运营的ISP网络，不能直接延伸到用户区域，例如：家中，用户就需要借助接入网络实现与ISP的连接。常见的网络接入技术：电话拨号接入（使用调制调节器）、非对称数字用户线路ADSL（常见，使用频分多路复用技术）、混合光纤同轴电缆HFC接入网络（电缆调制解调器，使用频分多路复用技术，独享式接入）、局域网（以太网、WIFi）、移动接入网络（个人设备接入网络。如：2G/3G/4G）3.网络核心：是由通信链路互连的分组交换设备构成的网络，作用是实现网络边缘中主机之间的数据中继与转发典型的分组交换设备：交换机、路由器二、数据交换技术1.计算机网络的目的：在网络边缘的主机之间实现相互的数据传输与信息交换2.数据交换网络：中间网络不需要关心传输数据内容，只是为这些数据从一个节点到另一节点，直至到达目的地，提供数据中继与交换的功能。交换节点：组成交换网络的节点通信子网：交换节点和传输介质的集合，即网络核心。3.数据交换是实现在大规模网络核心上进行数据传输的技术基础。常见的数据交换技术：①电路交换：电话网络是最早最大的电路交换网络。（例如：电话拨号呼叫过程）电路交换包括三个阶段：建立电路、传输数据、拆除电路。、缺点：信道容量与有效时间的浪费②报文交换：发送方把要发送的信息附加上发送/接收主机的地址以及其他控制信息，构成一个完整的报文，然后以报文为单位在交换网络的各个节点之间以存储-转发的方式传送，直至目的主机。缺点：不能满足实时通信速度要求、节点存储空间不够、输出链路被占用不能及时转发报文，使报文被丢弃。③分组交换：目前应用广泛的技术，分组交换将报文分割成较小的数据块，数据块加上地址、序号等控制信息构成数据分组，每个分组独立传输到目的地，目的地将分组重新组装，还原为报文。优点：交换设备存储容量要求低、交换速度快、可靠传输效率高、更加公平