avr-chat
[Top][All Lists]
Advanced

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

Re: [avr-chat] ATmega164P/324P/644P and Dragon Rider (was JTAG Debug)


From: Peter LaDow
Subject: Re: [avr-chat] ATmega164P/324P/644P and Dragon Rider (was JTAG Debug)
Date: Thu, 20 Nov 2008 10:32:58 -0800

On Thu, Nov 20, 2008 at 9:19 AM, larry barello <address@hidden> wrote:
> I fail to see what the complaint is about.  An awful lot of code can be
> wrangled in 32k of flash on an AVR even with a C compiler (I have > 10kloc
> and just recently broke the 32k barrier and that is mainly because of fonts
> and graphics..)

I have worked on AVR projects (in my former job) that didn't
necessarily use a lot of memory, but it did exceed the 32k barrier.
For a couple of reasons:

1.  There was a bootloader.  And since the bootloader lives in the
upper end of flash, I presume support for the full flash space would
be required.  And debugging the bootloader (especially writing new
firmware to flash) requires that the code actually run in place.

2.  We used a "module" approach in our architecture that could be
written to flash.  In order to ensure expandability, we allocated the
flash into segments, each available for module use.  We used the
ATmega128L, and allocated the bottom 64k for the main firmware, then
everything else beyond it and up to the bootloader was for module
space.  This already went beyond the 32k requirement.

My current project will also use a bootloader.  I plan to ensure that
the devices are field upgradable, and I don't know how the Dragon or
other clone could debug such an item.  I know there are existing
bootloaders, but I plan to incorporate things that aren't typical in
(open source) bootloaders, such as a command interface, XModem
firmware download, signed/encrypted firmware, etc.

> AVRs are so compatible it is fairly easy to develop major blocks with the
> Dragon (or clone JTAG and legacy mega128) and then change the CPU type for
> your target, download it and just have it run. After that one can use printf
> debugging (my case using C) or in David's case his DSO &  bit twiddler.
>
> So, Atmel made high end JTAG and DebugWire debugging absurdly affordable
> with the Dragon - but only those who can't afford an extra $250 might have
> the time to kill to develop small and bolt blocks together on larger chips.
> I guess it all depends upon how much you value your time...

Fair point.  One can do a lot with this method.  But not all.  I
personally would be able to afford the extra $250, but I don't want to
(and my wife certainly doesn't want me to either!  That O-scope
purchase is in her too recent memory :) ).  And I find the convenience
and power of the MkII more than worth it.

In my case, I would probably defer the purchase until I could convince
my wife I wasn't being too extravagant.

> Another route is to pay attention to those Atmel seminars.  The last one I
> attended was for the AVR32 UC3 series (last summer): $100 got me a nice
> lunch, complete toolset including a (second) JTAGmkII, nifty dev board and
> help setting everything up and compiling a HID for the dev board that made
> it into a Wii like mouse for the PC.

Like others mentioned, this is great if 1) you live near a city that
has these events (I don't), or 2) you can convince your company to
send you to one.  My current job doesn't work with AVR at all (we use
all custom ASIC's with embedded ARM processors), so I'm not likely to
convince my boss to send me to an AVR seminar across the country.

However, a kindly soul on the list hooked me up with an MkII, so it is
all good now.

> BTW. I have issues with the Atmel tools, but for the most part they are my
> misinterpretation of the chip spec, programming model or something about the
> tool that is easy to work around once I actually read the manual and find
> out what the limitation is :)

I too have experienced issues with the Atmel tools.  But overall I
have found them quite good.  At my last job we were using the
ImageCraft compiler toolset, and AVRStudio worked quite well with the
COFF output.  I occasionally had trouble getting the processor to
stop, but like you said, once I figured out the intricacies things
were fine.  I've had more trouble with "professional" toolsets (such
as BDM pods from GreenHills) than I have had with the Atmel tools.

Pete
-- 
--
"To love for the sake of being loved is human;  to love for the sake
of loving is Angelic."  -- Alphonse de Lamartine




reply via email to

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