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 <[email protected]> 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/avrdude-dev > _______________________________________________ avrdude-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avrdude-dev
