Re: [avrdude-dev] suggest a "programmer"?

[Nicholas Flowers]

Thanks again.

With regard to stk500v2, usb_libusb, how are endpoints selected?  I need
3/4 for the data bridge, and a third if I go the CDC route (which requires
an interrupted endpoint: this is the reason I ditched CDC for FTDI, because
I was thinking I might require 1/2 for avrdude).

Also, my understanding (which may be wrong) is that USB considers IN 2
distinct from OUT 2, but that the 16U2 (at least) doesn't allow you to both
configure IN 2 and OUT 2.  I could have an IN 1/OUT 2 or vice versa.

My cursory reading of the code:

stk500v2.c has some hard-coded rep/wep values depending on which programmer
type.  For example, AVRISP2 uses IN 2/OUT 2 (which, as I suggested above, I
don't think I can handle in the 16U2?).  In fact, all the hard-coded values
look to conflict.

usb_libusb.c looks like it requires ->usb.wep to be set by the programmer
(ie, hard-coded), but if ->usb.rep is not set, it tries to infer it.  I'm
not sure which programmer uses that codepath (stk500v2 seems to hard-code
its ->usb.rep values).

In addition, I fear that using such logic could get confused with the
read/write endpoints used in the bridge.  Overall, it seems like what one
might want is a configuration option to select an interface class/subclass,
let the endpoints be derived from that.

... of course, I'm not asking for that :).  It looks like overall, if I can
get the tiny to work (no read/write endpoints, everything issued over
control), that would be the easiest way forward?  (Open to advice, of
course.)  I'll give it a shot, and let you know it goes.

Regards,
Nick.


On Sun, Feb 21, 2016 at 10:48 AM, Joerg Wunsch <address@hidden> wrote:

> As Nicholas Flowers wrote:
>
> > > So a CDC device is nothing you could live with?
>
> > I'm also using the chip as a USB-UART bridge (I'm cloning myself as an
> FTDI
> > device, but would be happy to switch to CDC if you have reason to think
> it
> > is better?), but that is for serial data.  I'd rather keep my programming
> > interface separate,
>
> OK.
>
> > Adding ser# support: I'm confident I could change it to work for me, less
> > confident that it wouldn't screw someone else up.
>
> There are enough precedent cases to copy from.  (I wish USBtiny and
> USBasp were using the standard stuff from usb_libusb.c where the
> serial number matching is already included.)
>
> But again, if you are going to mimic an AVRISPmkII, you'd already have
> the serial number stuff included.
>
> > Another consideration:
> > it'd be nice if this "just worked" on any reasonably-recent ubuntu
> machine
> > I apt-get from.
>
> Well, if we add it right now, it will be in the next AVRDUDE release, and
> from there, the Ubuntu package maintainers typically pick it up relatively
> quickly.
>
> Since I've just added the libhidapi stuff (I long wanted to add), I
> won't want to wait too long for a new release.  Just picking up some
> bugfixes and patches, and make confident the new addition works well.
>
> > It looks like I can get bus #/device # given a ser# from /sys/bus/usb.
> And
> > that I could use those to give a name to "usbtiny" type.  Maybe I'll give
> > that a go -- unless anyone has reason to think the tiny interface is
> > problematic?
>
> I have no real idea about USBtiny.  I've been testing it off and on,
> but that's it.  As my main development work is done on FreeBSD, I
> could not use that /sys/bus/usb stuff here anyway.
>
> But if it works for you, why not?
> --
> cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL
>
> http://www.sax.de/~joerg/
> Never trust an operating system you don't have sources for. ;-)
>
> _______________________________________________
> avrdude-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>