I´ll try out the trunk when I get back into the office. Here is the
patch that I forgot to attach. I think regardless of whether the
trunk works this patch is a good idea just to be safe.
On Sun, May 24, 2009 at 12:29 AM, Zach Welch <[email protected]> wrote:
> On Sat, 2009-05-23 at 21:06 -0700, David Brownell wrote:
>> On Saturday 23 May 2009, Zach Welch wrote:
>> >
>> > > Considering that USB bulk transfers are "best effort" and might easily
>> > > be delayed by concurrent activity to a USB disk or webcam ... a single
>> > > second seems absurdly short. Even if the device were guaranteed to be
>> > > able to respond that quickly.
>> >
>> > Right, but that does not mean we should simply throw the program into a
>> > blocking call with a longer timeout. I would rather see the device make
>> > a try using a _shorter_ timeout and allow for other processing to occur
>> > in between retries.
>>
>> "Retry"?
>
> Well, I am thinking of the J-Link code in particular, which I suppose is
> more of a "continuation" condition.
>
>> I'd rather see the event loops structured better, so that each activity
>> gets its own thread. That would move from those error-prone presumptions
>> that manually timesliced event loops can scale.
>
> I like the idea of threads, but that opens a new dimension of problems
> for embedded systems (though none supported... today). It would be nice
> to be able to run OpenOCD in a single thread.
>
>> I see messages about needing to increase some GDB timeout/interval. But
>> that's foolishness, since I'm not even working with GDB when they start
>> spamming me. The core problem has nothing to do with GDB, and everything
>> to do with a weak concurrency model.
>
> I agree. This is what I meant by retries. If we're working on the
> single thread model, no event/action can be allowed to take more than
> MAX_TIME_SLICE, or you see those sorts of problems. I thought that
> libusb worked in non-blocking mode, but perhaps I was wrong....
>
>> Too bad that can't be fixed before the next release. ;)
>
> Yeah. These are Big Changes.
>
> Cheers,
>
> Zach
>
> _______________________________________________
> Openocd-development mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
Index: src/jtag/jlink.c
===================================================================
--- src/jtag/jlink.c (revision 1881)
+++ src/jtag/jlink.c (working copy)
@@ -951,9 +951,18 @@
/* Read data from USB into in_buffer. */
static int jlink_usb_read(jlink_jtag_t *jlink_jtag, int expected_size)
{
- int result = usb_bulk_read_ex(jlink_jtag->usb_handle, JLINK_READ_ENDPOINT,
- (char *)usb_in_buffer, expected_size, JLINK_USB_TIMEOUT);
+ int result;
+ if(expected_size > JLINK_IN_BUFFER_SIZE)
+ {
+ LOG_ERROR("jlink_jtag_read illegal length=%d (max=%d)",
+ expected_size, JLINK_IN_BUFFER_SIZE);
+ return -1;
+ }
+
+ result = usb_bulk_read_ex(jlink_jtag->usb_handle, JLINK_READ_ENDPOINT,
+ (char *)usb_in_buffer, expected_size, JLINK_USB_TIMEOUT);
+
DEBUG_JTAG_IO("jlink_usb_read, result = %d", result);
#ifdef _DEBUG_USB_COMMS_
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
