Hey guys i wanted to ask before i go all crazy and attempt to create my own bootloader.... is there a UART... yes UART .. NOT USB bootloader avaiable for the p18F27J53. I know this is a USB PIC.
The hardware i have uses the UART port and has no USB available for a USB Bootloader.
If i had the USB option available .... Would it be possible to setup the PIC to have a USB Bootloader while also being a USB CDC? So i can use the UART from PC to both program and communicate with PIC?
The Current hardware is basic with a USB to UART (CP2104) IC to allow communication. Now if i can setup a simple UART bootloader and program it once. Ill be able to reprogram from USB Port. Otherwise ill have to reprogram over and over for testing via ICSP port. Which on this hardware is 5 tiny pads and i have no test jig.
Any help and sorry for this confusing post.. i kinda got a headache already and keyboard is being a pain ..
I know I'm gonna sound like a picky brat but I hate ASM and the fact this bootloader makes me rearrange stuff in the linker script. I know there is a way to move it to the end of the chip and have a simple goto command to jump to it on boot.
Is it possible for a bootloader to overwrite itself? Or is that blocked. For instance...
Can I make code and implement a custom loader.. not bootloader in the send it will program from a command in UART. Instead of having to signal it only at boot time?
Like have it load my program as normal and o want to reprogram the MCU have it run a subroutine to do it?
Probably a good place to start to make your own for a more modern device?.
As for 'writing over itself', it's certainly possible, and it's up to you to write it so it doesn't.
Back in my days of playing with bootloaders there were usually two programming options:
1) Allocate an I/O pin, and check it on power up - if it's 'set' then enter the bootloader.
2) Check the serial port on power up, for a couple of seconds, waiting for a bootloader command - if it's found then enter the bootloader, if not jump to normal program operation.
Personally I always used the second option, as it avoided wasting an I/O pin.