标签: bin

        最近做一块板卡，有一组LED灯需要驱动，固定亮度发光。板卡5V供电，于是未加思索，按照以往设计方法，设计电路如下： 图1 LED灯驱动电路         计划板卡做好后，在进行调试时，根据实际的亮度情况，调节限流电阻R1的阻值，最终获得期望的效果。         在做方案评审时，自己觉得这个地方应该没有问题，于是粗描淡写，一笔带过。但却被打断，有人问：“这么一组灯，是用恒流源驱动还是恒压源驱动？每个灯的亮度能否保持一致，不出现差异？”我比较茫然，我知道LED灯的亮度取决于前向电流If，用恒流源驱动是最好的。但这样的话，电路结构会复杂些。如果想用恒流源驱动多个灯，如使用LED灯驱动芯片，但这需要较高电压才行，目前是5V供电，无法采用该方案。另外，自己觉得用图1所示恒压源驱动也是一种成熟电路，无可厚非的。于是我说了自己的想法，大家让我下来再研究确认下。         之后，我看了LED灯的手册，发现其发光一致性是受很多因素影响的，并非以前一直认为的那么简单。          首先手册上给出的各种参数，如光强、波长、色度坐标、饱和度、前向电压等，都是在前向电流If为额定值的时候测得的。         但即使每个LED灯流过的前向电流If是一致且为额定电流，其光强、波长、色度坐标、饱和度、前向电压等参数也是有差异的，这是由制造工艺决定的。一般LED厂家会对这些光电参数的值的范围划分BIN区间，如下图所示分别为某款灯的光强BIN区间和前向电压BIN区间： 图2 某款灯光强、前向电压BIN区间         可见，光强分为了J2、K1、K2三个BIN区间，前向电压则分为了28、29、30、31四个BIN区间。LED厂家会对生产出来的LED灯按照这些光电参数的划分区域进行筛选，比如某个灯属于光强J2等级、前向电压28等级，就筛选到这个等级区域。一般来说，同一批次内的LED灯会是同一个等级区域，光电参数一致性较好。但不同批次的LED灯，则可能处于不同的等级区域，如果使用，可能会带来发光不一致。当然，可以要求厂家严格筛选，保证每一个批次的LED灯都处于同一等级，但这样的话，LED灯价格就会昂贵一些，带来成本的增加。         我们希望每个LED灯之间的光电参数的差异越小越好。在存在一定差异的时候，根据应用场景，比如单板上仅有几个LED灯，基本难以碰到不同批次LED灯的情况，我们就希望厂家能够将BIN区域划分的越多越好，因为这样厂家的筛选就更加严格，每一批次LED灯的光电参数差异就越小。         对于光强、波长等光参数的差异，我们在设计电路上几乎是无能为力的，只能寄希望于LED灯制造的水平。而对于前向电压Vf，使用图1所示的电路话，就要求VCC电压越高越好，因为这样的话，前向电压Vf变化对前向电流If的影响就越小。如果VCC电压较低时（当然要高于前向电压Vf最大值），可将恒压源电路改为恒流源电路，从而消除LED灯前向电压Vf差异对前向电流If造成的影响。如下图所示为恒流源的改造方法： 图3 恒流源驱动LED灯电路         这个电路是很简单的，关键点在于设计电路，比如选择稳压源使得三极管b极的电压恒定不变，从而使得限流电阻R1上的电流不变，最终使得LED灯的前向电流If不变。         一般情况下，最好按照额定前向电流来设计LED灯电路。如果不按额定前向电流来设计，厂家未进行过筛选，LED灯个体间光电参数的差异会更大。          最终由于这块板卡加了面罩，会均匀发光的不一致性，所以仍采用图1所示的LED灯驱动电路。但这也告诉我，任何一个看似较小较简单的部件，其实都值得去深入研究学习，只有这些基本知识掌握透彻了，才能够加深对设计的理解，提高设计的质量，这是以后自己需要进一步去做的。                   

  　ARM处理器的映像文件是.axf文件或者.bin文件。.axf文件和.bin文件的区别在于，前者包含调试信息和注释信息，后者没有。编译器输出的ARM映像文件以.axf文件为主。通过fromelf工具，可以把.axf文件转换成.bin文件。实际下载到系统板的映像文件多数是.bin格式文件。   　.axf文件是一种满足DWARF (Debug With Arbitrary Record Format，带任意记录格式的调式)V2.0调试文件格式的ELF文件，而DWARF调试文件格式又是UNIX操作系统的调试文件格式。目前，DWARF的最高版本是V3.0。   　Linux编译器GCC输出文件格式就是符合DWARF V2.0调试规范的ELF映像格式，Window。平台集成开发环境ADSI. 2翰出的也是符合DWARF V2. 0调试规范的ELF映像格式，即.axf格式文件。     文章由 A9开发板 供应商小编原创，转载请注明文章来源出处，谢谢合作！

这个工具是与HexToBin功能相反的工具，非常相似的界面。功能和特别也非常相似。     软件功能： 1. 可以将镜像文件(. bin )转换为inter-extended 文档(. hex )，是单片机开发中的常用格式。 2. 没有64kb的限制 3. 可视界面，支持输入文件路径,输出文件路径及名称设定 4. 绿色软件，直接运行   软件运行需求： 1. win xp, win vista, win7, win8 2. 安装.NET 4 3. 支持64位系统 C#开发     软件主页： http://blog.sina.com.cn/newbittech   下载地址： 百度云   http://pan.baidu.com/share/link?shareid=28277914uk=339018285 新浪微盘  http://vdisk.weibo.com/s/BIZlkEwPqiHzI     ---------------------------------------------------------------------------------------------   第二个小工具，请大家多提意见！   NewBit Studio 2013     转自  http://blog.sina.com.cn/s/blog_adcc88040101fg0h.html  

  2011/10/18,挪威奥斯陆 -全球最节能的微控制器和无线射频供应商Energy Micro,，宣布其与睡眠监视仪生产厂商Zeo公司的合作。Zeo在其有开创性的移动睡眠监视仪使用Energy Micro 的产品EFM32 Gecko MCU。Zeo的这款监视仪，能够非常准确地追踪睡眠时间和睡眠质量，它能帮助用户通过智能手机控制并改善他们的睡眠方式. Zeo 的移动睡眠监视仪是同类产品中首款能够通过科学地衡量浅度睡眠，深度睡眠，快速眼动阶段，精确而完整地描述使用者的睡眠质量的产品。该监视仪有无线装置的头带，能跟踪记录不同的睡眠阶段，并将每晚的睡眠质量发到智能手机上。智能手机能与Zeo 的一个账号自动同步，该账号能提供在线分析工具及针对不同用户提供提高睡眠质量的专业指导。 Zeo 选择Energy Micro这款基于ARM? Cortex?-M3的EFM32 Gecko微控制器，是看重了它的32-bit的处理能力 以及它超低的运行功耗。EFM32 Gecko微控制器使得多个模拟感应器及数据处理能够通过一内置蓝牙无线装置的头带进行控制。该无线装置通过电池进行供电，无需在床边安装特定的监控设备，只需要通过智能手机就可以监控的睡眠。头带的电池95 mAh充电一次能使用4天。 Zeo 的CTO及联合创始人Ben Rubin称：“在设计智能监控仪头带的时候，电池能耗的精确管理是我们考虑的重点。Energy Micro的EFM32 Gecko MCU，让我们超越了预期设定的电池使用寿命时间，同时这种MCU 又能保证高精度的感应监控，进行复杂的32 bit的数据处理及快速的串行数据通信。” Energy Micro的 CEO，Geir F?rre 表示：“能被Zeo选中，作为其具有开拓性意义的睡眠监视仪的合作伙伴，我们感到很骄傲。作为真正的创新者，Zeo选择将最新的节能技术融入到新一代的智能手机辅助设备当中，无疑是具有前瞻性的公司的典范。” EFM32 Gecko系列控制器，以超低的运行及等待功耗，快速的处理时间，超短的唤醒时间及灵活的能耗模式而著称，它的能耗只有同类8-bit, 16-bit and 32-bit控制器的四分之一。Gecko系列微控器多种低能耗的外设模块，这些模块能自主运行而不需要CPU的介入。Energy Micro独特的“AEM能耗监控系统”及“简易工作室”软件控制台为全面的应用工具的能耗调试提供技术支持。   EFM32 MCU 的更多相关资料可在 www.boccn.com.cn 中咨询到 。

说明: 本文的实践是基于lpc1343; 要想在keil中直接生成bin文件一般需要加用户命令调用fromelf工具： 如下图在Options for Target 中 加上编译后的命令； fromelf --bin ".\obj\@L.axf" --output ".\obj\@L.bin" 这样build or rebuild之后就会生成 bin 文件了；   在NXP CM0 CM3 上应用存在的问题： 这样生成的bin文件却不能通过nxp的代码有效性检测； 原因如下： 在nxp CM0 或CM3 的UM 中有对有效用户代码的判断标准作出说明： 有效用户代码判定标准 ： 保留的 Cortex-M3 微控制器异常向量单元 7 （在向量表中的偏移量为 0x0000 001C ）应当包含表入口 0~6 的校验和的 2 的补码。这样就使前 8 个表入口的校验和为0 。引导装载程序代码校验 Flash 扇区 0 中的前8 个单元。如果结果为 0 ，执行控制权便转移给用户代码。 如果符号无效，那么自动波特率程序通过串口（UART ）与主机进行同步，或从 USB 端口启动（PIO0_3 管脚的采样为高电平）。 查看用keil直接生成的bin文件（推荐用ULtraEdit查看），发现其地址0x1c处并不是对前面6个向量的校验和的2的补码； 用lpc1343的usb isp（u 盘方式）把bin文件烧入进去，复位启动后，其bootloader会对其有效性进行检查，此时发现其代码无效而不会允许已经更新的用户程序；如果条件允许则会自动usb端启动或者通过uart与主机通信； 但是用Flashmagic等工具下载的代码则不会出现该问题，因为FlashMagic软件会自动计算0x1C处开始的四字节的内容，修改后写入。   解决方法 MDK410已经解决了这个问题。描述如下：   Added: ELFDWT utility creates boot checksum for NXP LPC11xx, LPC13xx, and LPC17xx device series. Usage is: C:/Keil/ARM/BIN/ELFDWT elf_file.AXF 利用ElfDwT.exe先把axf格式的进行修正，让后再把axf 转换成bin 使用方法如下 ： keil-project-options for target-user-run user programs after build -  run #2 RUN#1: $K\ARM\BIN\ELFDWT.EXE #L RUN#2: fromelf --bin ".\obj\@L.axf" --output ".\obj\@L.bin" 如下图： 这样问题就得到了解决；直接把生成的bin文件拷贝的lpc1343的u盘中，程序就得以了更新；