Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: USB and ATmega

2005-01-05 by Joel Kolstad

--- In AVR-Chat@yahoogroups.com, Kathy Quinlan <kat-yahoo@k...> 
wrote:
> I have the dev kit for the 355M, but I find it hard to use due to 
lack 
> of documentation and example code for beginners, but I am hopping 
that 
> after reading Jan ALexson's USB for embedded design (I think that 
is the 
> title) I will get a grasb on the subject and be able to do 
something 
> useful with them :)

You'll also want to check out the USB developers forum 
(http://www.usb.org/phpbb/); there's been plenty of discussion there 
about the AT43USB355E (and variants), and Jan Axelson shows up 
occasionally as well.

I used the AT43USB355E to implement what was effectively a USB <--> 
I2C interface with a few extra bells and whistles last year.  The 
problem, at the time, was that the code that comes with the Atmel 
development kit is heavily biased towards building a human interface 
device such as an X-box joystick (this is what the AT43USB355E was 
initally designed by Atmel to do!); they do NOT give you all the 
source code you need to build a 'general purpose' USB device.  
However, if you pester the appropriate people at Atmel (see the USB 
IF forum for details), you CAN get all the source code except for 
one file that contains the functionality of the hub in the '355E; 
Atmel considers this proprietary, and given that no one else seems 
to be handing out hub source code, that seems reasonable enough.

Overall, there's a lot more work if you use the '355E than if you 
simply use an FTDI chip.  What you gain, however, is better 
throughput (speed) in the system (compared to the serial FTDI chips) 
and the ability to have your USB device looks like 'whatever you 
want it to' rather than 'just' a serial port.  You're also adding 
another chip with the FTDI approach, of course.  On the downside, 
for the '355E you'll also have to write your own USB device driver 
(highly non-trivial if you haven't done this before, although there 
are toolkits out there that make this a lot easier if you can afford 
them -- we used DriverX USB) unless you make the '355E look like a 
human interface device (HID) -- which pretty much negates the speed 
advantage that you otherwise would have gained.

Hence, if the FTDI chip will work for your project, unless you're 
going into mass production (where the extra cost of the FTDI chip 
more than pays for the added development costs), or unless you're 
interested in learning a lot about low level USB (this was my 
motivation), it's pretty hard to beat the FTDI approach.

BTW, there's a web site out there about a guy who implements a low 
speed (1.5Mbps) USB peripheral strictly via 'bit banging' the I/O 
ports.  Once you get done reading Jan's book, you'll realize just 
how impressive that feat is!  Interestingly, he did it using one of 
the older devices (this was a couple of years back), and since then 
the newer devices such as the tiny2313 have come out with faster 
clock speeds and more memory that would be even more attractive for 
this purpose.  It's a HUGE amount of work to do this (the guy with 
the web site said he spent six months working almost every night 
after work getting to the point where Windows would recognize his 
device), but it'd be a great benefit to the AVR-using community if 
someone did.

---Joel Kolstad

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.