AVR with embedded USB?

Hi, all,

Just wondered why the Arduino boards are all still using the (external) FT232 chip when Atmel do parts with embedded USB transcievers (e.g. AT90USB1287)?

Are there any plans to migrate to or make an AT90 variant of the Arduino?



Hi, all,

You can even get demo boards with the USB parts in, like here: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879 ;)



1) None of the AVRUSB chips is particularly backward compatible with the CPUs currently in use. 2) Cost of ATmega168 + FTDI chip is less than any of the USB chips with equal RAM (1K or more.) 3) The FTDI chip comes with well-tested drivers emulating a serial port on all three popular desktop operating systems, making it easy for random applications to communicate with. Getting to that point with an native-USB AVR would be a lot of work (and/or expense) for someone.

There are a few of us working on this. The project is in its infancy right now. Currently, there is code to allow sketches to run on the AT90USB162, but without any support for using the USB (yet). If you're alpha/beta testing or getting involved, please contact me.

It is absolutely true that the USB portion is very different from using a UART and supporting it well will be a LOT of work. I could go on about the details, but honestly at this early stage everything is still in flux. But if you're interested in getting involved, we could certainly use help. The rough plan is to add an "easy" API on top of Dean Camera's LUFA (MyUSB) library. It's not clear yet how the host side and IDE will work and several different ideas are on the table.

Help is of course very welcome. I would particularly like to hear from you if you're able to do Alpha (not even "alpha", pre-alpha, whatever) testing with good, reproducible bug reports. That will be very helpful as the USB support is added. Unlike the FTDI chip, there are a lot of ways the USB can work with and much testing will be needed.

Regarding the hardware cost, while the bigger chips are pretty spendy, the little chips that have admittedly only 1/2 the RAM of an Arduino are very affordable.

Sounds very cool. You should post about your progress and consider writing to the developers mailing list (http://mail.arduino.cc/mailman/listinfo/developers_arduino.cc)if you've got something that you think would make sense to incorporate into the standard Arduino boards.

Do the smaller AVUSB devices have separate ram for USB buffers, or are you talking about half the ram of a mega8 MINUS the usually-substantial memory used by USB ?

All the USB chips have separate memory to buffer sending and receiving data on the various endpoints. The AT90USB162 chip has 176 bytes of this memory, which Atmel calls "DPRAM" (DP = dual port, because it can be accessed by both the processor and USB hardware), and it also has 512 bytes of regular RAM.

USB also includes flow control implemented at the hardware level (in all the Atmel USB chips), so it is not necessary (if done properly) to buffer incoming data in regular RAM. For example, the regular serial port via FTDI has no flow control (CTS/RTS is not used), so a 128 byte receive buffer is allocated in memory to hold characters your PC might send before your sketch has a chance to read them, like if it's sitting inside a delay() for quite some time. With USB, the data will be buffered inside the dedicated DPRAM and when that buffer is full, the USB hardware will automatically prevent your PC from transmitting more until your sketch finishes that long delay() and reads the data from the buffer. (actually, in reality the hardware sends "nak" packets that make your PC retransmit the data, but the point is it's all done at the hardware level so you don't need to consume regular RAM for buffering like would be necessary with regular serial).

A small amount of RAM is needed to hold a few variables related to the USB configuration. It's surprisingly small.

The USB chips do have a regular UART built in, and if you use that the regular serial buffer memory will be needed.

thanks for the info. Having the separate dpram makes having half the normal ram a lot less worrisome...

This crazy idea is now in beta test....


Interesting device, it looks like the USB can be configured so it appears as mouse or keyboard ( and presumably as a mass storage device) , is that correct?

Although it does not have a timer2, the data sheet does say it has 5 PWM channels (3 using timer1)

Looks to be a nice addition to the arduino world.

Good stuff. Couple quick questions for my amusement:

1) Does TeensyDuino software have any way to interface with the AT90USBKey devices? I grabbed two of those early on and haven't done anything with them since the Arduino's a little more permissive.

2) It says "serial:1", but just to confirm--would these allow basic TTL-style serial while simultaneously using the USB port (for say HID)? (I'm thinking in the context of a serial-interface game controller mapped to a HID device from the USB port, which I'm doing with Arduino's serial port and the UsbJoystick library but might be cleaner with the AT90USBKey's proper USB interface and LUFA).

Paul, I like the project, but you should publish all source files and schematics or be extremely upfront about your plans to not open source the teensyduino hardware and bootloader and any other exceptions.

I ran the install but did not see a bootloader created and have not seen a schematic anywhere. Are you keeping your hardware and bootloader closed? People need to know this as it is a key motivating factor when deciding to participate in a particular project or not.

Yes, the hardware most definitely is able to act as a HID, Mass Storage or almost any type of USB device. Currently, Teensyduino only adds files to Arduino for a serial type device. I intend to add other types. However, the Arduino IDE contains a lot of serial-only assumptions, so support non-serial device types on Arduino is going to take a lot of work. I am working on that....

You most certainly can use the serial at the same time as the USB. It's like having 2 serial ports. Or a HID and serial, if you program the USB to act as HID.

Teensyduino only supports the Teensy. If you have a usbkey board, Dean Camera's LUFA library, win-avr, and Atmel's FLIP tool are your best option.

Please understand that this project is very new and the website and supporting files are still under development, and Teensyduino (the software add-on for the Arduino IDE) is only in its very first beta test right now. A full schematic will be added soon. Many more examples are also planned. It is a lot of work, as so many people have said dismissively regarding the possibility of using this chip with Arduino. I'm working on a giant TO-DO list.

However, the bootloader is not open source. If you are looking for a 100% pure open source project, including bootloader source code and CAD files under a share-alike license, Teensy is not for you. It is most certainly NOT my intention to deceive anyone. Building excellent web pages is an iterative process, and the teensyduino page has already been revised substantially based on feedback from many people. Please if you have any constructive and specific suggestions, contact me directly at paul@pjrc.com

All code that becomes part of your program is open source. Everything I have added is under the MIT license, which is more permissive than the LGPL which Arduino uses. Of course the additions to the Arduino IDE are open source under the GPL, and they are placed in a "src" directory when you run the Teensyduino installer. The IDE changes have also been offered to the Arduino developer list.

About the PWM, while Atmel's datasheet says there are 5 PWM, and indeed there are inside the chip. Unfortunately Atmel decided to put 2 of them on the same pin! The web page says 4 because you can never actually use all 5. I wouldn't want anyone to buy the board or plan their project around 5 PWM outputs and later discover you can only use 4.

I personally wouldn't be interested if it is not Open Source no matter what the advantages are. The beauty of the Arduino is peopel can modify the hardware and code to their liking and there are lots of nice clone kits out there all tailored to your individual needs or you can make your own.

I'll stick with my Arduino thanks.

To be honest, it just looks like a less comprehensive but cheaper alternative to the Arduino Nano..


I'm sure this will appeal to some people, but I personally only use Arduinos for interfacing with the outside world, not my USB port.. 38Kbps is plenty fast enough for this purpose IMHO.

There's a fair bit of use for turning that USB port into a proper USB device, though (particularly a lot of HID applications). It's less to do with speed than with seamlessness. I personally would love to have a "proper USB" support rather than just bit-banging with the AVRUSB library (which I'm doing now because I want to use the Arduino).

I'm all for it, basically, just like I'd love to see a better option than SoftwareSerial for serial interfaces (even if it means a little more add-on circuitry).

Don't know if anyone's interested, but see my post "Arduino for AT90USB1287 / AT90USBKey demo board with Eclipse"

Thanks zaiq. read my reply.

As to Paul Stoffregen, I would rather you do not decieve others by using -duino. While we legally cannot stop you, -duino implies true compatibility to Arduino, not just in hardware and software but also how they share, which is in GPL/LGPL. You may see MIT as less restrictive, but we do see it as a loophole for people to decieve the openness of a platform.

Clearly you're very unhappy with me, apparently due to using the -duino suffix, and because I used the MIT license?

Would it help if I were to switch to LGPL & MIT dual license in the next release? Or maybe just LGPL and no mention of MIT at all?

That USB code was developed separately, and is also released as a stand-alone project intended for use in C language projects, totally separate from the Arduino IDE and wiring API. For that, I chose the MIT license for few reasons. 1: it's short and simple. 2: it's OSI approved. 3: everybody claims it is compatible with all other open source licenses. I specifically wanted a license that's as compatible as possible with any other project, and MIT seemed like a good idea. I never imagined anyone would take exception to that decision.

Anyway, the only reason there's MIT licensed files in there is because I copied them from my other work and because OSI says the MIT license is compatible I didn't bother to change it. But I could certainly change that to LGPL in a future release. I'm an engineer, not an attorney, so these finer license details really don't mean a lot to me, and I've based most of my decision making on the what I've read from the OSI website.

You also seem pretty upset about the name. I'd first like to point out the FAQ that appears on the Arduino website. http://arduino.cc/en/Main/FAQ

What should I call my boards?

If you're making your own board, come up with your own name! This will allow people identify you with your products and help you to build a brand. Be creative: try to suggest what people might use the board for, or emphasize the form factor, or just pick a random word that sounds cool. "Arduino" is a trademark of Arduino team and should not be used for unofficial variants. If you're interested in having your design included in the official Arduino product line, please see the So you want to make an Arduino document and contact the Arduino team. Note that while we don't attempt to restrict uses of the "duino" suffix, its use causes the Italians on the team to cringe (apparently it sounds terrible); you might want to avoid it.

As nearly as I can tell, this seems to say that the name "Arduino" is what implies true compatibility and while the -duino suffix many sound terrible to Italians, its use it not restricted.

As a practical matter, there are lots and lots of projects using the -duino suffix to communicate they are somehow intended to be used together with the Audino IDE, or an official Arduino board or an unofficial clone or unofficial non-clone or whatever it might be called. If the -duino suffix were meant to imply "true compatibility" (your message being the first I have ever seen suggesting it), the reality is the suffix is already in very widespread use for a very diverse range of projects. That really isn't so surprising considering the FAQ.

It's certainly never been my intention to deceive anyone. I've tried to be very clear. Many people have offered advise and several times I have improved the web page, trying to make it as clear as possible. In fact, it even says 'While many types of sketches can run, Teensy is NOT an "Arduino clone" due to the substantial technical differences. The Teensy hardware and Teensyduino software add-on are NOT endorsed or supported by the Arduino developer team.'

I've tried, perhaps not successfully, to apply the -duino suffix only to the software add-on that gets included into the Aduino IDE, but NOT to the hardware itself.

I'm really sorry you're so upset with me. I have listened to feedback from many people and tried to incorporate suggestions where I can. I have tried to follow the published guidelines on naming, and I've tried to follow OSI's advise regarding open source licenses. I've edited the web page many times to clarify things. I am only human and far from perfect, but I am continuing to make incremental improvements as I can.

Has anyone messed with bootloadHID recently? http://www.obdev.at/products/avrusb/bootloadhid.html

or it's parent, avrusbboot? http://www.fischl.de/avrusbboot/

It is all open source as far as I can see, though I have a feeling we've been here before :)

Paul, only problem is that random person X cannot verify your claims without ordering your stuff, because it isn't entirely open. And so who is going to send you money to help you build your credentials and reputation so you can have a monopoly on your hardware? I don't think this is the right forum for non-open projects personally.