On 2013.01.30 20:43, Mohamed HAMZAOUI wrote:
> Does the number of handling event call should be equal or great the
> number of transfer submitting given that the handler thread execute
> the callback and then spent more time on executing them ?
I'm not sure I understand your question, but I don't
I have an important inforation,
I added a hanling event instruction on sender thread just after
sending, so, we have one thread for handling and another thread for
sending and handling an event after sending
and i protect the two handling call with libusb_lock/unlock_event
function like that :
/***
On Wed, Jan 30, 2013 at 6:33 AM, Xiaofan Chen wrote:
> On Wed, Jan 30, 2013 at 12:45 AM, Mohamed HAMZAOUI
> wrote:
>> Now I use libusbx library static in debug mode (i just have changed
>> /MTd to /MDd in compiling parameter).
>>
>> more information about the bug : there is a corruption in memor
On Wed, Jan 30, 2013 at 12:45 AM, Mohamed HAMZAOUI wrote:
> Now I use libusbx library static in debug mode (i just have changed
> /MTd to /MDd in compiling parameter).
>
> more information about the bug : there is a corruption in memory
> because the dev handle address are wrong 0x4f8 and this is
On Wed, Jan 30, 2013 at 1:12 AM, Mohamed HAMZAOUI wrote:
> Another remark : I found the same problem in an old libusb ticket
> http://www.libusb.org/ticket/140
> maybe the memory corruption is caused by pthread-win32 in a stress context ?
Just for reference here. Please take note the following ma
On 2013.01.29 17:12, Mohamed HAMZAOUI wrote:
> Another remark : I found the same problem in an old libusb ticket
> http://www.libusb.org/ticket/140
> maybe the memory corruption is caused by pthread-win32 in a stress context ?
I don't think we can assume anything at this stage, especially given
t
On 2013.01.29 16:45, Mohamed HAMZAOUI wrote:
> I updated the libusbx but i think the modifications doesn't help you
> because the crash is before this log call
Yeah, I've been wondering about that, but still I want to see what the
error code is, so that at the very least we can improve our handl
Another remark : I found the same problem in an old libusb ticket
http://www.libusb.org/ticket/140
maybe the memory corruption is caused by pthread-win32 in a stress context ?
ragards,
Mohamed
On Tue, Jan 29, 2013 at 5:45 PM, Mohamed HAMZAOUI wrote:
> Hi Pete,
>
> Thank you for your response.
>
Hi Pete,
Thank you for your response.
I updated the libusbx but i think the modifications doesn't help you
because the crash is before this log call
Yes I'am linking with linking pthread-win32 library for portability
consideration.
Now I use libusbx library static in debug mode (i just have chan
Hi Mohamed,
On 2013.01.28 09:57, Mohamed HAMZAOUI wrote:
> I return for you for a crash problem in my soft.
> For remember, I'm now developping a software based on libusbx to send
> and receive with my CAN-USB gateway card.
> In my program i have a start a thread to handle event with this code :
>
Please do not take into account this :
libusb_cancel_transfer(transfer->xfer); /* the callback do the free */
Regards,
Mohamed
On Mon, Jan 28, 2013 at 10:57 AM, Mohamed HAMZAOUI wrote:
> Hi,
> I return for you for a crash problem in my soft.
> For remember, I'm now developping a software based o
Hi,
I return for you for a crash problem in my soft.
For remember, I'm now developping a software based on libusbx to send
and receive with my CAN-USB gateway card.
In my program i have a start a thread to handle event with this code :
static void *event_handler_thread(void *args)
{
struct dtlib *l
Mohamed,
Please bear in mind that, Peter Stuge's conflicting statement with
regards to the answer previously given by Xiaofan, and earlier myself,
is from someone who is (was) a simple subscriber of libusbx, as well as
the sole lead of a competing project, and is therefore not an official
voic
Mohamed HAMZAOUI wrote:
> Is this a bug on the libusb/WinUsb or a limitation ?
Yes, I consider it a bug. Others might not.
//Peter
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access P
On Thu, Dec 13, 2012 at 10:12 PM, Xiaofan Chen wrote:
> On Thu, Dec 13, 2012 at 6:56 PM, Mohamed HAMZAOUI wrote:
>> I'm developping a card which support 2CAN HS(baudrate up to 1Mb/s)/2
>> CAN LS and 2 LIN channel.
>> The protocol implemented is the standard CAN layer with normal and
>> extended I
On Thu, Dec 13, 2012 at 6:56 PM, Mohamed HAMZAOUI wrote:
> I'm developping a card which support 2CAN HS(baudrate up to 1Mb/s)/2
> CAN LS and 2 LIN channel.
> The protocol implemented is the standard CAN layer with normal and
> extended ID support.
>
> In critical load on USB with several frame to
I'm developping a card which support 2CAN HS(baudrate up to 1Mb/s)/2
CAN LS and 2 LIN channel.
The protocol implemented is the standard CAN layer with normal and
extended ID support.
In critical load on USB with several frame to send and receive, it's
normal that USB protocol cannot deal with the
On Wed, Dec 12, 2012 at 4:49 PM, Xiaofan Chen wrote:
> On Wed, Dec 12, 2012 at 2:11 AM, Tim Roberts wrote:
>> Mohamed HAMZAOUI wrote:
>>> Solution, as pointed out Tim, is to buffer more data in a single
>>> request. It's like nagle algorithm that I will implement, but I think
>>> it is not a good
On Wed, Dec 12, 2012 at 2:11 AM, Tim Roberts wrote:
> Mohamed HAMZAOUI wrote:
>> Solution, as pointed out Tim, is to buffer more data in a single
>> request. It's like nagle algorithm that I will implement, but I think
>> it is not a good solution in my case.
>> Firstly, there's several threads th
Mohamed HAMZAOUI wrote:
> Solution, as pointed out Tim, is to buffer more data in a single
> request. It's like nagle algorithm that I will implement, but I think
> it is not a good solution in my case.
> Firstly, there's several threads that send CAN frames in accordance
> with specific conditions
Hi,
To summarize, the number of fds is limited to the size of the table,
256 elements at most, this is an estimate from Microsoft that is
enough!
Solution, as pointed out Tim, is to buffer more data in a single
request. It's like nagle algorithm that I will implement, but I think
it is not a good
On Mon, Dec 10, 2012 at 5:23 PM, Peter Stuge wrote:
> Peter Stuge wrote:
> > Are there considerations (timing? something else?)
> > related to asking Windows for memory as needed
>
> Pete Batard wrote:
> > Adding and testing array reallocation code is a PITA
> > and development time is always sup
Peter Stuge wrote:
> Are there considerations (timing? something else?)
> related to asking Windows for memory as needed
Pete Batard wrote:
> Adding and testing array reallocation code is a PITA
> and development time is always super-limited
Thanks for the clarification!
//Peter
--
On 2012.12.11 00:32, Peter Stuge wrote:
> Why is that?
We maintain an array. Adding and testing array reallocation code is a
PITA and development time is always super-limited, so the smart
approach, instead of ignoring the more pressing matters to do "the right
thing" (TM), is to just use a fix
Pete Batard wrote:
> We do have a maximum limit on the number of (fake) fds
Why is that?
Are there considerations (timing? something else?) related to asking
Windows for memory as needed vs. using the current fixed size internal
array?
Thanks
//Peter
--
On 2012.12.10 18:46, Tim Roberts wrote:
> That's way too much overhead. You need to submit larger transfers at
> longer intervals. For example, think about having 10ms or 20ms kin each
> request.
I think Tim has identified the issue here.
We do have a maximum limit on the number of (fake) fds w
Mohamed HAMZAOUI wrote:
>
> From the main thread i call this function every 500micro second on
> average :
That's way too much overhead. You need to submit larger transfers at
longer intervals. For example, think about having 10ms or 20ms kin each
request.
--
Tim Roberts, t...@probo.com
Provid
Hi Pete,
>From the main thread i call this function every 500micro second on average :
static int submit_transfer(struct usb_device *dev, struct message *msg,
unsigned int lenUsbFrame)
{
struct transfer *transfer;
int status;
int i = 0;
int ret;
struct timeval tv = {1,0};
transfer = transfer_pool_
Ho Mohamed,
On 2012.11.30 10:16, Mohamed HAMZAOUI wrote:
> ret = libusb_handle_events_timeout_completed(lib->ctx, &tv, NULL);
> if (ret)
> {
> ret = 0;/* for debug */
Please don't try to hide errors under the carpet, even for debug.
Instead, can you enable debug logging and send us a log of wha
29 matches
Mail list logo
