i have doubt that wheather bootloader is good or bad?
if i am using any kinda of bootloader that is serial or usb so there is need to remap the vector address.
so i am confuse that whether it good for any project??
and does remapping make any affect on firmware?
which bootloader is good??

 

Boot loader is a poor mans programmer. If you have a PIC programmer (assuming you are using PIC due to your XC8 thread) stay with that. At least until you learn more about programming

 

A bootloader is an inexpensive way to program a micro, period. For hobby use it can replace the need for a programmer (as long as you can work with one chip that never burns out or gets erased). For professional use it can get a firmware update into your product without costly returns.

"Good" is too subjective a term to comment upon.

Any bootloader that works with your micro is "suitable."

 

thank you for your valueable feedback but as for bootloader vector address need to be re-map then will it affect on firmware flow. means while running firmware will it affect.

 

AN1310 describes how to implement bootloaders on PIC16 and PIC18.

EDIT: MikroC has bootloader support on the library level derived from AN732. Serial and USB are supported. If you download the free version of the compiler, you can consult the Project Manager and user's manual to see how they did it.

I haven't used them - yet.

 

I used the MikroC bootloader on their SmartGLCD product.

It worked good enough, but was quite slow compared to the proper PIC programmer, and the bootloader had no benefits (to me) so I just switched to using a proper programmer.

I think the only benefit was for people who did not own a programmer (so it was better than nothing).

 

thank you for your valueable feedback but as for bootloader vector address need to be re-map then will it affect on firmware flow. means while running firmware will it affect.

Bootloaders typically run for a few instructions as the device starts; that is when they check for the "update required" switch. If no update they toss execution to the main program and don't run again.

The main program does need some special handling as to where it resides, usually a custom linker script is all you need.

The exact process is highly device and compiler specific.

 

thank you all of you . bcoz i just looking for solution like nxp's 8051 get programmed via simple flash magic and serial cable instead of middle adds ons.

 

If you use it as an alternative to a programmer during development then it's just a poor mans programmer as other pointed out. If your application needs to be updated on the field by non-tech users then it is the only way to go. The only difference it makes on the firware is the location where it is stored in memory.

 

If you're talking about it messing with your program because it resides at the
chip's reset vector then I think it's unlikely ever a problem depending where your interrupt vector is,
and how that's handled if the bootloader is consuming that memory as well.

The only thing I can think of jumping to reset vector is actual hardware reset or reset by watchdog,
and both of those instances, timing should not be critical.

I imagine a bootloader would jump out to some other memory to avoid
consuming the interrupt location like any other program does.

So I think it just boils down to the bootloader consuming a little of the chip's
memory to store the serial routines it uses to write itself.

 

It doesn't need to be at the reset vector.

All that is needed is that the executing firmware at some time provides an option of running the bootloader or not.

The only real cost is the bootloader uses up some ROM, and probably a whole chunk because internal ROM-writes are usually chunk based.