USB video class?

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm looking into capturing video from a couple of small LCDs built into a device with no video out. I can get the RGB data out of the bus going to the LCDs, however I can't find a simple method to send the data over to a computer for capturing. USB video class (or UVC) seems like a possible solution that can make my life easier, however I've only seen a couple of ICs that could be used for the task and they are not cheap at all. I would like to avoid implementing something like that as USB related stuff is complicated and I'm not up to the task.

 

Any other suggestions about going the USB path or over-wise? I need to transfer about 40MBytes per sec.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What will be sending this data?

 

Might a UART at 921600 be sufficient ... ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think whichever way you look, there’s going to be some effort involved. My first thought would be a fpga. There’s a lot of free ip modules that would do most of the work. Nevertheless, you’ll have to come up to speed with how it all works. Saying it’s too hard won’t help.
As for cheap - what do you define as cheap? I dare say you could find a solution for $1usd if you were buying millions. If i were building one, i use a beaglebone. Where between those two extremes do you want to be?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

slow_rider wrote:

I need to transfer about 40MBytes per sec.

This is beyond USB2 or Fast Ethernet. I doubt Beagle or RPi can do it without compressing it to a lossy format first.

 

There are FTDI USB3 devices.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The video is being "collected" using an FPGA from the LCD busses - however that is the easy part. The data needs to go into a desktop computer for capturing. Getting the data over is the big challenge. In addition I can not fit physically large connectors on the device because lack of space so mini or micro USB would do OK if I could manage to pass through the data. I would also like to avoid compression as implementing it is also difficult.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you’ve got a fpga already, then implement usb.Job done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
If you’ve got a fpga already, then implement usb.Job done.

 

That's the main part of the task I'm willing to pay extra for not having to implement on my own. This seems difficult and I don't have the time resources required to figure it out. As I wrote in the original post, I'm trying to avoid implementing USB + willing to spend money on parts however all within reason. This means no for $30 ICs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Get some engineering students to solve your problem and they can use it as part ofvtheir project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ftdi ft602 might fit your needs

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

slow_rider wrote:
capturing video from a couple of small LCDs
slow_rider wrote:
The video is being "collected" using an FPGA from the LCD busses
I must be misunderstanding something. LCD is a video (and other image) "output" device, not an "input". To collect images/video you usually use a CMOS sensor array?

 

Are you saying there is some "3rd party device" in all this that is actually outputting video and normally just sending it to LCD but you want to "hack in" to the video driving signals going to LCD to take a snapshot of the traffic? Wouldn't it be easier to have the dialog with the originating device - perhaps it will simply share it's frame buffer contents?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Are you saying there is some "3rd party device" in all this that is actually outputting video and normally just sending it to LCD but you want to "hack in" to the video driving signals going to LCD to take a snapshot of the traffic? Wouldn't it be easier to have the dialog with the originating device - perhaps it will simply share it's frame buffer contents?

 

That is exactly what I'm doing. I'm reading the RGB data from cable going to the LCD and capture frames. I'm afraid there is not much I can do regarding the source device. Its out of production for a long time, original manufacturer is gone as well. In addition there is no documentation of anything that goes on inside so I'm "hacking" it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ooph - Nasty!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
ft602

True - I'm considering it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this a one-off project or a product going commercial? That $30 chip (assuming FX3) comes with great documentation/examples/support and is available on a $50 dev board. The FT602 comes on a $70 dev board and has inferior support. How much is your time worth? How soon do you want a working prototype?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can send even pixels for one frame and odd pixels for the next frame, reducing the bandwidth in half. This brings the traffic in USB2 range. If this is acceptable, you can get away with a CY7C68 that is used extensively in cheap logic analyzers. You could even replace your fpga with some discrete gates / registers / counters.