Re: Problem with libstrings.fs and the bootloader

Hi Alex,

I'm the culprit responsible for the bootloading kit.
Sorry about the trouble you've had, and thank you for putting in the 
time to investigate.

In my PicForth environment, all my progs import a site file before doing 
anything else. This site file imports picisr.fs, so I never saw the 
effect of not including picisr.fs

The easiest and cheapest workaround I can think of is to first define an 
empty word:

  : dummy ;

This will cause address 3 to have a 'return' written to it, so your 
actual words will start from address 4 and not be molested by pfd.py.

If you've got your own site include file, maybe you could put the dummy 
word there.

Bootloading necessarily involves some kludges, since the bootloader 
takes over the reset vector. In the case of PicForth versus pfd.py, 
there's a reason why I'm moving the first four words - the 16f87xA chips 
can only be flash-written in blocks of 4 words, So for convenience 
(read: programmer laziness), I'm relocating the first 4 words.

This dummy word only costs you one word of prog mem, so for the 
convenience offered by bootloader support, I'm sure it's not an 
excessive price.

Cheers
David

Alex Holden wrote:
> Alex Holden wrote:
> 
>> Using the bootloader, I get a huge amount of garbage printed out 
>> instead of the expected "Hello World\r\n".
> 
> 
> OK, after disassembling a hex file read from a chip that was programmed 
> using the bootloader and comparing it to what was expected, I've figured 
> out what the problem is.
> 
> If a program doesn't include picisr.fs, picforth starts compiling words 
> at location 3 in the program memory. pfd.py relocates the first four 
> instructions to somewhere else in program memory. In my case the first 
> word that was compiled was flash-read, which is called by str-char. The 
> upshot being that first instruction of flash-read got replaced by pfd.py 
> with a nop.
> 
> A workaround is to include picisr.fs even if you don't need it, because 
> it causes words to be compiled starting at location 4 instead of 
> location 3. Any ideas on a better way to fix this?
>