Yahoo Groups archive

AVR-Chat

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

Message

RE: [AVR-Chat] Re: USB HID Controller

2005-06-28 by Dave Miller

Hello Joel,

Thanks for the information it is very helpful.  I didn't realize that this
was being used in the XBOX stuff, that could explain the low cost I have
been quoted on small quantities (1000 pieces less than $2).  

Let me see if I understand what you are describing for the development
process.  I understand I can't use the standard AVR ICE, bummer.  But the
part is an AVR Core and I can still write code using the Imagecraft C
compiler I have? I can also use the ISP programmer to download firmware? But
the actual USB descriptor is stored in the EEPROM?  That I can handle as I
want to be able to map the keypad as I need.  I also have a few other
non-keypad functions that I want to handle.

FYI - I am looking at the AT43USB326 for my project.  I don't plan to
implement the HUB features.

Thanks,
Dave Miller


-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Joel Kolstad
Sent: Tuesday, June 28, 2005 8:57 AM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: USB HID Controller

Hi Dave,

For an HID device, the AT43USB355E would probably work pretty well.  
Atmel has gone and made something of a "wizard" that generates the 
skeleton of _all_ the code that goes into the part, and it's very 
heavily biased towards HID devices (in case you're not aware of it, 
Atmel specifically designed the AT43USB355E to be used in Microsoft 
Xbox game controllers... previously those controllers used a separate 
USB hub IC and a USB microcontroller, and they get the contract by 
offering Microsoft a cheaper "all in one" solution... and Xbox game 
controllers are HID devices, BTW).

> I know there has been some complaints about Atmels support for 
their own USB
> controllers, has this improved lately?  

I don't know, but as of late last summer it was only slowly 
improving.  The main problem was that there was really only one guy 
working on "continuing support" of it; you can find lots of my old 
messages about Atmel on AVRFreak.org, I believe, from that time 
period.

> I would prefer to use their product
> since I have Dev tools already.

Well, I hate to break this to you, but there's really nothing in the 
standard line of development tools that'll work for you.  The 
AT43USB355E boots from a serial PROM, and there's no hardware in-
circuit debugging support (e.g., JTAG).  The Atmel demo board for the 
part uses your PC's parallel port connection to re-program that 
serial PROM (and once you're up and running, your own firmware can 
also re-program it with not much code over USB -- this is what I 
did).  

I used standard "printf" debugging, which of course isn't ideal, but 
it worked fine for me.  I did have to drop the serial port rate to 
2400bps, though -- USB interrupts have priority over time interrupts 
(this was bit-banged serial off a timer intterupt), so at 115.2kbps 
the serial transmissions would get garbled if a USB transfer came 
in. :-)

---Joel Kolstad





 
Yahoo! Groups Links

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.