Wouldn’t it be nice if there was an AVR microcontroller with USB device support built in so you would not need a separate programmer or serial link? Well in fact there are quite a few of them, and this awesome tutorial (google translate) is a quick and easy crash course in using the ATMega 16/32U4 micro controllers.
These 8 bit AVR’s (16k and 32k) have the usual list of features you would expect in a Mega AVR. 26 GPIO pins and a pretty easy to solder 44 pin surface mount package, the micro controller also has a USB 2.0 Full-speed/Low Speed Device Module and allows programming though a standard bootloader.
Once you have a pretty standard board assembled you need Atmel’s FLIP RS232, USB, or CAN device programming software (Windows or Linux) and your favorite AVR IDE setup, you’re good to go!
Join us after the break for a quick video.
[youtube=http://www.youtube.com/watch?v=IsRRNQQkat4&w=450]
nice
See: Teensy at pjrc.com
Exactly: this is what the Teensy already proposes, plus you can run Arduino sketches on it (Teensyduino).
Unluckily the teensy does not have opensourced bootloader (and i am unsure about opensource schematics and toner transfer stencil). Well… you can use opensource LUFA bootloader, but then you are probably loosing compatibility with official IDE (and TeensyDuino), or at least they can disable it in future releases.
I’d really like something like teensy, but more opensource. Ideally if i’ll be able to make it at home (It’s bit difficult, because Atmel does not have any DIP uCs with native USB support)
You might want to check out ladyada’s 32u4 breakout board.
Lufa bootloader available. Compatible with TeensyDuino.
http://ladyada.net/products/atmega32u4breakout/
Check out the Micropendous, then.
http://code.google.com/p/micropendous/
AT XMega support USB, see http://bit.ly/rfu1h6
Only those with a U suffix, which is 7 of the 26 XMega chips. Hum, they actually seem rather good! Thanks for the tip :D
Yep, it’s just a teensy.
Funny, I’m programming mine right now, I was just taking a snack/hackaday break when I read this. I’m using avr-gcc and the makefile you get from their website. Easy. I use it for all kinds of stuff in the lab. The Teensy’s got a bootloader already in it (I don’t know if they come from atmel that way or not).
Yep, it’s just a teensy ($16, or $20 for the big at90usb1286 version).
Funny, I’m programming mine right now, I was just taking a snack/hackaday break when I read this. I’m using avr-gcc and the makefile you get from their website. Easy. I use it for all kinds of stuff in the lab. The Teensy’s got a bootloader already in it (I don’t know if they come from atmel that way or not).
Can anyone summarise the difference between these and the Mega 168/328 in an Uno? Would it be possible to build an entirely Arduino-compatible board with one? And if so – why do the Uno and other clones use a separate IC for USB support?
if memory serves, when the shortage of the usual PDIP packages forced the temporary redesign of the board with the surface mount chips, they intentionally did not use any of the added capabilities of the substituted part to maintain compatibility and functionality with the regular builds. as such, it still uses the 8u2 as a usb to serial adapter like all the other unos. not 100% sure on that since it’s from memory, but it sounds awful familiar.
The Uno with an SMD chip is just an smd atmega328, not a hcip with more features.
I think you are confused the ATmega8U2 is only used as a replacement for the FTDI USB to serial convertor. The bootloader and all the arduino code still goes onto the ATmega328 DIP.
http://pjrc.com/teensy/teensyduino.html
scroll down to the bottom.
The teensy is also mostly arduino compatible.
Which leaves my latter question – why aren’t there Arduino clones with a USB AVR only, and no separate USB interface?
@Nick – there aren’t more single-chip clones because the software side is incredibly difficult.
> Which leaves my latter question – why aren’t
> there Arduino clones with a USB AVR only, and no
> separate USB interface?
AFAIK the serial pins are connected to the Arduino header pins so it is possible to communicate with shields using the serial protocol when the Arduino is not connected to the PC (or anything else) through USB. It would be impossible if the pins were switched to USB mode by default.
I use this Bluetooth shield that works that way: http://iteadstudio.com/store/index.php?main_page=product_info&cPath=18&products_id=307
That’s a good point. I don’t think it’s insurmountable, though, especially given how relatively uncommon that setup is – a few tweaks would make it work fine, and even allow you to talk to the shield at the same time as the PC.
Might want to check out the ps3 hacking community. They’re using avr dev boards to hack the ps3, only now they’re going at firesale prices. Atmega32u2 for $10, add some header pins and you’ve got a breadboardable USB uC
You must be talking about the minimus. I found it for around $10 at a few places but they all charged $9 and up for shipping.
Can you quantify that? Other than the UART issue rizsi mentioned, I struggle to see why it would be so hard to integrate – just the standard port mapping is all that should be required.
You don’t need any new/special microcontroller to run USB on AVR -> http://www.obdev.at/products/vusb/index.html
This is OK, but the XMega uC’s with on-chip USB are the sweet spot IMHO.
Avoid Teensy, proprietary locked-up stuff.
There are other USB stacks/bootloaders for AVR out there that will run on even the ATtiny uC’s, but I don’t think any of them are srictly free and open (as in BSD or MIT license). Plus the hardware USB support is so much nicer to work with and the footprint is much smaller too, really only the bootloader.
I have found ATMEL’s Web site and documentation to be less than helpful when it comes to the USB stuff.
FLIP integrates nicely with AVR Studio though, once you figure out how to get it installed and running (there’s that pesky documentation thing again!) If you have an AVR Dragon (everyone working with AVRs should), then you’ve got FLIP working already I think.
It’s amazing you characterize Teensy as “proprietary locked-up”, but then recommend Flip, Dragon, AVR Studio, and presumably Atmel’s bootloader… all of which are closed source, and most of them only work with with Microsoft Windows.
Then you even go on to complain that VUSB isn’t MIT or BSD. You want everything to be open source, but not GPL! Why would that be? The only realistic reason is to incorporate open source code into your own proprietary application!
I am the author of Teensyduino, and I have some news for you. Every last bit of code written by PJRC that gets linked into your .hex file is MIT license. That only parts that aren’t fully open source are the bits you’d need to copy if you wanted to sell a development board (eg, like Adafruit’s board which uses Teensyduino, and certainly would be identical to Teensy and destroy PJRC sales – sales which fund all the documentation and arduino compatibility work – if those bits were fully open).
If you’re developing your own project or product, even if your product will be proprietary, all PJRC-published code you actually use is very open. Among all your single-chip USB AVR options, Teensy is probably the best documented, and it’s probably the only one where hobbyist-friendly applications and documentation are under very active development. That development, amazingly, is all funded by sales of inexpensive ($16) boards.
Sure, if you use only pure Debian/GNU software and Arduino, then yeah, go for 100% ideologically pure open source. But if you’re using Windows, Flip, AVR Studio, Dragon and lots of other proprietary stuff, and especially if you’re going to avoid GPL code so you can make your own application proprietary, a more pragmatic philosophy would serve you well. If you take another look at Teensy and Teendyduino, I’m pretty sure you’ll discover all the code you actually use is not only open source, but MIT license to give you maximum freedom for your own application.
Plug my own open hardware USB device design: USB90uC, a minimal development board for the Atmel AT90USB162 USB enabled microcontroller. I designed it originally to learn how to program and interface to the AT90USB162 MCU as a first step for several other work-in-progress USB enabled projects I have which will also be open hardware/software.
Adafruit also sells an ATMega32u4 breakout board, which uses a slightly modified version of the Arduino IDE. It uses the Teensy libraries, but has its own bootloader (download the modified Arduino IDE from Ladyada.net– the instructions for modifying it yourself don’t seem to work).
This page compares the two:
http://ladyada.net/products/atmega32u4breakout/
One advantage of the adafruit board not mentioned there is that all the pins are at the edge of the board. The Teensy has some pins in the middle of the board.
Some comments have mentioned the ATxmega for its features, especially for USB connectivity, but I *urge* you to read the errata in their data sheets. I couldn’t possibly use those chips, given their ADC and a few other problems, many with no work-around. Add on top of that the relatively slim availability of the xmega lineup, and I see a poor ‘ecosystem’ for future use, support, and replacement parts.
That said, I am very happy to see another ATmegaxxUy board out there. These megas are amazingly easy to connect with the outside world, and finally allow makers to break free of the MAX232 and FT232RL chips that have enjoyed a virtual monopoly between USB and talking to your uC. Yes, I’m ignoring the AVRISP, because that’s $30, and I’m not going to include one with every product I send out the door; my users can now upgrade the firmware themselves. :)
The xmega A4U datasheet lists only 2 errata for “rev E”. It says “rev A-D not sampled”.
The xmega A4 datasheet lists TONS of errata for “rev A/B”.
Do you suppose Atmel fixed those many problems from rev A/B in these newer chips? Or maybe the datasheet is incorrect (would be typical for Atmel on new parts)?
All the erratas listed for the XMEGA-A devices that are not found in the XMEGA-AU device errata list has been fixed for the XMEGA-AU devices. This was one of our highest priorities for the XMEGA-AU devices.
We have also improved and will continue to improve our datasheets with more information and better usage descriptions. If you find that something is described in a difficult way or missing from the datasheet, or application notes for that matter, please let us know at avr@atmel.com