嵌入式系统成为物联网主要技术
随着**疗电子、智能家居、物流管理和电力控制等方面的不断风靡，嵌入式系统利用自身积累的底蕴经验，重视和把握这个机会，想办法在已经成熟的平台和产品基础上与应用传感单元的结合，扩展物联和感知的支持能力，发掘某种领域物联网应用。随着**疗电子、智能家居、物流管理和电力控制等方面的不断风靡，嵌入式系统利用自身积累的底蕴经验，重视和把握这个机会，想办法在已经成熟的平台和产品基础上与应用传感单元的结合，扩展物联和感知的支持能力，发掘某种领域物联网应用。作为物联网重要技术组成的嵌入式系统，嵌入式系统的视角有助于深刻地、全面地理解物联网的本质。这有两层意思：第一，物联网的核心仍然是互联网，是在互联网基础上的延伸和扩展的网络;第二，其用户端延伸和扩展到了任何物品与物品之间，进行信息交换和通信，必须具备嵌入式系统构建的智能终端。因此，物联网系统是通过射频识别(rfid)、红外感应器、全球定位系统、激光扫描器等信息传感设备，按约定的协议，把任何物品与互联网相连接，进行信息交换和通信的系统架构。物联网不仅仅提供了传感器的连接，其本身也具有智能处理的能力，能够对物体实施智能控制，这就是我们今天所说的嵌入式系统所能做到的。诚然，物联网将传感器和智能处理相结合，利用云计算、**识别等各种智能技术，扩充其应用领域。从传感器获得的海量信息中分析、加工和处理出有意义的数据，以适应不同用户的不同需求，发现新的应用领域和应用**。综上所述，物联网嵌入式系统有其鲜明的特征：
1、要有数据传输通路;2、要有一定的存储功能;3、要有cpu;4、要有操作系统;5、要有专门的应用程序;6、遵循物联网的通信协议;7、在世界网络中有可被识别的唯一编号。以上特征很鲜明地指出嵌入式系统已经成为物联网行业的关键技术。经过长期的演变，嵌入式系统技术成为综合了计算机软硬件、传感器技术、集成电路技术、电子应用技术为一体的复杂技术。它正在无形地改变着人们的生活，小到人们身边的mp3，大到航天航空的卫星系统。如果把物联网用人体做一个简单比喻，传感器相当于人的眼睛、鼻子、皮肤等感官，嵌入式系统则是人的大脑，在接收到信息后要进行分类处理。嵌入式系统的十大设计趋势
这项年度调查采取一个较广泛的观点来看嵌入式系统设计的市场与技术趋势。从今年1月18日～2月21日之间，总共有2,258位工程师参与并响应了这项在线调查。大部份的受访者(55%)来自北美，22%的人来自欧洲，亚洲则占14%。他们分别来自不同的领域，包括工业(33%)、消费性电子(24%)、通讯(22%)、汽车(18%)和**疗(18%)等等。以下图集将说明在嵌入式系统设计中的十大开发趋势：
wi-fi占主流，蓝牙迅速崛起
在嵌入式系统中，搭载wi-fi技术的比重较排名第二的无线传输技术更高出两倍。但蓝牙正迅速地迎头赶上，特别是蓝牙4.0/le/smart版。出人意料的是，蜂窝式技术似乎正开始走下坡。同时，专用接口的比重也持续下滑，而 6wlopan 则尚未取得吸引力。开放原始码超越商用os
从该调查的历史来看，今年开放原始码的os首次超过了商用os。相较于商用os在整体系统中约占33%，目前使用开放原始码 os的系统约占36%。android与freertos为主导
工程师们在选择所使用的各种开放操作系统时表示，android和freertos是他们的最佳选择。在嵌入式系统中，android和freertos的应用即将超过主导多年但近来持续下滑的内部(in-house)/客制(custom)的操作系统。完整原始码可用
在选择操作系统时的最重要因素是完整的原始码可用。根据这项调查显示，工程师最在意是否可提供完整原始码(41%)，当然，如果能提供一些技术支持以及免权费就更棒了。多处理技术成为主流
这是第一次，我们看到有一半的受访者表示在其现有设计中使用一个以上的微处理器。事实上，平均每项现有设计所使用的微处理器数目为2.4。32位出线，8位出局
根据调查显示，8位mcu应用正缓步而稳定的下滑，取而代之的是32位持续稳定成长。从工程师回复在现有设计中所使用的mcu即可看出，这一趋势将在2014年持续发生。fpga开始走下坡
fpga应用正持续稳步下滑中，从6年前约占45%下降至2013年约为31%的占有率，但预计今年可微幅增加到32%。让我们持续关注，看看今年会发生触底反弹?还是继续下跌。虚拟化陷入低潮
从2013年的虚拟化使用情形来看，可以发现它并未受到嵌入式系统设计者的青睐。虚拟化在最近的一些设计中已略微下滑，但我们期待它最终将可重新取得成长动能。iot首度上榜
多年来，工业控制一直是嵌入式系统的主要应用。今年，物联网(iot)首度出现在排行之列。通讯与计算机应用开始下滑费性电子、汽车、**疗与电子仪器等领域仍持续成长。专案时程延迟
根据受访者表示，所属的嵌入式设计团队规模逐渐缩减，而且也经常无法按照时间表完成排定计划。在2014年，有41%的项目准时或提前完成，但有59%的项目延迟或者被取消。本文由**特资讯收集整理(www.big-bit.com)
开发嵌入式系统的7个技巧
尽管许多嵌入式工程师充满了希望和梦想，但高可靠性的代码不是一蹴而就的。它是一个艰苦的过程，需要开发人员维护和管理系统的每个比特和字节。当一个应用程序被确认为“成功”的那一刻，通常会有一种如释重负的感觉，但仅仅因为软件在受控条件下的那一刻运行正常并不意味着明天或一年后还会运行正常。从规范完善的开发周期到严格执行和系统检查，开发高可靠性嵌入式系统的技术有许多种。本文介绍了7个易操作且可以长久使用的技巧，它们对于确保系统更加可靠地运行并捕获异常行为大有帮助。技巧1—用已知值填充rom
软件开发人员往往都是非常乐观的一群人，只要让他们的代码忠实地长时间地运行就可以了，仅此而已。微**跳出应用程序空间并在非预想的代码空间中执行这种情况似乎是相当少有的。然而，这种情况发生的机会并不比缓存溢出或错误指针失去引用少。它确实会发生!发生这种情况后的系统行为将是不确定的，因为默认情况下内存空间都是0xff，或者由于内存区通常没有写过，其中的值可能只有上帝才知道。不过有相当完备的linker或ide技巧可以用来帮助识别这样的**并从中恢复系统。技巧就是使用fill命令对未用rom填充已知的位**。要填充未使用的内存，有很多不同的可能组合可以使用，但如果是想建立更加可靠的系统，最明显的选择是在这些位置放置**r fault handler。如果系统出了某些差错，处理器开始执行程序空间以外的代码，就会触发**r，并在决定校正行动之前提供储存处理器、寄存器和系统状态的机会。技巧2—检查应用程序的crc
对嵌入式工程师来说一个很大的好处是，我们的ide和工具链可以自动产生应用程序或内存空间校验和(checksum)，从而根据这个校验和验证应用程序是否完好。有趣的是，在许多这些案例中，只有在将程序代码加载到设备时，才会用到校验和。然而，如果crc或校验和保持在内存中，那么验证应用程序在启动时(或甚至对长时间运行的系统定期验证)是否仍然完好是确保意外之事不会发生的极好途径。现在一个编程过的应用程序发生改变的概率是很小的，但考虑每年交付的数十亿个微**以及可能恶劣的工作环境，应用程序崩溃的机会并不是零。更有可能的是，系统中的一个缺陷可能导致某一扇区发生闪存写入或闪存擦除，从而破坏应用程序的完整性。技巧3—在启动时执行ram检查
为了建立一个更加可靠和扎实的系统，确保系统硬件正常工作非常重要。毕竟硬件会发生故障。(幸运的是软件永远不会发生故障，软件只会做代码要它做的事，不管是正确的还是错误的)。在启动时验证ram的内部或外部没有问题，是确保硬件可以如预期般运作的一个好方法。有许多不同的方法可用于执行ram检查，但常用的方法是写入一个已知的**，然后等上一小段时间再回读。结果应该是所读就是所写。真相是，在大多数情况下 ram检查是通过的，这也是我们想要的结果。但也有极小的可能性检查不通过，这时就为系统标示出硬件问题提供了极好的机会。技巧4—使用堆栈**
对许多的嵌入式开发者而言，堆栈似乎是一股相当神秘的力量。当奇怪的事情开始发生，工程师终于被难倒了，他们开始思考，也许堆栈中发生了什么事。结果是盲目地调整堆栈的大小和位置等等。但该错误往往是与堆栈无关的，但怎能如此确定?毕竟，有多少工程师真的实际执行过最坏情况下的堆栈大小分析?堆栈大小是在编译时就静态分配好的，但堆栈是以动态的方式使用的。随着代码的执行，应用程序需要的变量、返回的地址和其它信息被不断存储在堆栈中。这种机制导致堆栈在其分配的内存中不断增长。然而，这种增长有时会超出编译时确定的容量极限，导致堆栈破坏相邻内存区域的数据。绝对确保堆栈正常工作的一种方法是实现堆栈**，将它作为系统“保健”代码的一部分(有多少工程师会这样做?堆栈**会在堆栈和“其它”内存区域之间创建一个缓冲区域，并填充已知的位**。然后**会不断的监视图案是否有任何变化。如果该位**发生了改变，那就意味着堆栈增长得太大了，即将要把系统推向黑暗地狱!此时**可以记录**的发生、系统状态以及任何其它有用的数据，供日后用于问题的诊断。大多数实时操作系统(rtos)或实现了内存保护单元(mpu)的微**系统中都提供有堆栈**。可怕的是，这些功能默认都是关闭状态，或者经常被开发人员有意关闭。在网络上快速搜寻一下可以发现，很多人建议关闭实时操作系统中的堆栈**以节省56字节的闪存空间。等等，这可是得不偿失的做法!技巧5-使用mpu
在过去，是很难在一个小而廉价的微**中找到内存保护单元(mpu)的，但这种情况已经开始改变。现在从高端到低端的微**都已经有mpu，而这些 mpu为嵌入式软件开发人员提供了一个可以大幅提高其固件(firmware)鲁棒性(robustness)的机会。mpu 已逐渐与操作系统耦合，以便建立内存空间，其中的处理都分开，或任务可执行其代码，而不用担心被stomped on。倘若真有事情发生，不受控制的处理会被取消，也会执行其他的保护措施。请留意带有这种组件的微**，如果有，请多加利用它的这种特性。技巧6-建立一个强大的看门狗系统
你经常会发现的一种总是最受喜爱的看门狗(watchdog)实现是，在看门狗被启用之处(这是一个很好的开始)，但也是可以用周期性定时器将该看门狗清零之处;定时器的启用是完全与程序中出现的任何情况隔离的。使用看门狗的目的是协助确保如果出现错误，看门狗不会被清零，即当工作暂停，系统会被迫去执行硬件重设定(hardware reset)，以便恢复。使用与系统活动独立的定时器可以让看门狗保持清零，即使系统已失效。对应用任务如何整合到看门狗系统中，嵌入式开发人员需要仔细考虑和设计。例如，有种技术可能可以让每个在一定时期内运行的任务标示它们可以成功地完成其任 务。在此**中，看门狗不被清零，强制被复位。还有一些比较先进的技术，像是使用外部看门狗处理器，它可用来监视主处理器如何表现，反之亦然。对一个可靠的系统而言，建立一个强大的看门狗系统是很重要的。由于有太多的技术，难以在这几个段落中完全涵盖，但针对此一议题，笔者未来还会发表相关的文章。技巧7-避免易失存储器分配
不习惯在资源有限环境下工作的工程师，可能会试图使用其编程语言的特性，这种语言让他们可以使用易失存储器分配。毕竟，这是一种常在计算器系统中使用的技术，在计算器系统中，只有在有必要时，内存才会被分配。例如，以c开发时，工程师可能倾向于使用malloc来分配在堆(heap)上的空间。有一个操 作会执行，一旦完成，可以使用free将被分配的内存返回，以便堆的使用。在资源受限的系统，这可 能是一场灾难!使用易失存储器分配的其中一个问题是，错误或不当的技术可能会导致内存泄漏或内存碎片。如果出现这些问题时，大多数的嵌入式系统并没有 资源或知识来监视堆或妥善地处理它。而当它们发生时，如果应用程序提出对空间的要求，但却没有所请求的空间可以使用，会发生什么事呢?使用易失存储器分配所产生的问题是很复杂的，要妥善处理这些问题，可以说是一个噩梦!一种替代的方法是，直接以静态的方式，简化内存的分配。例如，只要在 程序中简单地建立一个大小为256字节长的缓冲区，而不是经由malloc请求这样大小的内存缓冲区。此一分配的内存可在整个应用程序的生命周期期 间保持，且不会有堆或内存碎片问题方面的顾虑。结论
这些都只是一些可以让开发人员开始建立更可靠嵌入式系统的方法。另外还有很多其他技术，例如利用良好的编码标准、位翻转的监测、执行数组和指针边界检查，及使用断言等。所有这些技术都是让设计者...