[patch #9565] Patch for WiFi AVR Programmer, uPDI support for jtagmkII, and serial-over-network improvements

[avrs-admin]

Wed 14 Feb 2018 04:29:49 PM UTC

Here are a set of patches against trunk which add the following features:

• support for my WiFi-enabled AVR programmer which I’ve just started selling commercially,
• support for uPDI in the jtagmkII protocol (used by the above programmer),
• tweak serial timeout in ser_posix.c/ser_win32.c to be more network-friendly.

The programmer supports ISP, PDI and uPDI using the jtagmkII protocol using the "-p net::" option. It also supports ISP and PDI over stk500v2, and I may extend that to uPDI later.

Steve

file #43314: avrdude-wavr-jtag2-updi.diff.gz

This issue was migrated from https://savannah.nongnu.org/patch/?9565

[avrs-admin]

Joerg Wunsch <joerg_wunsch>
Tue 09 Nov 2021 09:32:45 PM UTC

I reviewed the patch, and mostly like it.

What I don't understand is why this SERIAL_ETHERNET_TIMEOUT is needed. The basic idea behind that serial_recv_timeout variable is that individual drivers might override the default. Why can't that also be used for the network traffic here?

[avrs-admin]

Steve Woodford
Wed 10 Nov 2021 08:06:52 AM UTC

Thanks for looking over the patch.

From memory, I think the fixed ethernet timeout was required because round-trip times for TCP over WiFi can exceed the low values set by some drivers.

For instance, jtag3.c sets serial_recv_timeout to 100 mS, which is cutting it fine on a moderately congested WiFi connection.

Steve

[avrs-admin]

Joerg Wunsch <joerg_wunsch>
Sun 21 Nov 2021 09:22:30 PM UTC

Well, all that timeout handling is a mess. A lot of that is probably just heritage from AVRDUDE's 22-year old history.

I wonder whether there's a better way than introducing just another timeout hack^H^H^H^Hsetting though.

The jtagmkII.c code tries to implement a kind of adaptive timeout setting, by doubling the value on missed transactions. Doesn't that already help in your case?

Short of that, maybe we should implement a kind of per-programmer notion of a short vs. long timeout (defaulting to 100 ms / 5 s) that is subsequently be used to toggle between both values. Then, the wavr programmer driver could establish a longer "short" timeout than those 100 ms.

How does that sound?

[mcuee]

Well, all that timeout handling is a mess. A lot of that is probably just heritage from AVRDUDE's 22-year old history.

Since this is targeted for avrdude 7.1 milestone, maybe the timeout improvement can be seperated into a general improvement.

Ref: existing enhancement request related to timeout.

• [bug #41637] avrdude timeout should be specifiable #332
• [bug #41857] avr109 atmega2564rfr2 erase timeout to short #336

[mcuee]

By the way, the info about the WiFI AVR programmer is here.
https://www.maverick-embedded.co.uk/?page_id=20

[mcuee]

@dl8dtl and @stefanrueger

I think we can defer this one and remove the 7.1 milestone flag.

jtag2updi has already been added to support UPDI parts. Serialupdi has also been added. So there is no high priority to add this paticular programmer which does not seem to be popular yet.

[dl8dtl]

Well, I do have the hardware here, and we've got a patch. So I think it would be fair to at least have it in 7.1 (after it didn't make it into 7.0).
The patch just doesn't apply anymore, alas. It needs a bit of care now, but the longer we keep it back, the harder it's going to be.

[mcuee]

Well, I do have the hardware here, and we've got a patch. So I think it would be fair to at least have it in 7.1 (after it didn't make it into 7.0). The patch just doesn't apply anymore, alas. It needs a bit of care now, but the longer we keep it back, the harder it's going to be.

Good to hear that you have the hardware and intend to merge it before 7.1 release.

[dl8dtl]

Will do my best …

[mcuee]

Will do my best …

Thanks. I think no need for you to feel the pressure as this is not a paid work. It is perfectly fine if this is pushed further to a date after the 7.1 release, as it is an enhancement.

I tend to think it is good to have a release as the Christmas present as there are enough good changes in avrdude already.

[dl8dtl]

A Christmas release would be fine with me, too.

[mcuee]

@dl8dtl
I shifted this to AVRDUDE 7.2 milestone. But I think we can always delay it if necessary.

[MCUdude]

So, what should we do with this patch?

The Mavericks Embedded company closed down in March 2022, and their website is also down. The programmer itself is also marked as retired on Tindie.

I suggest we close this one as "Not planned".

[mcuee]

@MCUdude

I agree with you.

@dl8dtl

Any objections?

[dl8dtl]

The company is a Brexit victim. :-(
He donated me one of those programmers for tests, so I feel a bit guilty … I tried to fix up those patches before, but the codebase has changed quite a bit since (even before the move to Github), so it's not so easy.
I still think the idea of a WiFi-attached programmer has some merit.

[mcuee]

I still think the idea of a WiFi-attached programmer has some merit.

I think there are already WiFi and Bluetooth enabled Arduino compatible board already.

For Bluetooth, they just expose a serial port so there is no need to change anything on avrdude side.

I am not so sure about WiFi side. Arduino Uno WiFi Rev 1 supports OTA.
https://docs.arduino.cc/retired/getting-started-guides/ArduinoUnoWiFi (Rev 1, retired)

Arduino Uno WiFi Rev 2 does not seem to support OTA.

[mcuee]

Close this for now and convert it into a discussion.

[MCUdude]

Do we really need a discussion for this issue?
IMO, the issue can be closed as "Not planned". I have no plans to implement it, and I doubt anyone else has either.
If someone wants to create a PR for it, that's fine, but there are "no plans".

I'd rather do this (close issues as "Not planned") rather than use the discussion section for stalled issues.
Just my 2 cents 🙂

[mcuee]

@MCUdude

I agree. I have closed quite a few old discussions.