Hi Enrico, On Sunday 28 June 2009 13:18:18 Enrico Di Lello wrote: > Hello everibody, > > I am currently working on integrating a camera on small robotic > platform. The robot mounts a FoxBoard running an embedded 2.6.25 linux > kernel. The camera I am using is a Logitech E3500, which works pretty > much ok. The camera is connected via a USB 1.1 port, so it looks like > that, even setting a very low frame rate, 176x144 is the maximum > resolution allowed for YUYV format.
Most cameras don't have any video frame buffer, so instead of sending F------R------A------M------E------F------R------A------M------E at low frame rates they just send FRAME------------------------------FRAME------------------------ The required bandwidth is thus quite high during short bursts, making it impossible to stream high resolutions in uncompressed formats. > Anyway, even thought my issue is not directly related to the uvcvideo > driver, I hope that some of the people reading this newsletter could > help. > > When grabbing frames, everything goes fine. > The problem arises when trying to acquire frames and reading from a > serial port (not necessarily at the same time). If one application is > reading data from a serial port, it gets interrupted (pretty much > randomly) after that another application does the VIDIOC_STREAMON > ioctl call, even if it is not grabbing frames yet. What do you mean by "gets interrupted" ? > Probably the issue is related with the USB DMA configuration of the > FoxBoard, but I would like to ask if it is possible to lower the > priority that the linux scheduler assigns to the uvcdriver somehow, or > have a little more detail about how the driver behaves in this > context. The Linux kernel scheduler assigns priorities to processes, not to drivers. The uvcvideo code is run either in userspace context (ioctl handlers for instance), in which case the code runs using the priority associated with the userspace process, or in interrupt context (URB completion handlers), in which case the concept of priority isn't really relevant, as the scheduler won't interfere with interrupts (except when using threaded interrupt handlers which are a very new and experimental feature). Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
