Hello, i have a use case where i have approx. 8 ESP32S3 connected on a CANbus. My idea is to upload new firmware using one of them to open a AP, with a Websocket. This is what i have now.
Then i would like the others to recieve it over the CANbus ? - the OTA dosent care where the data comes from, is what i have read?
but how could i configrure a good consistant flow ?
Do some of you have code of this or ideas to the configuration ?
Thanks!
OTA over CANbus/TWAI ?
-
- Posts: 168
- Joined: Sun May 22, 2022 2:42 pm
Re: OTA over CANbus/TWAI ?
This is a cool idea which I'm sure will work out, however the devil is -- as always -- in the details.
The golden path is easy: The main device will broadcast the OTA data to the auxiliary devices,
when the devices receive the frames, they will reassemble the chunks and send it towards the OTA API.
When the last frame has been received, they will individually complete the OTA procedure and reboot into
the new firmware.
That said, you have to solve the edge cases. There are many ways to tackle this. One would be to
do it like a standard CAN protocol, that is you let the main device "broadcast" the frames (possibly
in chunks to minimize traffic waiting for ACKs), then wait for all aux devices to send you an ACK,
after, say, every 1 KB or so. If you got all ACKs, then you continue. If you got one NACK, you will have
to send the whole block again.
For this you will want to use a protocol that carries some kind of sequence
number around, so that the aux devices have a chance to find out when they're missing a frame.
Another way would be to let the aux devices completely buffer the input (in PSRAM) until you're done
with the whole batch.
Then you ask every one of it about any missing frames and only send these again. This is
a bit more complex, but might be faster.
The golden path is easy: The main device will broadcast the OTA data to the auxiliary devices,
when the devices receive the frames, they will reassemble the chunks and send it towards the OTA API.
When the last frame has been received, they will individually complete the OTA procedure and reboot into
the new firmware.
That said, you have to solve the edge cases. There are many ways to tackle this. One would be to
do it like a standard CAN protocol, that is you let the main device "broadcast" the frames (possibly
in chunks to minimize traffic waiting for ACKs), then wait for all aux devices to send you an ACK,
after, say, every 1 KB or so. If you got all ACKs, then you continue. If you got one NACK, you will have
to send the whole block again.
For this you will want to use a protocol that carries some kind of sequence
number around, so that the aux devices have a chance to find out when they're missing a frame.
Another way would be to let the aux devices completely buffer the input (in PSRAM) until you're done
with the whole batch.
Then you ask every one of it about any missing frames and only send these again. This is
a bit more complex, but might be faster.
-
- Posts: 10
- Joined: Tue Feb 28, 2023 8:42 am
Re: OTA over CANbus/TWAI ?
Thanks for your answer. Yes a have also though of the ACK/NACK solution, i will keep this post updated with a possible solution in the near future.DrMickeyLauer wrote: ↑Thu Apr 11, 2024 9:20 amThis is a cool idea which I'm sure will work out, however the devil is -- as always -- in the details.
The golden path is easy: The main device will broadcast the OTA data to the auxiliary devices,
when the devices receive the frames, they will reassemble the chunks and send it towards the OTA API.
When the last frame has been received, they will individually complete the OTA procedure and reboot into
the new firmware.
That said, you have to solve the edge cases. There are many ways to tackle this. One would be to
do it like a standard CAN protocol, that is you let the main device "broadcast" the frames (possibly
in chunks to minimize traffic waiting for ACKs), then wait for all aux devices to send you an ACK,
after, say, every 1 KB or so. If you got all ACKs, then you continue. If you got one NACK, you will have
to send the whole block again.
For this you will want to use a protocol that carries some kind of sequence
number around, so that the aux devices have a chance to find out when they're missing a frame.
Another way would be to let the aux devices completely buffer the input (in PSRAM) until you're done
with the whole batch.
Then you ask every one of it about any missing frames and only send these again. This is
a bit more complex, but might be faster.
Who is online
Users browsing this forum: Bing [Bot] and 96 guests