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

[Nicholas Flowers]

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 <address@hidden>
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 <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
>>
>
>