Hi Dave,
--- In AVR-Chat@yahoogroups.com, "Dave Miller" <dave@c...> wrote:
> 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
Yes, it's an AT90S8515 at its core with the USB "peripheral" grafted
on into memory space. It's a reasonably clean interface -- much
better than some USB microcontrollers I've seen.
> and I can still write code using the Imagecraft C
> compiler I have?
Nope, they only support GCC and IAR. I bitched about this but didn't
get anywhere with them. :-) Surprisingly enough, if you look through
Atmel's source code, you'll find the occasional "#ifdef IMAGECRAFT"
(whatever IMAGECRAFT really is to detect their compiler), so clearly
someone at Atmel once worked on trying to get it to work but never
finished.
Why can't you just re-compile Atmel's code yourself for any
compiler? Because Atmel considers one particular source code file
that implements the functionality of the hub portion of the IC
proprietary and will only give you the object code for it. Hence,
unless you can figure out how to get Imagecraft to support the object
file format used by IAR or GCC (I certainly couldn't), you're out of
luck.
Atmel _does_ or ("will," with a little pushing) provide all _other_
source code files for the IC (the routines for USB enumeration via
control read/write commands, basic routing routines for other USB
commands, etc.), so with effort, you could attempt to get it working
under Imagecraft without the USB hub functionality (the source code
already has #ifdefs in case you don't care about the hub
functionality). At that point, if you're REALLY ambitious, you could
write your own USB functionality code and provide the world with a
great service by releasing it publically.
Personally, I had a deadline, I was doing this as a paid project, so
I just punted, used GCC, and called it good. :-)
GCC does produce noticeably larger (and I suspect slower) code that
IAR or Imagecraft, but for free the price is right, and it didn't
matter for my project.
> I can also use the ISP programmer to download firmware?
When the '355 wakes up, it copies 24KB out of a serial EEPROM into
its RAM and then starts executing at the reset vector. How you get
that serial PROM programmed the very first time is up to you -- if
you get Atmel's evaluation kit, they have a little board with a PAL
on it and a parallel port connection that'll do it for you (the PAL
switches PROM control between the '355 and the parallel port). Once
you get the thing bootstrapped the first time, you can (with the use
of a couple of spare I/O pins) use the '355 itself to re-program the
PROM.
So... no AVRISP, no STK500, no nothing. Just you and a serial prom
and some means to initially program it...
Oh, hey, here's a nice anecdote: The programming software for AVR's
evaluation board doesn't know how to reset an EEPROM that's been
write protected (internally). I had their software crash one day and
it somehow wrote to the write protection bits, at which point I had
to go off and use PonyProg to completely erase the EEPROM!
> But
> the actual USB descriptor is stored in the EEPROM?
Technically it's in RAM, but since all RAM initially comes from the
PROM, effectively the answer is "yes."
---Joel