 |
 |
| View previous topic :: View next topic |
| Author |
Message |
neo19
Joined: 14 Aug 2012
Posts: 30
Location: France
|
| PIC18F4550 and bootloader |
 Posted: Mon Oct 31, 2022 2:06 pm |
 |
|
Hello,
I'm working with PIC18F4550, PCWH compiler 5.030.
I'm new with bootloader and I have some questions.
My system is composed of multiple of slave boards using PIC18F4550.
My main board is a RCM4300 from Rabbit.
All of these boards communicate using a RS232/485 link.
I would like to know if it's possible to upgrade all the PIC18F4550 from my main board, my rabbit board.
Thanks for your advice,
Best regards |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Tue Nov 01, 2022 2:28 am |
|
|
Yes, of course it is. The key questions are going to be getting the data
into this board, and setting up the serial driver here to send the data
to the PICs. Great care needed to ensure the serial supports XON/XOFF
(this is used to stop the transmission while each block is programmed),
and handles this stop correctly. |
|
|
neo19
Joined: 14 Aug 2012
Posts: 30
Location: France
|
|
| Posted: Sat Nov 05, 2022 3:50 pm |
|
|
Thanks for your answer.
Also, another question: I have different type of slave boards with different software.
If all of the slave boards are powered ON and all plugged to the main board, is there a way to upgrade all the boards?
Thanks |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Sat Nov 05, 2022 4:05 pm |
|
|
If all slaves are on separate serial lines, then yes...
if they're on the SAME serial lines, I's say no unless the bootloader programs were designed to have a 'slave ID' as part of the data.
Upgrading ONE slave at a time is easy, trying to upgrade 2 or more will be 'tricky'.
Either way it is 'possible' though it does require some good tight code. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Sat Nov 05, 2022 8:37 pm |
|
|
| Ttelmah wrote: | Yes, of course it is. The key questions are going to be getting the data
into this board, and setting up the serial driver here to send the data
to the PICs. Great care needed to ensure the serial supports XON/XOFF
(this is used to stop the transmission while each block is programmed),
and handles this stop correctly. |
If the slaves only transmit in response to a command from the master then XON/XOFF is not needed.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Sat Nov 05, 2022 8:44 pm |
|
|
| temtronic wrote: | If all slaves are on separate serial lines, then yes...
if they're on the SAME serial lines, I's say no unless the bootloader programs were designed to have a 'slave ID' as part of the data.
Upgrading ONE slave at a time is easy, trying to upgrade 2 or more will be 'tricky'.
Either way it is 'possible' though it does require some good tight code. |
A bootloader slave ID is a must. Ideally the ID would be the same ID used by the application code on the board. However another issue is how do you put the slaves into bootloader mode? If this is via a command over the serial bus (i.e. the application on the PIC has to somehow signal a bootload is required) then it gets tricky when you have multiple slaves. For example, do you use a common command (equivalent to a broadcast or multicast message to put all into bootloader mode but only the PIC would the matching slave ID would be bootloader) or do you only put the one being updated into bootloader mode? In the latter case this means all other nodes are interpreting the comms on the serial bus, so your application code has to handle this. Anytime you have application / bootloader dependency the solution integrity is compromised.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Sun Nov 06, 2022 12:45 am |
|
|
| asmallri wrote: | | Ttelmah wrote: | Yes, of course it is. The key questions are going to be getting the data
into this board, and setting up the serial driver here to send the data
to the PICs. Great care needed to ensure the serial supports XON/XOFF
(this is used to stop the transmission while each block is programmed),
and handles this stop correctly. |
If the slaves only transmit in response to a command from the master then XON/XOFF is not needed. |
Er. No.
That is the wrong way round.
For a bootloader, the 'slave' is the device receiving the code. The 'master'
is the one sending it. You can write the slave bootloader so it requests
the code from the master, in which case the request replaces the need
for XON/OFF, but what you describe is the wrong way round. It is the
'slave' device that has to be able to stop the transmission, while the
block is programmed.
If you are bootloading from a PC, you would not consider the PC to be
the 'slave' would you?. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Sun Nov 06, 2022 6:32 am |
|
|
hmm, this IS a tricky problem !!
What happens when one slave is being updated ? Is the network shutdown and ALL communications is stopped until the slave is updated ?
Do you need an 'abort' command, say of the slave takes too long to update ?
Gets more complicated when more slaves are being updated. Just how long can the network be 'down' ?
For sure some 'code' is needed to determine that the network bus/hardware is OK
Then there's the 'slave #1 data needs to be sent to slave #5 but #5 is being updated' problem.....
This is truly turning into a 'can of worms'.....
changing 9 clocks back an hour is easier. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Sun Nov 06, 2022 7:47 am |
|
|
The other issue, is that adding complexity to the bootloader makes this
larger. Key is normally that the bootloader is written to be small. This then
leaves a nice amount of space for the main program. Now adding a relatively
simple address, can not add too much to the size of the bootloader, but
anything much more complex, risks making the bootloaders unacceptably
large. Honestly if the hardware can be designed so that there are either
individual serials to each board, or so there is perhaps hardware multiplexing
to allow the target board to be selected, makes this much easier to do. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Sun Nov 06, 2022 10:40 am |
|
|
It'd probably be the 'host' or 'master' side, a 'Rabbit' that could be the nightmare to code for 'multi slave' bootloadering......
Keeping everything 'in order' wouldn't be easy to implement. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Sun Nov 06, 2022 9:08 pm |
|
|
[quote="Ttelmah"] | asmallri wrote: | | Ttelmah wrote: | Yes, of course it is. The key questions are going to be getting the data
into this board, and setting up the serial driver here to send the data
to the PICs. Great care needed to ensure the serial supports XON/XOFF
(this is used to stop the transmission while each block is programmed),
and handles this stop correctly. |
If the slaves only transmit in response to a command from the master then XON/XOFF is not needed.
Er. No.
That is the wrong way round.
For a bootloader, the 'slave' is the device receiving the code. The 'master'
is the one sending it. You can write the slave bootloader so it requests
the code from the master, in which case the request replaces the need
for XON/OFF, but what you describe is the wrong way round. It is the
'slave' device that has to be able to stop the transmission, while the
block is programmed.
|
This is purely implementation dependent. In my bootloader, Ethernet, Serial, RS485, I2C, the master is normally a PC. The PC bootloader application is the master and is responsible for error detection and retransmission . The master (PC in this case) transmits a block to the slave and waits for a successful reply, an error reply or no reply to determine the next next step.
| Ttelmah wrote: |
If you are bootloading from a PC, you would not consider the PC to be
the 'slave' would you?. |
No I would not, the bootloaded PIC is the slave but no XON/OFF or any other type of flow control by the slave is necessary flow control is necessary.
In the case of cascaded bootloaders where a master PIC communicates to downstream PICs, the master PIC is a slave to the PC programmer application as well as being a master to the cascaded slaves. For some of my cascaded bootloaders typically the master PIC's bootloader, uses an ID field to determine is the target is itself or a cascaded PIC.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Sun Nov 06, 2022 9:14 pm |
|
|
| temtronic wrote: | hmm, this IS a tricky problem !!
What happens when one slave is being updated ? Is the network shutdown and ALL communications is stopped until the slave is updated ?
Do you need an 'abort' command, say of the slave takes too long to update ?
Gets more complicated when more slaves are being updated. Just how long can the network be 'down' ?
For sure some 'code' is needed to determine that the network bus/hardware is OK
Then there's the 'slave #1 data needs to be sent to slave #5 but #5 is being updated' problem.....
This is truly turning into a 'can of worms'.....
changing 9 clocks back an hour is easier. |
I agree, cascaded bootloaders can be complex.
In my implementation the PC programmer application is responsible for the error handling and yes, the simplest implementation is the bus is not available for other communications during the bootload process. However ON/OFF only complicates such an implementation where you are using the bus for simultaneous bootloading while supporting normal comms with other targets. If this type of operation model is required then I believe the simplest approach is to use two separate busses, one for bootloading and one for production.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Mon Nov 07, 2022 2:29 am |
|
|
So Andrew, you are setting your bootloader up so it has a buffer of a
size known to the master, so you can send this without pauses, and then
wait for it to say that this has been handled?.
Sensible.
You presumably add an end of block marker, so that when a block is
shorter, the slave knows to deal with this. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Mon Nov 07, 2022 3:57 am |
|
|
| Ttelmah wrote: | So Andrew, you are setting your bootloader up so it has a buffer of a
size known to the master, so you can send this without pauses, and then
wait for it to say that this has been handled?.
Sensible.
You presumably add an end of block marker, so that when a block is
shorter, the slave knows to deal with this. |
Pretty close, it does depend on whether it is an encrypted bootloader or non encrypted and it also depends on the technology, for example, Ethernet deals with larger buffer sizes because the Ethernet controllers have large ring buffers with each individual packet, of any legal length, being clearly delineated and can be easily serialized out on a byte by byte basis. Particularly helpful for small PICs with limited RAM.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Tue Nov 08, 2022 5:10 am |
|
|
The 'key' point to understand, is that during the actual programming of
the processor's ROM, it has to completely stop. For a couple of mSec, it
can't do anything at all. Can't send, can't receive, etc. etc.. So during
this the communication has to be stopped. Now the supplied CCS bootloader
takes the simplest approach, and just sends an XOFF to stop transmission
before starting the programming. Asmallri's approach is instead to have
the packets 'requested', and then do the programming from a buffer.
In either case though the key thing is that all communication has to stop
while each programming operation is performed. Whatever protocol is
chosen, there has to be a way of making sure this happens.
The 'best way', will depend on how the communication is really handled
in the system being talked about. This so far has been 'vague', talking about
a Rabbit board controlling a number of slave boards. No details of how
the connections are actually made (a bus protocol, individual connections,
etc. etc.), so we are all just guessing.
Give some details of how the board communication is actually 'done', and
more useful data may start to appear. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
