# Firmware update via GUI tool

**URL:** <https://forum.opencyphal.org/t/firmware-update-via-gui-tool/383>\
**Category:** Applications & Usage\
**Created:** [March 6, 2019, 9:56am UTC](https://forum.opencyphal.org/t/firmware-update-via-gui-tool/383 "2019-03-06T09:56:20Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![deekay](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/d/8491ac/32.png) [@deekay](https://forum.opencyphal.org/u/deekay)\
**Post date:** [March 6, 2019, 9:56am UTC](https://forum.opencyphal.org/t/firmware-update-via-gui-tool/383/1 "2019-03-06T09:56:20Z")

</div>

Hi!

I am testing the performance during firmware download between GUI tool and node, using different bus speeds.  
On node side , I am using the [Updatee](https://uavcan.org/Implementations/Libuavcan/Tutorials/11._Firmware_update/) code snippet and testing multiple timer intervals of the periodic timer.

Even if I reduce the file.Read periodic timer on node side to very short, I notice that the bus load only reached ~30% @ 1Mbps. When investigating GUI tool server response time I see that it is ~12ms delay between file.Read client command and GUI response. I have a feeling that this is the reason that bus load is so low.  
My target is to make use of a larger bandwidth usage (~80%) during firmare update.

For comparison I did the test using 125kbps and then the bus load reached 85%, hence the longer bit time.

So my question is if the GUI tool can be faster or if it is a constraint in pyuavcan or somewhere else?  
Do I have to implement my own file server for firmware update, perhaps in C++, to be able to make use of all bandwidth?

BR

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [March 6, 2019, 3:06pm UTC](https://forum.opencyphal.org/t/firmware-update-via-gui-tool/383/2 "2019-03-06T15:06:45Z")

</div>

> [@deekay](#):
>
> When investigating GUI tool server response time I see that it is ~12ms delay between file.Read client command and GUI response. I have a feeling that this is the reason that bus load is so low.

Sounds reasonable. Consider profiling the pyuavcan server; it might be that your system is a bit slow when reading from the disk (if that’s the case, rewriting things in C++ is unlikely to help). Also, consider emitting several requests concurrently.

---

<div class="post-metadata">

**Author:** ![deekay](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/d/8491ac/32.png) [@deekay](https://forum.opencyphal.org/u/deekay)\
**Post date:** [March 7, 2019, 7:23am UTC](https://forum.opencyphal.org/t/firmware-update-via-gui-tool/383/3 "2019-03-07T07:23:57Z")

</div>

Did not think about multiple requests… I want to try that. But do I not need to wait for hasPendingCalls() to return 0 before firing a new request via same node?

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [March 7, 2019, 8:07am UTC](https://forum.opencyphal.org/t/firmware-update-via-gui-tool/383/4 "2019-03-07T08:07:01Z")

</div>

No, because that behavior would essentially serialize your requests.

---

<div class="post-metadata">

**Author:** ![deekay](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/d/8491ac/32.png) [@deekay](https://forum.opencyphal.org/u/deekay)\
**Post date:** [March 7, 2019, 9:04am UTC](https://forum.opencyphal.org/t/firmware-update-via-gui-tool/383/5 "2019-03-07T09:04:37Z")

</div>

Ok. so it is just a matter of keeping track of the image offsets in the multiple ongoing requests. Sounds like a no brainer. 🕶