[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&data=04%7C01%7C%7C7011d05fefb048ba43f108d9b3441762%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637737927290195893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qp2jAOJ1YLsUpR2ZefOgUHfn9AbtxGZv3LrijvPlfLU%3D&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&data=04%7C01%7C%7C7011d05fefb048ba43f108d9b3441762%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637737927290195893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CtA%2B6wR4eTmibqBRWISkJ1q0371%2FvgLiwG3qdbY2Ulo%3D&reserved=0
Never trust an operating system you don't have sources for. ;-)
Re: Introducing SerialUPDI programmer, Andy Bennett, 2021/11/30