BIOS/USB help

Andre,

From your message I understand that you want to transfer the captured data on the SATA HDD/NAND media to the PC through USB.

To do that you could use the Device MSC example.

When you capture the sensor data to the storage Media, storage media will not be visible to the PC.  Once you complete the Sensor data storage on to the Storage media then you can expose the storage media using the msc device example application to the PC. The storage media will be visible to the PC as a drive which you can copy on the PC or analyze using the PC based tool.

Hope the above way of opertion works for your product needs.

regards

swami

swami

First of all, thanks for your answer.

Actualy, the ideia is to transfer the data storaged in the internal RAM memory. So, we can not use the MSC class because we need something that looks like real-time transfer, but for datas. In fact, we want to fill the internal RAM and, after this, send to PC.

The HID applications could work with some speed that allow this?

regards

Andre,

When you indicate that you will dump data on to the memory and then move it to the pc do you have the capture ongoing to the ram when you are moving the data from ram to the pc simultaneously?

If not then you could construct a ramdisk in the RAM and use the MSC function driver to move data.  It simplified your task significantly.

HID app is not tested for data movement.  Tested only for mouse/keyboard example.  You can give it a try though.

regards

swami

swami,

Yes, that's my case. As I see, need to configure my USB to work as "DEVICE_TYPE_VENDOR", but there is no documentation that explain me well how to do this. I've read all the usb_device_stack.pdf but i still with lot's of doubts.

My routine is like that:

This is the first (and only) routine that I call in main.

jstart_stack(&arguments)

This structure that I send as argument is where I give all the informations about my communication (isn't it?), so I put the type of the device like DEVICE_TYPE_VENDOR. The problem is that I don't know how/where to configure the rest. I imagine that it is on the dynamic FD initialization function, but how? I initialize it with NULL for test purposes. And I recieve a Failed allocating memory error code as return.

Other thing is that I don't understant what should I do with the "context", how to initialize and use it.

Certainly, I'm missing some steps.

Ty

regards

Perhaps I may chime into this thread, since my problems are similar.  I've been looking over the documentation for BIOSUSB, and I'm having a lot of trouble.  The documents are too cryptic for my purposes.  It's looking like a huge research/software project, and not friendly to the user of the BIOSUSB libraries.  These libraries are essential if you want to make a career of writing USB interfaces, and have the time to study each of the function calls, parameters, and #defines.  But all of that is overwhelming and obscure to me.  I scarcely know where to begin.  The "keyboard example" is the closest to what I want to do, yet my case is not a keyboard -- so I have to alter the keyboard example -- somehow.  But how? 

In my case, I just want my PC (host) to occasionally load some parameters (about 200 bytes of data) through the USB into the c6748.  Simple yes!  But the USB portion of my project is turning out to be vastly more cryptic and difficult than my signal processing task. I do not want or need to understand the bowels of USB interfaces.  I just have a simple task I need to get done.  Is there some documentation that makes things clearer?

Update:

I was operating under the assumption (which seemed reasonable at the time) that the BIOSUSB package comes bundled with all the necessary documents for using the package.  That assumption is mistaken, I found out.  Buried within the fine print of the hid_class_driver.pdf (in section 1.4) is a note about a "related document" called the Device Class Definition for Human Interface Devices (HID), Firmware Specification – 6/27/01, Version 1.11, which sounded like another boring ISO spec of some kind.  But this spec is ESSENTIAL if you want to modify the example code.  This spec gives lengthy, clear definitions of all the parameters and such.  It's a gold-mine of understanding, compared to the cryptic documentation that comes with the BIOSUSB package. 

This spec is available at: 

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

Walter Snafu,

As I can see, you need to do data transfer through the USB, as I need. So we need to use the Data Interface Class to do this, I suppose, or, in last case, Vendor Specific. But as I was looking some old topics here in e2e forum, I think it's only given to us the HID and MSC support, and the documentation to configure and use the other classes are poor or nonexistent. That is why I am looking for help in here.

swami sads me that HID class is not tested for data transfer. In my case, specifically, that the data transfer is more hard than yours. So, it becomes inapplicable.

In another topic I read, a user sads that he was going to adapt the MSC for his purposes.

Althought, realy thanks for your reply.

swami,

As I sad lately, I am completly lost in the implementation. In the MSC or in the HID examples, the organization of the code confuses me.

I need the answers for three questions.

Is it realy possible to configure a Data Interface Class or a Vendor Specific?

If yes, how do I implement and initialize, step-by-step, this classes?

If there is any example of this implementations, how do I get them?

As the libraries are in binary form and can not be released for us because some contract terms (I do not like this, but I understand and don't reproach), it is realy hard to explore all the features of the stack in a kind of blind mode.

Regards

Dear Texas Instruments;

Having spent some time (including nights and weekends) reading the BIOSUSB package and related documents, I'm starting to think it is all just:

• a taste
• a sample
• a teaser
• a diabolical advertisement for a product sold elsewhere by Jungo Corp!

In other words, I'm starting to think the BIOSUSB package is not much use (unless you can spend six months figuring it out). 

Has anyone used the BIOSUSB package to do anything useful?  (other than compile/build its "examples" ...)

Has anyone -- anyone not already well-versed in USB code -- actually done something useful with the BIOSUSB package? 

Its software libraries might be useful (someday), but its "documentation" is cryptic.

My task is the simplest thing you can possibly do with USB.  I merely want to occasionally (not time critical) send a few dozen bytes of data over the USB from the Host-PC to a C6748/EVM board.  It couldn't be simpler!  Yet after having spent days reading the BIOSUSB package, I haven't the foggiest idea what to do or where to begin.  I am completely in the dark. 

Am I wasting my time?  Can anyone out there verify the utility (or not) of the BIOSUSB package? 

Walter,

Pl. note that BIOSUSB stack supports MSC and HID (Mouse and Keyboard) apps as of today and the same has been documented.  The stack is not tested or validated to support custom development (and that is the need as it appears from your response).  If any of the documentation conveyed message on the contrary we would correct the same at the earliest to avoid further confusion to our customers.

If custom development is the intended need pl. work with the local TI Field engineer as this feature is currently not supported or planned for.  TI can get back to you with possible ways to enable you.

BIOSUSB stack has been integrated into customer products (as far as I know) that need MSC and HID (Keyboard/Mouse) features.

regards

swami

Swami,

The message came from you that the BIOSUSB stack could be used to do custom development !  There are many threads in the forum where you personally recommend this, for example:

"Another option would be to develop a custom class on top of the BIOSUSB stack using the API's provided in the DCD API document.    "

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/12313.aspx

"Pl. refer to the DCD api documentation on the API's needed to create a CDC class application over BIOSUSB stack."

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/12313/130296.aspx#130296

If there has been a policy change of advising customers to no longer attempt custom development using the BIOSUSB stack, then just say so.  To imply that the confusion is on our part, after having spent many hours of fruitless effort, is a little frustrating to say the least. 

Lori

P.S.  My volume of parts is low, my TI Field engineer won't give me the time of day.

swami,

If it is not possible, say that in the first reply. I'm working on USB communication for more than one month and getting no progress.

I lost precious time in something that will never work.

My suggestion to TI: Improve this stack (preferably with another partner) and rewrite all the documents.

Ty.

André

swami said:

Pl. note that BIOSUSB stack supports MSC and HID (Mouse and Keyboard) apps as of today ...  The stack is not tested or validated to support custom development ...

Ordinarily, simple things are supported, and complicated things are not.  Ordinarily, it is the complicated things that require custom development.  But it's the other way around with BIOSUSB, where the simplest things are not supported -- instead they are labeled (and brushed aside?) as "custom development" -- while the complicated things (like MSC and HID-mouse-keyboard) are "supported" -- so long as you do not stray far from the canned examples. 

If you want to test-drive a demo that prints "Hello Jungo!" on the screen (thereby demonstrating that Jungo Corp can do USB), then BIOSUSB will serve you well -- otherwise BIOSUSB appears nearly useless. Trouble is, the documentation for the "supported" items (like MSC and HID-mouse-keyboard) are so tediously cryptic that we cannot throw-out the complexity we don't need, so as to get back to something simpler.  So far as I can tell, this seems intentional on the part of Jungo Corp.

Can anyone out there testify that they have succeeded in doing something useful with BIOSUSB?

Lori,

My apologies that I was not completely clear (or if I have mislead) in my communication and hence the confusion caused.

BIOSUSB stack is validated only for the application that come pre-packaged in the stack - MSC, HID (Keyboard/Mouse) and hence these are the only apps that are supported.

DCD API based development was an option that I recommended looking at the custom class development needs that I saw at that point in time.  No reference apps are available to validate this feature.

To make things clear BIOSUSB stack does not support custom app/class development as of today.

You still pass on your needs to the TI engineer.

regards

swami

swami,

Thanks for the reply.  It won't help our current situation, but I have a few additional comments.  Providing binary code with no source is worse than providing nothing at all.  I realize that this is the agreement that was made with Jungo, but it really just leads us to believe that there are drivers available when in fact they are not usable for many applications.  Second,  example code that would work with WinUSB would have been nice.  This is a generic Windows USB driver that provides what most of us need - a control endpoint,  a bulk-in endpoint and a bulk-out endpoint. 

Regards,

Lori

Lopi, or is it Lori? said:

....example code that would work with WinUSB would have been nice.  This is a generic Windows USB driver that provides what most of us need - a control endpoint,  a bulk-in endpoint and a bulk-out endpoint. 

Yes!  I second that!  We need something simple and straightforward (without the complexity and specificity of mouse/keyboard/MCU drivers). We need a generic Windows USB driver that provides a control endpoint -- for occasional transfer (not continuous transfer, not time-critical transfer) of small blocks of data (not Megabytes of data, not a file-system with directories and such). 

This has got to be the easiest possible thing to do with a USB, yet it is not available for c674x. The c674x USB sub-system is effectively dead-in-the-water.  As an interim measure, I recommend putting a note/warning on the BIOSUSB package that accurately describes what users can and can't reasonably expect.  That would have saved many of us a lot of wasted time.

Lori,

Appreciate the valuable feedback and your understanding.  Let me take this feedback (and others expressed elsewere) internally and see how best to help you and other customers.  If you get the opportunity pl. provide the same to TI field folks.

If I may summarize I see the below features as being requested based on this and other threads

• Custom Function driver class reference to transact data over
  • Interrupt endpoint
  • Bulk (in/out) endpoint
• CDC (serial) function driver.

regards

swami

swami,

In my case (using OMAP-L138) could I use Linux SDK in a Linux VMware to control the USB data transfers with ARM core, as my first intent was using ARM to control the acquisitions and transfers and the DSP just to process data?

Sorry if I was rude in any earlier post. The moment was not good.

Ty

André

Andre,

Yes you can use the Linux USB driver for the said tasks.  It does support broader set of features as compared to BIOSUSB stack.  Pl. note that you would be running linux on L138 (not vmware).

regards

swami

swami said:

[...] Pl. note that you would be running linux on L138 (not vmware).

[...]

But I need a Linux workstation to run this features? Or I misunderstood in this explanation?

Ty

André

Excuse, dear TI Employee swami !

But,  after all, are ANY examples how to translate data from  OMAP-L138 DSP core to WinXP   through USB-port? And back?

Does TI employees do anything in this way?  In that time we may see such  example?

regards.

Swami,

9 Months have passed since. Meanwhile did a solution for simple but reliable USB communication using the C6748 become available?

Thanks,

Peter