Marco Accame

About: >>The long delay, you notice in get targets, I don't think is due to the time used by firmware to respond , but to the increased of the numer...

Hi @drdanz and @pattacini, about the `We should have a new qt firmware tool but I've never used it `: we have had *FirmwareUpdater* in devel since december 2016 and...

For what regards *canLoader* and *ethLoader*: yes we can. See however issue https://github.com/robotology/icub-main/issues/473 which I have just created to help P&M (production & maintenance ) dropping the use of *canLoader*...

I had a look at the links. There are several cases, hence I write some comments in here as an help to do proper changes when we remove GTK and...

> Hi @davidetome > > Please, don't put this PR in "ready for review" if the twin [robotology/icub-firmware-shared#72](https://github.com/robotology/icub-firmware-shared/pull/72) is not merged yet, otherwise the CI will fail miserably 😉 Now...

Hi @martinaxgloria, in here some comments. - icub-main + firmware already support the way the execution overflow messages are emitted by the ETH boards (see https://github.com/robotology/icub-main/pull/971) in two modes: -...

With `emitRXDOTXoverflow = false` the warnings are not displayed as I expected and that is OK. From the measured stats however we see that we cannot properly tune `maxTimeOfRXactivity`, `maxTimeOfDOactivity`...

> * i developed last month and i will soon test a new FW w/ a modified approach of the RX-DO-TX threads in which they are not executed at exactly...

> Hi [@marcoaccame](https://github.com/marcoaccame) , I have only a doubt: > >  Will it be a problem if we lose this synchronization? I wrote that just because originally the slotted...

> Don't know which fw version is on the boards but that might be related to: [robotology/icub-firmware#620](https://github.com/robotology/icub-firmware/pull/620) or it is due to a ETH network issue. cc: [@marcoaccame](https://github.com/marcoaccame) [@ale-git](https://github.com/ale-git) This...