Hi Amit, On Thu, Jul 14, 2011 at 5:20 AM, Amit Nagal <helloin.amit@gmail.com> wrote:
Hi ,
In my embedded linux-arm target , in a userspace thread , i am reading hid events over usb-hiddev interface (/dev/hiddev) .
basically what i do is this :
read_thread(){ while(1){ ret = read( "/dev/hiddev" , user_buffer , bytes_to_read); printf("bytes received =%d" , ret ) ; // (printf prints debug message to serial console ); } }
now whenever i use the printf statement in read thread , kernel space ring buffer in usb-hid driver is overrun frequently , which results in loss of data send by usb device . if i remove printf in read thread , no overruns are reported in usb-hid driver . that means if printf is used , application read_thread is not able to read data in time which leads to driver ring buffer overrun .
does this behaviour of printf points to some problem in embedded linux's scheduler ( printf prints data to debug serial port , and consecutive read() calls in read_thread() are scheduled lately due to that ) ?
No - It points to the fact that you're trying to generate more bandwidth than the serial port can process.
do the actual implementation of printf involves any kind of sleeps ?
Absolutely. Let's say that your serial port is running at 115K baud. That means that you can send approximately 11,500 characters/second. If you try to generate higher bandwidth than this then you will eventually fill whatever buffers exist, and then you'll sleep waiting for space to become available in the buffer.
kindly share necessary insight wrt above printf usage and driver ring buffer overrun .
For situations like this, you typically need to log to a memory buffer (I normally use a circular buffer of some type and have new entries overwrite old entries). Then when you're finished, you can dump information from the memory buffer. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com