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._________________Adrian Jansen
Computer language is a framework for creativity

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.

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._________________Adrian Jansen
Computer language is a framework for creativity

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)

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._________________Adrian Jansen
Computer language is a framework for creativity

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.

The same problem we have with the usb-avr's from Atmel like the usb162 and usb1287.
The usb needs a clock of 48mhz, so the crystal must be 8mhz or 12mhz. This will be intern multiplied.
The Usb1287 that i'm using a lot must run on 8mhz otherwise the usb won't work, the disadvantage is indeed that the uart is not running perfect, however it works perfect now for 1year at 38k4.

One of the disadvantage of the FTDI is that you can not decide yourself when flushing the internal buffer. This will give unregular delay in "realtime" transmission, maybe packet burst is a better name.
With dedicated usb chips like the atmel's and Ollopa code you can do this yourself. You still have a delay, but it's now regular and that's easier to compensate in the software._________________www.evertdekker.comBascom code vault

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.

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.

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 !_________________Adrian Jansen
Computer language is a framework for creativity

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum