I want to write some code to be loaded into a PIC16F1459 using Matt Sarnoff's USB-based bootloader, which you can read about here:
https://github.com/74hc595/PIC16F1-USB-Bootloader

I use the Mikroelectronica compiler, but it seems to me that MikroC doesn't give the user the flexibility to do this. What the bootloader requires is:
- User's code must start execution from address 0x200 (but has to be a jump).
- There must be a single word at address 0x202, containing a RETLW instruction with a data byte which informs the bootloader how much current the user's application needs from the USB connection, or whether it's self-powered.
- Interrupts must begin execution from 0x204.

At first I thought I could use the #pragma orgall directive (the instructions even use 0x200 as an example) but that doesn't do everything I need. The compiler always seems to produce code starting at address 0, and from there it jumps to an address that skips the interrupt code, like this:

;Address Opcode    ASM
0x0000   0x2A40         GOTO       576
0x0001   0x0000         NOP
0x0002   0x0000         NOP
0x0003   0x0000         NOP
0x0004   0x3180         MOVLP      0
0x0005   0x2A04         GOTO       516
_pjump:
;Trybootl.c,22 ::      void pjump(void) org 0x200
;Trybootll.c,24 ::      asm goto 576
0x0200   0x2A40         GOTO       576
;Trybootl.c,25 ::      }
L_end_pjump:
0x0201   0x0008         RETURN
; end of _pjump
_app_power:
;Trybootl.c,27 ::      void app_power(void) org 0x202
;Trybootl.c,29 ::      asm retlw 0x33
0x0202   0x3433         RETLW      51
;Trybootl.c,30 ::      }
L_end_app_power:
0x0203   0x0008         RETURN
; end of _app_power
_interrupt:
;Trybootl.c,32 ::      void interrupt(void) org 0x204
                              // My interrupt routine, ends at 575

The initial jump, GOTO 576, gets around my interrupt routine, but I needed to place a GOTO instruction at 512 (0x200), and I did it manually with the routine pjumip, based on knowing where the jump would be going to. It involves an extra RETURN line, but that's harmless. Also of course, I don't want any code below address 0x200 at all, and I can't see how to tell the compiler not to produce it. The word at 0x202 is dealt with by the single-line function app_power, again with a harmless RETURN added by the compiler. None of this seems like the right way to do it.

I'm wondering if anyone who uses a different compiler might know if there's another way I could get this working. The bootloader seems like such a fine thing to have that I'm frustrated to be held up by the compiler!

Edited to say that Matt Sarnoff offers an example application, which he compiled for his bootloader using the open-source SDCC (Small Device C Compiler). I suppose I have to get it and try to make it work (sigh).

 

When I was working on a bootloader for the PIC32 using C32 a few years ago the hardest thing to do was to write the linker scripts to wedge the code into the slots I had available. (The easy part was reading the code out of an SD card.) I found few documents or tutorials on writing these scripts and mostly bluffed my way thru by trial and error. Several days of error.

Then the compiler got revised and the scripts changed. Oisch.

The MikroC compiler is designed to hide the hard parts of C from beginners, such as the PIC include file (which it uses but hides behind the scenes). The good news is they do include a bootloader example in their package you may be able to either use or adapt.

 

I have to say:

The most brutally difficult embedded programming task is getting bootloaders to work right.
Lost more hair over this than anything else.

Beware.

 

Having written a bootloader a while ago--yes, it worked--I do understand that it's a complicated thing to do. But in this case what I'm trying to do is write application code that works with someone else's bootloader. I'm already a bit discouraged by having to make special arrangements in the code to fit round the bootloader. I think it should be invisible to the user!

Ernie, I have looked at what Mikroelectronika has to say about a bootloader, but it doesn't seem very useful.Certainly nothing about how to shift the startup and interrupt vectors.