Hello Joerg,
I realized towards the end of my work on Avarice and libusb that
effectively, libusb 1.0 could provide a socket interface which could used
in this case.
That's why I am calling my modification a hack :-) I couldn't even figure
out how to tell the configure script to look for libusb-1.0 instead of
libusb.
For the regular command / response processing, I just used the synchronous
interface of libusb-1.0. It seemed like an overkill since the AVR Dragon
just answers to the command and there does not seem to be any unexpected
answers.
I used the asynchronous interface when the target is running and you need
to poll for either a GDB interrupt packet or the "Break" packet coming from
the AVR Dragon.
One thing which is leftover from the serial interface is the fact that
avarice will try to resend the command after a timeout if it did not get an
answer, this is definitely a No-No for USB, repeating the command packet
does confuse the AVR dragon ...
I'll try to see if I can get further with these patches. but no commitment
since I am not sure how much time I can spend on that.
Quick question : When you have a Jtag2 interface, is it always connected
via USB or can you have the JtagIce connected via serial ?
Regards
Francois
On Sun, Nov 11, 2012 at 11:00 PM, Joerg Wunsch <j...@uriah.heep.sax.de> wrote:
> Hello Francois,
>
> > I ended up modifying avarice to use libusb-1.0 directly.
> > It is a hack more than a nice clean architecture improvment ... but it
> > could be useful if somebody sees the same issue.
>
> Well, actually I'd be very interested in getting a clean
> implementation of libusb-1.0.
>
> The entire reason for the "USB daemon" subprocess, and all the
> multiprocessing around it is that the libusb-0.1 API did not allow to
> select() (or poll()) for anything from USB. However, AVaRICE is in
> the need of polling two channels for IO multiplexing, the GDB channel,
> and the ICE channel.
>
> The GDB channel is just a socket, so it's easy to poll for it.
> Historically (for the first JTAGICE, as well as the JTAGICEmkII
> connected through a standard serial port), the ICE connection was a
> simple serial one, which was also easy to poll. Both connections were
> handled in a single select() system call.
>
> However, when implementing USB access to the JTAGICEmkII using the
> libusb-0.1 API, there were no provisions to get access to a standard
> filedescriptor which could be polled. Thus, I invented the "USB
> daemon", as a subprocess being forked off the main process. The
> entire purpose of this child process was to operate the libusb API,
> eventually sleep for USB messages, and connect to its parent through a
> couple of pipe descriptors. As a pipe descriptor is a standard Unix
> filedescriptor which can be used in select(), this any messages
> arriving on the USB could be made the parent process wakeup, and
> continue its processing.
>
> As the libusb-1.0 API has provisions to obtain the Unix filedescriptor
> being used by the library, it ought to be possible to return to the
> single-process single-thread scenario we have been at years ago. As
> this eliminates a number of potential pitfalls (see the
> multiprocessing problems reported for Solaris), and in general makes
> the code more straightforward again, I'd appreciate a solution towards
> that direction.
>
> I do hope a change like this would not cause too much compatibility
> issues for all the platforms supported, notably Cygwin. However, the
> libusb-1.0 API is now several years old, and for sure did replace the
> old 0.1 de-facto standard API.
> --
> cheers, J"org .-.-. --... ...-- -.. . DL8DTL
>
> http://www.sax.de/~joerg/ NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
avarice-user mailing list
avarice-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avarice-user
