关于8051 bootloader的一个思路 (amoBBS 阿莫电子论坛)

关于8051 bootloader的一个思路(amoBBS 阿莫电子论坛)
前一段时间做了个8051的bootloader，在C8051F340上运行，效果还可以。

基本思路如下：
1，中断向量的处理。

考虑到应用的可靠性，bootloader不应被擦除，而bootloader 和中断向量表通常都在单片机程序区的起始位置，所以中断向量表也不能变。

有些bootloader的解决方法是对主程序里的所有中断函数定位，这样做很麻烦。

我的解决的办法是，在startup.a51里，添加这样的语句
org 0003H
ljmp 3000H
org ....
ljmp .....0003H是第一个中断的入口，而3000H是主程序里的地址，在这里用一系列org、ljmp的语句全部跳到3000H 开始的连续位置。

在主程序的工程属性里，option for target->C51,Interrupt vectors at设置里，设置为0x3000。

这样，编译器就会把中断入口函数定位在3000H开始的位置。

唯一的缺点只是所有的中断会延迟一个ljmp指令的执行周期。

这样做，主程序里就不必对中断函数做特别的处理。

2，bootloader的处理流程：
首先，bootloader检查主程序是否正常。

主程序在下载的时候，会提供一个校验码，这个校验码也会保存在一个特定位置，如果发现校验码出错，则提示并进入下载模式
然后，bootloader检查有没有用户要求升级的（这个请求可以来自任何通讯接口），如果有，则进入升级模式。

如果主程序没有错误，在一定时间内也没有用户要求升级的请求，则进入主程序开始运行。

因为前面提到，中断向量表已经做了重映射，所以bootloader 里一般不使用中断。

3，主程序的处理
主程序除了第一点提到的，要对中断向量做一个重定位，还需要对入口定位，以确保bootloader顺利进入主程序。

另外，主程序需要在工程属性里设置ROM地址范围，当然，那个重映射的中断向量表，肯定要在这个范围内。

4，升级文件的处理。

我看到不少bootloader都是直接升级hex文件，PC上使用一个专门的程序来把文件传输到单片机里。

这样做不是很好。

Hex文件如果直接提供个用户，会导致程序的泄密。

另外，这样还可能导致错误的hex文件被下载进去。

我的做法是自己写一个PC端的程序，把HEX文件变成bin文件，并加上文件头和校验信息，可执行代码部分加密处理。

传输到单片机后，单片机检查文件头和校验是否正确，并对执行代码解密，写入主程序区。

5，升级文件的传输方式。

很多bootloader是用串口升级的，并且专门写了一个程序来做升级。

其实如果用串口来升级，可以使用xmodem协议，windows下自带的超级终端就有这个功能了，不需要自己单独写PC上的软件。

而且xmodem 协议本身很小，而且可靠性很高，是个不错的选择。

6，从主程序里升级系统。

不少情况下，升级系统的时候，传输文件的过程并不是在bootloader完成的，而是在主程序下完成的。

这是因为bootloader下传输文件，一般需要用户在启动设备的时候，在规定时间内快速做出动作，对用户来说并不方便；另一方面，bootloader的代码都很简单，如果遇到复杂的传输方式，例如通过网页上传，协议很复杂，在bootloader里无法完成。

但是主程序显然不能传输一个文件来覆盖自己。

我的解决方法有两种：
1，主程序不大，单片机程序存储区大。

将单片机的存储区划分一半出来，用来临时存储升级文件
2，外挂存储器，例如SPI接口的FLASH，用来暂存升级文件。

在主程序传输完成后，让系统自动复位，进入bootloader进行升级主程序的操作。

当然在这种情况下，bootloader需要增加一个检查临时存储区的动作，为了避免重复升级，升级完成后，还要擦除临时存储区。

这是我正在使用的方法，如果各位有更好的方法，欢迎提出来。