UVC (USB Video Class) on Atmel SAM V71

Discussions around product based on ARM Cortex M7 core.

Moderator: nferre

ArturGasparyan
Posts: 2
Joined: Tue Nov 17, 2015 7:48 pm

UVC (USB Video Class) on Atmel SAM V71

Tue Nov 17, 2015 8:03 pm

Hello everybody, nice to meet you!

I'm currently working on a SAM V71 Xplained Ultra board and I'm building an application that is able to capture the video stream of a UVC compliant camera and process it.

What I've done so far is networking, including a client application, which can receive a RGB coded UDP packet "stream" and show the image live.

What I'm failing at and where I would like to ask you for advice and help is how to implement a UVC driver on the SAM V71?
I know about the example code which allowed me to compile a USB host for a mouse or a keyboard which works nicely.

There's a class called libuvc which does more or less (let's say exactly) what I need (including RGB to/from YUV conversion) but it kind of builds on top of libusb which I found out won't run on the SAM V71.

I hope that you might have good hints or projects that might help me!

Thank you very much in advance!

Kind regards

Artur
ArturGasparyan
Posts: 2
Joined: Tue Nov 17, 2015 7:48 pm

Re: UVC (USB Video Class) on Atmel SAM V71

Tue Feb 23, 2016 12:23 am

Hello everybody,

I have to come back to this one. I’ve been working nonstop on this project since my first post and I managed to use Atmel’s USB implementation and to build my own USB Vendor Host layer. Atmel offers only HID, CDC and MSC classes, but I needed UVC (USB Video Class) in order to connect my USB camera.

Tremendous difficulties stopped my advancements for weeks now and I have no idea whatsoever what to do, since I feel like having tried *EVERYTHING*.

The thing is this:

When talking with a UVC camera, there’s a negotiation, consisting of a PROBE SET, PROBE GET, COMMIT and SELECT ALTERNATE INTERFACE. These steps I do and my camera turns on (it has a nice little blue light, so I know it’s working).

During negotiation I ask for a certain frame and format (in my case it’s YUV2, 160x120 pixels) and the UVC camera acknowledged my choice! Meaning, it replied to my the same format and frame indicating that it can support it.

Now comes the difficult part. 160x120 pixels times 2 bytes per pixel (YUV2 format) yields 38400 Bytes for one frame. Choosing a different resolution, let’s say a higher one, results in a higher frame size.

BUT, no matter which format out of 5 possible ones I chose, the camera ALWAYS sends me 342160 Bytes, exactly. Dividing through 2 bytes, this tells me 171080 pixels which I cannot divide into a reasonable resolution, and it simply is not the one the camera tells me, that it wants to send.

I triple checked all necessary configurations and code copy portions, but nothing helps.

I went ahead and calculated RGB values out of the YUV2 format and transferred them via my UDP connection to MATLAB or my JAVA application and visualised in both the RGB image. The biggest issue here is, that I don’t know after how many pixels, I shall begin a new line. So I played around a little bit and this is what I found:

Breaking after exactly 182(!) pixels, yields an actual dividable resolution 171080 pixels / 182 width = 940 height!!! And this was exactly how the image looked like.

To explain, using the manufacturer’s own computer software, I captured an image and without changing the setup I used my code on the SAM V71 and received aforementioned 182x940 image. It looked correct, from a width perspective, but it looked stretched vertically, which can be also seen by its ridiculous height.

I know the camera works (since I am able to use it with third party UVC applications on my computer and the manufacturer’s software), so I’m out of luck, since I think I did everything right. I don’t know of any setting in UVC, with which one could stretch the image vertically.

Furthermore, my biggest concern currently is Atmel’s USB implementation. I’m not particularly sure what in the callback function “uhd_callback_trans_t” the parameter nb_transfered is supposed to mean. The API says “number of data transfered” - I just assume they mean bytes… Furthermore, many UVC implementation, like the one mentioned in this thread, work with USB/UVC transactions which consist of 128 packets! There is no such thing in the Atmel USB implementation. I only receive callbacks after a transfer with nb_transfered and the payload transferred. That’s all that I have and that’s all that I get…


I know this post got long, but it would simply not correspond to the hundreds of hours that put into finding a solution only for this problem alone.

Hopefully, somebody could give me a hint or a tip what I could try… No programmer of the UVC implementations I’ve found responded.

Thank you very much!

Return to “SAM Cortex-M7 MCU”

Who is online

Users browsing this forum: No registered users and 1 guest