标签: BOOTLOADER

这个话题相信很多嵌入式的同行都困惑过很长一段时间，其实说起来也不算复杂，借此机会，也把以前做过的bootloader方案说一下 先说怎么实现的，要知道bootloader本身其实也是一个应用程序，不过这个应用程序本身不会做太多的处理，他只负责告诉程序得往哪里走。 一般来说，需要以下几个操作， 地址跳转，需要跳转到某一个位置开始执行 中断向量表需要偏移 需要关闭总中断 需要注意一点是需要关闭看门狗，不然在app中没喂狗会重启 关于这个升级方案，有以下几种做法， 将芯片的flash分为几个部分，一部分用来存储升级数据app2，一部分用来存储正常运行的代码区app1，当有升级任务来的时候，mcu将数据先放到app2的区域，并在升级手法完成时候对数据进行校验，考虑到嵌入式设备的算力，建议用md5或者crc16.比较无误后在某个安全地址写入标志位后，重启设备 设备上电后会检测到有app2存在，将其数据更替到app1的区域，更新完成后跳到app1(此时存储的是app2的代码) 程序正常运行后擦除标志位 当本身空间不够的情况下，使用25q80等外设，增加一些成本，但这样可以做到更高的灵活性，比如针对刚才的情况,假如说程序运行失败了，升级固件失败了或者更新的固件达不到要求，这个时候需要回复出厂设置了，那该怎么处理呢？可以先把出厂时候的程序放在外置flash，等到比如检测到按键长按，这个时候就可以回复出厂设置了，程序从外置flash中将数据加载到app1的区域，加载完成便跳转。

　　在IC卡公用电话系统中，在线式公用电话由于其具有保密性高、可扩展性强等特点，已逐渐获得人们的青睐。这种公用电话系统被置于终端和交换机之间，对两者的信号进行调制、解调以及其它的运算，来完成诸如卡验证、终端维护、多媒体信号传输等工作。与软件无线电相类似，这种系统的硬件平台通用性很强，数字信号处理的算法将由专门的芯片来承担，所以这种系统可以兼容目前在电话线上应用的各种调制解调方法，也可以适应未来出现的其它调制解调标准。 　　由此可以看出，要实现这样一个系统，数据采集是一个非常重要的方面。为了节约成本和提高DSP芯片的利用率，在这个系统中，一片DSP要承担16个通道的运算。从数据采集的角度来说，由于通道同时对应着终端和交换机两端，故DSP需要高速采集32个通道的数据。另外，高速ADC的出现和DSP性能的不断提高也对系统将来的升级提出了要求。所以对数据采集部分来说，高速、可扩展性是两具非常重要的指标。实现的系统就是以这两个指标为指导的。 　　目前的高速多通道数据采集系统一般有以下几种实现方法：一是直接采用高速的多通道模/数转换芯片，这些芯片有专门设计的与DSP接口的部分，但是这些芯片一般价格都非常昂贵；二是直接用FPGA完成整个的采集过程，这将耗费FPGA巨大的资源；三是DSP和模/数转换芯片的地址以及数据总线直接相接，通过单片机控制转换等过程，这种方法虽然便宜，但是可扩展性太差。综上所述，提出一种通过CPLD实现接口，将模拟转换通道映射到DSP的I/O设备空间甚至内存空间的方法。这种方法大大提高了DSP可以访问的外设数目；同时由于DSP不直接与模/数转换模块接口，所以ADC芯片的升级或者替代都不会影响原来的数据采集；而且采用了时分复用方式读取转换完成的数据，因此这个系统数据采集速率可以达到所采用的ADC芯片输出的最高速率。 　　DSP虽然在算法处理上功能很强大，但其控制功能是非常弱的；而CPLD本身并不具有内部寄存器，虽然可以用CPLD的逻辑块来实现寄存器，但是这将耗费大量的CPLD资源。然而，CPLD的强项在于时序和逻辑控制。本文介绍的多路数据采集系统就是充分利用了DSP和CPLD的优点，将多个A/D转换单元通过CPLD映射到DSP的I/O地址空间，利用CPLD屏蔽A/D转换的初始化以及读写操作过程，使得DSP可以透过CPLD这个"黑匣子"快速、准确地获取数据。 　　 1 数据采集系统框架 　　整个数据采集系统主要由DSP处理模块、CPLD接口模块和ADC阵列三个部分组成，如图1所示。透过这样一个结构，DSP可以在未知ADC的控制方式的情况下，定时地以访问外设的方式来获得总共32个通道的模/数转换后的数据。 　　这样的系统框图只是完成了一个完整的数据采集功能，至于数据的处理以及DSP需要完成的其它功能，此图并未涉及。但对于一个DSP系统来说，数据采集在硬件中占据了很大的比重，这也符合DSP芯片应用的原则：用软件完成大部分的数字处理算法。 　　 2 各功能模块的实现 　　2.1 ADC阵列的实现 　　此数据采集系统的设计目标是完成32路信号的采样，并且要求每路的采样率为50kHz。所以，这样一个系统达到的整体采样率为32×50k=1.6MHz。 　　在模/数转换环节，采用的A/D芯片一片一次可以同时完成4路转换。为了达到设计目标，需要8片这样的芯片。但是，如果直接将8片模/数转换芯片的数据总线全部连接起来输入到CPLD中或者将CPLD出来的某条控制信号线直接连接到8片芯片上，那么在驱上就会出现总是。基于此种考虑，此系统将8片芯片分成两组，每组4片，然后从CPLD中引出两组数据总线以及两级控制总线分别对它们实现控制。这样就能很好地解决芯片的驱动问题。图2就是其中一组芯片的连接架构图。 　　从这个架构图可以看出，这4片A/D转换芯片除了片选控制信号以外，其它的数据总线以及控制总线全部是分别连在一起的。将片选控制与其它控制分开的原因在于：芯片的初始化以及转换过程需要同时完成，但是转换后数据的输出则分则完成。ADC控制时序框图如图3所示。 　　要实现这样的控制时序，各个阶段对芯片的片选控制如下：在初始化阶段，所以A/D芯片的片选信号有效，此时可以对每片芯片写入相同的模式选择信号，同时启动采样脉冲和转换脉冲；在转换阶段，所有片选信号全部无效，此时芯片本身在内部完成模/数转换，同时将转换完成的数据放置在芯片内部的寄存器中；在数据输出阶段，首先是第一片芯片的片选有效，此时若有一个脉冲下降沿到A/D芯片的RD端口，则芯片1的转换完成，第一路数据将浮出到数据总线上，而其它芯片由于片选信号无效，虽然有RD输入也不会有数据输出，不会造成总线冲突。对于芯片1而言，接下来的几个RD脉冲可以分别使得转换完成后的几路数据浮现在数据总线上。芯片1的数据全部输出完成后，片选1无效，此时可使芯片2的片选信号有效。依此类推，就可以完成4片芯片的转换及数据输出。 　　 2.2 CPLD接口模块的实现 　　整个CPLD接口模块实际上就是一片ALTERA公司的7000系列的CPLD(外部时钟电路除外)，它控制ADC模块的初始化，同时接收并分析DSP过来的I/O端口读取信号，为DSP和ADC之间搭起一个通道。 　　在DSP要求读取数据时，CPLD将DSP过来的IOSTROBE作为A/D芯片的RD信号，同时对I/O地址总线的第3位至第5位译码产生A/D芯片的片选信号，这样只要是地址按照每次递增1的方式读取数据，就可以使得8片A/D分时片选有效，完全符合上面提到的读取数据的要求。另外，还依靠最高位地址确定CPLD到DSP的数据输出总线是否定义成高阻态来避免总线冲突。 　　由于A/D芯片是采用5V供电的，所以其输出高电平将高于DSP输入高电平所能承受的范围。解决这个总是的方法之一是采用降压芯片（比如LVT系列）用3.3V供电，3.3V供电可以承受5V的输入，同时输出也和3.3V兼容，但是这种方法需要单独外接几片LVT芯片，占据宝贵的PCB板空间；方法之二是给CPLD芯片提供双电源，其中提供给I/O脚的电源为3.3V，此时输入电压可以和5V及3.3V系统兼容，同时电平可以达到3.3V，符合A/D芯片高电平最低电压2.4V的要求。所以，数据总线通过CPLD到DSP实际上是因为电平转换的需要。 　　 2.3 DSP处理模块 　　DSP处理模块在硬件电路上是非常简单的，主要由一片DSP芯片、一片EEPROm以及一片介于这两者之间的用作电平转换的LVT系列的芯片组成。 　　DSP通过地址总线可以区分访问的模拟通道的标号。需要注意的是：由于采用的A/D芯片是通过对RD脉冲信号计数来确定访问的是同一片芯片内部4路中的哪一路，所以实际上地址总线的低两位是没有选择功能的，对一片A/D芯片访问时，最后两位地址一定要从00开始递增到11，否则所读取的数据就是乱的。例如，转换完成后的DSP若想越过前两个通道来获得第3个通道的数据，它必须给出两个读取I/O端口的指令，紧接着这两个指令后的读取端口指令才可以获得3个通道的有效数据。 　　当然，可以通过CPLD首先将所有转换完成的数据缓存下来，然后分析I/O地址来将对应的通道的数据浮现到数据总线上。这样做使得DSP可以自由地选择需要访问的通道，但需要比较大的缓存，利用CPLD作缓存是非常不经济的。 　　 3 仿真和调试 　　本系统的软件开发主要包括两部分，一是DSP读取I/O口的程序，二是CPLD的时序控制程序。前一程序的开发采用的是TI公司的CCS开发环境，并且利用DSP内部的BOOTLOADER在起电时将存储在外挂EPROM中的程序装载进DSP的程序空间。而后一程序的开发采用的是ALTERA公司的MAXPLUSII，利用这个环境，完成了程序的编制、仿真以及时序分析，并在找出关键路径的基础上优化了整个芯片的内部延时。 　　在调试的过程中，利用DSP提供的JTAG接口实时地观察采集进来的数据。当对32路模拟通道分别提供不同频率的正弦信号时，可以看到相对应的通道的数字信号也按照固定的频率来变化，并且各个通路不存在串扰的情况。经过测试获得本系统的各种参数如下： 　　单路模拟信号采样率：5kHz 　　系统模拟信号采样率：50kHz×32=1.6MHz 　　单个采样点读取时间：80ns(受ADC芯片的限制) 　　DSP(5402)单指令周期：10ns 　　DSP读取数据占用资源：((80÷10）×1.6×10 6）÷10 6=12.8mips 　　CPLD使用I/O口：48 　　CPLD使用Logic cells：80 　　由此说明这样一个系统达到1.6MHz的采样率时工作是稳定可靠的。 　　本系统的设计思想和方法不仅适用于多路数据采集，而且能有效地扩展DSP访问外设的能力。实践证明，这种系统在成本控制、可扩展性以及资源利用效率上都有非常大的提高。

世界上很少有什么项目能给嵌入式固件开发人员提供足够多的开发时间。事实上，嵌入式固件开发就好像气体一样，会占据它所在的整个空间。而这往往意味着项目结束阶段的测试和质量评估承受压力，进而提高风险。项目经理为如何跟上项目计划进度发愁，嵌入式设计人员和测试工程师也面临开发时间和测试覆盖质量之间的矛盾。要是所有人都能实现自己的目标该多好。要是硬件设计能在代码完成前就进一步推进该多好。要是固件测试在生产构造阶段也能继续进行该多好。要是整个团队都能明确如果设计情况不好，他们总是能够通过现场升级实现重大修改该多好。这样，所有人晚上都能睡个安稳觉，而通过适当利用嵌入式引导加载程序(bootloader)，这完全有可能实现。 首先我们先明确一下有关术语。引导加载程序是一段常驻微处理器中的代码，有时也位于只读存储器（ROM）中（在工厂制造时编写）或者位于板载闪存存储器的预留区域。可加载引导代码能载入内存并作为正常工作期间在微处理器上运行的主应用代码。可加载引导代码可通过引导加载程序更新。产品固件的现场升级正是通过板载引导加载程序实现的。 那么，什么是引导加载程序呢？引导加载程序就是位于给定微控制器上受保护程序存储器中的一部分代码。它通常是加电启动或重启后运行的第一个软件，往往针对具体处理器和电路板。引导加载程序可视为一种“笨”代码，因为它并不了解需要执行什么应用，甚至也不了解器件功能是什么。引导加载程序专门用来理解如果通过任意数量的通讯协议与外部进行通讯（这些协议包括UART、I 2 C、SPI、CAN、以太网等），也可用来了解微控制器的存储器映射。引导加载程序在发挥作用时，负责与外部或主机进行通讯；读取主机发送的数据文件；更新它所在的微处理器，从而运行所提供的最新应用代码。 图1：典型的嵌入式硬件架构。 引导加载程序可以在接收到人工操作员（也就是手动重启）或外设设备（即系统主机）的启动信号后开始工作，视具体嵌入式系统而定。引导加载程序信号首先确认引导加载程序本身是否有效，明确当前器件应用是否有效，与主机通讯并载入提交的新应用，随后根据指令执行应用闪存重写。大多数现代微控制器都能对自己的闪存重新编程。典型的引导加载程序在几微秒内就能完成这一工作。不过，存储器尺寸较大情况下，该时间就会大幅延长，有时甚至要花几秒钟才能完成一次更新。一旦完成加载引导，引导加载程序必须确认加载引导镜像，并将控制权交给加载引导代码。用于中断矢量的指针也必须进行设置。典型情况下，引导加载程序将进行软重启，以便让应用掌握控制。图2给出了引导加载程序的逻辑流程实例。 图2：引导加载程序的逻辑流程。 由于引导加载程序是在制造过程中被编程到器件中，并且不是器件工作所必需的首要应用，因此实际上可以把它看作是“开销”代码。项目经理和嵌入式设计人员必须要考虑引导加载程序所带来的风险保护功能与其所占用的代码空间相比是否值得。由于这段代码要占用空间，许多设计人员需要尽可能减小引导加载程序的存储器占用量，从而将用于应用代码的存储器空间实现最大化。引导加载程序至少应提供：通讯通道、擦写并重新编程闪存存储器的方法以及确认和执行新应用代码的方法。 此外，引导加载程序应该能够检测、报告和处理加载引导操作过程中出现的错误，如断电、通讯损失、闪存写入错误等。一般通过存储应用的校验和或循环冗余代码（CRC）来实现闪存错误保护功能。加载引导操作开始后，这些位就会被清空。如果新的应用成功下载并安装，校验和就会被更新。如果下载过程中出错（通讯损失、断电等），那么引导加载程序会检测无效的校验位，且不会开始应用操作，而是与主机通讯，等待有效的加载引导操作。 《电子设计技术》网站版权所有，谢绝转载 还有一个重要的加载引导考虑因素，那就是避免代码本身覆盖引导加载程序所在的区域。如果引导加载程序尝试或无意中确实覆盖了自身，并出现了某种错误事件，那么引导加载程序会无法工作。下次处理器启动时，引导加载程序很可能会损坏。这种情况造成的影响可能有不同反映。引导加载程序可能无法打开到主机的通讯通道，或者系统可能无法将控制权交给上次有效的加载引导镜像。不管是什么情况，结果都需要对整个系统进行再编程。再编程通常需要由合格的技术人员利用可插入板上的开发工具来完成。这可能会影响人们对引导加载程序的兴趣。开发引导加载程序时，必须对器件存储器位置进行适当的控制，特别要注意确保存储器位置得到妥善管理，同时应用大小的变化不会错误地擦写或重写引导加载程序的存储区域。为了避免潜在的重写问题，某些微控制器甚至把引导加载程序放到硬编码的加载引导只读存储器（ROM）中，实现与闪存相分离，如图3所示。 下图显示了四个存储器空间实例。最左边的图是正常的非引导加载程序应用程序，典型的工具链将把应用代码放在地址0上，整个闪存存储器阵列都能作为应用代码空间。如果这种类型的系统作为发布产品进行实地使用，将无法实现远程修改。重启后，应用代码将开始执行。应用代码中的任何问题或瑕疵都将是永久性的。 图3：引导加载程序和应用位置的存储器映射实例。 中间靠左的引导加载程序具备在ROM中存储的可加载引导镜像。这种配置能让全部闪存空间为应用所用，因为引导加载程序位于单独的ROM存储器中。这种方式能避免引导加载程序被错误地覆盖。不过，这种方法也无法对引导加载程序进行更新。ROM只能写入一次，如果发现瑕疵将无法再编程或修改。 中间靠右侧的图片中，引导加载程序位于地址0，重启后首先运行。一旦引导加载程序确定了可加载引导镜像有效，而且主机也没有发出对该部分进行重新镜像的命令，引导加载程序就会把控制权交给可加载引导应用。我们可以看到可加载引导镜像紧邻引导加载程序镜像结束的位置。这样能将用于可加载引导镜像的存储器空间实现最大化。在最后的镜像图中，有两部分存储器用于两种不同的加载引导事件。这种情况下，引导加载程序会根据主机要求决定在不同的启动操作下运行哪个应用。这种方法会占用双倍的闪存空间，因为它需要保存两个完整的应用程序，但它也是一种高效的设计方法，有助于工程师让单一器件在不同的主机指令条件下运行不同的工作。 《电子设计技术》网站版权所有，谢绝转载 引导加载程序最明显的优势就在于能现场解决故障。产品也能在功能升级方面受益。举例来说，我们知道客户会推出一些只提供基本功能的产品，以便加快投放市场的速度，随后再发布加载引导更新来升级操作系统驱动程序、产品功能和电源管理选项等。引导加载程序能够让设计团队在产品投放市场的同时制定未来硬件更新路线图。再举例来说，一些公司用无线电链路进行通讯，以实现设备的远程监控。这些公司发现通过无线电链路进行设备升级比让技术人员到远程站点更新固件的成本更低。可以设想一下在卡车运输领域对整个车队进行管理的情况。为代码升级改进这种小事就让一辆卡车暂停运输服务，那成本太高了。仅仅进行代码现场升级的成本就高达好几百美元。远程加载引导对需要现场更新的产品来说具有极大价值。 那么什么样的引导加载程序才是好的引导加载程序呢？这个问题会有很多答案，不过一个重要要求就是易用性。引导加载程序要能让设计人员方便地选择和连接到串行通讯端口，这非常重要。此外，要能通过简单的方法进入引导加载程序或绕开引导加载程序直接访问应用，这也非常重要。一旦创建出来，可加载引导镜像就依赖于引导加载程序。明确引导加载程序镜像在哪里结束以及应用从哪里开始，该过程非常繁琐且容易出错。好的引导加载程序应该可以自动解决这些问题，同时还要让设计人员灵活地使用多个应用镜像。可以实现双加载引导的系统有时被称为多应用引导加载程序。这种类型的引导加载程序会把新镜像载入到存储器中不同的区域。一旦确认，引导加载程序可能会复制新镜像以替代原有应用，或者直接执行新镜像。 下面看看赛普拉斯是如何在其PSoC3和PSoC5LP系列产品中支持引导加载程序的吧。如下图所示，通过下拉菜单选择通讯组件。可以设置用于进入引导加载程序的“命令等待”时间（图中为2秒）。设计人员还能选择校验和类型，这也非常方便。 图4：赛普拉斯引导加载程序配置工具。 在可加载引导侧提供识别版本修订的数字信息，这样固件就能自动确定新的可加载引导镜像是否已过期。图4显示出设计人员如何灵活地指定应用版本和ID。此外，设计人员还能手动将应用镜像移动到所需的存储器地址。最后要注意的一大关键问题就是存储器覆盖风险。工具链可自动确定引导加载程序结束和应用开始的地址，这样就能消除风险。由于使用引导加载程序的根本目的就是在战略上规避风险，因此这个功能的采用非常重要。 如果所有项目都按时进行，所有代码都完美，所有固件工程师都在硬件构造之前完成了代码，那么就无需使用引导加载程序了。但如果您与所有其他人一样处在现实世界中，那么您所在机构开发的任何嵌入式系统在采用引导加载程序后都会受益匪浅。引导加载程序能让产品在发布之后进行更新，实现灾难问题修复以及产品预订特性升级等不同需求。加载引导的主要问题在于必须考虑引导加载程序本身的灵活性和易用性，还有引导加载程序所使用的代码空间和配置。不过说到底，设计良好的引导加载程序可以挽救您的产品，挽救您的团队，帮您排忧解难。 《电子设计技术》网站版权所有，谢绝转载

实在纠结,这是写的第三遍了,第一次是上传附件时网站说什么系统错误写的全没了,第二次是自己不小心碰了下鼠标也没了,这次是在WORD里写的,看它还会不会不见!   现在大部分单片机都支持BootLoader功能,BootLoader从字面上解释就是引导程序,也就是像电脑开机后一样,电脑也会给出进入BootLoader选项.在单片机复位后,单片机并不是直接就进入了应用程序存储区,而是先进入BootLoader区,在跳转到应用程序存储区.现在的单片机支持BootLoader的方式也有所不同,有的是出厂前就已经将BootLoader程序固化到了MCU内部,有的是在单片机的程序存储区内划分了一块区域专门用来存储BootLoader程序,方便用户自行开发适合自己的BootLoader程序,如AVR,而有的单片机既不事先固化BootLoader程序,也不在程序存储区内划分一块区域专门用来存储BootLoader程序,但是单片机的结构却允许使用其它的方式来模拟实现Boot区,如MicroChip公司的PIC系列单片机.三种方式相比之下,第三种开发起来难度最大,开发者要对单片机的程序存储区的结构具有很深的了解,不适合初学者学习.   其实BootLoader早就出现在我们的单片机学习道路中.举个例子,大学时学习51单片机时大部分人会购买51的学习板进行学习,但是很少会有人去购买专用的编程器进行程序下载,那当初我们是怎样将应用程序下载到单片机内部的呢?我记得大学时我也买过一块51学习板,当初卖家就给了一个好像叫做ISP的上位机软件(具体软件名字记不太清了)进行程序的烧入,我们只需要将编译后的hex文件通过此软件利用电脑的串口就能很快的将程序烧入单片机内部.那这是为什么我们能直接的将应用程序通过上位机软件和串口下载到MCU内部呢?而有的单片机却需要购买专用的编程器才能将应用程序烧写进去,这就是BootLoader的功劳,记得当初51学习板上的单片机是STC公司的增强型51单片机,它最大的特点就是在其内部将BootLoader程序已经固化好了,用户是不能进行访问和修改的,这样就方便了用户不用自己开发就能将应用程序很快的下载到单片机内部,但是通过上位机将应用程序烧写到单片机时有一个步骤不知道大家还记不记得就是每次烧写程序时都要事先将单片机断电在上电才能将应用程序烧写进去,而且有时还会出现,如果断电上电 的时间不是很及时还会出现应用程序也无法烧入进去,为什么要先断电在上电呢?这在后面将会提到.将BootLoader程序固化到单片机内部虽然方便了用户不用用户在去开发BootLoader,但是它不好的一面就是不能进行代码的保密,无法通过BootLoader进行加密.说到这里,大家是否对BootLoader有点印象了呢!   BootLoader到底有什么功能呢? 它的功能实在是太多了,大家可以上网查询一下.在此向大家推荐一本好书,此书是以AVR单片机为切入点,以在单片机开发过程中出现的问题为专题进行讲解,读者能很快的用到其它的单片机上,此书面向的读者是具有一定开发工作经验的单片机开发工程师.应用专题精讲   在此说说 BootLoader几个显著的功能 ,应用专题精讲 第一:方便下载,更新程序.在使用时我们只需在使用一次编程器将BootLoader程序下载到MCU内部,以后的下载更新就直接使用上位机软件就能简单的将应用程序下载到单片机内部,假设我们已经将产品称交给用户,如果我们想升级程序,只需要将应用程序的hex文件给用户,让用户通过简单的上位机软件就能进行下载,方便了用户和自己,同样也增加了程序的保密性.应用专题精讲 第二:程序的保密性.使用BootLoader我们只需要使用应用程序的HEX文件就能更新应用程序,并且还可在此hex文件中进行加密操作,加密的算法很多,具体的我也没有使用过,相关的资料大家可以上网查询.应用专题精讲 第三:下载的方法很多,例如有UART,CAN,SOFTWARE UART,SPI,I2C等等,因为我们电脑大多是带有RS232接口,所以用的最多的还是UART.应用专题精讲 应用专题精讲     应用专题精讲 单片机应用专题精讲 关于PIC单片机的BootLoader它就是属于上述的第三种方式,即单片机内部没有固化的BootLoader程序,也没有在Flash内专门留出一块内存区用来存放BootLoader程序,只能用户自己通过软件模拟的方式来实现Boot区的划分.BootLoader在PIC单片机内的工作原理是当单片机上电后,MCU不是立即的运行到用户应用程序区,而是先运行Boot区中的BootLoader程序,在BootLoader程序中我们会设置一个时间上限,如果在这个时间内收到了来自于PC机串口发出的程序指令字节,那么MCU就开始进行接收PC机发出的这些命令字节并将其存储在相应的Flash区,接收完成后MCU就跳转到这一区域开始运行新的用户应用程序,如果在这一时间上限内没有收到PC机发出的相关命令字节,则当时间到后,MCU依旧会运行到相应的用户应用程序区,只不过这时运行的还是上次的程序,并没有实现对程序进行升级处理,说到这里肯定有人会想MCU怎么知道是不是接收完成 或者在接收过程中是否出现了错误呢,对于是在上位机端的程序就要求对发出的命令字节进行校验,常用的校验方法有CRC检验,和检验等等.关于PIC单片BootLoader程序在网上的资源不是很多,但在官网上还是能找到相关的应用笔记,MicroChip提供的模拟Boot区的方法是在应用程序存储区的第一页 留出Boot区,将相关的中断向量表向后移,这种方法难度较大,因为要对编译器本身提供的.gld文件进行修改, 一旦出错后果严重.并且还会造成FLASH资源的浪费.而在国外的一个开源组织上,它们采用的方法是将Boot区划分在应用程序存储区的最后一页,这样就不需要对单片机的FLASH进行重新的划分,不用修改其链接脚本文件就能进行移植,相关的网站和相关的移植程序在最后列出,在移植过程中要注意对从Boot区跳转到应用程序存储区的时间设置,不要设的太短,不然的话会出现你还没来得及将新的应用程序下载到MCU内部,MCU就运行到应用程序区了,这样你将无法进行第二次下载以及后续的下载也无法进行.注意接下来升级程序时,采用的是和上面说过的51类似的方式,即要让单片机进行复位,这也就是为什么说利用上位机下载程序到51单片机时,也要让它重新上下电,原因在于上下电后,单片机产生复位,单片机重新开始运行又从Boot区开始运行,这时你将应用程序进行烧写,才能将程序烧写进去,不然的话,如果你直接的通过上位机将 应用程序下载到MCU内部,是无法成功的,因为MCU一直在运行应用程序区不会去运行Boot区,你就无法升级程序,如果不想通过不断的上下电来进行处理,还有一种方式就是你在应用程序中放置一条goto指令,让应用程序定期的去运行Boot区,这样你就有机会下载程序,但感觉这种方式还没有直接上下电或者是利用复位按键好.     PIC BootLoader网站:http://mrmackey.no-ip.org/elektronik/ds30loader/                                    

       我的主要关注点是linux内核和驱动和bootloader。在将来的一段日子里，我会不定期的就以上几点写一些东西，以和大家共同探讨。         linux的真谛在于开放和共享。我辈为人，不光要有能力，更要有让能力传承下去的能力。这是我钦佩Linus的地方。望与大家共勉。