pic18单片机在BootLoader中的应用

较合适。?

　　④ 增加了编程响应。在每成功接收到一行HEX数据后，发出一个回应字节，用于编程时的错误检测。PC端的下载程序可以根据这个字节来判断下载过程中是否出错。?

　　⑤ 针对上面3（1）中③的问题，可以这样解决。将编译后的HEX文件手工稍作修改，将0x200～0x220（假设用户程序是从0x200开始的）地址段的数据从文件的开头移动到文件的结尾。这样0x200处的代码会在最后才写入单片机中。如果写入过程中出现故障，复位后即使BootLoader启动了用户程序，也会因为这段区域没有代码而重新复位，而不会去运行部分被写入的用户程序。不过这种方法需要对HEX文件的结构有一定的了解才行。

　　一个简单判断HEX数据地址的方法是，HEX文件的每一行第一个字符是冒号"："，冒号后的第3、4、5、6这四个数字就表示这一行数据的地址，是以十六进制表示的。如："：100200.。。"就表示地址是0x200。在正常情况下，编译后的HEX文件数据是地址从低到高的顺序排列的。?

　　改进后的程序增加了一部分参数，它们是：?

　　BOOT_SIGNAL——使用单片机引脚电平触发方式进入BootLoader；?

　　BOOT_SIGNAL_PORT——定义电平触发启动方式检测用的引脚；?

　　BOOT_SIGNAL_LEVEL——定义检测电平1=高电平触发，0=低电平触发；?

　　BOOT_TIME_DELAY——使用超时方式进入BootLoader，这个参数和上面的BOOT_SIGNAL不能同时?使用；??

　　USE_EXTEND_HEX——是否接收扩展的HEX代码，不使用可以节省代码，建议不用；?

　　USEWDT——是否在BootLoader中使用看门狗，建议使用；?

　　CONFIRM_TIME——联机同步字节数，在超时方式中使用多字节进行同步；?

　　CONFIRM_DATA——用户可定义的联机数据；?

　　USE_ECHOBACK——编程时是否回应，使用可以增加下载时的安全性，建议使用。

　　使用了BOOT_SIGNAL方式后，与超时方式相关的部分都不再起作用。这时可以定义使用任意引脚来判定是否需要进入BootLoader。在使用BOOT_TIME_DELAY（超时方式）时，增加了一些与之相关的内容，如CONFIRM_DATA，可以使用任何特定的字符串来确认是否需要进入BootLoader状态，增加了BootLoader程序的安全性，避免受到干扰而误进入程序升级状态。?

　　（3） 其他改进的建议和方法

　　① HI-TECH的BootLoader程序接收的是标准的HEX文件。这在很多时候是不够安全的，不利于程序的加密，容易被反汇编和破解。可以对HEX进行加密处理，变成不能直接查看的数据。?

　　② 使用超级终端进行程序下载速度比较慢，同时，如果下载中出现错误，超级终端程序不能及时发现停止下来，而是一直把文件发送完才能停下来。这时BootLoader程序会反复进入BootLoader状态，对单片机有一定的损伤。最好是自行编写一个计算机端的专用下载程序，不但可以提高下载的速度，也可以提高下载的成功率。?

　　③ 使用RS422/485方式。有些时候，使用的并不是RS232串口，而是RS422/RS485串口。它们实际是类似的，只是在接口方式上有些区别。RS422/RS485需要控制发送，所以在BootLoader程序中增加一个发送控制就可以了。?

　　④ 在BootLoader中，将波特率设置得很高并没有太大的用处，它并不能够提高下载整体的速度，而只能加快数据传输的速度。因为整个下载分为数据通信（数据传输）和Flash写入/擦除（数据等待）两个部分。程序代码Flash空间的擦除和写入速度是比较慢的（典型值是3～?4 ms），太快了反而容易丢失数据，造成下载失败。

　　使用9600 bps的波特率时，传输1字节的数据大约是1 ms，接收一个缓冲区8字节大约需要8 ms，大于写入延时，所以不需要延时；当通信速率超过9600 bps时，接收8字节缓冲区的时间可能会小于写入时间，需要在通信中延时。实际使用的测试结果是：使用9600 bps比使用14 400 bps时慢50%，使用57 600 bps比9600 bps快一倍，而使用115 200 bps时与57 600 bps几乎没有任何区别。如果使用超级终端下载，就更没有必要设置高波特率了。因为在使用最常用的三线方式通信时（没有控制信号），超级终端采用了比较保守的方式发送数据，本身就比较慢。?

　　结语

　　一个良好的BootLoader程序应该具有良好的可维护性并可以正确处理异常情况，不会因为意外情况引起系统的损坏和崩溃。