Actually, I don't think USBtiny can work, either: its commands overlap with FTDI's. For example, POWERUP will look like FTDI's GET_MODEM_STATUS (request type vendor, request code 5).
Hmm. On Sun, Feb 21, 2016 at 11:37 AM, Nicholas Flowers <[email protected]> wrote: > 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
