Hello all...
I've just started to think about how to update a (slave) PIC mcu's firmware using another PIC (master) thru I2C. Basically, the master mcu will get the data from its usb port and send it to the slave mcu using i2c....
Does anyone know where could I find any information on this subject ? Thanx a lot... Regards. Victor
I suppose you could do this, but you will need a boot loader installed in the the target PIC. The protocol to program a PIC is not I2C based.
Yes, I suppose a slightly different bootloader based on the PIC18F bootloader (AN851) could be used for this opperation, but have found nothing on the Microchip's web site on this...
Search on PIC bootloader.
Best regards, Spehro Pefhany
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Would help if we knew which PICs are involved here.
But guessing what people are thinking in this newsgroup is standard.
Some of the older PICs can not in-circuit program. Are you using one of those ??
But I'm only guessing.
donald
The master PIC could for example be a PIC18F4550 and the slave(s) PIC18Fxx 's. So, recent PIC families and none of the older ones ! In any case, the slaves programming (firmware) will have to be done through I2C so they previously have to be programmed with some kind of bootloader that will fill the program memory with data coming from the I2C port.
thanx for guessing... :) Victor
But why? Any reason you're insisting on i2c? Because:
If you're using a bootloader anyway then you don't ever need the master PIC, program the slave PIC to accept data directly from whatever is convenient: USB, Serial etc. Therefore you don't need i2c.
On the other hand, if you insist on using a master PIC then why waste program memory by requiring a bootloader on the slave PIC? Just use a slave PIC with LVP and use Microchip's documented and published ICSP protocol to program the slave. Therefore again you don't need i2c.
So, any reason you're insisting on i2c?
To program the PIC using USB/serial you prior need a bootloader on the chip...
Well, the reason why we'll need a bootloader on each PIC is that the embedded firmware may be modified and has to be easily downloaded on each device.
The only port accessible will be either USB or serial; the customer hasn't got an ICD and only the bootloaders will be programmed by us.
That's why I pretend that the I2C port connecting master to slaves is the best solution...
To program the PIC using i2c you prior need a bootloader on the chip... anyway. Same difference. Also the amount of code required to implement an i2c bootloader on the slave is roughly the same as to implement a serial bootloader.
They don't need an ICD, just an ICSP.
Your "master chip" is in effect a built-in ICSP that you're shipping with your product. My suggestion is that rather than have a bootloader in the slave communicating in i2c with the master, have the master directly talk to the slave in ICSP protocol. That way you don't need any bootloader on the slave and you only need to waste 2 i/o pins (RB6&RB7) which you'll be wasting anyway if you program in i2c.
The ICSP protocol is daunting but not that hard. These days there are lots of PICs that don't require high voltage to program provided you're willing to sacrifice another i/o pin for the LVP function.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.