Maker Pro
Maker Pro

PIC micro firmware update

V

Victor

Jan 1, 1970
0
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
 
A

Anthony Fremont

Jan 1, 1970
0
Victor said:
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...

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.
 
V

Victor

Jan 1, 1970
0
Anthony Fremont a écrit :
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...
 
S

Spehro Pefhany

Jan 1, 1970
0
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

Search on PIC bootloader.


Best regards,
Spehro Pefhany
 
D

Donald

Jan 1, 1970
0
Victor said:
Anthony Fremont a écrit :

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...

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
 
V

Victor

Jan 1, 1970
0
Donald a écrit :
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
 
Donald a écrit :

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

But why? Any reason you're insisting on i2c? Because:
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.

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?
 
V

Victor

Jan 1, 1970
0
[email protected] a écrit :
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.

To program the PIC using USB/serial you prior need a bootloader on the
chip...
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?

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...
 
[email protected] a écrit :

To program the PIC using USB/serial you prior need a bootloader on the
chip...

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.
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.

They don't need an ICD, just an ICSP.
That's why I pretend that the I2C port connecting master to slaves is
the best solution...

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.
 
Top