BIOS and USB on C6748

I am reluctant to say anything good about BIOSUSB, but I have gotten the BIOSUSB HID example to run a OMAP-L137 EVM (Spectrum Digital). It was fairly painless. Maybe the L137 EVM kit is better packaged and tested than the L138 EVM kit.

From what I can tell, these files are not to be modified by the end-user:
 config.h
 config_device.h
 config_host.h
They tell you what was compiled into the library and what the library expects in structures passed to it. In the BIOUSB case, CONFIG_FD_MASS and CONFIG_FD_HID means the library has MSC and HID support. The file hid_init.c hints at other functions like CONFIG_FD_CDC_ACM, CONFIG_FD_AUDIO, etc. that are probably available for purchase from Jungo.

Customizing BIOSUSB for other than HID and MSC is extremely difficult. I eventually gave up and moved the ARM/Linux side. I consider this thread is best documentation on how to customize BIOSUSB:
  http://e2e.ti.com/support/embedded/f/355/t/93931.aspx
Tantalizingly close to enough detail to writing your own Class driver on top of the Core driver. I think the thread went underground when it became a rant thread. Most BIOSUSB threads seem to go that way.

1) What do I need to do to get the usbdev_his_sample project running on my board?

I will get back to you on this. I have this sample working C6747. Need to check this one on C6748.  You may try some other samples like usbhosthid to test the hardware whether its working fine or not. 

2) When I am ready to move things over to my project what do I need and what don’t I need?

you can take this sample only to build your own project. Other than this you can start writing your own project and configuration mentioned in the configuration file. You need to enable tasks which are mentioned in the configuration file with the same function name to start the task with. Other thing needs to keep in mind is the task priority, it should remain same as mentioned in the sample application. 

3) What config settings do I really need on/off in the config file?

 as mentioned above, sample application is the minimal stuff that you need to run an application over BIOSUSB stack. You probably need to put all the things on from this sample. 

Thanks and Regards,

Pankaj Anand

Hello Json,

  I have tested the HID dev keyboard example on c6748/Freon as well. it worked perfectly out of the box.

Thanks and Regards,

Pankaj Anand

Dear USB seeker,

I'll try to save you some time.  Over the past six months many of us here tried to use the Jungo BIOS USB software, with no luck.  We all wasted a lot of time (go back and read the archives).  The canned examples of keyboard and mouse might work, but for any other purpose it is an overwhelming, many-month, multi-person research project, especially because the Jungo BIOS USB documentation is so cryptic. 

My own goal is to occasionally move a block of bytes (say, 200 bytes) into the c6748 over its USB port.  (Not video time-critical stuff.  Not huge data / mass storage / with directory structure stuff.  Just a simple, occasional transfer of 200 bytes.)  That's about the simplest thing you can do with a USB port.  But no luck.  Lots of time wasted.

About two months ago, TI folks told me they had a research team (in India) working on a USB solution.  I was excited to hear that.  So recently, on May 26th I attended a seminar at TI tech-day, called "USB: From Introduction to Rapid Development"  Of course, the "Rapid Development"  caught my eye.  I assumed TI would be announcing their new solution for USB, and I made a special point of being there. The seminar gave a lot of tedious details straight from the international standard USB specification, and then, in the closing minutes, referred us to the Jungo BIOS USB software.  Since that software is not usable, I queried the presenter afterward, and learned there is nothing new.  The title of the seminar was misleading, and many of those attendees are going to waste their time.....

So far as I'm concerned, there is no c6748 USB development, not even turtle-paced development, until TI reveals some clearer approach to it. 

Hi Walter,

I was waiting to meet you at the TIDC luncheon to go over the potential solutions to this issue. I will send you an email so we can hook up.

Loc

Hello Loc and Walter,

I have managed to implement a full usb stack for serial ports that offers 1-3 virtual serial ports and is configurable at run-time. It has been developed on the C6748 and also used on the OMAP L138. The company I am working for is looking to license it in some way. We are currently using it on products that we are shipping to customers, Please feel free to get in contact.

If you intend on doing it yourself, may I suggest starting from scratch and ignoring Jungo/BIOSUSB. I spent at least 6 months with another engineer trying to get it working. The DMA implementation seems to fail intermittently or lock up, which it is impossible to debug without the source code. On top of this the very helpful TI engineers cannot support you in developing on top of the BIOS/USB anything other than the HID / MSC classes provided, in fact it appears their hands are tied. Review the many posts from them, and replies from the likes of yourself with respect to the USB and you will see.

Hopefully you will find success in your choice,

Peter

Dr Peter Myerscough-Jackopson  -  Principal Engineer

Tel: +44 (0)23 8076 7808 Fax: +44 (0)23 8076 0602
Web: http://www.macltd.com/  Email: peter.myerscough-jackopson@macltd.com
MULTIPLE ACCESS COMMUNICATIONS LIMITED is a company registered in
England at Delta House, The University of Southampton Science Park,
Southampton, SO16 7NS, United Kingdom with Company Number 1979185 and
VAT Number GB 411942866

Dear USB Seeker, Loc, and Peter,

I have heard TI folks mention the following USB "solution."  I'll describe the steps here, as best I understand them. (You be the judge as to whether it is a solution.)

1. Dump the C6748 part, and instead use the OMAP part, which has the ARM co-processor.  This will require the extra cost for the OMAP part, because the ARM co-processor is required for the following approach.
2. A version of the Linux operating system is available for the ARM co-processor.
3. Load the Linux operating system on the ARM co-processor (this will require extra memory).
4. Use the available Linux drivers that will simulate a UART COM port on the USB port.
5. Your USB research project has now been transformed into a (somewhat easier, but still substantial) Linux research project. (But at least you can get answers about Linux, whereas your original C6748 USB port was a black hole sucking in all your time.) 
6. Unfortunately, this approach simulates a UART COM port.  It transmits only one byte at a time (each byte representing an 8-bit ASCII character).
7. But like many people here, I want to transmit a block of many bytes, say a block of 200 bytes. This would require a way to identify the first byte of the block.  It requires some kind of framing, such as a start-of-frame signal of some type.  And that must all be packed into a stream of 8-bit ASCII characters. 
8. This requires that you also write software at each end for packing, and later for unpacking, the 200 bytes.
9. This requires a message stream that will end up being substantially longer, say approximately 250 ASCII characters in length, depending on how tediously you perform the packing. 
10. This will require (approximately) 250 separate USB transmission packets, where each packet requires two layers (or is it three layers?) of USB transmit-acknowledge handshaking. In other words, to transmit your 200 bytes, it could require (approximately) 1000 separate USB message packets (including all the handshakes in both directions.

Am I being unfair in calling that a kludge design?  A Rube-Goldberg machine? 

This is good feedback. For your particular need as described, to get around the Linux serial TTY limitation, may be you can use raw HID mode. This will allow 64-byte packets. The caviat is that you need to write an application on the host PC to send and receive this data. Other options that can be explored for periodically transmit blocks of data via USB are with the iso modes.

Loc

Loc, (and other USB Seekers),

For several months now, my guess has been that the HID class (Human Interface Device) is the easiest path to USB success.  It is good to see that guess confirmed.  That's a step forward.

The HID class includes such devices as:  keyboard, mouse, joystick, game controller, drawing pad, bar-code reader, automobile simulation controllers, exercise machines, telephony devices, thermometers, audio controls and medical instrumentation. I believe it also includes credit card readers, and passports.  Even uninterruptible power supplies declare themselves under this class, despite the fact they often have no human interface at all. Any device can be a USB HID class device as long as a designer meets the USB HID class logical specifications. Their uniting feature is that they occasionally transfer a not-huge block of bytes. 

I did not know the byte limit on HID transfers. You say it is a 64-byte limit, and I presume that is free-and-clear after all the transmission overhead is subtracted. (Even so, that's a big improvement over the UART / COM / TTY approach.) 

Is that a firm limit for the HID class?  I suspect not.  I somehow suspect that many of these devices can transfer more than 64 bytes at a time.  (I hear about passports, credit cards, and medical devices transmitting lots of bioinformatic identifiers.) 

The Jungo BIOS-USB software comes with two canned examples that happen to be HID class devices:  keyboard and mouse.  These canned examples compile and work properly (or so some folks here have reported).  The Jungo libraries don't come with source code.  But in these two examples, they supply the source code for how to call their libraries.  Perhaps these two examples can be modified, to strip out the specific details about mouse and keyboard, and thereby leave an interface that simply transfers a block of bytes.  ???  That seemed like a potential path to follow, and I gave it some thought many months ago.  However, I ran into the incomplete, cryptic documentation provided by Jungo -- and I eventually gave up. One problem, for example, is the Jungo software examples treat the mouse and keyboard like slave devices, where the C6748 is the host device.  But in my application, it's the other way around -- my personal computer is the host device, and the C6748 is the slave device. 

 Loc, are you suggesting that ARM-Linux includes generic drivers for the HID class devices?

Dear USB Seekers,

I hope I'm not breaking any Forum rules by mentioning a third party USB solution.  (?)  But like you, I'm casting about, trying to find some way to work the C6748 USB port.  So I googled "USB HID", and found a marketed software package called "HIDmaker FS".  (I have no relationship with them.) From the description, it solves BOTH ends of the USB problem -- the PC and the slave device.  And does it all automatically for you. It produces all the source code for you.  Sounds nice!

Here is their description of it:

Not just a function library or a set of example programs that you have to figure out, HIDmaker FS actually generates COMPLETE, ready to compile and run, CUSTOM source code for both the PIC peripheral device, AND for a matching PC program: a finished, working Windows GUI program that runs on the PC host. All you have to do is describe the data that you want to send between the peripheral device and the PC host, using our graphical sketchpad called the Visual Data Designer.  Then, HIDmaker FS generates matched source code for both the peripheral and the PC at the same time, in your choice of programming languages. You compile that source code using the compilers you already own, and in minutes, you have the PC host and PIC peripheral talking to each other, exchanging the data that you specified.

It says it works with the PIC peripheral device, but doesn't explicitly say whether or not it works with the TI USB ports (such as the C6748 USB port).  ???  How much difference is there? 

Does anyone here have insight or experience with this?

Dear USB Seekers,

I just got off the phone with the author of the HIDmaker software package (see my previous post).  I asked him if it would work with the TI USB port.  He said the HIDmaker would completely solve the PC computer side of the problem, and also get about half way in solving the slave (DSP) side of the problem.  In other words, about 75 percent of the problem would be automatically solved. The difficulty, he said, is that the low-level routines (available to the user in assembly language code) are specific to the PIC micro-controller (I believe it's the 18F4550, 18F4450, and 16C765 families).  That code is placing data in specific PIC registers, and so forth.  That portion of code would have to be modified to instead use the TI USB-port register set.  Perhaps I'm naive, but that sounds straightforward to do. 

How different are the USB controllers on the PIC and TI?  I suspect they're pretty similar. Does anyone here have insight into this? 

He said he is too overwhelmed with other PIC projects right now, so has no plans to make these upgrades himself -- however, he is available on a consulting basis. 

Perhaps TI would be interested in pursuing a USB solution there.  Perhaps a cross-licensing agreement of some kind......

Back to the USB CDC-ACM(serial port) option. In theory, 1216 kbytes/sec with 64 bytes per packet should be possible. Host or Device drivers should be transferring data 64 bytes at a time. They shouldn't be sending data one byte at a time.

The serial port model is appealing because I believe there is a lot of existing code out there that uses a real serial port (ie. COM). The serial port model is much easier to use on the Host side than the USB HID or raw USB bulk model. Dealing with the Windows DDK can be quite hurdle.

I believe that if a CDC-ACM class was included with BIOSUSB there would be a lot less complaints. That said, for those that must create their own USB classes, BIOSUSB is not an option. Customizing BIOUSB is near impossible.

It seems that "big iron" DSPs are poor cousins to the Stellaris and MSP line. DSP developers have to pay in the development time or pay for a third party IP. TI appears to push buying a solution from Jungo. The solution offered by Peter Myerscough-Jackopson above sounds pretty good if they can productize the thing at a reasonable cost. A port of HIDmaker might be more than just low-level USB controller changes. There might be higher level changes to fit into DSPBIOS/SYSBIOS.

Does anyone have any new/good news on this front. I am now at a point that I want to utilize a USB client connection to my OMAP-L138 based board.

Hi,

I also need to develop CDC driver on 6746 (single core) which talks to PC host on virtual COM. Basically it would be a simpIe device with BULK transfer capability.

Will customizing TI's USB BIOS HID driver be a good starting point? Or any other pointers?

Thanks,

Mona Gandhi.

Dear Pankaj Anand:

     I am using TMSC6748. The usb OTG interface has interruptted me for a long time. USB bulk cannot work in bois sys.. I want that C6747 example. My email is 404155474@qq.com.

Best Wishes!

Yan