avrdude-dev
[Top][All Lists]
Advanced

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

Re: Introducing SerialUPDI programmer


From: Dawid Buchwald
Subject: Re: Introducing SerialUPDI programmer
Date: Tue, 30 Nov 2021 11:59:38 +0000

Thanks for the hint about SVN repo. I don’t know why, but I assumed that the 
git repo available in GitHub is up to date (it wasn’t, not even close!) and 
have just spent several hours catching up to revision 1504.

Anyway, as for the implementation, I’m still working on it, and probably will, 
at least for a while. What I do need to know right now, is whether it is OK to 
change some of the core AVRDUDE serial code. The thing is that for this 
particular implementation I need to be able to change serial connection 
parameters - UPDI uses slightly different ones. What I did was change to union 
pinfo, like so:

union pinfo
{
struct {
long baud;
unsigned long cflags;
} serialinfo;
struct
{
unsigned short vid;
unsigned short pid;
unsigned short flags;
#define PINFO_FL_USEHID 0x0001
#define PINFO_FL_SILENT 0x0002 /* don't complain if not found */
} usbinfo;
};

And, obviously, changed each and every occurrence to set the values to default, 
like so:

pinfo.serialinfo.baud = 19200;
pinfo.serialinfo.cflags = SERIAL_DEFAULT_FLAGS;

All these flags are defined in “architecture-agnostic” way so that they will be 
translated by whatever serial provided is implemented (I did it only for 
ser_posix.c) for now.

The question now is: are this kind of changes OK? I know I’m fiddling with 
internals of AVRDUDE, so it goes a bit beyond just a new programmer definition, 
so I need to know if this has any chance of getting accepted. Bonus question: 
should it all go in one huge patch, or should there be one first, containing 
only change enabling different serial connection parameters, followed later on 
by the one related to SerialUPDI implementation only? Any preference?

Thanks in advance,
Dawid


On 29 Nov 2021, at 15:10, Joerg Wunsch 
<j@uriah.heep.sax.de<mailto:j@uriah.heep.sax.de>> wrote:

As Dawid Buchwald wrote:

I might be wrong, but based on the information found here:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSpenceKonde%2FAVR-Guidance%2Fblob%2Fmaster%2FUPDI%2Fjtag2updi.md&amp;data=04%7C01%7C%7C7011d05fefb048ba43f108d9b3441762%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637737927290195893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=qp2jAOJ1YLsUpR2ZefOgUHfn9AbtxGZv3LrijvPlfLU%3D&amp;reserved=0
there are actually quite a lot of issues with jtag2updi
implementation in AVRDUDE, and the SerialUPDI utility provided by
Microchip seems to be better option.

While I don't see many issues ...

The idea is to implement direct support for simple USB->UART based
UPDI programmers without the need to install additional tools like
pymcuprog.

... the option to perform programming with a simple UART adapter
rather than a CMSIS-DAP compatible programming dongle is certainly
useful. (Of course, the CMSIS-DAP dongle also offers debugging
capabilities, but that's beyond the scope of AVRDUDE.)

Please don't start out with any offspring Git repositories, unless you
make sure it is really in sync with the current Subversion repo. The
latter is still the definitive source reference for AVRDUDE.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sax.de%2F~joerg%2F&amp;data=04%7C01%7C%7C7011d05fefb048ba43f108d9b3441762%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637737927290195893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=CtA%2B6wR4eTmibqBRWISkJ1q0371%2FvgLiwG3qdbY2Ulo%3D&amp;reserved=0
Never trust an operating system you don't have sources for. ;-)



reply via email to

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