FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - lzerman

Pages: [1]
1
Thank you so much for addressing the problem directly at hand. Sadly, I am still not successfully reading bytes yet. Between the time I posted, and I received your response I had already corrected the issues that you pointed out.  I think my problem may lay with the configuration of the camera. I still get 0 bytes read upon return:

xfer.len_psw[i - 1].size == 0
xfer->len_psw[I - 1].cond_code == 9 (SBHOST_CC_DATAUNDERRUN)
Which makes sense if it is not reading the proper amount.

I have tried multiple different Formats and Frames
FormatIndex 1 = Uncompressed
FormatIndex 2 = MJPEG

As well as different FrameIndex
FrameIndex = 1 (Default 640x480)
FrameIndex = 2 (160x120)
FrameIndex = 5 (320 x 240)

To reproduce the same MJPEG 320 x 240 @ 15fps I configure:
// Add lines between the GET_CUR and SET_CUR
VProbeAndCom.bFormatIndex = 2; // MJPEG
VProbeAndCom.bFrameIndex = 5; // 320 x 240
VProbeAndCom.dwFrameInterval = 0x000A2C2A;  // 0x000A2C2A = 66.666600 mSec (15.00 Hz)

Still no bytes read. I have attached the dump of the Logitech camera I am using to see if you may find a flaw.

1.)   When you tested, did you actually do a debug dump of the buffer that the bytes are being read into or only just view the USB Analyzer?
2.)   What chip pin count where you using in the V2Eval? (I am using 48 pin.)

Thank you again for your help on the specifics of what I am doing.

Leonard

2
Thank you for replying as well of the repeated history of the very limited scope of the WebCam demo code. I am fully familiar with every single line of that code, the SET_CUR/GET_CUR and in code can printout all of the valid values in every USB structure and the VideoProbeAndCommiteControl_t VProbeAndCom structures. I can post all of the camera USB dumps, all of the USB ioctl structure dumps, etc, but held off overwhelming the question with that much detail. That is why I took the time to create a special one-off program to demonstrate the problem in literally the shortest amount of code possible.

>>
… the USB Host (FTDI Vinculum-II) connects to a UVC camera, properly enumerates the device interfaces, end points, etc
… The Host -> UVC camera ioctl r/w work fine and all values … are validated properly against the USB dumps
<<

There are so many details of the larger program that I did not believe were necessary to cover in my initial question.

The “real” app will be reading a USB 2.0 720p@30fps when it is in MJPEG mode. I have already profiled the camera stream on Windows and Mac. On average each (and almost all) JPEG frames (in the mjpeg) runs less than 45k-bytes per frame. 30 FPS * 45k-bytes * 8-bits = 10,800,000bits/sec (10m-bit/sec) well within the 12m-bits/sec of Full Speed. If a frame gets dropped it is ok. The only thing on the USB bus is the camera since this is an embedded application. No bus contention with any other device. I considered doing BULK transfer, but the non-error recovery of ISO is (more) appropriate in this case.

Because of NDA I cannot disclose why we must use a USB camera vs the OmniVision cameras. The project started with the medical grade very tiny Omnivision OCHSA10 camera. I have been dealing directly with the medical group of Omnivision and in the end they cannot supply us what is required as they had (incorrectly) represented that they could. As well, if you are not selling at least 2-million cameras per year, (year-1 we may be 10k) you are not even a blip on their radar for their tiniest cameras.

So, can we please be moving beyond in this discussion of the hard-coded nature and limited scope of the WebCam sample and any potential help on the actual problem at hand. As I stated previously: “Bottom line; find a fix for this program and the same will work for the real program.” This is what I need help with pleeeeasssse!

I have 40-years of programming and EE hardware design experience, much of with embedded controllers. I know what I am doing with both USB and with UVC cameras, but once in a while in a career, you come across a real-bugger of an issue that can stump the best. I believe I am just missing a one-liner or even one-biter detail. That is where I am now and asking for assistance focused on the question at hand since this is what I am working on, and not a suggested change of chip to the FT90x which I am already familiar with but deemed not the right chip for this purpose.

Thank you,

Leonard


 

3
I have extracted the minimal program down to a single file necessary to demonstrate the issue I am having outside the context of the larger program. At the highest level of description the USB Host (FTDI Vinculum-II) connects to a UVC camera, properly enumerates the device interfaces, end points, etc., sets up for transfer, but in the end when it finally does a vos_dev_read() (line 511), it returns with no error, and zero bytes read.  The Host -> UVC camera ioctl r/w work fine and all values retrieved from the UVC camera (multiple cameras have been used in testing) are validated properly against the USB dumps from USB Device viewer. So, the bi-direction conversation is working great, just no video data. If I change values to invalid values or unplug the camera, I do get the expected error codes.

To be clear, this derivative program does nothing with the data read beyond it writes out to the UART terminal (9600 baud, no flow-control) the number of bytes read. Bottom line; find a fix for this program and the same will work for the real program.

I know it would be finding a Unicorn with someone who has experience with the Vinculum-II USB 2.0 chip, but I believe the issues is a USB/UVC issue and not a problem with the chip or what it is attempting to do. There is a slightly larger hive mind of UVC than the FTDI host chip. I have tried to find the magic incantation; I have tried yelling 4-letter words at the chip, and have even asked nicely, “Please” to no avail. The code was original derived from FTDI’s WebCam demo program which was very poorly written and contains a large number of un-described hardcoded numeric constants.

I have looked at every USB/UVC drivers (mostly Linux and Windows) on the entire internet. Calling all USB Host gurus for help please.

Thank you!



Pages: [1]