Thought Leadership

USB – what we learned

Last week we ran a Web seminar about USB. It was very popular. We offered two shows and had well over 2000 registrations and hundreds of people attended each event – in one case the web seminar “room” was full. I hope that not too many people were disappointed. If you were there, thanks for coming along. If you were not and would like to hear about USB, the archived recording is online here.

In these sessions, I made the presentation [which was recorded previously] and then fielded questions, assisted by my tame USB guru Stephen Olsen [thanks Steve!]. The Q&A session in this type of event is often, for me, the most interesting part. That is when I learn stuff, both from what the questions are and, in this case, from Stephen’s detailed answers. I thought it might be interesting to share some of what I learned …

There seemed to be a good appreciation that USB was complex and that a bought-in solution tends to be a very good option, which resulted in many questions specifically about Nucleus USB.

The 3 key areas of confusion seemed to be:

  • The role of middleware. Middleware is the generic term for all the software components that go with a real time kernel to make it into an operating system – networking, graphics, file system etc. It is important that the USB stack interacts with the middleware in a reasonable and efficient way. The example that I cited in the session was Nucleus FILE which hands over the file system to Nucleus USB when appropriate.
  • Compatibility of USB 1.1, 2.0 and 3.0 hosts and functions. Each generation of USB has inherited the capabilities of the earlier ones and added more speed/functionality. Since control is always from the host downstream, a USB 2.0 host can be connected to a USB 1.1 function [and likewise USB 3.0/USB 2.0], but not the other way around.
  • The role of class drivers. A USB class driver is not related to a device driver. Class drivers provide a characterization of the USB device. It is likely that one or more of the standard class drivers are utilized to provide the required functionality for a device. Separate corresponding class drivers are required for both the USB host and function – they are different code as host and function USB stacks perform different operations.
Colin Walls

I have over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv

More from this author

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/embedded-software/2010/03/30/usb-what-we-learned/