The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
From: Chuck Simmons
Organization: You jest.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.33 i586)
Subject: Re: Which Microcontroller to use?
References: <3D8A6BE9.6455BB7@webaccess.net> <3D8A8F7D.865B97EB@webaccess.net> <2Jxi9.email@example.com>
Date: Fri, 20 Sep 2002 06:23:24 GMT
NNTP-Posting-Date: Thu, 19 Sep 2002 23:23:24 PDT
Dave VanHorn wrote:
> > It is an incredible luxery in realtime MCU code to know "exactly what's
> > happening at any given moment." I would almost kill for that happiness.
> > Unfortunately, I have to handle up to 11 completely asynchronous
> > interrupts with some being time critical and others not.
> Sounds about normal to me.
> My current app has 21 populated vectors, out of a possible 34 on this
> processor (AVR Mega-128)
When I was approached to help with the architecture, they didn't want me
to use interrupts. I went sort of non-linear and they conceeded me some
and I expanded a bit in the design phase. I have three custom mega-103
cores in one chip with no external bus at all and no boundary scan. I
insisted on the UART from the AT90S8515 since it only costs two pins.
> >Bugs are all
> > the nightmare sort where somebody stepped on somebody elses data in some
> > archane way and you can't see how it happened because its a buried MCU
> > not to mention the fact that breakpoints make no sense in such a
> > situation.
> ??? The only way that happens, in my experience, is when I screw up
> I do a couple things that help protect me. I dedicate one register to
> storing the status register during ints. I dedicate one or more registers
> for use in ISRs. I avoid pushing data onto the stack wherever possible.
> The worst thing I've hit in the last couple years was a typo where I was
> using TEMP instead of ITEMP in an ISR.. Way bad.. But way obvious, and easy
> to fix.
I have 40 MHz cores so I save all registers I intend to use. I have
avoided dedicating registers. At 40 MHz, context switch is not a big
deal. The problems come because the various ISRs have to communicate.
None of them are completely independent. My last great fluff was putting
a certain initialization in an ISR where it seemed to belong but
subsequent complaints from others on the project indicated that it
belonged in a different one. It showed up as an intermittant problem I
never saw myself but I finally figured out what was happening. It had to
do with an unexpected but occasional order of events. 3 lines of code
> I use breakpoints extensively when developing. What proc/toolset are you
> The AVR gives you a nice simulator, a $200 ice which isn't a cadillac, but
> it's damn nice for $200. There's a Jtag ice.There's also higher end ICEs at
> about $3200-ish from atmel, and I think Signum and a few others make them as
At project start, we decided not to implement Jtag. It would not have
been much help without a larger team doing the logic for the 3 AVRs
along with a special tool development group. Another problem is that
breakpoints are dangerous. For dynamic reasons, my power drivers can fry
my actuators. A breakpoint can literally cause smoke. Debug has to be
done with the real physical environment. I design the code as far as
possible with a GIGO philosophy (Garbage In, Gospel Out), I can't
predict transient conditions at the inputs so "gospel" is my best guess.
I knew the architecture was difficult and that is why I asked for a
UART. I wrote a tiny monitor for the AVR that has the UART that allows
me to look at all memory (including that of the other AVRs). It is a
powerful debuging tool. The hard part is figuring out what I see in
memory means. That tends to involve some hours of head scratching at
times but I eventually get there.
A confusion I have is that I have more than one version of the chip I
program and my counterpart has two versions of his. We have both made
errors with version combinations. We can't merge to a single line until
we get all of the physical issues (boards and so on) sorted out.
> >The situation is that the machine state at any given moment
> > is unknown. That's realtime. It's very tricky to debug. Oh! It's all in
> > assembly language.
> That's the only way to fly! :)
Dunno. I do things different ways. There's more than one way to solve a
problem. You have to pick one and hope it is good one.
... The times have been,
That, when the brains were out,
the man would die. ... Macbeth
Chuck Simmons firstname.lastname@example.org
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup