avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch #9110] Let reserved fuse bits to be read as *don't care*


From: David Sainty
Subject: Re: [patch #9110] Let reserved fuse bits to be read as *don't care*
Date: Sun, 21 Nov 2021 13:59:31 +1300

On Sun, 21 Nov 2021 at 12:30, David Sainty <david.sainty@gmail.com> wrote:

> On Thu, 18 Nov 2021 at 22:47, Joerg Wunsch <j@uriah.heep.sax.de> wrote:
>
>> As David Sainty wrote:
>>
>> > There is a patch https://savannah.nongnu.org/patch/index.php?8719 too,
>> but
>> > github is more up-to-date.  I haven't tested it with the current trunk
>> but
>> > certainly will do if it may get it merged.
>>
>> I'd consider it if you can update it within the next few days.
>>
>>
> I'll update the patch now.  Here's a test run from a clean build checked
> out of the avrdude subversion trunk + bootstrap + configure + gmake on a
> MacBook.  You can see from the program times that traversing Zigbee meshes
> is not lightning fast :)
>
>
Patch updated at https://savannah.nongnu.org/patch/index.php?8719

The XBee support adds a new programmer type with no other changes, so it's
a very light-touch patch - if the user doesn't select the "xbee" programmer
then there's no opportunity for the patch to cause problems.

It does need to know the XBee Zigbee address of the remote device on the
mesh, which is supplied along with the serial port of the local XBee device
- E.g. `-P 0013a2004183dd6d@/dev/tty.usbserial-DN05LQ2S`, where
`/dev/tty.usbserial-DN05LQ2S` is MacOS's serial port device name and
`0013a2004183dd6d` is the ZigBee address of a remote XBee that shares a
mesh with the XBee on that serial port.  That is somewhat quirky, and arose
from there not being a straightforward place to store that data without
treading on the feet of the stk500 programmer I'm essentially overloading.
However as user interfaces go it isn't too bad :)  A quick grep suggests
that the -P parameter has several other special-purpose syntaxes, so
perhaps it isn't that quirky.

Because it is essentially a transport layer for the stk500 programmer it
sets `serdev = &xbee_serdev_frame;` and then proxies onto serial_serdev.
Everything else is just dealing with Zigbee/XBee.

Thanks Joerg, hope you'll merge it :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]