TI E2E Community
Digital Signal Processors (DSP)
C6000 Single Core DSP
C67x Single Core DSP Forum
BIOS and USB on C6748
I am trying to get the BIOS USB to work. I have spent a few days on it and I cannot seem to appropriately wrap my head around it. I am looking for help.
First of all the users guide is crap. It doesn’t explain anything important. Here are some of my gripes with it.
-They expect you to use their software driver package for the demo but don’t say if they are required for custom projects
-They expect you to use the DMA and don’t explain how to use it without
-They show you the build options but they don’t tell you specifically what project they are for (because they seem to love to make us rebuild their projects to get the library we want) or what file they are for, in addition they don’t explain what each option means. While some are obvious some are not and I don’t know if I need to have it on or not.
-The API is terrible. The MOST IMPORTANT functions, ConfigureUSB and dsp_bios_entry, are barely explained. They do not explain how to write your own ConfigureUSB for something OTHER than the EVM, and dsp_bios_entry isn’t even explained! It says to refer to application example for usage but the application example has no comments! What does the return mean? What is the arg? Is it supposed to be called from a task or idle? Is it like the NDK where it stays in the function or does it leave every time with a certain return value? I have no idea.
-When looking through the code for the HID keyboard device example I notice there are a lot of drivers, structures, defines that I know nothing about and are barely commented. The user guide makes no reference about any of this and as a result, if I wanted to take anything to our own project and do our own thing with it I would be stuck assuming what “looks” important.
-There is no description on how to make any other device. What if we wanted to make an audio device? I understand there are additional documents with this thing but the USER guide should help you write for whatever driver you want. At the very least tell you where to look and what you need to get started.
-The section for building the projects makes no reference to the fact that if you are not using the EVM board that you will likely have to rebuild the USB_platform project too. Also for CCS4 build it says to follow the procedure in section 7, which can’t be right because section 7 is about power management and has nothing to do with building a project
Now on to the project(s):
-There is a complete lack of comments. I have very little idea what is going on. The printf statements are useless and only print when something good happens but not when something bad happens (which is kind of the point). If there is an error there is no way to tell what is going on or why something went wrong.
I cannot get the HID keyboard device project to run on our board (unless I am mistaken, the project examples they give you can be slightly tweaked to be used with any 6748 board with a USB attached). My problem is that I get to the “dsp_bios_entry” call and it leaves that goes into the while(1) loop. In the meantime Windows is telling me that the USB attempting to connect is malfunctioning and the driver doesn’t load. I have no idea what is going on. And since the documentation is so terrible I don’t know if “dsp_bios_entry” is supposed to return and if it does what the return value means. When looking at some of the files I came across some questions:
-In config_device.h there is a reference to primus_platform.h but I cannot find this file on my computer at all. I have no idea what it wants it for. I was just told it is part of a library…still though I have no idea what it is for.
-Also in that file CONFIG_FD_MASS and CONFIG_FD_HID are both enabled. Does one need to be disabled?
-Also in the file CONFIG_DAVINCI is enabled. Why does davinci matter to a USB program? Is the 6748 considered a davinci?
-The EVM init code makes changes to the pinmux registers, but the USB doesn’t use pinmux. What is the point of those pinmux registers (from what I can tell it is turning them into GPIO)
I am sure I have more questions about it but right now that is my first rant. I don’t expect you to figure out everything for me, if you have to focus on something this is what I would prefer you focus on:
1) What do I need to do to get the usbdev_his_sample project running on my board?
2) When I am ready to move things over to my project what do I need and what don’t I need?
3) What config settings do I really need on/off in the config file?
I guess I kind of challenge you to get a 6748 evm board and run the HID keyboard device project on it and tell me how difficult it was for you. The end goal for right now is to figure out if the USB hardware on our board works and the only want to make sure it works is to load a simple project and do something simple with it. As far as I know I am doing everything in software right and the hardware is wrong.
Can someone help guide me?
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.hThey 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.aspxTantalizingly 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,
I have tested the HID dev keyboard example on c6748/Freon as well. it worked perfectly out of the box.
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.
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.
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,
Dr Peter Myerscough-Jackopson - Principal
Tel: +44 (0)23 8076 7808 Fax: +44 (0)23 8076 0602
Web: http://www.macltd.com/ Email: email@example.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.)
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, (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?
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.
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?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.