Virtual USB-port for AVR

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

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

Can anyone write a library for BASCOM to use this subj? It needs for many application. Pleeeeeeeease!

pedro · Joined: 24 Apr 2009 Posts: 128

Hello

Show this. I is Usb direct to Attiny2313 in Bascom without extra chip, but compare the schematic with the Bascom code i not understand how can this work.

Regards
Sato

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

I'm in the process of writing a firmware USB library for BASCOM.

OBDEV has a nice implementation but I don't want to copy theirs because of the infectious GPL license.

My results so far are promising. I'm about 80% through. I think I will have a library available for testing in about 1 week.

I plan to release it under a licensing structure similar to ARV-DOS, including a binary-only library that is free for personal use.

pedro · Joined: 24 Apr 2009 Posts: 128

Hello ollopa

That's great, all people that programming in Bascom will gratefull

Regards
Sato

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

I too would love to see someone make this work! If possible I'd like the DTR line out as I use it for the reset line when serial boot loading to other avr chips.

Thanks again!

-Glen

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

I dont see that you gain much over what you can do with an AVR connected to either an FTDI FT232 or 245 device. You tie up a fair bit of the AVR resources in doing the USB, rather than pass it off to a chip already well capable of doing just that job. Extra cost is almost negligible for small qty, compared to the time writing and integrating in the USB code, so unless you have some killer app selling in thousands, I cant see much advantage.

I would like to see an app that REALLY needs this, and could not be done any other way. The only one that I see would be a bootloader, where you dont want to add an extra chip just to provide that rarely used function.

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

Damn, the forum ate my reply! I had typed up a big one too.

AdrianJ: You are right that in many cases a dedicated chip is a better solution. The FTDI chips, however, are limited to emulating RS232 and parallel endpoints as far as I know. There are times when you want to make a custom class device or a HID class joystick or keyboard and then the FTDI chips are no good.

"Can I make FTDI devices appear as a different device class?
Return to Introduction Previous page Next page
FTDI have defined our own device class, so FTDI devices return a 0 for the bDeviceClass (Vendor class).

The class cannot be configured by the designer.

Our devices do not return the correct USB device descriptors to be USB HID class or USB Mass Storage class. It may be possible to write a filter driver that will make our chip appear to be a HID or mass storage class device, but to do this would involve a lot of work."

So there ARE cases when it is better to do a firmware implementation.

For what Glen is talking about, it doesn't make sense. USB is not RS232. USB is a multi-layer packet-oriented protocol with several important limitations.

Anyway,

An app that needs this would be a HID class keyboard or joystick. Can't do it with FTDI. Nice thing about HID class is that you don't have to write any custom drivers for the PC. When I'm done with my library and my project, I will put up a site with documentation and examples.

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

I look forward to seeing your progress. I must admit I think much more about using AVRs as stand-alone controllers and data collection devices than as PC peripherals.

ex4 · Joined: 13 Jan 2006 Posts: 1062 Location: indonesia

to ollopa : may we know in what avr type it would fit? quick preview of the technical spec maybe Very Happy

very nice research you got there
hope it will be release soon

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

You need a part with at least 2k of flash. The USB code will use about 40 bytes of SRAM for one USB endpoint (+12 bytes for each additional endpont).

Two IO pins on the same port. One must be an interrupt pin--preferably Int0 because it is the highest priority.

A 12MHz crystal must be used. Timing is very critical and it must be exactly 12.000MHz. (in the future, the code may be modified for faster crystals like 15MHz. 12MHz is very hard to do, so I did it first. After that, it is easy to extend the code)

USB voltage levels are 3.3V. You can either run your AVR at this voltage or use zener diodes to clamp the IO pins. I will show schematics later, or you can search online. The important note is that if you use zener diodes, get small ones and get 3.6V zeners. 3.3v diodes will start to break down around 2.7v, which is technically too low for the USB spec.

So it should run on all the standard-voltage MEGAs and all but the smallest TINYs. (V and L parts are too slow)

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

One real nuisance I can see with using this firmware USB as a bootloader, is that you MUST use a 12MHz crystal. That means your app must use that frequency too, unless you want to swap crystals just for a program load.

12 MHz is hopeless for UARTs. 7% error at 115200 baud, 2% error at 38400.
I suppose if it will work at 12 MHz, it can be adapted to work at 14.74 Mhz, the next nearest useful UART frequency.

But that still means recompiling a lot of programs, and adjusting timer prescalers. Especially for many apps running at low speeds or timing long intervals, you probably run out of timer range, which can be a pain.

I think I prefer being able to select processor crystal frequency to suit the application, than to suit the USB requirements.

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

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

Well 19200, 28800, and 57600 work fine with an error 0.16%. I use 57600, myself (MEGA644). The crystal requirement is because low-speed USB works at 1.5Mbps and does not tolerate any error. 12MHz allows for 8 cycles between bits, 15MHz allows for 10, 16.5MHz gives 11. 14.74, on the other hand, would be 9.826666 cycles between bits. You can see that the error would accumulate and it would be impossible to maintain accurate USB timing at that frequency.

There are definitely trade-offs that need to be considered when bit-banging USB on an AVR. I think a lot of people have misconceptions about how USB works, too. It's not like RS232 where you just connect two devices together and start sending data back and forth. Data are sent in packets of limited size with headers and CRC footers. The host (the PC) always initiates communication. Even if the device (AVR) has a burning message to transmit, it has to wait until the host requests the data. There is a whole enumeration phase that the device must go through when it is first connected that describe in detail all its specifications and requirements to the host. The PC uses some of this information to search for drivers or to decide how much power to make available to the device. The minimum polling time is also specified and for low-speed USB devices this is no less than 10ms. That means there is at least 10ms latency in all low-speed USB communications. If you specify 10ms polling interval, then the AVR will be busy processing USB packets all the time. If you specify a less frequent polling interval, then there will be greater latency in the communications.

USB passes information in virtual "pipes" that terminate at different "endpoints" on the device. That's how some devices might have a keyboard AND a mouse, but only one plug. Or a scanner, fax, and a printer. Each virtual device likely has its own separate endpoint. Low-speed USB (which is all the AVR can do in firmware) supports only the default control endpoint (which is bidirectional) and two additional unidirectional endpoints. I know it's funky and somewhat confusing and I swear I am not making this up. I have no idea why supplemental pipes were decided to be unidirectional.

The full usb1.1 spec is available for free on usb.org for anyone who is interested. It's a long read and it doesn't even begin to cover HID class, which is something I think people will be interested in. There is a separate document that describes HID descriptors and how all that works.

Suffice it to say, rolling your own USB peripheral is not for the faint-of-heart. It still is of great interest to myself and undoubtedly others. I was planning to wait to announce my work with BASCOM in this area, but this was the second request for firmware USB that I have seen and I thought I should mention something.

A complicated subject like this will generate a lot of questions and require both a healthy set of documentation and lots of examples. USB is very open-ended. Just like programming, there are several ways to solve the same problem and I cannot say which way will be the best for anybody else's particular project. The library I am putting together is the Serial Interface Engine (SIE) part of the protocol. It gets and sends the raw USB packets with a minimum of automated processing. That leaves all the possibilities open to implement whatever kind of endpoints and communication protocols you choose. Again I plan to demonstrate how to do that through examples--I'm sure most of what I am babbling on about is confusing unless you have some prior USB experience.

For anyone who really wants to get into this, I recommend the following two condensed introductions to USB:
http://www.usbmadesimple.co.uk/
http://www.beyondlogic.org/usbnutshell/usb1.htm

They give good explanations of the data flows and basic descriptors of USB. After that, what I just said above will make more sense.

HID is a wholly separate topic and some tools and resources on it can be found here: http://www.usb.org/developers/hidpage/

I think this is the last big post I will make until I have some code to show. I have my work cut out for me if I'm going to deliver on all these promises I have made. I have basic sending and receiving working right now. ACK and NAK working fine. I'm extending the code to handle multiple endpoints and to properly track DATA0/DATA1 toggling for each endpoint (I refer you to the spec or those condensed links I posted for further explanation). I spent weeks working on the assembly ISR so that it can decode the captured serial stream in real-time. You need about 9 or 10 instructions to read and decode each bit, but at 12MHz you only have 8. There are lots of tricks required to optimize the routine and make it work and I will just leave it at that. The hard part is working and I just have to extend it for those optional endpoints and write up some examples.

Luciano · Joined: 29 Nov 2004 Posts: 3149 Location: Italy

Hi,

Here's some additional reading:

AVR309: Software Universal Serial Bus (USB)
www.atmel.com/dyn/resources/prod_documents/doc2556.pdf
Author: Igor Češko

Igor Češko WEB site:
>http://www.cesko.host.sk/IgorPlugUSB_RS232/IgorPlug-USB%20(AVR)%20RS232_eng.htm

* * *

Implementing USB 1.1 in Firmware by Christian Starkjohann
http://www.obdev.at/developers/articles/00003.html

Best regards,

Luciano

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

Yah ! I too read through the USB spec, and decided it was all too hard. Great for PCs and their standard peripherals.

You have done a lot of work to get so far, congratulations. I am glad someone still does this sort of heavy ASM processing, but in this case I'm also glad its not me.

The transmission delay lags I dont see as a problem, at least for any of my apps, I dont need real time response, just a way of transmitting data to/from a PC with only a USB port. But certainly for a HID type device it could become an issue.

Have fun !