驱动 - 21ic中国电子网

当前位置：首页 > 驱动

linux在DVR系统中的应用和发展

视频监控系统一直是监控领域中的热点，它以直观、方便、信息内容丰富而在各个行业得到广泛应用，如：交通、电力、通信、石油、码头、仓库、金融、政府机关企事业单位办事窗口，和军队、公安、监狱、水利/水厂、民航等要害部门。 Linux所具备的特性从微软掌管操作系统至今，多数人认为操作系统即是Windows95/98/2000/XP，甚至有很多人并不了解什么是操作系统，更遑论是使用Linux了。近来由于多家国际计算机业龙头纷纷表态支持Linux,使得Linux顿时成为计算机界的热点，许多人相继投入Linux。最近在许多的信息媒体上可以看到 “Linux”的报导，Linux也不再是资深计算机人才知道的操作系统，有越来越多的人对Linux好奇，越来越多使用者愿意尝试这个操作系统。到现在包括IBM等许多大型厂商都公开宣布旗下产品支持Linux，连最近相当热门的IA(信息家电)也都陆续宣布将采用Linux作为系统核心,监控产业也已有厂商开始投入研发资金以Linux为作业平台的监控产品，Linux俨然形成的当前唯一能对抗微软的操作系统。前面已很多次提到了Linux这个名词,那Linux到底是什么?简单地说，Linux是一套免费使用和自由传播的类Unix操作系统，这个系统是由世界各地的成千上万的程序员设计和实现的。其目的是建立不受任何商品化软件的版权制约的、全世界都能自由使用的Unix兼容产品。 1.Linux提供多人使用(Multi-user)、多工(Multitask)的完整作业环境，只要很少的硬件支援，便能在多种不同电脑设备(或是单晶片)上运作。 2.Linux具备高解析度与优秀的图形界面(GUI)，大幅提升数字监控系统应用的亲和力。 3.Linux完全免费，可任意在网路上下载、复制、使用，同时它的程式码也完全公开，可以任意开发、更改。这样的特点使得全世界已超过千万人使用Linux，更由于许多厂商投入开发核心程式、发展相关软体以及硬体周边驱动程式，使Linux功能和完整性日益壮大。 4.Linux本身开放性的架构与弹性(Scalable)设计，可针对数位影像监控应用量身订作，去除与监控无关的多余功能，在提升系统效能的同时，也减少了出问题的机率。 5.Linux从头到尾即针对网络应用而设计，可支持TCP/IP、WWW等多项国际标准，能迎合新一代DVR产品网际网络/通信网络连结的所有需求。由于数字录像监控系统是比较专业的领域，其中又牵涉到大量I/O作业的录像撷取/储存以及CPU运算的录像压缩/解压缩，因此，为能满足每天24小时、每周7天的线上服务需求，以及有效减少整体作业营运的成本，除了对功能方面的考虑外，操作系统平台的选择亦十分重要。 Linux在DVR系统中的应用 DVR已成为全球热门产品，在未来网络时代，其重要性更是不容小觑，使用者的需求增加，使得全球知名监控业大厂愈来愈积极在DVR产品的研发与改良上。监控行业的商家更是结合了图象处理技术、数字管理技术、通讯传输技术、自动化集成界面技术及操控软件技术于一体发展出数字硬盘录像远程监控产品，加上简单易用的人性化图形使用界面(GUI)使一般人可轻易地使用监控系统。 Linux操作系统搭配实时视频采集卡与摄影机，进行视讯即时压缩、录像、储存等工作，除了可以开发操作简单、功能简易、价格大众化的数字录像监控系统外，亦可有效整合互联网络、电话网路、安全防盗设备，作为自主性保全的安全监控设备。有别于其他视讯的应用，DVR由于必须储存大量的安全监视录像资料，因此具备高容纳资料的储存空间以及资料备份功能，是其选择操作系统的重要条件。 Linux除了支持大容量的硬盘供资料储存外，并可透过加装硬盘及具有资料镜映像功能的磁盘阵列来增加储存容量;此外，其备份周边支持丰富，可将资料有效备份在CD-RW以及结合网络技术的NAS网络存储设备。 Linux操作系统具备分散式、无人操作、大量集中管理、设定、监控、告警处理等所需的稳定性与完整的网络功能;多台Linuxbase的数字硬盘录像监控系统可有效透过网络予以结合，配合中央监控系统与远端数字硬盘录像监控主机解决方案，不仅能满足此一需求，并具备未来扩充的弹性。在未来的网际网络时代，使用者须要的是具有强大网络功能的远端监控系统，整合数字录像监控、门禁防盗、消防受信等安全设备，藉由模组化的智能型中央监控系统的图形控制界面，让使用者可透过网际网络浏览器或是其他终端设备，随时随地有效地进行远端多点即时影像监看与相关设备的控制;透过Linux操作系统提供所需的稳定性与效能，此系统将可有效协助企业、工厂、社区建立内部控管中枢，控管分散在各地的分支机构。

时间：2018-04-10 关键词：设备 Linux 驱动 dvr
Linux进程退出之方法论

当一个进程结束了运行或在半途中终止了运行，那么内核就需要释放该进程所占用的系统资源。这包括进程运行时打开的文件，申请的内存等。进程退出 Linux 下进程的退出分为正常退出和异常退出两种: 1.正常退出 a. 在main()函数中执行return 。 b.调用exit()函数 c.调用_exit()函数 2.异常退出 a.调用about函数 b.进程收到某个信号，而该信号使程序终止。不管是哪种退出方式，系统最终都会执行内核中的同一代码。这段代码用来关闭进程所用已打开的文件描述符，释放它所占用的内存和其他资源。几种退出方式的比较 1.exit和return 的区别： exit是一个函数，有参数。exit执行完后把控制权交给系统 return是函数执行完后的返回。renturn执行完后把控制权交给调用函数。 2.exit和abort的区别： exit是正常终止进程 about是异常终止。 exit()和_exit()函数 exit和_exit函数都是用来终止进程的。当程序执行到exit或_exit时，系统无条件的停止剩下所有操作，清除各种数据结构，并终止本进程的运行。 exit在头文件stdlib.h中声明，而_exit()声明在头文件unistd.h中声明。 exit中的参数exit_code为0代表进程正常终止，若为其他值表示程序执行过程中有错误发生。 exit()和_exit()的区别 _exit()执行后立即返回给内核，而exit()要先执行一些清除操作，然后将控制权交给内核。调用_exit函数时，其会关闭进程所有的文件描述符，清理内存以及其他一些内核清理函数，但不会刷新流(stdin, stdout, stderr ...). exit函数是在_exit函数之上的一个封装，其会调用_exit，并在调用之前先刷新流。 exit()函数与_exit()函数最大区别就在于exit()函数在调用exit系统之前要检查文件的打开情况，把文件缓冲区的内容写回文件。由于Linux的标准函数库中，有一种被称作“缓冲I/O”的操作，其特征就是对应每一个打开的文件，在内存中都有一片缓冲区。每次读文件时，会连续的读出若干条记录，这样在下次读文件时就可以直接从内存的缓冲区读取;同样，每次写文件的时候也仅仅是写入内存的缓冲区，等满足了一定的条件(如达到了一定数量或遇到特定字符等)，再将缓冲区中的内容一次性写入文件。这种技术大大增加了文件读写的速度，但也给编程代来了一点儿麻烦。比如有一些数据，认为已经写入了文件，实际上因为没有满足特定的条件，它们还只是保存在缓冲区内，这时用_exit()函数直接将进程关闭，缓冲区的数据就会丢失。因此，要想保证数据的完整性，就一定要使用exit()函数。通过一个函数实例来看看它们之间的区别：函数实例1 ： exit.c #include #include int main() { printf("using exit----\n"); printf("This is the content in buffer\n"); exit(0); } 执行结果为： using exit---- This is the content in buffer 函数实例2：_exit.c #include #include int main() { printf("using _exit--\n"); printf("This is the content in buffer"); _exit(0); } 执行结果为： using _exit-- printf函数就是使用缓冲I/O的方式，该函数在遇到“\n”换行符时自动的从缓冲区中将记录读出。所以exit()将缓冲区的数据写完后才退出，而_exit()函数直接退出。大家也可以把函数实例2中的printf("This is the content in buffer");改为printf("This is the content in buffer\n")(即在printf中最后加一个\n看运行结果是什么，为什么会产生这样的结果呢?) 父子进程终止的先后顺序不同会产生不同的结果 1.父进程先于子进程终止：此种情况就是我们前面所用的孤儿进程。当父进程先退出时，系统会让init进程接管子进程。 2.子进程先于父进程终止，而父进程又没有调用wait函数此种情况子进程进入僵死状态，并且会一直保持下去直到系统重启。子进程处于僵死状态时，内核只保存进程的一些必要信息以备父进程所需。此时子进程始终占有着资源，同时也减少了系统可以创建的最大进程数。什么是僵死状态呢? 一个已经终止、但是其父进程尚未对其进行善后处理(获取终止子进程的有关信息，释放它仍占有的资源)的进程被称为僵死进程(zombie)。 3.子进程先于父进程终止，而父进程调用了wait函数此时父进程会等待子进程结束。

时间：2018-04-12 关键词： Linux 内存驱动
嵌入式Linux设备驱动开发之驱动分层/分离思想

嵌入式Linux设备驱动开发之驱动分层/分离思想我们在学习I2C、USB、SD驱动时，有没有发现一个共性，就是在驱动开发时，每个驱动都分层三部分，由上到下分别是： 1、XXX 设备驱动 2、XXX 核心层 3、XXX 主机控制器驱动而需要我们编写的主要是设备驱动部分，主机控制器驱动部分也有少量编写，二者进行交互主要时由核心层提供的接口来实现;这样结构清晰，大大地有利于我们的驱动开发，这其中就是利用了Linux设备驱动开发中两个重要思想，下面来一一解析一、设备驱动的分层思想在面向对象的程序设计中，可以为某一类相似的事物定义一个基类，而具体的事物可以继承这个基类中的函数。如果对于继承的这个事物而言，其某函数的实现与基类一致，那它就可以直接继承基类的函数;相反，它可以重载之。这种面向对象的设计思想极大地提高了代码的可重用能力，是对现实世界事物间关系的一种良好呈现。 Linux内核完全由C语言和汇编语言写成，但是却频繁用到了面向对象的设计思想。在设备驱动方面，往往为同类的设备设计了一个框架，而框架中的核心层则实现了该设备通用的一些功能。同样的，如果具体的设备不想使用核心层的函数，它可以重载之。举个例子： return_type core_funca(xxx_device * bottom_dev, param1_type param1, param1_type param2) { if (bottom_dev->funca) return bottom_dev->funca(param1, param2); /* 核心层通用的funca代码 */ ... } 上述core_funca的实现中，会检查底层设备是否重载了funca()，如果重载了，就调用底层的代码，否则，直接使用通用层的。这样做的好处是，核心层的代码可以处理绝大多数该类设备的funca()对应的功能，只有少数特殊设备需要重新实现funca()。再看一个例子： copyreturn_type core_funca(xxx_device * bottom_dev, param1_type param1, param1_type param2) { /*通用的步骤代码A */ ... bottom_dev->funca_ops1(); /*通用的步骤代码B */ ... bottom_dev->funca_ops2(); /*通用的步骤代码C */ ... bottom_dev->funca_ops3(); } 上述代码假定为了实现funca()，对于同类设备而言，操作流程一致，都要经过“通用代码A、底层ops1、通用代码B、底层ops2、通用代码C、底层ops3”这几步，分层设计明显带来的好处是，对于通用代码A、B、C，具体的底层驱动不需要再实现，而仅仅只关心其底层的操作ops1、ops2、ops3。图1明确反映了设备驱动的核心层与具体设备驱动的关系，实际上，这种分层可能只有2层(图1的a)，也可能是多层的(图1的b)。这样的分层化设计在Linux的input、RTC、MTD、I2 C、SPI、TTY、USB等诸多设备驱动类型中屡见不鲜。二、主机驱动和外设驱动分离思想主机、外设驱动分离的意义在Linux设备驱动框架的设计中，除了有分层设计实现以外，还有分隔的思想。举一个简单的例子，假设我们要通过SPI总线访问某外设，在这个访问过程中，要通过操作CPU XXX上的SPI控制器的寄存器来达到访问SPI外设YYY的目的，最简单的方法是： copyreturn_type xxx_write_spi_yyy(...) { xxx_write_spi_host_ctrl_reg(ctrl); xxx_ write_spi_host_data_reg(buf); while(!(xxx_spi_host_status_reg()&SPI_DATA_TRANSFER_DONE)); ... } 如果按照这种方式来设计驱动，结果是对于任何一个SPI外设来讲，它的驱动代码都是CPU相关的。也就是说，当然用在CPU XXX上的时候，它访问XXX的SPI主机控制寄存器，当用在XXX1的时候，它访问XXX1的SPI主机控制寄存器： return_type xxx1_write_spi_yyy(...) { xxx1_write_spi_host_ctrl_reg(ctrl); xxx1_ write_spi_host_data_reg(buf); while(!(xxx1_spi_host_status_reg()&SPI_DATA_TRANSFER_DONE)); ... } 这显然是不能接受的，因为这意味着外设YYY用在不同的CPU XXX和XXX1上的时候需要不同的驱动。那么，我们可以用如图的思想对主机控制器驱动和外设驱动进行分离。这样的结构是，外设a、b、c的驱动与主机控制器A、B、C的驱动不相关，主机控制器驱动不关心外设，而外设驱动也不关心主机，外设只是访问核心层的通用的API进行数据传输，主机和外设之间可以进行任意的组合。如果我们不进行上图的主机和外设分离，外设a、b、c和主机A、B、C进行组合的时候，需要9个不同的驱动。设想一共有m个主机控制器，n个外设，分离的结果是需要m+n个驱动，不分离则需要m*n个驱动。 Linux SPI、I2C、USB、ASoC(ALSA SoC)等子系统都典型地利用了这种分离的设计思想。

时间：2018-04-23 关键词：设备 Linux 驱动
Linux系统下MTD/CFI驱动介绍

某些Intel的FLASH芯片(如StrataFlash系列)支持多分区，也就是各个分区可以同时进行操作。应该说这是不错的特性，但是也会带来些问题。记得当初移植Linux-2.4.21，挂JFFS2文件系统的时候，经常会报一些"Magic bitmask not found"之类的错误，跟进去发现FLASH读出来的都是些0x80之类的数据，查看资料发现该款FLASH有分区的特性，而Linux的FLASH驱动只用一个状态变量表示整个FLASH的状态，这就会造成某个分区的实际状态和系统记录的不符,从而导致读FLASH的时候该点实际上不处在读状态。当时的解决办法是，每次读的时候，不管记录的状态是什么，先进入读状态再说，当然这会带来性能的下降，具体损失多少个时钟周期就不算了。话说进入Linux-2.6.x的时代(具体是2.6.13),除了Lock/Unlock(Linux在擦/写的时候不先Unlock，解决办法就是初始化的时候先全部Unlock)这个老问题外，竟然多分区的错误没有出现，惊讶之下决定好好研究下Linux的MTD/FLASH驱动。说驱动之前，先明确几个编程要点： 1：读写，要按照总线位宽读写，注意不是FLASH芯片位宽(例如背靠背)。 2：寻址，程序要访问的地址和FLASH芯片地址引脚得到的值是不一样的，例如16位的FLASH芯片，对于CPU，0x00和0x01表示2个不同的字节，但是到了FLASH引脚得到的都是0，也就是都指向FLASH的第一个WORD。可以认为地址总线的bit0悬空，或者认为转换总线, bit0上实际输出的是bit1。这个解释了要点1。 3：芯片手册提到偏移量都是基于WORD的，而WORD的位宽取决于芯片的位宽，因此在下命令的时候，实际偏移=手册偏移*buswidth/8。 4：芯片手册提到的变量长度(典型如CFI信息)例如2，指的是，变量是个16bit数，但是读的时候，要读2个WORD，然后把每个WORD的低8位拼成1个16bit数。读WORD再拼凑确实挺麻烦，尤其是读取大结构的时候，不过参照cfi_util.c的cfi_read_pri函数的做法就简单了。 5：背靠背，也就是比方说2块16位的芯片一起接在32位的总线上。带来的就是寻址的问题，很显然，首先要按32位读写;其次就是下命令的地址，实际偏移=手册偏移*interleave*device_type/8，device_type=buswidth/interleave，而buswidth这个时候是32(总线位宽)。另外就是背靠背的时候，命令和返回的状态码是“双份的”，例如2块16位背靠背，读命令是0x00ff00ff。如果不是想写像Linux那么灵活的代码(考虑各种接法/位宽/CFI获取信息等)，那事情就简单很多，只要考虑要点1以及擦除块的大小就好了，当然如果是背靠背接法，擦除块的实际大小要乘个interleave。进入Linux代码关于CHIP/MAP/MTD之间绕来绕去的关系现在还糊涂着呢，因此下面只是简单的跟一下脉络和各个编程要点。 1：构造map_info结构，指定基址/位宽/大小等信息以及"cfi_probe"限定，然后调用do_map_probe()。 2：do_map_probe()根据名字"cfi_probe"找到芯片驱动"cfi_probe.c"直接调用cfi_probe()。 3：cfi_probe()直接调用mtd_do_chip_probe()，传入cfi_probe_chip()函数指针。 4：mtd_do_chip_probe()分2步，先调用genprobe_ident_chips()探测芯片信息，后调用check_cmd_set()获取和初始化芯片命令集(多分区初始化就在里面)。 5：genprobe_ident_chips()函数如果不考虑多芯片串连的情况，那只需看前面的genprobe_new_chip()调用，完成后cfi.chipshift=cfi.cfiq->DevSize，2^chipshift=FLASH大小。

时间：2018-06-29 关键词： Linux 驱动 linux系统 mtd/cfi
linux下Intel 3945ABG 安装无线网卡驱动

1. 添加 atrpms 源# gedit /etc/yum.repos.d/atrpms.repo添加以下内容：代码:[atrpms]Core $releasever - $basearch - ATrpmsbaseurl=http://dl.atrpms.net/fc$releasever-$basearch/atrpms/stablegpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpmsenabled=0gpgcheck=1安装 key：# rpm --import http://ATrpms.net/RPM-GPG-KEY.atrpms2. 安装驱动# yum --enablerepo=atrpms install ipw3945-kmdl-`uname -r` ieee80211-kmdl-`uname -r`3. 打开无线网卡脚本：代码:#!/bin/bash## ipw3945d Load/Unload Intel ipw3945 daemon## chkconfig: 2345 09 90# description: Load / Unload Intel ipw3945 daemon#### BEGIN INIT INFO# Provides: ipw3945d### END INIT INFO# Source function library.. /etc/init.d/functionsif [ ! -f /etc/sysconfig/network ]; thenexit 0ficase "$1" instart)echo -n "Starting ipw3945d:"/sbin/ipw3945d > /dev/null 2>&1echo;;stop)echo -n "Stopping ipw3945d:"killproc ipw3945decho;;status)status ipw3945d;;restart)cd "$CWD"$0 stop$0 start;;*)echo $"Usage: $0 {start|stop|restart|status}"exit 1esacexit 0把上面的代码保存为 ipw3945d。# mv ipw3945d /etc/init.d# chmod +x /etc/init.d/ipw3945d# chkconfig --level 5 NetworkManager on# chkconfig --level 5 NetworkManagerDispatcher on# chkconfig --level 5 ipw3945d on# service NetworkManager start# service NetworkManagerDispatcher start# service ipw3945d start4. 测试# ifconfig# iwlist scanning完成

时间：2018-07-02 关键词：无线网卡 Intel Linux 驱动 3945abg
多串口扩展卡IPMC712驱动在MV5100上的使用方法

IPMC712串口扩展板在MV5100板上使用方法： 1. 配置跳线将MV5100板上的J6跳线跳到2-3(默认的为1-2)，J20跳到1-2(默认的为1-2) 2. 修改BSP程序修改config\mv5100\config.h文件，修改如下 #undef INCLUDE_IPMC761 /* IPMC761 support */ 改成： #define INCLUDE_IPMC761 /* IPMC761 support */ 3. 硬件连接注意点将IPMC712的PMC板卡插到mv5100主板的PMC插槽内，固定好。将P2适配器插到机箱后板的P2口(下面)，插到中间的A-C列。 4. 如何测试是否成功在没有将DB25接到对端的时候，可以如下通过软件来判断是否成功：将712的第一个串口的2和3针脚用导线短接，这样可通过回环方式来确认发送接收是否成功。 -> devs drv name 0 /null 1 /tyCo/0 1 /tyCo/1 1 /tyCo/2 1 /tyCo/3 1 /tyCo/4 1 /tyCo/5 5 host: 6 /vio value = 0 = 0x0 -> fd2 = open("/tyCo/2", 2, 0644) new symbol "fd2" added to symbol table. fd2 = 0x2226bb0: value = 5 = 0x5 -> sp readFd,fd2 task spawned: id = 1ef10550, name = s1u0 value = 519112016 = 0x1ef10550 -> write(fd2, "kkkkkkkkkkkkk", 11) value = 11 = 0xb 如果正常的话，这样就能在终端上显示kkkkkkkkkk的信息了。 // 其中测试程序readFd()的代码如下： #include "vxworks.h" #include "stdio.h" #include "ioLib.h" int readFd(int fd) { int result; char buffer[50]; for(;;) { bzero(buffer, sizeof(buffer)); result = read(fd, buffer, 10); if(result != ERROR) { printf("%s", buffer); } else { printf("read error.\n"); } } return result; }

时间：2014-12-21 关键词：驱动 VxWorks 扩展卡
WinCE的USB Camera流接口驱动开发

引言 WinCE5.0是一个32位、多任务、多线程的实时嵌入式操作系统。USB Camera 以其良好的性能和低廉的价格得到广泛的应用，同时因其灵活、方便的特性，易于集成到嵌入式系统中。通过采用USB Camera可以在WinCE5.0下方便地得到实时图像。但是由于嵌入式硬件环境的多样性以及WinCE5.0对USB设备驱动开发只提供了一些底层支持，摄像头厂商尚未提供WinCE5.0下USB摄像头的驱动，因此开发出WinCE5.0下USB摄像头驱动具有实际的意义和价值。本文正是针对这一情况，对WinCE5.0下USB设备驱动开发进行研究，并设计出基于流接口驱动模型的USB摄像头驱动程序。现在已经开发出来的驱动适用于Zc030x PLUS这一系列的摄像头。Samstmg 2410为实验的硬件平台。 1 WinCE5.0下USB总线驱动框架 USB系统由USB主机、一个或多个USB设备和物理总线组成。主机上又分两层：较高的包含USB设备驱动程序的软件层和主机控制器硬件层，也称作“适配层”。主机的主要任务是控制对USB设备的双向数据传输。物理总线是一组USB电缆，用来将控制器和外围设备连接起来。WinCE5.0的USB系统软件由两层组成：USB设备驱动程序层和底层的由WinCE5.0实现的USB函数层。 USB设备驱动程序使用USB函数来建立与它们所控制设备的连接，并对这些设备进行配置和通信。较低的USB函数层本身又由两部分组成——较高的通用串行总线驱动程序(USBD)模块和较低的主控制器驱动程序(HCD)模块。HCD提供了抽象的主机控制器，且对主机控制器所见到的USB系统的数据传输进行抽象。USBD提供一个抽象的设备，且对USBD客户和USB设备功能部件之间的数据传输进行抽象。USB设备驱动程序使用USBD接口函数与外围设备进行通信。 IHV和USB设备制造商利用USBD提供的函数来实现USB设备的驱动程序。OEM负责给基于WinCE的平台提供HCD模块，这样相应的硬件才能与USBD模块进行交互。图1说明了与主机的USB硬件和外围设备相对应的软件的各个层。 2 WinCE5.0下流驱动模型基于WinCE5.0平台的两种专用的驱动模型为：本机设备驱动程序和流接口驱动程序。本机设备驱动程序适合于集成到WinCE 5.0 平台的设备;而后者则是一般类型的设备驱动程序，适用于大部分外围设备，如调制解调器、打印机等。对大多数USB外围设备来说，适用于采用流接口驱动程序模型来开发驱动程序。流接口驱动程序是一种可以定制接口的驱动模型，一般由设备管理器负责管理。它把设备管理器和应用程序的命令转换成所控设备的适当动作所需信息。流接口驱动程序需要实现一组固定的流接口函数，供给WinCE5.0系统内核使用。 USB设备的流接口驱动程序和WinCE5.0系统其他部件间的关系如图2所示。流接口驱动程序通过系统提供的文件系统API与应用程序交互;而系统通过设备管理器完成对流接口驱动程序的加载、卸载等管理工作;流接口驱动程序通过调用USBD模块提供的接口函数实现与底层USB设备通信。本文使用的流接口函数方法如表1所列。 USB设备驱动程序必须输出的函数有： ①USBDeviecAttach()。当USB设备连接到计算机上时，USBD模块就会调用此函数。这个函数主要用于初始化USB设备，取得USB设备信息，配置USB设备，并且申请必需的资源。 ②USBInstallDriver ()。主要用于创建一个驱动程序加载所需的注册表信息，例如读/写超时、设备名称等。 ③USBUninstallDriver ()。主要用于释放驱动程序所占用的资源，以及删除UsbInstallDriver ()函数创建的注册表等。上述3个函数接口是所有的USB驱动程序必须提供的，缺一不可。另外较为重要的是USB设备驱动程序的注册表配置。一般的USB设备驱动程序的注册表配置在[HKEY_LOCAL_MACHINEDriversUSBLoadClients口]下，每个驱动程序的子键都有Group 1_IDGroup2_IDGroup3_IDDriverName 格式，设备的子键由供应商、设备类和协议信息通过下划线组成。表2列出了允许的组合。以本实验所采用的USB Camera为例，该USB Cam-era的供应厂商ID为0X046d，设备ID为0x08a2，那么它的加载注册表应该写为：需要注意的是，注册表的构成都是以十进制数值来标识的，也要注意十进制和十六进制之间数的转换。 3 WinCE5.0下USB摄像头驱动程序实验使用的USB Camera是中星微公司的301芯片组的Zc030x，它的Vid/Pid为0x046d、0x08a2。由于实时图像数据传送量比较大，很多USB Camera产品在图像传输之前已进行了数据压缩处理，如果不知道解码算法，是没有办法在WinCE上获得图像的。在开发的时候主要使用SnoopyPro，它是一款可以分析USB通信数据的软件，辅助进行Zc030x的驱动开发工作，最后成功开发出Zc030x在WinCE5.0下的驱动程序。下面结合USBCamera驱动开发说明驱动中的数据流向和必要的函数使用。首先是具体的注册表信息：其中，hDevice是由系统提供的当前外设的句柄，通过它可以获取外设的信息，如VID、PID等;UsbFuncs是系统提供的指向USBD函数的函数指针，通过它可以调用USBD函数，如GetlsochResult、IssuelsochTransfer等;AcceptControl指针指向的bool值需要我们确定，如果可控，令其为TRUE，否则为FALSE。在这个函数里面，要做的工作包括确定外设是否可控，分配和填写设备的上下文内容，调用ActivateDevjce()函数在“DriversUSBClientDriversCamera_Class”键值中注册分配到的设备上下文的指针(其中Camera_Class是对USB Camera的命名)，同时ActivateDevice在注册表[HKEY_LOCAL_MACHINEDriversActiveN]中登记设备上下文的指针，其中N为整数，它是系统自动分配给此驱动的数字。系统在调用ActivateDevice()过程中，又会自动调用CAM_Init函数。[!--empirenews.page--] DWORD CAM_Init(LPCTSTR pContext，LPCVOIDIp VBusContext) 其中，pContext是系统自动传入的字符串内容，也是上面的键名，即[HKEY_LOCAL_MACHINEDriversActiveN];CAM_Init要完成的就是在此键下读出设备上下文的指针，将其作为DWORD返回;IpvBusContext不用考虑。在USBDeviceAttach()中，最后要完成的工作是在此函数内调用USBD模块的RegisterNotificationRoutine函数登记注册DeviceNotify函数。这个DeviceNotify函数是必需的，在设备被移走后，系统调用这个函数完成相应的善后工作。 BOOL WINAPI DeviceNotify(LPVOID lpvNotifyPa-rameter DWORD dwCode.LPDWORD dwInf01.LPDW0RDdwlnfo2.LPDWORD dwlnfo3.LPDWORD dwlnfo4) 其中，IpvNotifyParameter是设备的上下文句柄，在RegisterNoticationRoutine中作为参数传入;dwCode是系统调用此函数的原因，如设备被移走，dwcode的值就为USB_CLOSE_DEVICE，相应的，用户进行卸载DLL工作;dwInfol，…，dwInfo4没有使用。自此，系统在USBDeviceAttach中完成对所加USB外设的驱动加载。当有用户调用CreateFile函数，系统会将用户填入CreateFile()的参数值，直接传到CAM_Open()。 DWORD CAM_Open(DWORD hDeviceContext，DWORDAccessCode，DWORD ShareMode) 其中，hDeviceContext是驱动上下文句柄，由系统自动填充;AccessCode是访问模式，ShareMode是共享模式，均由CreateFile()传递过来;CAM_Open的工作是将hDe-viceContext以DWORD的形式返回，再作为CreateFile()的句柄值返回给用户。当用户调用CloseHandle()时，系统将直接调用CAM_Close()，用于关闭一个驱动程序。 B00L CAM_Close(DWORD hOpenContext) 其中，hOpenContext是设备驱动的引用事例句柄，由CAM_Open创建。本驱动中，所有对USB Camera的操作均通过IOControl()映射到CAM_IOControl来完成。下面是CAM_IOControl的部分源码分析：由于本驱动是针对USBCamera的，因此CAM_Write、CAM_Read、CAM_PowerUp、CAM_PowerDown并没有内容;但是只要用户调用WriteFile，系统就将映射到CAM_Write。其他函数类似。通常，Camera对图像的压缩采用标准是MJPEG算法。在Zc030x上正是采用这一算法完成对数据压缩的。只要在驱动上增加MJPEG的解码算法，还原压缩数据，就可以正确显示图像了。至此，整个USB Camera的驱动编写工作完成。经过实验验证，已经实现了最高为25帧/s，大小为320×240的图片的传输。结语本文介绍了WinCE5.0下USB设备驱动框架，结合USB Camera的驱动开发实例说明了在USB驱动框架中驱动数据的流动方向，并已在中星微公司的301PLUS和303这两个系列的摄像头上得到成功运用和实践。所采用的程序设计方法及思想，对其他类似嵌入式系统软件的设计也有较高的参考价值。

时间：2014-01-22 关键词： USB WinCE 驱动 camera 流接口
WinCE平台USB摄像头驱动开发流程

由于良好的性能、低廉的价格和灵活方便的特性，USB 摄像头正被广泛的集成到嵌入式系统中。例如，通过USB 摄像头WinCE系统可以很方便地得到实时图像，这对某些要求实时图象监控的嵌入式系统是一个很不错的选择。但是由于嵌入式硬件平台的多样性，以及WinCE对USB设备驱动开发只提供了底层支持，再加上许多摄像头厂商尚未提供WinCE下的USB摄像头驱动，这对初级开发人员在开发WinCE USB摄像头程序时是一个难点。前段时间，公司委派我负责一个嵌入式项目，项目要求是在WinCE平台上集成USB摄像头驱动和视频采集程序。这个项目的关键是要集成USB摄像头驱动,并高效的把摄像头设备进行初始化以取得一幅完整的图像。幸好我以前开发过WinCE USB的主从设备的驱动程序。但虽然如此，我还是花了一些时间来调整系统的稳定性和可靠性。在这里我分享在这次项目实践中得到的经验和教训，希望大家能少走弯路。一. 什么是USB设备驱动程序开发? 随着USB设备的普及，USB设备驱动开发在嵌入式系统变得越来越重要了。为了支持不同类型的硬件可以连接到WinCE平台上，微软提供了具有定制接口的流接口驱动程序模型。WinCE的USB外围设备一般是使用流接口驱动程序。流接口驱动程序是指通过系统提供的文件系统API与应用程序交互;WinCE内核系统会通过设备管理器来完成对流接口驱动程序的加载、卸载等管理工作;而流接口驱动程序则会通过调用USBD模块提供的接口函数实现与底层USB设备通信。因此，在进行USB设备驱动程序开发之前，我们必须先了解USB设备驱动的结构和分类。 (1)主机与USB摄像头的通讯结构 USB摄像头驱动程序主要是利用系统提供的底层接口配置设备和摄像头设备进行通讯。因此，WinCE的USB摄像头驱动分为两层：USB Client设备驱动程序和底层的WinCE函数实现层。而底层的函数层本身又由两部分组成，即通用串行总线驱动程序(USBD)模块和较低层的主控制器驱动程序(HCD)模块。HCD负责最底层的处理，USBD模块实现较高的USBD函数接口。因此，USB摄像头驱动主要是利用USBD接口函数和外围USB摄像头打交道。一般来说，主机和USB外设之间的通讯是由在主机端通过USBD模块和HCD模块使用的PIPE访问一个通用的逻辑设备来完成。也就是说，USBD和HCD是一组抽象出来用于访问USB设备的逻辑接口，它们主要是负责管理USB外设的连接、加载、移除、数据传输和通用的配置。其中HCD是由主机控制和驱动的，是为USBD提供底层的功能访问服务。而USBD则是由USB总线驱动的，位于HCD的上层，是利用HCD的服务提供较高层次抽象的功能。由于HCD和USBD都是面向一致的逻辑设备接口，因此如果嵌入式系统中拥有多种USB物理外设的话，那么就需要有唯一对应的外设驱动程序，也就是要有最上层的PIPE所连接的物理设备和USB设备驱动程序。有了对这个结构的认识，那么我们在进行USB设备驱动程序开发时首先要写的就是最上端的USB摄像头客户端驱动程序，在WinCE的样例程序中它也被称为USB Client Driver。它是工作于USBD之上，所以实际上我们的工作就变成了利用USBD提供的接口针对特定的物理设备来完成USB设备驱动程序。(见图) (2)流驱动程序的分类和函数结构 WinCE驱动程序是介于内核系统和物理设备之间的一个代码层，它的主要作用是为内核系统提供一个接口用来操作不同的外围设备，包括物理设备和虚拟设备。驱动程序提供给内核系统的接口一般可以分为：本地驱动(Native Drivers)和流驱动(Stream Drivers)。我从这次项目实践中得到的经验是，WinCE下的所有驱动都可以归类到这两个里面，二者必居其一。流驱动是指通过为内核系统提供流接口函数来实现驱动外围设备，如XXX_Init()、XXX_Open()、XXX_Read()、XXX_Write()、XXX_Close()等。这一类的驱动由Device Manager来管理，它是通过调用ActivateDeviceEx()函数来实现加载流驱动的。ActivateDeviceEx()的参数是注册表中相应的键，用来设定加载流驱动的属性，如Index、Order、Prefix等等。流驱动加载成功后，应用程序就可以通过调用CreateFile()、ReadFile()、WirteFile()等函数来访问流驱动设备了。而与流驱动相反，本地驱动提供给内核系统的不是标准的流接口，而是事先约定好的特定接口。因此不同的本地驱动设备，接口也是不一样的。在WinCE中，常见的本地驱动有LCD显示驱动、触摸屏驱动、鼠标和键盘驱动及打印机驱动等。从这里可以看出，本地驱动主要是涉及与人机界面相关的驱动。它们是由GWES来管理的，由于他们在注册表中有各自相应的配置信息，因此它们会在系统启动时自动加载。简单的说，就是本地驱动是由内核系统操作和调用的，一般的应用程序是不能访问和调用的。在上一段描述中我们提到自动加载的概念，这是从驱动加载时间来区分的。主要分为两种：一是系统启动时自动加载;二是需要时才加载。一般来说，本地驱动都是在启动时自动加载的。而需要时才加载的方式，顾名思义就是想加载时才加载、想卸载时就可卸载。USB设备的驱动加载都是属于需要时才加载的驱动，例如USB摄像头的驱动程序。而从驱动的接口来看，USB摄像头驱动又属于流驱动接口。但相对于普通的流驱动接口，它增加了几个特有的接口函数：如USBDeviceAttach()、USBInstallDriver()、USBUnInstallDriver()等。在这次项目的调试中，我们发现需要时才加载的驱动程序有一个非常实用的好处，就是能在不修改嵌入式内核系统的情况下，应用程序可以动态加载该驱动以完成对硬件的操作，而操作完成后又可卸载其驱动程序以节省有限的内存。 (3)USB设备驱动程序入口点函数分析大部分USB外围设备由于功能性的原因会更适合使用流接口驱动结构，所以一般都会采用加载式流接口驱动程序模型来开发USB设备驱动程序。流驱动是指通过流接口函数来实现驱动外围设备的。因此，编写流驱动程序实际上就是对各种流函数进行调用。又由于USB摄像头驱动程序主要是和USBD打交道，所以我们必须详细的了解USBD提供的函数。让人感到幸运的是在WinCE下微软已经提供了通用串行总线驱动程序(USBD)模块、USBD接口函数全集、样本主机控制器驱动程序(HCD)模块。所以，我们只需要根据USB摄像头的硬件特性，利用USBD提供的不同函数就能实现流接口函数与外围摄像头设备的交互。就能大大的节省开发时间，从而能更快速地进行嵌入式开发。[!--empirenews.page--] 二.USB摄像头流驱动的实现过程 WinCE系统下的 USB 摄像头驱动程序的编写不同于在 Windows系统下的编写，因为在WinCE中对USB设备驱动开发只提供了底层支持。所以，在 WinCE系统下必须要根据所选择的USB摄像头的硬件特性自行编写驱动程序。根据我在这次项目中得到的实践经验，具体可以分为以下三个步骤： (1)创建USBD函数控制模块从上述的WinCE USB设备驱动模型及结构分析图中，我们可以清晰的看到主机和USB外设之间的实现方式。因此，我们首先需要编写USB Client Driver。也就是说，我们首先需要利用USBD提供的接口针对特定的物理设备来完成USB摄像头客户端驱动程序。虽然WinCE 没有提供USBD的标准机制，但是编写USBD 可供采用的方法有：①是使用流接口函数;②是使用现有的WinCE 应用程序编程接口(API);③是创建用户指定的API。根据在这个项目的多次实践经验，我在编写 USB摄像头驱动时采用了流接口驱动模式，该驱动程序的位置是位于 USBD 协议栈层上，属于控制具体设备功能的客户端驱动程序。然后，我把流接口驱动程序的流接口函数设计为匹配系统的文件系统API函数形式。通过这种机制方式，USB摄像头就可在流接口的管理下通过文件系统API暴露给应用层，这样应用层就可把USB摄像头作为一种特殊的文件进行操作，从而达到对USB摄像头的控制。 (2)创建控制USB摄像头的各种流接口函数从结构分析我们可知，所有的USB设备驱动程序必须在它们的DLL库设置一定的入口点函数与USBD模块进行适当的交互。设置入口点函数有两个作用：一是使得 USBD 模块能与外部设备交互;二是使得驱动程序能创建和管理任何可能需要的注册键。因此，在编写USB摄像头驱动程序时有一个重要的步骤，就是要创建和实现三个入口函数 USBDeviceAttach()，USBInstallDriver()，USBUninstallDriver()。实现这三个入口函数的主要目的是为了使客户端驱动与系统的 USBD协议栈进行联系。因为在USB摄像头接到主机后，USBD模块会调用这个函数来初始化USB设备，取得USB设备信息和配置USB设备，并且申请必需的资源。USBInstallDrive是在第一次加载USB设备驱动程序时首先被调用，它使得驱动程序能创建需要的注册键。但需要值得注意的是，USB设备驱动程序不是使用标准的注册表函数，而是使用RegisterClientDriverID()、RegisterClientSettings()函数来注册相应的设备信息。USBUninstallDriver则是在用户删除USB设备驱动程序时调用，负责删除注册键并释放其它相关资源。同样，它是通过调用UnRegisterClientSettings()和UnRegisterClientDriverID()函数来删除由驱动程序的USBInstallDriver()函数创建的所有注册键。因此，我们在驱动程序中需要严格按照这三个函数的原型来实现，否则就不能为设备管理器所识别。 (3)在注册表中配置USB摄像头驱动信息 USB摄像头一般是使用需要时才加载的方式来加载的，因此在设备加载时会先检查设备的相关信息。在WinCE系统中，这些相关的设备配置信息都是存储在系统注册表中的。所以，内核系统会先访问注册表以获得必要的相关信息。例如，USBD模块会使用一组跟踪驱动程序和设备的注册键来定位正确的驱动程序。如果注册表信息与 USB 设备信息符合，USBD就会加载此驱动程序，否则 USBD 就不会加载此程序。因此，编写USB摄像头驱动程序的最后一个关键步骤，就是要正确的在注册表中配置相关的USB 摄像头驱动信息。

时间：2014-01-27 关键词： USB WinCE 驱动摄像头开发
WindowsCE.Net下CAN卡的驱动程序设计

摘要：主要讨论在WinCE设计和开发CAN卡通信程序的方法;详细介绍CAN卡底层驱动函数的设计和实现，同时将驱动进行封装，用动态库的方式提供给用户CAN卡通信用的驱动，使用启可以方便地在自己的程序中调用，实现WinCE下的CAN卡通信。关键词：WinCE.NET CAN 驱动引言近年来电力行业为了快速部署变电站，采用了建造整体变电所的方法：在生产基地将变电站的内部设备安装、调试完成，只留下与外界的接口，整体运到变电站所在地后进行安装和简单调试即可投入运行。其内部设备通过CAN总线进行通信，系统原有的监控软件基于DOS系统，维护调试比较困难，因此想要寻求更方便、友好的系统支持。经过比较，嵌入式操作系统市场上风头正劲的Windows CE .NET成为最终选择。微软的最新产品Windows CE.NET提供了端对端的开发、调试手段，可以不拆卸设备的情况下通过Telnet登录到WindowsCE上进行调试和维护，其系统本身为嵌入式市场进行重新设计，包括创建一个基于WindowsCE的定制设备所需的一切。这样就需要将原来DOS下的程序移植到WindowsCE.NET下，但是各个硬件厂商目前还没有提供CAN通信卡在Windows CE.NET下的驱动，所以开发Windows CE.NET下的CAN卡驱动成为项目推行中的关键一环。本文主要针对研华的双口CAN卡PCM3680进行分析，介绍在WindowsCE.ENT系统下进行底层设备驱动开发的方法并提供CAN通信的实例。 1 CAN总线通信协议及CAN通信卡介绍 CAN总线是德国Bosch公司20世纪80年代初为解决现代汽车中众多的控制与测试仪器之间的数据交换而开的一种串行数据通信协议。它是一种多主总线，废除了传统的站地址编码，而代之以对通信数据块进行编码。这种方法使网络内节点个数在理论上不受限制，扩展格式中的29位的标识码便可以定义2 29个不同的数据块。在本项目中使用的是研华的PCM3680，这是一块嵌入式PC104的双口CAN总线通信卡;CAN控制器采用Philips的独立CAN控制器SJA1000芯片;CAN收发器采用Philips的P82C250，可以同时操作两个CAN网络，提供高达1Mb/s的传输速度。PCM3680支持很宽的中断范围：中断3、4、5、6、7、9、10、11、12、15，同时1000V的光电隔离提供系统高可靠性。在CAN卡通信中，要用到CAN控制器中的很多寄存器，各个寄存器的含义和作用可以参考控制芯片的说明书。图1列出驱动程序设计中用到最主要的寄存器结构。 2 CAN卡驱动底层函数设计本方案设计CAN驱动是放在Windows CE操作系统的内核下层，位于OEM adaptation layer(OAL)层的一个真正的驱动，而不是在主程序中的串口操作。在Windows CE的设备管理器可以看到CAN1和CAN2两个端口，并且可以查看其工作的正常与否和对其进行配置。如：中断号和I/O地址。 2.1 CAN卡寄存器读写函数 CAN卡的通信是通过操作CAN卡上的CAN控制器进行的。在CAN控制器中有很多寄存器，如控制寄存器、命令寄存器、状态寄存器、中断寄存器等，通过读写这些寄存器中的命令状态字可以检测和控制CAN卡的行为。在Windows CE.NET下，通过调用DOK中的API函数HalTranslateBusAddress，将CAN卡分配的物理地址映射为逻辑地址。这样各个寄存器对应的就是CAN卡基地址的偏移地址，因此，对寄存器的读写就转化为对内存地址的读写。下面是CAN卡寄存器的读写函数： *在偏移量为off的地址读取一个字节的数据inline BYTE CANR(LPCAN_HW_OPEN_INFO hCan，DWORD off) { return hCan->lpCanHWInfo->lpCanObj->lpMappedBaseAddr[off]; *将一个字节数据写到偏移量为off的地址中inline VOID CANW(LPCAN_HW_OPEN_INFO hCan，DWORD off,BYTE val) { hCan->lpCanHWInfo->lpCanObj->lpMappedBaseAddr[off]=val; } 参数LPCAN_HW_OPEN_INFO定义的是CAN卡的数据结构，其中成员lpMappeBaseAddr[0]表示的是映射后基地址，lpMappedBaseAddr[1]就是基地址+1的地址，对应CAN卡的寄存器是命令寄存器。通过上述两个函数可操作CAN卡上的所有寄存器。 2.2 CAN卡初始化 CAN卡的控制器比较复杂，在通信前必须确认硬件信息正确性、初始化各寄存器。初始化函数的基本流程如图3所示。第一步，检查端口号和硬件信息的正确性，主要是CAN卡中断号是否有效。第二卡，设置CAN卡默认参数： CanCardConfigInfo CAN_DEFAULT_SETTING= {0X00,0XFF,0X03,0X1C};/*设置默认波特率为125Kbps*/ DWORD dwThreadID =0; PHYSICAL_ADDRESS phyAddr={hwInfo->dwIOBaseAddr *16,0 }; 第三卡，用WinCE API函数LocalAlloc为CAN卡驱动中用到的数据结构分配缓冲区;通过HalTranslateBusAddress和MmMapIoSpace函数映射I/O地址，提供直接访问设备的虚拟地址： if(!HalTranslateBusAddress(Isa,0,phyAddr,0,&phyAddr)) goto _ExitInit; hCan->lpCanHWInfo->lpCanObj->lpMappedBaseAddr= (LPBYTE)MmMapIoSpace(phyAddr,CANCARDADDRLEN,FALSE); if(!hCan->lpCanHWInfo->lpCanObj->lpMappedBaseAddr) goto _ExitInit; 如果分配内存或映射逻辑地址失败，则退出初始化程序，CAN卡初始化失败。第四步，初始化读写属性、共享模式、读超时时间和第二个CAN口的基地址。第五步，创建CAN卡事件和数据接收事件：hCan->lpCanHWInfo->hCanEvent=CreateEvent(NULL,FALSE,FALSE,NULL); hCan->lpCanHWInfo->hRecvMsgEvent=CreateEvent(NULL,FALSE,FALSE,NULL); 第六步，初始化中断，如果CAN卡有复位请求就退出初始化程序。设置好中断后启动数据接收线程，设置线程优先级继续线程处理;最后配置CAN卡参数，进入正常运行状态。 2.3 CAN卡信息发送 CAN卡的信息发送分为两个步骤。在对CAN卡基本信息进行检查后，首先设置发送缓冲的ID号。CAN标准模式的ID号为11位，偏移地址10中存放的是ID号的高8位，偏移地址11的高3位存放的是ID号的低3位，剩下5位分别是RTR位(远程传送请求位)和数据长度。通过CANW函数将处理后的数据写入到相应的偏移地址，设置完相应的地址数据后，通过循环将偏移地址12～19的数据采集回来存到数组中。然后，设置CAN卡的传输请求为允许并不断侦测状态寄存器的变化，当传输缓冲满标志或传输结束标志为1时通出程序，完成一次数据采集。传输缓冲区的寄存器如表1所列。[!--empirenews.page--] 表1 ID号 10 ID.10 ID.9 ID.8 ID.7 ID.6 ID.5 ID.4 ID.3 RTR，数据长度码 11 ID.2 ID.1 ID.0 RTR DLC.3 DLC.2 DLC.1 DLC.0 数据1～8 12～19 数据数据数据数据数据数据数据数据 [!--empirenews.page--]表2 ID号 20 ID.10 ID.9 ID.8 ID.7 ID.6 ID.5 ID.4 ID.3 RTR，数据长度码 21 ID.2 ID.1 ID.0 RTR DLC.3 DLC.2 DLC.1 DLC.0 数据1～8 22～29 数据数据数据数据数据数据数据数据 [!--empirenews.page--]CAN消息发送函数的实现如下： BOOL CAN_SendMessage(LPCAN_HW_OPEN_INFO hCan,LPCanCardMessageBuflpMsg) { BOOL bSuc=FALSE; ASSERT(hCan && lpMsg && lpMsg->dwMessageLen <=8); /*防错处理*/ if(0= =(hCan->dwAccessCode & GENERIC_WRITE)) return FALSE; :: EnterCriticalSection(&hCan->lpCanHWInfo-> TransmitCritSec); /*进入临界区*/ BYTE byV=static_cast(1pMsg->dwMsgID>>3); CANW(hCan,10,byV); /*设置ID值高8位*/ byV=static_cast=((lpMsg->dwMsgID & 7)<<5); if(lpMsg->bRTR) byV|=0x10; byV+=static_cast(lpMsg->dwMessageLen); CANW(hCan,11,byV);/*设置ID值低3位、RTR及数据长度*/ for(UINT i=0; { CANW(hCan,12+i,lpMsg->byMsg); } /*采集数据*/ CANW(hCan,1,1);/*重置传输请求*/ while(TRUE) {byV=CANR(hCan,2); if(byV & 0X40) /*传输缓冲区满，退出*/ {break;} if(byV & 0X8){ /*传输结束，正确返回退出*/ bSuc = TRUE; break;} } ::LeaveCriticalSection(&hCan->lpCanHWInfo->TransmitCritSec); /*离开临界区*/ return bSuc; } 2.4 CAN卡信息接收 CAN卡的信息接收是发送的逆过程，当接收缓冲区标志为1时，表示缓冲区已满可以接收数据，将数据接收到数组后释放接收缓冲区，然后对接收到的数据进行分解并存储到CAN卡信息缓冲区的结构体。接收缓冲区的寄存器结构如表2所列。 CAN消息接收函数的实现如下： BOOL CAN_RecvRecvMessage(LPCAN_HW_OPEN_INFO HCan,OUT LPCanCardMessageBuflpMsg) {…… if(CANR(hCan,2)&1){ /*判断接收缓冲区是否已满*/ for(UINT i=0;i<10;++i) recvBuf=CANR(hCan,20+i);/*将数据暂存到临时缓冲区*/ CANW(hCan,1,4); /*释放接收缓冲区*/ LpMsg->dwMsgID=recvBuf[0]<<3; /*取出ID的高8位*/ BYTE byV =recvBuf[1]; LpMsg->dwMsgID+=byV >>5;/*取出ID低3位，然后和高8位合并*/ LpMsg->bRTR =byV &0x10?TRUE:/*返回RTR状态*/ LpMsg->dwMessageLen = byV &0XF; /*返回数据长度*/ …… } else {++hCan->lpCanHWInfo->dwErrorMsgCount;}/*没有收到数据，错误计数加1*/ ：：LeaveCriticalSection(&hCan->lpCanHWInfo-> ReceiveCritSec); /*离开临界区*/ Return bSuc; } 2.5 CAN卡事件处理 CAN卡事件处理函数是CAN卡驱动程序中很重要的部分。驱动设计要求具有消息通知的功能，当事件发生时及时捕获事件并进行消息处理。下面是事件处理函数的实现： staric DWORD WINAPI CAN_EventHanle(LPVOID lpParam) { ASSERT(lpParam); LPCAN_HW_OPEN_INFO hCan=(LPCAN_HW_OPEN_INFO)lpParam; CanCardMessageBuf bufMsg; while(TEUE) { /*循环等待CAN卡消息产生，然后进行处理*/ ：：WaitForSingleObject(hCan->lpCanHWInfo->hCanEvent,0XFFFFFFFF); if(hCan->lpCanHWInfo->bKillCanThread) break; /*若CAN线程已关闭则中断*/ if(CAN_RecvMessage(hCan,&hufMsg)){ /*正确接收数据后*/ CAN_RecvBufPush(hCan，&bufMsg);} /*将数据压入缓冲*/ BYTE byV=CANR(hCan,3); /*将3号寄存器读出然后立即写入*/ CANW(hCan,3,byV);/*能够获取每次中断*/ InterruptDone(hCan->lpCanHWInfo->lpCanObj->dwSysIrqt); } /*本次中断结束，等待下次中断*/ return 0; } 2.6 其它函数为了提供更多的功能和更方便地使用CAN卡进行通信，在CAN卡驱动程序中还设计了一些函数如CAN_Config用CAN卡信息配置、CAN_RecvBufPop用于处理接收缓冲区、CAN_Reset用于复位CAN卡、CheckHWInfo用于硬件信息检查等。这些函数提供了对CAN通信卡的设置、检查等功能，在这里不再详述了。 3 CAN卡驱动封装设计 CAN卡底层驱动函数虽然功能完整，但是对于用户使用比较复杂并且一般用户不需要了解底层实现的机制。为了便于使用，最后对CAN卡的驱动进行了封装，提供CanOpenFile、CanSendMsg等五个函数用于CAN总线的通信，以动态连接库(DLL)的形式提供给用户调用。封装函数及功能如下： *CanOpenFile;初始化并打开CAN卡的一个端口。 *CanCloseFile;关闭由CanOpenFile打开的CAN卡端口。 *CanRecvMsg;接收CAN卡数据，打开CAN卡时必须具有GENERIC_READ权限。 *CanSendMsg;通过CAN卡发送数据。打开CAN卡时必须具有GENERIC_WRITE权限。 *CanIOControl;设置或获取CAN卡I/O参数支持的I/O控制包括：IOCTL_CAN_CONFIG，IOCTL_CAN_RESET，IOCTL_CAN_TIMEOUT，IOCTL_CAN_SENDREADY，IOCTL_CAN_RECVREADY。下面是CanSendMsg函数实现的代码： BOOL CanSendMSg( HANDLE hCan, LPCanCardMessageBuflpMsg) { if(!hCan||INVALID_HANDLE_VALUE= =hCan|| !lpMsg||lpMsg->dwMessageLen>8)return FALSE; return CAN_SendMessage(LPCAN_HW_OPEN_INFO) hCan,lpMsg); 该函数就是通过封装CAN卡的底层驱动函数SendMessage来实现的，这样将功能集中的五个函数更方便了用户使用。结语程序开发的上位机是普通的PC机，软件环境是：Windows2000 Professional、Embedded Visual C++4.0、与下位机中WinCE.NET对应的SDK，该SDK是在用Platform Builder 4.0定制WinCE时编译生成的。下位机使用的硬件是研华的嵌入式PC104主板PCM3346N，操作系统为WinCE.ENT。[!--empirenews.page--] 本文设计开发的驱动已经在北京怀柔的变电站项目中得到成功的应用，CAN卡通信稳定，系统在WINCE.NET下运行可靠，保证了项目的顺利实施。

时间：2014-06-07 关键词： WinCE 驱动 can wince.net
WinCE驱动编写小结

1、基础知识： 1)系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件细节，在应用程序看来硬件只是一个设备文件，应用程序可以像操作普通文件一样对硬件设备进行操作。设备驱动是内核的一部分。 2)驱动程序完成以下功能： ——对设备初始化和释放; ——把数据从内核传送到硬件和从硬件读取数据; ——读取应用程序传送给设备文件的数据和回送应用程序请求的数据; ——检测和处理设备出现的错误。 3)上层应用程序运行在用户模式(非特权模式，Ring 3)，代码被严格约束执行。如不能执行硬件IO指令。所有的这些被阻止的操作如果想运行必须通过陷阱门来请求操作系统内核。 4)操作系统内核运行在内核模式(特权模式，Ring 0)，可以执行所有有效的CPU指令。包括IO操作，可访问任何内存区。 5)整个硬件系统资源在驱动程序面前是赤裸裸的，驱动可以使用所有系统资源，编写驱动程序时我们必须格外小心驱动代码的边界条件，确保它们不会损坏整个操作系统。 2、Windows支持的驱动： 1)虚拟设备驱动程序(Virtual Device Driver)：Windows3.1(Windows95/98/Me) 2)内核模式驱动程序(Kernel Mode Driver)：Windows NT 3)Win32驱动程序模型(Win32 Driver Mode)：从Windows98开始使用。其中WDM是目前主流，然而在WinCE系统中，由于硬件资源有限和嵌入式系统的特点，对其的支持非常有限。 3、WinCE系统驱动简介： 1)WinCE毕竟是一个嵌入式系统，有其自身的特殊性，为了提高运行效率，所有驱动皆为动态链接库，驱动实现中可以调用所有标准的API。而在其他Windows系统中可能的驱动文件还有.vxd， .sys和动态链接库。 2)WinCE驱动从结构上讲分为本地驱动(Native Driver)和流接口驱动(Stream Driver)。 ——本地驱动主要用于低级、内置的设备。实现它们的接口并不统一，而是针对不同类型的设备相应设计。因此开发过程相对复杂，没有固定的模式，一般做法是通过移植、定制现有的驱动样例来实现。 ——流接口驱动是最基本的一种驱动结构，它的接口是一组固定的流接口函数，具有很高的通用性，WinCE的所有驱动程序都可以通过这种方式来实现。流接口驱动程序通过文件系统调用从设备管理器和应用程序接收命令。该驱动程序封装了将这些命令转换为它所控制的设备上的适当操作所需的全部信息。流接口驱动是动态链接库，由一个叫做设备管理程序的特殊应用程序加载、管理和卸载。与本地驱动程序相比，所有流接口驱动程序使用同一组接口函数集，包括实现函数：XXX_Init、XXX_Deinit、XXX_Open、XXX_Close、XXX_Read、XXX_Write、XXX_PowerUp、XXX_PowerDown、XXX_Seek、XXX_IOControl，这些函数与硬件打交道。用户函数：CreateFile、DeviceIoControl、 ReadFile、 WriteFile，这些函数方便用户使用驱动程序。 3)WinCE下驱动的加载方式： ——通过GWES(Graphics, Windowing, and Events Subsystem)：主要加载与显示和输入有关的驱动，如鼠标、键盘驱动等。这些驱动一般为本地驱动。 ——通过设备管理器：两种结构的驱动都加载，加载的本地驱动主要由PCMCIA Host Controller，USB Host Controller driver，主要是总线类的驱动;流接口驱动主要有音频驱动，串并口驱动。 ——动态加载：前两者都是系统启动时加载的，动态加载则允许设备挂载上系统时将驱动调入内核，主要有外接板卡驱动，USB设备驱动等。 4、流接口驱动函数介绍： 1)DWORD XXX_Init(LPCTSTR pContext, LPCVOID lpvBusContext); pContext：指向一个字符串，包含注册表中该流接口活动键值的路径 lpvBusContext：该函数是驱动挂载后第一个被执行的。主要负责完成对设备的初始化操作和驱动的安全性检查。由ActiveDeviceEx通过设备管理器调用。其返回值一般是一个数据结构指针，作为函数参数传递给其他流接口函数。 2)BOOL XXX_Deinit(DWORD hDeviceContext); hDeviceContext：XXX_Init的返回值。整个驱动中最后执行。用来停止和卸载设备。由DeactivateDevice触发设备管理器调用。成功返回TRUE。 3)DWORD XXX_Open(DWORD hDeviceContext, DWORD AccessCode , DWORD ShareMode); hDeviceContext：XXX_Init的返回值。 AccessCode：访问模式标志，读、写或其他。 ShareMode：驱动的共享方式标志。打开设备，为后面的操作初始化数据就够，准备相应的资源。应用程序通过CreateFile函数间接调用之。返回一个结构指针，用于区分哪个应用程序调用了驱动，这个值还作为参数传递给其他接口函数XXX_Read、XXX_Write、XXX_Seek、XXX_IOControl。 4)BOOL XXX_Close(DWORD hOpenContext); hOpenContext：XXX_Open返回值。关闭设备，释放资源。由CloseHandle函数间接调用。 5)DWORD XXX_Read(DWORD hOpenContext, LPVOID pBuffer, DWORD Count); hOpenContext：XXX_Open返回值。 pBuffer：缓冲区指针，接收数据。 Count：缓冲区长度。由ReadFile函数间接调用，用来读取设备上的数据。返回读取的实际数据字节数。 6)DWORD XXX_Write(DWORD hOpenContext, LPCVOID pBuffer, DWORD Count); hOpenContext：XXX_Open返回值。 pBuffer：缓冲区指针，接收数据。 Count：缓冲区长度。由WriteFile函数间接调用，把数据写到设备上，返回实际写入的数据数。 7)BOOL XXX_IOControl(DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut); hOpenContext：XXX_Open返回值。 dwCode：控制命令字。 pdwActualOut：实际输出数据长度。用于向设备发送命令，应用程序通过DeviceIoControl调用来实现该功能。要调用这个接口还需要在应用层和驱动之间建立一套相同的命令，通过宏定义CTL_CODE(DeviceType, Function, Method, Access来实现。如：[!--empirenews.page--] #define IOCTL_INIT_PORTS \ CTL_CODE(FILE_DEVICE_UNKNOWN,0X801,METHOD_BUFFERED,FILE_ANY_ACCESS) 8)void XXX_PowerDown(DWORD hDeviceContext); hDeviceContext：XXX_Init的返回值。负责设备的上电控制。 9)void XXX_PowerUp(DWORD hDeviceContext); hDeviceContext：XXX_Init的返回值。负责设备的断电控制 10) DWORD IOC_Seek(DWORD hOpenContext, long Amount, WORD Type) hOpenContext：XXX_Open返回值。 Amount：指针的偏移量。 Type：指针的偏移方式。将设备的数据指针指向特定的位置，应用程序通过SetFilePointer函数间接调用。不是所有设备的属性上都支持这项功能。 5、流接口驱动的加载和注册表设置：系统启动时启动设备管理程序，设备管理程序读取HKEY_LOCAL_MACHINE\Drivers\BuiltIn键的内容并加载已列出的流接口驱动程序。因此注册表对于驱动的加载有着关键作用。下面是一个例子：【HKEY_LOCAL_MACHINE\Drivers\BuiltI\IOControler】 “Prefix”=”XXX” “Dll”=”drivername.dll” 其中，“Prefix”=“XXX”中的XXX要和XXX_Init等函数中的一样。CreateFile创建的驱动名前缀也必须和它们一致。 6、驱动程序的编写、编译及其相关目录、配置文件的格式和修改： 1)首先必须在PB相应平台的的driver目录下建立要创建的驱动所在的目录。如在x:\Wince420\platform\smdk2410\drivers目录下建立一个IOCtrol目录。 2)修改Drivers目录下的dirs文件。 3)创建驱动源文件XXX.c，在该文件中实现上述流接口函数。并且加入DLL入口函数： BOOL DllEntry(HINSTANCE hinstDll, /*@parm Instance pointer. */ DWORD dwReason, /*@parm Reason routine is called. */ LPVOID lpReserved /*@parm system parameter. */ ) 4)创建Makefile和Sources和.def文件，控制编译。 5)使用CEC Editor修改cec文件，编译添加的新特性。 6)复制新生成的4个文件到Release目录下，修改注册表文件platform.reg和platform.bib文件。 7)Make Image。 8)DownLoad Image。

时间：2014-09-24 关键词： WinCE 驱动
技术干货：WinCE 7.0下的触摸屏驱动

在嵌入式系统中较为常用的是四线电阻式触摸屏，通过检测x轴和y轴的电压，来确定触点的位置。一般触摸屏系统结构为：触摸屏->触摸屏控制器->处理器。 wince7下触摸屏的驱动分为PDD层(位于bsp目录中)和MDD层(位于public目录中)。PDD层和MDD层通过DDSI接口函数连接，MDD层和上层通过DDI函数连接。其中MDD层一般无需修改，我们只需修改PDD层的代码。比如我的bsp目录下触摸屏驱动中的touchscreenpdd.cpp文件中主要有如下函数： TchPdd_Init() TchPdd_Ioctl() PDDTouchIST() PDDInitializeHardware() PDDTouchPanelEnable() PDDTouchPanelGetPoint() PDDCalibrationThread() PDDStartCalibrationThread() PDDDeInitailzeHardware() PDDTouchPanelDisable() 其中TchPdd开头的函数就是DDSI函数，PDD开头的函数就是PDD层的函数。MDD层会最先调用TchPdd_Init()函数，该函数会将DDSI函数以函数指针的形式传递给MDD层，并调用PDD层的函数进行必要的初始化，如调用PDDInitializeHardware()来初始化SPI，GPIO(我的触摸屏控制器使用SPI接口)，调用PDDTouchPanelEnable()来创建“触摸屏事件”，创建IST线程等。 IST线程函数PDDTouchIST()中会有一个while循环，如下图所示：循环中有一个WaitForSingleObject(，)函数。该函数有两个参数，第一个参数是“触摸屏事件”的句柄，第二个参数用来设置等待超时的时间。 IST线程执行到这个函数会等待“触摸屏事件”发生或者超时。当这两种情况之一发生后，线程就会往下执行，并调用 PDDTouchPanelGetPoint()函数来读取触点坐标。在“触摸屏事件”发生之前，超时时间会设置为无限等待。只有当“触摸屏事件”发生后(触点按下)才会开始读坐标，并判断是否还是按下状态，如果还是按下状态，那么就会设置超时时间为某一个有限值，这样当 WaitForSingleObject等待时间超过这个值后又会去读取坐标。这种机制就能保证我们能读取到触点移动的轨迹。当然要想使用“触摸屏事件”，必须要有一个触摸屏的中断(当触点按下，这个中断发生)，并将这个中断和“触摸屏事件”关联起来，这样中断发生后，才会触发“触摸屏事件”。还有一种方法：不使用中断，直接采用轮询方式来读取坐标，通过读取坐标值的合法性来决定是否有触点按下。这种方式下，WaitForSingleObject的第一个参数就不起作用，且第二个参数必须设为一个有限值，这个值就决定来轮询的频率。

时间：2018-03-23 关键词： WinCE 触摸屏 7.0 驱动技术干货
分析：DSP正在驱动半导体产业

根据一位在DSP领域跟踪已久的分析师的报告，数字信号处理器正在不断的失去其作为独立芯片的特性，而且DSP事实上已经成为整个半导体产业的驱动力量。 ForwardConcepts的总裁和首席分析师WillStrauss在最新的无线分析报告中指出，半导体产业协会在上周发布的数据，乍一看来，DSP出货量（基于3个月的移动平均）同比上一年下降了47.2%，环比十二月份下降了38.6%，在各个领域的下跌比例处于领先。 “然而，该有戏剧性的下降并不是简单的DSP市场的下降，而是反映出许多在去年被划分为DSP的产品今年都被划到了ASIC一类。比如说，为摩托罗拉公司供货的飞思卡尔3G基带芯片（去年被划分到DSP）目前就已经被高通的3G基带芯片（从没有称作DSP，一直划分在ASIC一类）所取代。” “即使一月份摩托罗拉所有的基带芯片采购量与去年相同（当然实际上不会相同），SIA报告也会显示出DSP出货的下降和ASIC出货的增长，”Strauss强调说。他补充到事实上MCU和MPU配合乘法累计（MAC）电路和单指令多数据（SIMD）电路，除了实现他们基本的数据处理功能外，也能达到DSP（通常在图形领域）的效果。 “DSP内核在SoC中的应用也非常普遍，但他们没有被看成是DSP芯片，所以说，在随时随地接入互联网和多媒体应用的新时代，DSP已经成为了底层的基础技术。”

时间：2009-03-12 关键词： DSP 分析半导体产业驱动
嵌入式系统智慧化驱动　Server IPC崭露头角

2012年为伺服器(Server)等级工业电脑(IPC)发展元年。为满足工业与医疗等嵌入式应用走向智慧化发展，市场对于具备伺服器等级的工业电脑--Server IPC需求已日益增温，以符合智慧型嵌入式系统对效能与系统稳定度要求。研华嵌入式电脑系统事业群产品企划专桉副理林群复表示，包括大型医疗设备、安全监控与自动光学检测(AOI)等嵌入式系统的中控管理单元，目前多由一般的工业电脑与消费型个人电脑担任，但随着嵌入式应用朝向智慧化与云端发展，系统对储存效能与可靠性要求已愈来愈高，因而让Server IPC的角色日益突显。与一般IPC不同的是，Server IPC的产品规格等级较高，除了储存容量更大之外，配置的网路埠数也较多，并结合云端管理系统。林群复解释，目前Server IPC配置的网路接口多为两埠或四埠，不但可利用多条网路线提升资料传输速度，还可在某一条网路线失效的状况下，由其他网路线接续资料传输的动作，达到系统不中断的高稳定度。另一方面，结合云端管理系统，使用者可对Server IPC进行远端遥控，诊断并警示系统运作状况，还可远端进行韧体、软体的更新。事实上，Server IPC完全是因应强调高稳定、高效能的智慧型嵌入式系统所研发的新产品，过去一般的IPC可能需要二到三台设备才能组成满足各种智慧型嵌入式系统所需的中控管理单元，如今，仅须一台Server IPC即可。更何况，有些应用如医疗领域因医疗法规较为严格，对系统可靠度要求更高，因此Server IPC将较一般IPC更为适合。更重要的是，对系统应用业者而言，导入Server IPC还可减少成本与库存。林群复指出，先前利用消费性个人电脑作为中控管理单元时，由于消费性机种产品生命週期短，因此业者须购买许多同机型的产品库存，以便替换，相当不经济，而研华Server IPC产品供货保证7年、保固亦可延长至5年、可远端侦测系统状况或进行软体升级，并可符合包括医疗、自动光学检测等系统相关法规要求。林群复认为，需要反应快速、成像快，却又不能对效能及稳定性妥协的智慧型嵌入式应用，Server IPC将有较大的发挥空间，因此今年度开始，已有业者逐渐淘汰过去作为中控管理单元的消费型个人电脑，改採Server IPC，其中以欧美日大型医疗影像设备业者改用Server IPC的动作最为积极，预期今年将是Server IPC市场起飞年。

时间：2012-03-21 关键词：驱动嵌入式系统 server ipc
AMD不再每月都发布催化剂驱动

我们获悉，AMD宣布从催化剂12.5驱动程序开始，放弃一直以来每月发布一次催化剂的传统。 AMD表示，以后催化剂驱动程序不会有固定发布日期。AMD决定将重点放在质量和性能改进上，而非固定更新驱动程序。这样就无需每月都有2个独立的驱动开发路径，1个开发微软WHQL认证驱动程序，1个开发一般的beta或者hotfix驱动程序。 AMD表示，一旦有新游戏发布或者有紧急的bug需要修复，AMD就会拿出更多的hotfix和Preview驱动程序。目前AMD正在测试新版beta催化剂，修复了Radeon HD7000系列，混合输出况下宽域第三屏画面撕裂问题，这版催化剂将在下周发布。

时间：2012-06-01 关键词：发布 AMD 驱动催化剂
创新驱动梦想创业点燃激情

2013 “英特尔-清华”全国大学生创新创业营(以下简称“创业营”)近日在清华大学落下帷幕。今年共有来自全国22所大学的35支大学生创业团队参加了创业营。与往届不同的是，本次创业营突出创业实战，入选的 35支团队中有24支团队已成立公司，另外11支团队也已拥有完整产品和融资意向。同时，在能联系到的以往参加过创业营的学生团队中，超过四分之一仍在创业的路上深耕，其中不乏已经拥有几十位员工的小型高新企业，这无疑给正在为就业苦恼的大学生们提供了一个新的机会。在此次创业营中获得特等奖的3支团队——清华大学弱水无极团队、四川大学DreamZ团队和山东大学星核科技团队将于10月出征在美国举行的2013年英特尔®全球挑战赛——伯克利*总决赛，代表中国队在决赛上角逐最高为50,000美元的创业奖金。获得特等奖殊荣的创业项目，主要覆盖环境治理、电子信息和移动互联三个方面。来自清华大学的弱水无极团队，专注于重金属污染治理，可以针对不同的重金属废水和受重金属污染的土壤，量身定制专业治理方案;四川大学DreamZ团队自主研发了蓝牙4.0室内精确定位系统，其低功耗、低成本、瞬时启动、高精度、加密更加安全、辐射范围更广等优势，弥补了国内市场室内定位系统需求的空白;星核科技团队来自山东大学，其研发的校园智能管理系统目前已经在山东枣庄居山路小学上线试运营，家长可以通过视频在线看到孩子在学校的实时情况，独有的模式实现了安全监控、信息查看和数据共享。英特尔中国执行董事戈峻参加了闭营典礼，表达了对获奖团队的祝贺并宣布最终晋级英特尔®全球挑战赛——伯克利*总决赛的团队名单，他表示：“学员们对于创新创业的热情和坚持，让英特尔备受鼓舞。英特尔将尽己所能为大学生创业者搭建最好的平台，使得创业者有机会提高创业技能、获取所需的资源和技术，并通过帮助创业者成功创业来推动创新，从而促进就业，对社会形成积极影响。” 清华大学史宗恺副书记表示：“创业营作为清华大学与英特尔的合作项目，取得了许多令人欣喜的成绩，有些创业项目甚至在世界范围内也获得了极高的认可，证明了自身的商业价值。大学生是最具创新、创业潜力的群体之一，在就业压力日趋加重的今天，努力创新、自主创业无疑会给就业市场注入一针强心剂。希望同学们继续发挥自己的优势，敢于突破现状，再创佳绩。” “同学们的创业计划有许多创新之处，也越来越接近实际操作和市场运作。我相信会有越来越多的投资机构对来自大学校园的创业计划感兴趣。”英特尔投资中国区总监，本次创业营评委之一卜君全先生说。“英特尔-清华”全国大学生创新创业营已成功举办四次，在以往经验上，本次创业营进一步创新了教学方法和管理：根据创业项目的行业背景划分班级，实行小班教学，使得课程体系更加具有针对性;增设了奖学金制度，用于奖励表现优秀的团队及个人，奖励覆盖至70%的学员;持续加强投资对接，举办了投融资峰会，为投资机构与学员架设全方位接洽平台等。作为本次创业营的特色活动和创新内容，“投融资峰会”环节为创业团队提供了与风险投资商洽谈的真实情境，通过搭建有效的面对面沟通平台，帮助优秀的团队项目脱颖而出。学员们在参加完“投融资峰会”后纷纷表示：“我们非常珍惜这个来之不易的机会，过五关斩六将，最终与真正的投资商面对面。除了全面展示商业计划、创业思路以及团队成员，我们还获得了投资商的直接反馈和建议。” 为了更加贴近创业需求，本次创业营为学员们精心设计了一系列课程，内容涉及商务谈判、初创企业运营、创业相关法律、商业模式、品牌与市场等实用领域，以帮助学员们提升创业知识和技能。而授课嘉宾则包括多位学术与行业领袖人物和资深创业导师以及英特尔投资部门的投资经理，他们与学员充分互动，分享和讨论了创业经验和行业见解。作为英特尔®全球挑战赛中国区分赛，“英特尔-清华”全国大学生创新创业营由英特尔公司和清华大学携手创办于2009年，原名为“英特尔-清华”全国大学生创新创业实践夏令营。创业营自举办以来，得到了共青团中央学校部、上海市大学生科技创业基金会的大力支持，目前已发展成为怀揣创业梦想的大学生的盛会。

时间：2013-07-17 关键词：创业创新驱动
AMD发布Adrenalin 20.2.2驱动：解决大部分RX 5000显卡黑屏问题

继NVIDIA发布GeForce 442.50 WHQL驱动之后，AMD也发布了全新的显卡驱动，版本号Radeon Software Adrenalin 20.2.2，修复了大量Bug，解决了大部分RX 5000显卡的黑屏问题，不过还是有一部分没有彻底根治。 Radeon Software Adrenalin 20.2.2驱动For Win7下载页面 Radeon Software Adrenalin 20.2.2驱动For Win10下载页面 Radeon Software Adrenalin 20.2.2驱动升级内容具体如下： 1、开启部分Radeon Software功能或者在第三方软件使用硬件加速的情况下切换任务会导致系统死机或黑屏。 2、改进Radeon RX 5700显卡风扇控制功能，使其加速或减速更加灵敏。 3、Radeon RX 5700进行游戏时，OSD和Radeon WattMan显示的频率低于实际运行频率。 4、启用即时重播后，启动游戏或应用程序时可能会出现TDR或黑屏。 5、《战地5》游戏中切换HDR会导致黑屏，并且游戏运行一段时间后出现无响应或TDR。 6、《巫师3：狂猎》在游戏的某些部分或在游戏过程中间歇性地出现应用程序挂起或黑屏的情况。 7、Radeon RX 5000系列显卡：Chrome浏览器开启硬件加速后，播放视频时黑屏或无响应。 8、《地铁：离去》游戏DLC“山姆的故事”中，部分对话提示会导致游戏无响应或者TDR。 9、使用第三方OSD时再调用Radeon软件监控会导致《GTA5》崩溃。 10、《怪物猎人世界：冰原》闲置或处于创建人物界面时游戏会间歇性崩溃。 11、Radeon RX 5700显卡开启HDR时色彩泛白问题。 12、选择“保留我的设置”选项重置Radeon软件后，如果之前启用了即时重播，则即时重播可能无法运行。 13、在游戏中调用Radeon性能监视时会出现屏幕闪烁。 14、开启直播时，系统锁定或休眠会导致Radeon控制中心软件崩溃。 15、使用Radeon RX 5000系列显卡时，更改模式设定可能导致显示器音频丢失。 16、禁用Radeon性能监视且游戏在后台运行时，Radeon控制中心软件会载入失败。 17、部分Origin游戏在Radeon控制中心中无法识别或识别错误。 18、Radeon控制中心游戏标签下会显示部分专业应用。 19、Radeon Chill快捷键可能无法删除。 20、《荒野大镖客:救赎2》雪景显示错误。 21、Radeon RX 5700系列显卡：Chrome播放视频时休眠，恢复后程序会崩溃。 22、通过显示器开关FreeSync功能时，Radeon控制中心无法及时更新状态。 23、《堡垒之夜》游戏在部分采用Radeon RX 500系列芯片的混合显卡系统中会出现崩溃。已知问题中，AMD提到，尽管新版本已经解决了大部分游戏黑屏问题，但是游戏长时间运行后仍然会发生黑屏或死机现象，AMD会持续关注。

时间：2020-03-10 关键词： AMD 驱动 radeon 黑屏 adrenalin
LED驱动具备高可靠性

繁华的城市离不开LED灯的装饰，相信大家都见过LED，它的身影已经出现在了我们的生活的各个地方，也照亮着我们的生活。要普及LED灯具不但需要大幅度降低成本，还需要解决技术性的问题。如何解决能效和可靠性这些难题，PowerIntegrations市场营销副总裁DougBailey分享了高效高可靠LED驱动设计的心得。一、不要使用双极型功率器件 DougBailey指出由于双极型功率器件比MOSFET便宜，一般是2美分左右一个，所以一些设计师为了降低LED驱动成本而使用双极型功率器件，这样会严重影响电路的可靠性，因为随着LED驱动电路板温度的提升，双极型器件的有效工作范围会迅速缩小，这样会导致器件在温度上升时故障从而影响LED灯具的可靠性，正确的做法是要选用MOSFET器件，MOSFET器件的使用寿命要远远长于双极型器件。二、尽量不要使用电解电容 LED驱动电路中到底要不要使用电解电容?目前有支持者也有反对者，支持者认为如果可以将电路板温度控制好，依次达成延长电解电容寿命的目的。例如选用105度寿命为8000小时的高温电解电容，根据通行的电解电容寿命估算公式“温度每降低10度，寿命增加一倍”，那么它在95度环境下工作寿命为16000小时，在85度环境下工作寿命为32000小时，在75度环境下工作寿命为64000小时，假如实际工作温度更低，那么寿命会更长!由此看来，只要选用高品质的电解电容对驱动电源的寿命是没有什么影响的! 还有的支持者认为由无电解电容带来的高纹波电流而导致的低频闪烁会对某些人眼造成生理上的不适，幅度大的低频纹波也会导致一些数码像机设备出现差频闪烁的亮暗栅格。所以，高品质光源灯具还是需要电解电容的。不过反对者则认为电解电容会自然老化，另外，LED灯具的温度极难控制，所以电解电容的寿命必然会减少，从而影响LED灯具的寿命。对此，DougBailey认为，在LED驱动电路输入部分可以考虑不用电解电容，实际上使用PI的LinkSwitch-PH就可以省去电解电容，PI的单级PFC/恒流设计可以让设计师省去大容量电容，在输出电路中，可以用高耐压陶瓷电容来代替电解电容从而提升可靠性。 “有的人在设计两级电路的时候，在输出采用了一个400V的电解电容，这会严重影响电路的可靠性，建议采用单级电路用陶瓷电容就可以了。”他强调。“对于不太关注调光功能、高温环境及需要高可靠性的工业应用来说，我强烈建议不采用电解电容进行设计。” 三、MOSFET的耐压不低于700V 耐压600V的MOSFET比较便宜，很多认为LED灯具的输入电压一般是220V，所以耐压600V足够了，但是很多时候电路电压会到340V，在有浪涌的时候，600V的MOSFET很容易被击穿，从而影响了LED灯具的寿命，实际上选用600VMOSFET可能节省了一些成本但是付出的却是整个电路板的代价，所以，“不要选用600V耐压的MOSFET，最好选用耐压超过700V的MOSFET。”他强调。四、尽量使用单级架构电路 Doug表示有些LED电路采用了两级架构，即“PFC(功率因数校正)+隔离DC/DC变换器”的架构，这样的设计会降低电路的效率。例如，如果PFC的效率是95%，而DC/DC部分的效率是88%，则整个电路的效率会降低到83.6%! “PI的LinkSwitch-PH器件同时将PFC/CC控制器、一个725VMOSFET和MOSFET驱动器集成到单个封装中，将驱动电路的效率提升到87%!”Doug指出，“这样的器件可大大简化电路板布局设计，最多能省去传统隔离反激式设计中所用的25个元件!省去的元件包括高压大容量电解电容和光耦器。”Doug表示LED两级架构适用于必须使用第二个恒流驱动电路才能使PFC驱动LED恒流的旧式驱动器。这些设计已经过时，不再具有成本效益，因此在大多数情况下都最好采用单级设计。五、尽量使用MOSFET器件如果设计的LED灯具功率不高，那么建议可以使用集成了MOSFET的LED驱动器产品，因为这样做的好处是集成MOSFET的导通电阻少，产生的热量要比分立的少，另外，就是集成的MOSFET是控制器和FET在一起，一般都有过热关断功能，在MOSFET过热时会自动关断电路达到保护LED灯具的目的，这对LED灯具非常重要，因为LED灯具一般很小巧且难以进行空气散热。虽然LED在生活中处处可见，但是LED也还有一些不足需要我们的设计人员拥有更加专业的知识储备，这样才能设计出更加符合生活所需的产品。

时间：2020-03-14 关键词： LED 驱动可靠性
LED驱动失效因素

现在大街上随处可见的LED显示屏，还有装饰用的LED彩灯以及LED车灯，处处可见LED灯的身影，LED已经融入到生活中的每一个角落。基本上可以说LED驱动器的主要作用是将输入的交流电压源转换为输出电压可随LED,Vf(正向导通压降变化的电流源。做为LED照明中的关键部件，LED驱动器的品质直接影响到整体灯具的可靠性及稳定性。本文从LED驱动等相关技术及客户应用经验出发，整理分析灯具设计及应用中诸多的失效情况： 1、未考虑LED灯珠Vf变化范围，导致灯具效率低，甚至工作不稳定 LED灯具负载端，一般由若干数量的LED串并联组成，其工作电压Vo=Vf*Ns，其中Ns表示LED串联数量。LED的Vf随温度变动而变动，一般情况下，在恒定电流时，高温时Vf变低，低温时Vf变高。因此，高温时LED灯具负载工作电压对应为VoL，低温时LED灯具负载工作电压对应为VoH。在选用LED驱动器时需考虑驱动器输出电压范围大于VoL~VoH。如果选用的LED驱动器最大输出电压低于VoH，可能导致低温时灯具的最大功率达不到实际所需功率，如果选用的LED驱动器最低电压高于VoL，则高温时可能驱动器输出超出工作范围，工作不稳定，灯具会有闪烁等情况。但综合成本及效率考虑，不能一味追求LED驱动器超宽输出电压范围：因为驱动器电压只在某一个区间时，驱动器效率才是最高的。超过范围后效率、功率因数(PF)都会变差，同时驱动器输出电压范围设计太宽，则导致成本升高，效率无法优化。 2、未考虑功率余量及降额要求一般情况下，LED驱动器的标称功率是指额定环境、额定电压情况下测得的数据。考虑到不同客户会有不同的应用，多数LED驱动器供应商会在自家的产品规格书上提供功率降额曲线(常见的有负载vs环境温度降额曲线及负载vs输入电压降额曲线)。如图1所示，红色曲线表示LED驱动器在输入120Vac情况下，其负载随环境温度变化的功率降额曲线。当环境温度低于50℃时，驱动器允许100%满载，当环境温度高达70℃时，驱动器只能降额到60%的负载，当环境温度在50-70℃之间变化时，驱动器负载随温度上升而线性下降。蓝色曲线则表示LED驱动器在输入230Vac或 277Vac情况下，其负载随环境温度变化的功率降额曲线，其原理类同。如图2所示，蓝色曲线表示LED驱动器在环境温度55℃时，其输出功率随输入电压变化的降额曲线。当输入电压为140Vac时，驱动器的负载允许100%满载，随着输入电压下调;若输出功率不变，输入电流将上升，导致输入端损耗加大，效率降低，器件温度上升，个别温度点将可能超标，甚至可能导致器件失效。因此，如图2当输入电压小于140Vac时，要求驱动器的输出负载随输入电压减小而线性减小。看懂如上降额曲线及相应要求后，选用LED驱动器时就应该根据实际使用时的环境温度情况及输入电压情况，综合考虑及选择，并适当留出降额余量。 3、不了解LED的工作特性曾有客户要求灯具输入功率为固定值，固定5%误差，只能针对每盏灯去调节输出电流达到指定功率。由于不同工作环境温度，及点灯时间不同，每一盏灯的功率还是会有较大差异。客户提出这样的要求，虽然有其市场推广及商务因数的考虑。但是，LED的伏安特性决定LED驱动器为恒定电流源，其输出电压随LED负载串联电压Vo变化而变化，在驱动器整机效率基本不变的情况下，其输入功率随Vo变化。同时，LED驱动器在热平衡后整体效率会有所上升，在相同输出功率的条件下，相比于开机时刻，输入功率会下降。所以，LED驱动器的应用者在拟定需求时，应先了解LED的工作特性，避免提出一些不符合工作特性原理的指标，同时避免出现远超实际需求的指标，避免质量过剩和成本浪费。 4、测试中失效曾经有客户采购过很多品牌的LED驱动器，但是所有样品都在测试过程中失效。后来到现场分析后发现，客户采用自偶调压器直接给LED驱动器供电进行测试，上电后将调压器从0Vac逐渐上调到LED驱动器额定工作电压。这样的测试操作，很容易使得LED驱动器在很小的输入电压时就启动并带载工作，而此种情况会导致输入电流远远大于额定值，内部输入端相关器件，如保险丝、整流桥、热敏电阻等因电流超标或过热而失效，导致驱动器失效。因此正确的测试方法是将调压器调到LED驱动器额定工作电压区间，再接上驱动器上电测试。当然，从技术上改善设计也可以规避此种测试误操作导致的失效问题：在驱动器输入端设置启动电压限制电路及输入欠压保护电路。当输入未达到驱动器设定的启动电压时，驱动器不工作;当输入电压降低到输入欠压保护点时，驱动器进入保护状态。因此，即使客户测试过程中依然采用自偶调压器的操作步骤，驱动器具备自我保护功能而不至于失效。但是客户在测试之前一定要仔细了解所购的LED驱动器产品是否具备这项保护功能 (考虑到LED驱动器的实际应用环境，目前多数LED驱动器不具有此项保护功能)。 5、不同负载，测试结果不同 LED驱动器带LED灯测试时，结果正常，带电子负载测试时，结果就可能异常。通常这种现象有以下原因： (1)驱动器的输出瞬间电压或功率超出电子负载仪的工作范围。(尤其在CV模式下，最大测试功率不应超过负载最大功率的70%，否则加载时负载可能会瞬间过功率保护，导致驱动器无法正常工作或加载。) (2)所用电子负载仪的特性不适用于测恒流源，出现负载电压档位跳变，导致驱动器无法正常工作或加载。 (3)因为电子负载仪的输入内部都会有一个大的电容，测试就相当于在驱动器输出并联了一个大电容，可能导致驱动器的电流采样工作出现不稳定。因为LED驱动器设计就是为了符合LED灯具工作特性的，最接近实际与真实应用的测试方式应该是用LED灯珠作为负载，串上电流表及电压表来测试。 6、常发生的以下状况会导致LED驱动器损坏： ·将AC接到了驱动器的DC输出端，导致驱动器失效; ·将AC接到了DC/DC驱动器的输入或输出，导致驱动器失效; ·将恒流输出端与调光线接到了一起，导致驱动器失效; ·将相线接到了地线上，导致驱动器无输出及外壳带电; 7、相线接错通常户外工程应用都是3相四线制，以国标为例，每个相线与零线间的额定工作电压是220Vac，相线与相线间的电压是380Vac。如果施工工人将驱动器输入端接到两根相线上，则通电后，LED驱动器输入电压超标导致产品失效。如图3所示，V1表示第一相电压，V2表示第二相电压，R1及R2分别表示正常安装到线路中的LED驱动器。当线路上零线(N)如图断开时，两个支路上的驱动器R1，R2相当于串联后接到380Vac电压上。因为输入内阻差异，当其中一个驱动器充电到启动时，内阻变小，电压可能大部分加到另外一个驱动器上，导致其过压损坏失效。因此建议同一配电支路上，开关或断路器要一起断，不能只断开零线。配电保险丝不要放在零线上，线路上要避免零线接触不良。 8、电网波动范围超出合理范围当同一个变压器电网支路配线太长，支路中有大型动力设备时，在大型设备启停时，电网电压会剧烈波动，甚至导致电网不稳。当电网瞬时电压超过310Vac时有可能损坏驱动器(即使有防雷装置也无效，因为防雷装置是应对几十uS级别的脉冲尖峰，而电网波动可能达到几十mS，甚至几百mS)。因此，路灯照明支路电网上有大型电力机械时要特别注意，最好监测下电网波动幅度，或单独电网变压器供电。 9、线路频繁跳闸同一支路上的灯接得太多，导致某一相电上的负载过载，及各相之间功率分布不均，从而致使线路频繁跳闸。 10、驱动器散热当驱动器安装在非通风环境下，应该尽量将驱动器外壳与灯具外壳接触，条件允许的话，在外壳与灯壳的接触面上涂导热胶或贴导热垫，提高驱动器的散热性能，从而保证驱动器的寿命及可靠性。综上所述LED驱动器在实际应用中有很多细节需要注意，很多问题都需要提前分析、调整，避免不必要的失效与损失!现在的LED灯或许会有一些问题，但是我们相信随着科学技术的快速发展，在我们科研人员的努力下，这些问题终将呗解决，未来的LED一定是高效率，高质量的。

时间：2020-03-14 关键词： LED 驱动失效
Windows 10已成为开发人员的利器：集成的Linux内核对每个人都可以访问，就像安装驱动程序一样简单

在 Windows 上运行 Linux ? 这其实并不奇怪，黑客早在20 年前就这么干过。不过大体都是虚拟机的做法，速度慢，能跑的 Linux 应用也少。三十年河东，三十年河西。微软的开发者博客刚刚公布 [1] ，下一个 Windows10 版本，不仅自带 Linux 内核，而且还会通过 Windows Update 安装方式更新，简单得就像安装驱动程序一样。大杀器这个大杀器叫做 WSL , 全称是“适用于 Linux 的 Windows 子系统”(Windows Subsystem for Linux)，它其实也不是一夜间冒出来的，只是一直默默无闻。最早它起源于一个叫 Astoria 的项目，目的是为了让一些安卓 APP 运行在 Windows 10 移动版上。但它的目标并不是硬件仿真或者虚拟化这样的项目，或者像流行的 Cygwin 这样的第三方 Linux 环境。它的设计目标是一个完整的 Linux 子系统，可以直接使用主机的文件系统，比如允许用户在同一组文件上使用 Windows 应用程序和 Linux 工具;也可以调用硬件的某些部分，这是微软官方提供的在 Windows 环境下运行 Linux 软件的最直接方式。比如直接使用 GNU Linux 的命令行工具，各种编程语言诸如 Python、Ruby 的解释器，甚至像 XWindow 这样的图形应用程序。当然，微软指出 WSL 主要是面向应用程序的开发者，而不是日常的桌面环境。对于主力开发环境是 Windows ，但时不时需要用到 Linux 的开发者、老师或学生来说，堪称提高效率的开源神器。下个月就可能发布这个要推出的 Windows10 版本号是 2004，根据 YYMM 格式的命名规则，2004 就是 2020 年 4 月，当然 5 月发布也不奇怪，Windows Insider 里则可以先行体验。这次更新的其实是 WSL 第二个版本(WSL2) ，它比上一个版本 WSL1 要强大得多，它打包了真正的 Linux 内核，推进到了普遍可用(GA，Generally Available)的状态。特别是它大幅度提高了文件系统 I/O 性能，可以在 Windows 上直接运行 Linux 二进制文件。WSL1 是通过转换层，对系统调用还要做翻译;而 WSL2 则包含自己的 Linux内核，具有完整的系统调用兼容性，比如像 Linux 版本的 Docker 这样的开源程序，就可以直接调用。 WSL2 是在 2019 年 6 月的微软 Build 大会上宣布的，到这次即将要达到的人人可用的状态，花了接近一年的时间。如何安装使用这次 WSL2 最值得称道的，就是它简便的安装和使用方式，说白了就像安装驱动程序或者打一个补丁那么简单。具体而言就是使用 Windows Update 进行更新，这样可以获得最新的内核版本，而无需更新整个 Windows 映像。如果是第一次安装 WSL ，就会在安装过程中检查更新并为您安装 Linux 内核。当然，你也可以在命令行里操作，直接下载软件包。在 Github 上，你可以看到完整的源代码：WSL2-Linux-Kernel [2]。它基于 Linux 修改而来的，采取 Linux 内核的 GPLv2 开源许可证协议。对于开发者来说，安装了 Linux 内核之后，不仅仅是使用 Linux 命令行工具，而是可以运行其上的 GNU/Linux，这意味着你可以选择不同的 Linux 发行版，比如 Ubuntu、Debian、SUSE 等等，这些发行版通过 Microsoft 商店就可以安装。开源的微软，开源的社区微软对开源的支持今非昔比了。随着 WSL 的发布，开发者已经形成了一个热烈的开源社区，甚至还办起了开发者大会 WSLCONF [3] ，今年的 WSLCONF 就是 3 月 3 日，当然由于疫情原因，变成了一次线上活动。开发者大会还是 Ubuntu 赞助的，围绕 WSL主题进行各个方面的讨论，其中社区的头号人物就是 WSL的微软项目经理克雷格·罗文(Craig Loewen)[4] 。克雷格非常年轻，2018年刚从加拿大滑铁卢大学机电工程毕业，在校时实习经验丰富，不仅做过微软的实习生，还做过 FIRST 机器人大赛的评委。作为微软官方的 WSL 项目经理，克雷格在微软开发者博客上也发布了他面对开发者的最新概述视频《在 WSL2 上如何更快的开发程序》。曾几何年，微软和 Linux 是操作系统领域最大的对手，为什么现在后者反而成了前者座上宾了? Engadget指出，微软越来越不依赖Windows销售，而越来越依赖Azure等云服务。在服务器和开发人员方面，对Linux的更好支持是为了打造更好的生态系统。

时间：2020-03-20 关键词： Linux 驱动 windows10
白光LED驱动设计方法

现在大街上随处可见的LED显示屏，还有装饰用的LED彩灯以及LED车灯，处处可见LED灯的身影，LED已经融入到生活中的每一个角落。推动移动电话显示由单色转换为彩色的一个主要趋势是拍摄功能的集成。最初这些成像器件的分辨率相当有限，同时图像质量也不佳。但随着技术的发展，分辨率由 30 万像素的 VGA 等级进展到 100 至 200 万级像素，并快速朝向 300 万像素以上的分辨率级迈进。在成像器件、处理器与软件不断得到改进后，消费者现在希望得到更多的数码相机功能，例如低照明情况下需要的闪光灯，甚至是自动对焦等。在这样的分辨率下，良好的画质输出以及图片与视频分享变得更加实用，这些更高密度的 CMOS 成像器件需要从目标获得更多的反射光，因此进一步推动了集成闪光功能的需求。 1、LED 驱动设计的新要求要将传统的氙气闪光灯放置到尺寸相当紧凑的手机内对设计工程师来说极具挑战性，因为除了粗大的闪光用高压电容外，还必须加上灯泡以及相关的变压器与电子线路，而传统的闪光灯也不适用于视频拍摄的用途。庆幸的是，LED 制造商已经着手通过采用如氮化铟镓(InGaN)等新材料来提升功率 LED 的光输出。另一方面，半导体制造技术的创新以及封装方式的改进也提高了能够产生的流明数以及光电转换效率。要产生最高的光输出，这些功率 LED 可能需要 400mA 或更高，且脉冲宽度在 50 到 200ms 的电流输出能力。但是对视频应用来说，则需要较小的电流，但时间却不仅限于单一脉冲。除了尺寸的限制以及人体工学的考虑外，这些相机模块通常会集成在屏幕的后方或上方，以便使用者可以利用 LCD 作为抓取图像的取景器，这在折叠式手机上特别常见。成像器件与镜头机构可能还必须能够旋转，以便手机可以在视频会议模式下作为面对面沟通的工具，这在 3G 网络的电话设计上预计将更加普遍，因为有足够的带宽可以运用在视频会议上。在讨论这些趋势时我们可以明显地看出，屏幕显示的质量与分辨率变得越来越高，同时尺寸也越来越大，特别是具备丰富多媒体功能的手机，预计未来将有越来越多的内容，如流视频或广播视频、互联网浏览与电子邮件、拍照与相片查看，以及游戏和信息获取服务等。因此，当手机在没有通话时屏幕使用将更为频繁，但是如果手机的电池续航能力不够，这些功能都将受到限制。因此，高效率的系统电源管理，包括屏幕与按键的背光电源管理就变得相当重要，而诸如相机闪光灯等以往只有在高端手机中才能看到的功能也将逐渐成为标准配置。这些也将对白光 LED 背光驱动电路的设计带来挑战：更大的屏幕代表了有更多的区域需要背光，因此必须提升驱动器件的整体效率;由于空间有限，所以必须在单一封装中集成更多的功能;由于考虑的不仅是大小，厚度也必须缩减，特别是滑盖与折叠式造型的产品。 2、驱动电路方案手机中白光 LED 驱动电路经常使用两种架构：LED 以串联方式连接的电感升压转换电路;每颗 LED 都通过稳定的电流源驱动的电荷泵驱动器。电感解决方案可以带来最佳的整体效率，而电荷泵方式由于使用小型陶瓷电容作为能量转换器件，因此体积最小。图 1 和图 2 分别给出了两种驱动架构的典型应用电路。当前，功率 LED 的效率不断地得到提高，降低了背光 LED 的功耗，因此可以用更少的 LED 提供更高的光输出。这意味着两、三年前需要 4 颗 LED 提供背光的 1.5 寸屏幕，现在只需两颗功耗只有一半的 LED 就能够得到相同的性能。为了满足这个需求，就需要一颗能够驱动两个 LED 的新产品，并能以相当低的电流支持屏幕背光的低功耗待机运行。为了解决这个问题，NCP5602/12 系列电荷泵 LED 驱动器件设计成可以支持超低电流的 ICON 模式，同时能够通过简单的单线式或传统的 I2C 串行总线提供两颗 LED 的普通背光功能。除了支持最新的轻薄封装趋势外，这些产品也在设计上采用新的极薄型 LLGA 微封装技术(2×2×0.55mm)来支持超薄应用。此外，部分改进的 LED 材料与设计拥有更低的正向电压(由 3.6V 降低到 3.1V)，因此对电感解决方案来说，相同的功率可以驱动更多的 LED。而更复杂的 LED 驱动器件，如 NCP5604A/B 就拥有更多的电压转换模式选择，提供更优化的功率转换，同时集成电流源的功率耗损也更低，在手机电源所使用的锂离子电池的大部分工作时间内达到 85%的转换效率(PLED/Pin)。 LED 闪光灯已经成为照相手机必备的配置，安森美开发出的 NCP5608 多重模式电荷泵 LED 驱动器，能够驱动 4 颗 LED 用于主屏幕与子屏幕的背光，以及可以提供用于驱动 1W 功率 LED 的高达 400mA 的高电流输出。这些功能在设计上共用一个高效率的电荷泵转换电路，以便将外接电容的数目降到最低。由于空间有限，特别是新型超薄直板手机以及翻盖手机，因此这款器件采用 4×4×0.75mm 的 QFN 封装。为了将控制驱动器所需的连线数降到最低，该器件采用了两线 I2C 数据总线作为控制配置接口。在驱动闪光灯 LED 上提供有 4 个专用通道，让引脚能够以并联方式驱动一个高功率 LED，或用来驱动数个以较低电流工作的闪光灯 LED。 3、应用展望当许多新兴的多媒体与数据服务变得越来越普遍，手机设计工程师也将持续面临需要集成更多功能(例如更大的屏幕、百万像素成像器件、视频处理以及应用协处理器等)的挑战，同时还得满足移动手机用户对待机与通话时间的要求，以及使用者对更长的视频播放、游戏与网络浏览的期望，这些都将需要更长的显示屏使用时间。幸运的是，高亮度 LED 效率以及创新性 LED 驱动器件的改进将能够帮助设计工程师满足这些需求，同时还能符合消费者对重量与尺寸的期望。事实上，背光不仅可以应用在屏幕与按键上，彩色 RGB(红绿蓝)LED 还可根据音乐、来电铃声等提供一些好玩的效果以及个性化设定，例如通过最新的来电识别功能，利用 RGBLED 在视觉上提示用户是谁打进电话。我们可以发现，LED 已经由简单的背光功能演变成更多的功能。在按键上已经开始加入边缘发光器件来协助按键背光的平均分配，同时还能降低手机的整体厚度以及产生背光所需的 LED 数量。未来，利用 LED 提供照明将在手机以及其他数字消费电子产品上可以看到更多的创新型应用。相信在未来的科学技术更加发达的时候，LED会以更加多种类的方式为我们的生活带来更大的方便，这就需要我们的科研人员更加努力学习知识，这样才能为科技的发展贡献自己的力量。

时间：2020-03-27 关键词： cmos 驱动白光led