Virtual USB-port for AVR

Mrshilov · Joined: 24 Jan 2009 Posts: 314 Location: Russia

Mr. Ollopa! What's new in your work?

ollopa · Joined: 03 Sep 2007 Posts: 233 Location: California

I ran into some unfortunate delays and setbacks. I had to rewrite a couple big sections of code and then other life problems took time away from my programming. Hope is not yet lost, though! Let me tell you where I am at:

The core of the library which is the ISR for sending and receiving is working. I have not had a chance to try to further optimize it or to thoroughly test it for bugs, timing issues, etc. I have USB enumeration about half working. In order to do further testing, I have to write a driver for the PC or create a device that uses the computer's built-in drivers. I decided my first test would be a HID class USB gamepad, since it is a very simple device and I can use the Windows drivers for it. I added sections of code for HID descriptors and I made the report descriptor for the gamepad. I pretty much just need to plug it in, see what happens, and continue debugging from there. I expect to have a chance to get back to programming in a couple days. I'm sorry for the delays! I'm frustrated myself because I really want this USB option for a couple other projects.

ollopa · Joined: 03 Sep 2007 Posts: 233 Location: California

An update on this project:

I just got back to work on it tonight. I'm still a long ways away from where I want this project to be, but I reached a significant milestone tonight. I created a 6-button HID gamepad from the example descriptors in the HID specs and got it working. (Plug AVR into USB port, Windows detects it as a gamepad, loads HID drivers, and begins polling the device for status. Buttons on my STK500 are mapped to the gamepad and work)

There are still several tasks left to complete:

Optimize Code (current size is 2.6k~2.7k)
Test/Debug on other computers and operating systems
Break the code into separate files and make it easier to work with
Add code to store descriptors in EEPROM as an option
Write some documentation
Write examples/windows drivers

I guess I'll get back to work Razz

Questions?

Evert :-) · Joined: 18 Feb 2005 Posts: 2156

Nice work Ollopa !

I'm curious to see it working in the future Very Happy

glena · Joined: 25 Jul 2007 Posts: 284 Location: PA near Philly

ollopa,

Any chance it would be able to act as a serial device?

-Glen

ollopa · Joined: 03 Sep 2007 Posts: 233 Location: California

Glen,

Yes it would be possible. It could be made to appear to the computer as a mouse, keyboard, joystick/gamepad, serial port, parallel port, modem, or your own custom designed peripheral.

Turning your project into a USB peripheral puts a lot of constraints on it, though. If you're just looking for an easy way to communicate with a PC, then a USB to RS232 adapter may end up being a better solution. It depends on what you want to do.

The AVR usb peripheral will need a 12MHz crystal (RC oscillators are not precise enough). It will also spend a fair amount of its time servicing interrupts from the USB host. Unfortunately, USB is fairly constant stream of chatter so the primary function of the AVR has to be blabbering away on the USB bus. There is time left over for other things but if your project is timing critical or has to do large calculations in a short period of time, then the load from USB communications will probably be too much.

If, on the other hand, your project does not involve measuring or generating precise timings or responding within a specific window of time, then you should have no trouble. You could, of course, use one AVR to do something timing critical and then use another to be your gateway to the PC, but in that case you could just use the FTDI chip instead.

What are you thinking of doing with it as a serial port?

glena · Joined: 25 Jul 2007 Posts: 284 Location: PA near Philly

ollopa,

I'm aware that most cpu time is spent on processing the USB bus. I'm also aware that I most likely will not be able to use any other interrupts as they would most likely interfere with the timing for the USB processing.

I'm mainly interested in using the serial drivers on the PC side as it would be the easiest way for me to talk to the AVR-USB device. It might be just as easy for others though...

Will you be supporting higher speed crystals? I understand that V-USB works with 12, 15, 16 & 20 MHz. To you think you will be able to support these clock rates?

Take care!

-Glen

ollopa · Joined: 03 Sep 2007 Posts: 233 Location: California

Oh good, I'm glad you know the limitations Smile

I'm just trying to cover my (@@) a little Laughing

Yes it's true that emulating a com port is the easiest way for your PC software to talk to the device. The operating system has generic drivers for communications-class devices like modems, but most of the usb<->rs232 dongles implement a com port using a custom class. All the ones I have seen actually use the same custom driver and it should be possible to emulate one of those commercial devices and use that driver. I've only briefly looked into what it takes to emulate a CDC modem but it's quite a bit more involved than just doing a com port with a custom driver.

After doing my research, I started with 12MHz because it is the most difficult to do. From there, higher clock speeds are easy. 12MHz, 15MHz, and 18MHz can be supported just by adding some NOPs to the existing code to maintain timing. Other frequencies are not evenly divisible by the USB bit rate of 1.5Mbps, so they require allowing the bit sampler and generator routines to drift ahead and behind in a controlled manner as close tho the center of 1.5Mbps as possible. It should be easy enough to do later. I only have 12MHz and 20MHz crystals on hand, though. I'll have to get some others with my next order of parts.

What frequency/frequencies are you interested in?

glena · Joined: 25 Jul 2007 Posts: 284 Location: PA near Philly

ollopa,

If all you get working is 12MHz I will still be very impressed and happy! If after that there are other frequencies that you will try then 16 and 18.432MHz (if possible) are of interest to me.

Thanks,

-Glen

vbb_77 · Joined: 24 Apr 2009 Posts: 14

Hello,

as comparisation: avr309

http://www.atmel.com/dyn/Products/app_notes.asp?family_id=607

...can be clocked with 12,15,16,20 MHz or from 12.8 or 16.5 MHz internal RC oscillator

ollopa · Joined: 03 Sep 2007 Posts: 233 Location: California

vb_77,

Thanks. I have seen the AVR309 appnote before, but it runs off a 12MHz crystal. I don't know where you saw

vbb_77 · Joined: 24 Apr 2009 Posts: 14

>I don't know where you saw...
>can be clocked with 12,15,16,20 MHz

here:
http://www.obdev.at/products/vusb/index.html

ollopa · Joined: 03 Sep 2007 Posts: 233 Location: California

Update:

I added the code to store descriptors in EEPROM and separated the code into a main file, a constants include file, and a library. Tested on Windows 7 and XP, on several different USB ports and on a USB hub. Fixed a few more bugs, increased SWSTACK a little. Occasionally the device fails enumeration when it is plugged in. It's fairly random and intermittent, so it will take a little while to pin down the cause.

Code size is still about 2.5 to 2.6k. It may not be usable in 2k parts after all. If somebody really wants to stuff it into a 2k part, then I suppose I could hard-code some options, remove a couple features, and employ a BASCOM trick or two in order to put out a special version for 2k parts. It would be extremely limited in what it could do, however.

I was making use of the pin toggle feature found on newer AVRs for the USB transmit routine. I didn't realize that many parts do not have the "write 1's to the PINx register and the port output pins will toggle" feature. I will have to update the transmit routine to support those parts.

I've ordered some crystals of various frequencies as discussed above, as well as several AVRs for further development and testing.

I'm running out of time, unfortunately. I have to leave town in a couple of weeks and then I will have other domestic and academic obligations until December. I hate to leave people high and dry for three or four months. I could, perhaps, release a beta version of the library that is functional but may contain some bugs, if that would be useful to anybody. I'm open to suggestions.

vbb_77 · Joined: 24 Apr 2009 Posts: 14

Hi ollopa,

thank you for all your effort with the virtual USB port for AVR. A beta version would be good so I could experience a little on my AVR.

ollopa · Joined: 03 Sep 2007 Posts: 233 Location: California

OK good news to report for today's work. I rewrote the transmit loop to support parts that don't have the pin toggling feature. I had to alter the transmit algorithm which had the side effect of shrinking the code size ever so slightly. Things are working pretty reliably. I'm thinking of shifting my attention to some examples now (until my digikey order comes in). Perhaps a HID mouse and keyboard, a joystick that returns two report descriptors and so one part acts like two joysticks, and that virtual com port we've been talking about. I'm finally at the point I thought I was going to be at a month ago Embarassed

Is the com port going to be the most sought-after example?