请教一下，使用PICC如何自己重定位程序在flash中的位置？

joylight

主要是想在PIC16F886上实现bootloader，但不知道应该如何实现程序位置的定位。

小弟对PICC编译的过程理解不深，猜测是不是只要更改PICC的某个文件，就可以自行规定LINKER的行为？

请教有经验的朋友，究竟应该如何操作，谢谢

joylight

自己顶一个

要是PIC分论坛和AVR分论坛一样火该多好啊

cheungman

方法是在MPLAB IDE中，从菜单中选择Project->Build Options...->Project，在PICC-18 Linker页标下的Specify offset for ROM（ROM代码偏移量）中输入偏移量XXX（注意这里输入的已经是16进制了，不用在转换）。

重新编译,然后在View->Program Memory就可以看到你的程序已经定位在XXX起始的地址上了.

joylight

多谢cheungman，再请教一下

PICC18可以向下兼容PIC16的设计吗？

那个Specify offset for ROM是针对一个工程而言吧？
是不是应该创建两个工程分别编写功能程序和引导程序，然后要怎么做？分别将两个工程编译成两个.hex文件，然后手工合为一个.hex文件？
能不能通过链接器将所有的.obj文件链接生成一个.hex文件？（不过好像每一个源文件都会生成一个对应的.obj文件，不知这样操作是否可行）

如果手工将两个.hex合成一个.hex文件，还涉及到一个问题是，0000-0003地址的程序会跳转到哪里？（0004是中断向量）功能程序和引导程序分为两个project，各自编译后跳转的地址肯定不一样。0000-0003的跳转程序要在什么地方更改？

cheungman

希望这个对你有点启发,我在21IC跟一网友的讨论.
http://bbs.21ic.com/club/bbs/list.asp?boardid=27&page=2&t=2978728&tp=%u60F3%u505A%u4E00%u4E2A%u7A0B%u5E8F%u53EF%u4EE5%u66F4%u65B0%u7684%u7A0B%u5E8F

PICC18可以向下兼容PIC16的设计吗？
答:不好意思,这个我不清楚,才接触PIC才两个月.

那个Specify offset for ROM是针对一个工程而言吧？
答:是的.

是不是应该创建两个工程分别编写功能程序和引导程序，然后要怎么做？
答:是的,可看链接上的例子,你应该会明白bootloaser是怎么一回事.

分别将两个工程编译成两个.hex文件，然后手工合为一个.hex文件？
答:可以,你可以先了解hex的格式.hex码表达的意思是指某地址上储存的数据(数
据就是程序编译后生成的MCU可执行的机器码),那么引导程序生成的数据位于
0x000-0x4ff地址上,功能程序位于0x500-0x1000地址上,然后我们把两者是可以合
并在一起,即把位于0x500-0x1000地址上数据插入到引导程序的hex文件中,生成一
个hex文件,再通过ICD2直接把这个合并后的hex文件烧写进去.已测试过,绝非乱说
,有空为这个主题写篇blog给大家拍拍砖.

能不能通过链接器将所有的.obj文件链接生成一个.hex文件？（不过好像每一个
源文件都会生成一个对应的.obj文件，不知这样操作是否可行）
答:你可以先了解一下链接器的功能.

如果手工将两个.hex合成一个.hex文件，还涉及到一个问题是，0000-0003地址的
程序会跳转到哪里？（0004是中断向量）功能程序和引导程序分为两个project，
各自编译后跳转的地址肯定不一样。0000-0003的跳转程序要在什么地方更改？
答:我们可以重新设置功能程序的中断向量,具体可看链接上说的;
复位向量也可以自己定义,用软跳转的办法,即(*((void(*)(void))Address))();
引导程序不要使用中断,仅采取查询方式.

joylight

多谢cheungman，太热心了

我先仔细拜读一下您的大作，消化吸收之后，再请教

cheungman

这个链接是讲述如何解决这个问题的:"是不是应该创建两个工程分别编写功能程序和引导程序，然后要怎么做？分别将两个工程编译成两个.hex文件，然后手工合为一个.hex文件？"

http://blog.ednchina.com/cheungman/124567/message.aspx

joylight

仔细看了您写的方法，但是遇到了一个问题

我写的程序代码4K多一点，用PICC9.5编译后，发现生成的.hex文件不是从头到尾排列的，而是中间空了两块没有程序。

这就很郁闷了，如果我想将两个.hex文件合起来（功能程序和引导程序分别形成一个project编译，再将两个.hex文件手工合起来），那就需要有一块连续的没有写程序的flash。但是现在整个flash空间好像都有代码，而不是将代码从flash的0000位置顺序往下排。请问应该如何处理？

默认情况下PICC编译是如何定位代码在flash中的位置的？有特殊的文件指示编译器如何动作吗？

joylight

即使不手工合成.hex文件，用引导的方式，也需要有一块空的flash用来存放更新后的程序。
但程序一大了，程序在flash中的定位就感觉“乱了”。

joylight

今天在Mplab-view-program memory看到了汇编代码，最后面确实都是0x3FF，但.hex文件为什么从头到尾都有内容呢？

joylight

.hex文件应该是搞错了，新情况如下：

1、功能程序无偏移时，从0x0000开始可以正常运行。说明功能程序没有问题，也不存在运行过程中堆栈溢出的问题。
2、引导程序，代码如下，跳转和中断重定位经过测试都是正常的。
3、引导程序+功能程序（分别编译，生成两个.hex文件，手工合成后下载），其中功能程序编译时偏移到0x1000，开始功能程序还能运行一段，一旦使能定时器中断，程序就好像复位了，又从头执行。
难道是新增的引导程序加重了堆栈的负担？但引导的代码中也没有CALL和中断啊，应该不会触发压栈啊。



0x0000-0xFFF的代码如下：
0000  MOVLW 0
0001  MOVWF 0xa
0002  GOTO 0x7
0003
0004  BSF 0xa,0x4
0005  BCF 0xa,0x3
0006  GOTO 0x4
0007  BCF 0xa,0x4
0008  BCF 0xa,0x3
0009  GOTO 0x7f9
.
空白
.
07F9  BSF 0xa,0x4
07FA  BCF 0xa,0x3
07FB  GOTO 0
07FC  CLRF 0x3
07FD  BCF 0xa,0x4
07FE  BCF 0xa,0x3
07FF  GOTO 0
.
空白
.
1000  功能程序