Bootloader for 16f87/88 that doesn't use UART

[mister_e]

i'll second the .HEX. Anyways.. what's the point of .BIN file while none of the assembler i know generate it anyway

[bcd]

Wow ! What have I started !

dhouston - i was aiming to take the freeware delphi source from the PIC_E project, as I hate the way VB projects seem to bloat. But looking into the source it has a checksum and some other funky stuff I don't think we need. It has also been a long time since I did any delphi stuff and I might be out of my depth. Is PureBasic a good coding app - I have never heard of it before.

mister_e - agreed .hex is the way to go. F10 in MCS to the unit. Hmmm - there is a thought - can we pass command line options to it for the name of the hex file ??

i have been thinking about other thinks that would be good and I am looking into the ability to also write the internal EEPROM. I have disected the INTEL HEX format and worked out which data points to which locations and it looks like it should be quite easy (famous last words...)

bill.

[dhouston]

Is PureBasic a good coding app - I have never heard of it before.

It's excellent. It's inexpensive. It's cross-platform. It compiles to teensy-weensy standalone executables. It's been a well kept secret. Here's the homepage - http://www.purebasic.com/

If you can supply easy to understand documentation, I'm willing to code the interface apps.

[bcd]

Hi Guys,

based on what I found in http://www.picbasic.co.uk/forum/showthread.php?t=4498 I set about modifying the PBPPIC14.LIB to move the library functions out of the low memory so we don't overwrite them when we upload a new programme. I was getting compilation errors about not being able to move the librarys off page 0, but commented out the warning section to see what happened.

Well the answer was - nothing. The programme appeared to not start (I have some LEDs to give me status). I set the library to start at 800 using a custom Make_Loader define that I had in my BL program and it works again.

Custom Define definition from PBPPIC14.LIB
<code>
ifdef MAKE_LOADER ; Added by Bill Coghill 08.01.08
LIST
ORG 800 ; Keep the library code out the way
NOLIST ; was 3584, but would then not work
endif
</code>

So it looks like we can't move the PBP libary files out of page 0 which means that we either need to see if we can jump over them with an ORG 128 (or similar - remember we can only erase blocks of 64 words).

What I need to do is see how big the PBP libraries are when I use an ORG to move the actual program code to high memory.

I wonder if only the Librarys that are used are compiled in ? That would mean if I was to use the bootloader with a skip over the libraries to upload a file that didn't use a library that the Bootloader needed that the next time you tried to go to bootloader mode it would hang the chip.

Just did a quick test and it seems that 153 words are needed for the library functions. But more testing reveals that PBP compiles in the Libs it needs, meaning that the value for the libs may change according to the commands used.

Oh dear and it was all going so well. I need to think about where we can go now.

We might end up loosing a lot of space as a skip at the beginning for the Libraries and 400 words for the BL at the end !!

bill.

[Jumper]

Well,

http://www.picbasic.co.uk/forum/showthread.php?t=4498 works.. but the hack you tried doesnt. The only way I have gotten this to work is to (as stated later in the thread)

ifdef LOADER_USED
LIST
ORG 60160 ; Own loader address depending how big loader you write
NOLIST
endif

And if you first write your bootloader and then you can change the address from where it starts to allocate just as much memory as it needs. By putting the bootloader last in the program space you also get less trouble with interupt vectors if you are using a 18-pic with high and low priority interupts. This is an ugly hack and dont forget to change back these things when you plan to compile your normal software.

/me

[bcd]

Jumper,

It seems the 16 series pics are different in how the libraries are assigned in memory space. I am going to look further in to it, but will try to mod the LOADER_USED jump as suggested.

stay tuned..

bill.

[bcd]

Well I did a bit more digging and talked to Jeff at MELabs.

This is what he told me :
<quote>
Jeff Schmoyer wrote:
Hello,

The problem is that you really can't do that. For the 14-bit
core parts, the library must be at the bottom of memory. The
bootloader has to be a completely separate program, including
its own library. This really isn't practical for a 14-bit
core part.

We did make a change for the PIC18 parts to allow the reset
location to be changed. This allows you to move the library
and the entire program up to higher memory. When you
boot load in a new program, it fills in at the bottom as
usual, with the bootloader and its library still up high.

For the 14-bit core parts, you will need to create an
assembler boot loader that does what you want, or modify
one of the many that are already out there.

To write one in PBP, you will need to move to a PIC18 part.

Thank you,
Jeff Schmoyer
microEngineering Labs, Inc.
</quote>

So it looks like it is back to reverse engineering other peoples ASM code to make it run in the 16F87. I am now going to look at the WLoader ASM and see how 'portable' it is to the 16F8x series.

Stay tuned...

bill.

[Charles Linquis]

This might be a silly question, but why not move to 18F parts and solve the problem that way?