avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] using the 43USB355 (was - Using IAR compile d lib


From: Tim Lapawa
Subject: Re: [avr-gcc-list] using the 43USB355 (was - Using IAR compile d lib with GCC?)
Date: Thu, 4 Sep 2003 12:12:30 +0200
User-agent: Mutt/1.5.3i

Hi Keith,

can I use this app with my AT43USB320?

On Wed, Sep 03, 2003 at 04:20:49PM -0700, Keith Gudger wrote:
> I posted, on avr freaks general and gcc forums today, a zip file with a
> USB HID app for the AT43USB355, for GCC.  It includes documentation and a
> PC app to examine the 355 over the USB bus.  The PC app is in MSC, and I
> need to convert it to GCC.  I can't seem to figure out how to use the USB
> HID stack in cygwin however - anybody willing to offer advice?  Thanks.
> 
> Keith
> 
> On Wed, 3 Sep 2003, Tim Lapawa wrote:
> 
> > Hello,
> > 
> > it is not necessary to get the source of the hubs firmware. I would be 
> > pleased with a 
> > library for the GCC.
> > With it I could start building the firmware for my actual project.
> > For easy entrance to the library a good example project would be great. 
> > The documentation delivered with the SDK is scanty. It is hard for me to 
> > find out 
> > how all these descriptor structs and global data pointers fit together.  
> > Since the mentioned 
> > table numbers from the source comments are from the older USB 
> > specifications.
> > 
> > I do not need the hub functionality at the first phase of my project. 
> > Perhaps you could build a closed source library for the GCC. And we all 
> > would be
> > able to start with our projects. At least for the devices 320  and 355.
> > 
> > Greetings
> >     Tim Lapawa
> > 
> > On Tue, Sep 02, 2003 at 09:14:56AM -0700, Keith Gudger wrote:
> > > Bryan:
> > > 
> > > I'll get to work on the boss & code (in that order :).  
> > > 
> > > What (we think) is nice about our current crop of AVR / USB devices is
> > > that a lot of what others do in hardware is left to firmware.  That gives
> > > us a lot more flexability.  In my chats with other USB chip/firmware
> > > developers, I hear some amazing horror stories about what you cannot /
> > > have to do when most of the stuff is in hardware.  I'm sure the
> > > participants on this list can appreciate this...
> > > 
> > > There are 2 components of the firmware:  hardware configuration and USB
> > > interrupt / response routines.  Configuring the hardware is easy.  All of
> > > the many interrupt routines to satisfy the USB requirements - that's a lot
> > > of effort.  The code must pass chapter 9 (and chapter 11 for the hub).  To
> > > save code space, our library uses the same routines for the hub and the 
> > > function.  That's why there isn't a separate hub and function library.  We
> > > put a lot of effort into using pointers and structures so that we could
> > > reuse the code.
> > > 
> > > BTW, if you crack open an x-box controller, you'll find the AT43USB355.
> > > Winning that design required a bulletproof library.  That's partly why we
> > > say the USB libraries have been thoroughly checked out.
> > > 
> > > Keith
> > > 
> > 
> > -- 
> >                 \\\///   
> >   Tim Lapawa    (o  -)   address@hidden
> > -------------oo0-(_)-0oo----------------------
> >  http://www.lapawa.net/GnuPG_public_key.asc
> >    ,ooo0                 Where do you want
> >   (     )         0ooo,     to go tomorrow?
> > ---\   (---------(     )----------------------
> >     \ _ )         )   / 
> >                  ( _ / 
> > 
> > _______________________________________________
> > avr-gcc-list mailing list
> > address@hidden
> > http://www.avr1.org/mailman/listinfo/avr-gcc-list
> > 
> > 
> > 
> 
> 

-- 
                \\\///   
  Tim Lapawa    (o  -)   address@hidden
-------------oo0-(_)-0oo----------------------
 http://www.lapawa.net/GnuPG_public_key.asc
   ,ooo0                 Where do you want
  (     )         0ooo,     to go tomorrow?
---\   (---------(     )----------------------
    \ _ )         )   / 
                 ( _ / 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]