Hi all.
Theres a lot of information and ideas out there, and a lot of implementations of bootloaders that its a bit hard to make heads or tails of what exactly is the best, simplest way to do something for your own situation.
Im trying to get my head around some theory, so I'll think out loud and if anyone has some input I'd greatly appreciate it.
Im working on a project, I have an existing means of "communicating with my PIC", and have already implemented a method to send new firmware to that PIC - it gets stored in an attached EEPROM where it can be later retrieved (thanks to mikeselectricstuff for that idea).
The part Im having difficulties with is the "bootloader" bit. What I thought would be super simple for my situation would be, within the first few lines of code of the application, use the "call" instruction to enter the bootloader, which can do some quick checks to determine whether anything needs to be done (e.g. software needs to be copied out of EEPROM), and if not it can simply "return" and the main application carries on. If firmware does need to be updated, the bootloader can go about doing that, and when it is done it can perform a reset and the PIC starts up as usual.
Ive seen a lot of examples of bootloaders being placed towards the beginning of program memory, but I believe this complicates things a bit with remapped interrupt vectors, so I think placing the bootloader higher in memory is more ideal - I can just reprogram the IVT as part of the firmware update. I figure I can get away without using interrupts in the bootloader as it should only need to be incredibly simple, some loops to read EEPROM and write program flash - really, nothing fancy.
The other thing I have noticed is that, compiling a bootloader separately seems to include a lot of "initialisation code" if you will, that executes before the main program loop of the bootloader. I believe that sets up the stack and other bits of the processor. Naturally, if the entry point to the bootloader is through the main application, that will already have been done, so the bootloader doesnt really need to be much beyond the code for the bootloader itself. So how to compile the bootloader without all of that additional initialisation code?
I dont really mind doing it the other way around if need be - reset vector to the bootloader which jumps to the address of the main application code. Either works for me.
So, I guess the question is, does anyone have any thoughts about this? I realise its "yet another way to do it", and may be reinventing parts of the wheel with "yet another implementation", but Im looking for something incredibly light weight that I can get my head around. Everything else seems geared towards direct communication with UARTs etc, whereas I already have that bit sorted, and just need to work out how to execute my bootloader to do the copy and return to the application itself while cutting out a little bit of fat.
Cheers and happy new year!
Tom