djyos

ZigBee协议栈架构图物理层(PHY)        ZigBee是一种短距离无线通信与网络技术，其数据交换最终是通过无线信道完成。物理层的任务就是通过无线信道进行安全、有效的数据通信，为MAC层提供服务。物理层定义物理无线信道和MAC层之间的接口，提供物理层数据服务和物理层管理服务。通过该接口维护物理层相关的管理对象的数据库(PIB)。完成的任务有：无线收发机的激活与关闭、信道能量

我们需要开发新操作系统么？答案是肯定的，没有听说过有了格力空调，美的空调就不需要了。 我们需要从新开发操作系统内核么？不一定！ 对于操作系统来说，有一个好内核永远都是最重要的，但是，最重要的事情，并不一定是工作重点，为什么呢？操作系统理论早在50年前就成熟了，嵌入式操作系统内核，也在几十年前就成熟了，选一个合适的内核，还是自己开发内核，需要仔细斟酌。据内部人士消息，华为的liteOS，就是选用成熟的t-kernel内核。

不知有多少搞嵌入式软件程序猿都是从main函数开始自己的第一行代码。遥想当年，第一次编写嵌入式软件代码还是在IAR的开发环境下写的，当时按照傻瓜式说明从安装开发IAR，配置开发环境到建立工程。还记得IAR自动生成了一个main.c文件，并且该文件中自动生成了voidmain();函数，只需在main函数中编写自己的代码，编译，烧录，调试，系统会自动从main函数的第一行开始运行，看到流水灯跑起来时

中断是嵌入式系统中一个魅力十足亮点， 关于DJYOS对中断的内部巧妙的处理机制，各位看官可阅读《都江堰操作系统与嵌入式系统设计》中第六章节“中断”相关内容以及DJYOS源码中int.c/int.h中相关内容。本文探讨两点：DJYOS中中断处理流程以及如何将自己板子上的中断快速地挂接到DJYOS的中断系统。      DJYOS中断控制块的结构示意图如图1所示：图1 DJYOS中

前期移植了ZigBee协议栈freakz到DJYOS上，打算出一个系列小文与诸位看官分享移植过程，敬请各位看官指正，欢迎拍砖。ZigBee网络特点Zigbee是基于IEEE802.15.4标准的低功耗个域网协议。其特点是：1.低功耗，两支干电池可支持节点工作半年以上。这是Zigbee的突出优势（在传感控制领域）。相比较,蓝牙能工作数周、WiFi可工作数小时。2.低速度，最高

物联网喊了多少年了，总是雷声大雨点小，厂商多应用少；在电商里也可以看到，智能硬件呈现三多三低的尴尬境地：品种多，厂商多，卖家多，销量低，价格低，评价低；产业见都没有见过蓝海，就已经在红海搁浅了。究其原因，无法实现智慧互联，联而不慧是主因。物联网的中心思想在于连接之后的智慧，而现有产品，多呈现出孤岛状态，顶多同一个厂商的产品之间，勉强实现互操作。我在这篇博文“http://blog.csdn.n

时下，在操作系统界，有一个热得发紫的名词“物联网操作系统”，但物联网和操作系统究竟是什么关系，物联网将面临什么问题，操作系统又能为其解决什么问题呢？    操作系统和其他电子产品一样，是个不断迭代、与时俱进的一个东西，由用户需求、软件积累、硬件成本等共同推动发展，反过来又激发需求、定义硬件。在物联网时代，大家都在谈论物联网操作系统，我们要分析物联网的核心问题是什么，操作系统对于物联网，能做什么

任何不考虑工业智能硬件的物联网方案，都是撒流氓！    在人工成本越来越高，生产设备越来越”聪明“，无人工厂日益增加，通过互联和协作，让”聪明“的设备更智慧，这就是工业物联网，这就是工业4.0的基础设施。工业自动化、物联网以及其服务平台相结合，使工厂完全变为信息融合、智慧生产的“智能空间”，生产、仓储、营销、分销及服务，被融入一个庞大复杂的信息链中。工业物联网无论在生产自动化、生产过程管理、企

前几篇，讲了许多远程桌面的功能和应用，但还是有不少网友不明白，在QQ上跟我讨论，在物联网和智能硬件方面，究竟能解决什么问题。    智能硬件发展这么多年，总是雷声大雨点小，投资大收成少，汗水多泪水也多，传统商店难觅智能硬件踪影，即使在电商上，则是一多两低，品种多，销量低，价格低。完全不像其他新产品，最早进入的人，赚得彭满钵满，后进入的人，喝汤啃骨头；智能硬件则是探险者哀鸿遍野。    为什

系列文章已经写到第七篇了，终于终于，当前业界最热们、最被投资界追捧的————智能硬件出现了。智能水杯、智能手表、智能手环、只等鞋子、智能球拍。。。。。。。不胜枚举，产品形态五花八门，应用程序也五花八门，操作系统基础都差不多，智能硬件提出了新的需求，开发平台就要做相应的调整，本篇继续分析只能硬件相关的开发平台需求。    上一篇提到，物联网时代的RTOS须提供脚本编程，有些网友不明白，MCU上能

前几篇博文发出后，有人问了个问题：“如果用手机做显示器，为什么不是在手机上实现UI，而是用远程桌面。”诚然，手机上做UI的工具更加成熟，调试也会更方便。可是，你要是在手机上做UI，那么，你就得写app吧，不同厂家的app，是不一样的吧，你必须为每个厂家的智能设备安装一个app，智能硬件普及后，手机上尽是智能设备的app，烦不烦？即使是同一个厂家的设备，手机上做UI，也有问题。这个厂

物联网操作系统是个伪命题，很多人炒物联网概念，炒物联网操作系统，其实，物联网操作系统，与其说是一个技术概念，还不如说是一个商业概念。这也无可厚非，你不炒，老百姓怎么知道物联网，投资人怎么知道物联网，运营商怎么知道物联网呢？但这就把嵌入式开发者弄许云里雾里，不知道物联网操作系统是何方神圣，有什么特点，怎么样才算物联网操作系统。待我把它的皮剥掉，露出忽悠过的本质。    物联网的核心，在于“连接”

上回说到，远程桌面是唯一的解决之道，有网友提出，可以用HTML。虽然技术上解决方案千千万万，条条大路通罗马，但实际上，HTML方案不是最优的。为什么呢？使用HTML，是不是还要搭上文件系统、搭上webserver。又有人说了，没文件系统，也可以用webserver啊，是的，可以，你可以通过修改webserver来实现。呵呵，你愿意这样干就干吧，至少我不愿意，为什么不愿意？我是不是要因此而维护两个w

降低模块间耦合，提高应用程序可靠性    另一个会严重降低应用程序可靠性的地方，就是模块间互相耦合，搅在一起。搅在一起的代码，就像一盘意大利面条，又杂又乱，如果代码写成这样的话，可靠性要高，上帝都会笑。    那么，避免意大利面条式的编码，全是应用程序的责任吗？OS作为基础软件，就一点责任都没有吗？这显然是不对的，只是大多数OS开发者没有意识到这点罢了，他们只讲究OS自身的高汇聚低

2.        简洁的调度器，提高操作系统可靠性我们知道，越简洁的东西，越可靠，这是永恒不变的真理。作为操作系统的核心——调度器，更加如此。但简洁，必须以良好的系统架构设计为依据，不能以牺牲功能和性能为代价，更不能因此而降低用户使用的方便性。如果降低了使用方便性，不但会降低用户的使用体验，更重要的是，可能导致应用程序更多的缺陷，进而大大降低用户产品的可靠性，这与“简洁以提高可靠性”的目标，

许多的操作系统，在宣传自己的优异性时，不外乎上下文切换时间多么短、占用系统资源多么少、功能模块多么多、线程间通信手段多么丰富。谈到可移植性时，不外乎说自己的C语言率多么高，移植需要修改的代码行多么少，等等！这些方面，都非常重要，但并不全面，主要是从操作系统本身出发看问题。嵌入式操作系统的核心要素是可靠性、实时性和可移植性。要从嵌入式产品的整体效果出发，例如可靠性，不能光考虑操作系统的可靠性，更多地

嵌入式设备网络化、u盘化、功能复杂化的趋势，使越来越多的、过去可以用裸奔实现的嵌入式产品，产生了应用操作系统的需求。    而人力成本的持续上升、芯片成本的连续下降，以及cpu性能的迅速提高，又为大面积应用操作系统提供了物质基础。    本文和大家一起讨论一下，从裸奔到操作系统，我们将面对什么挑战。1、速度    我们首先面对的，将是cpu运行速度的问题，毋庸置疑，操作系统调度需要

这里谈的安全性，跟通用计算机所说的网络安全性不是一个概念，网络安全性指的是数据不被人为破坏和窃取，计算机不被恶意控制。而这里谈的安全性，指的是设备安全，例如自动化生产线不夹断工人手指。    可靠性，是指设备的可信赖程度，即正确地完成设定功能的能力。    安全性，指的是在设备发生故障，或者人为误操作的情况下，确保安全的能力。这可能不好理解，举个例子就明白了，比如汽车要通过碰撞试验，确保在

上回说到，物联网节点的硬件是无法标准化的，那么，软件可能标准化么？    像高速公路一样，高速公路的价值不在于路本身，而是其承载的客货运输；物联网的核心价值也不在于物联网本身，而在于承载在上面的服务。而物联网软件作为设备接入、软件分发、业务承载的平台，客观上有标准化的需求。想当年，功能机时代，群雄并起诸侯争霸，事实上，功能机的软件一点也不简单，然而到了智能机时代，却只剩下iOS和Android

联网设备不断增加是目前全球的发展趋势，在我们生活工作的方方面面，无处不在的联网设备正在给我们带来翻天覆地的变化，我们正处于一个万物联网的世界中。    在物联时代，有两大主题，一是物联网运营，是构筑在标准物联网硬件和软件上的服务。比如智慧医疗，提供医疗服务的服务商，从各种各样连接在一起的医疗终端上采集数据进行分析，给用户提供合理的健康生活建议，对于潜在的病患者，会及时联系合适的医疗资源提前干预

在“全员编程，广泛嵌入，全面智联”的时代，恨不得把地球上的每一粒沙子连起来的时代，我们要怎样去设计这个时代的操作系统呢，现有的RTOS能否满足需求呢？      在上世纪8、9十年代的时候，当时的嵌入式CPU速度很慢，内存等资源也很少，很少有MMU和CACHE的。嵌入式系统编程，汇编是主流，C次之，RTOS只有在高端产品中才会用到，可供选择的RTOS也很少，发展RTOS，要解决的是有无的问题，

如果说，智能消费品即将进入全民编程时代的话，那么传统嵌入式系统即将进入全员编程时代。全民编程要解决的是接近自然语言的编程语言的话，那么全员编程需要解决什么呢？