DSPRelated.com
Forums
   Forums    More Forums    adsp  

Probelm with interrupts

Started by rallen_prsch911 ●August 12, 2003
Hello All,

I am very new to the Analog Devices DSPs, so my knowledge is somewhat
less than vast.

I am using the 21161N. I have one of the development kits, and am
trying to get a skeleton C application running. I started out with
just a main.c in my project, but then started adding all of the
library files that the compiler wants to add. The main reason for
this is that my actual project is a flight critical avionics system,
and I need to understand and have requirements for all code in the
project. This means that I have waded through quite a bit of the C
startup libraries that are automatically included.

I have my code running, but when I enable the timer interrupt, local
variables in main are getting corrupted. I assume this is by the
timer isr, because when I turn it off, I don't have any problems.

I use the 'interrupt( SIG, func )' method of registering my isr, so I
figured that I wouldn't need to worry about variable corruption. All
the function does is increment a counter and then return. I want to
setup a 500us timer interrupt, so that I can wait for certain amounts
of time in my main loop before continuing on. Currently my main loop
is just sequencing the lights on the dev kit, but I need to get the
timer isr running without cloberring my local variables in main().

I am just wondering if there is anything else that I need to do
prevent this from happening. I appreciate any help or or advice you
can give.

Thanks,

Robert Allen
Senior Software Engineer
Goodrich Sensor Systems
Burnsville, MN



Reply by Mike Rosing ●August 12, 20032003-08-12
On Tue, 12 Aug 2003, rallen_prsch911 wrote:

> I am using the 21161N. I have one of the development kits, and am
> trying to get a skeleton C application running. I started out with
> just a main.c in my project, but then started adding all of the
> library files that the compiler wants to add. The main reason for
> this is that my actual project is a flight critical avionics system,
> and I need to understand and have requirements for all code in the
> project. This means that I have waded through quite a bit of the C
> startup libraries that are automatically included.

Not to mention the level of testing you get to do when you think it's
working! Sounds like fun over all though.

> I have my code running, but when I enable the timer interrupt, local
> variables in main are getting corrupted. I assume this is by the
> timer isr, because when I turn it off, I don't have any problems.

What are the scope of the variables in the isr? How is your stack
pointer set up (I'm not familiar with C since I only do assembly, but
it sounds like the stack pointer is walking on things).

> I use the 'interrupt( SIG, func )' method of registering my isr, so I
> figured that I wouldn't need to worry about variable corruption. All

All that does is take the address of func and put it in the correct SIG
vector location in the interrupt table. It doesn't tell the compiler
anything about variables.

> the function does is increment a counter and then return. I want to
> setup a 500us timer interrupt, so that I can wait for certain amounts
> of time in my main loop before continuing on. Currently my main loop
> is just sequencing the lights on the dev kit, but I need to get the
> timer isr running without cloberring my local variables in main().
>
> I am just wondering if there is anything else that I need to do
> prevent this from happening. I appreciate any help or or advice you
> can give.

Make sure the scope of your variables is clear to the compiler. Another
option is to find out if you can allocate registers to the isr to force
the compiler to do what is normally done in assembler: you use the
alternate register set for interrupts and the regular register set for
foreground. I don't know how to do that, but there should be some kind of
compiler flag for it.

Patience, persistence, truth,
Dr. mike



Reply by bhaskar_thiagarajan ●August 12, 20032003-08-12
--- In , Mike Rosing <eresrch@e...> wrote:
> On Tue, 12 Aug 2003, rallen_prsch911 wrote:
>
> > I am using the 21161N. I have one of the development kits, and am
> > trying to get a skeleton C application running. I started out
with
> > just a main.c in my project, but then started adding all of the
> > library files that the compiler wants to add. The main reason for
> > this is that my actual project is a flight critical avionics
system,
> > and I need to understand and have requirements for all code in the
> > project. This means that I have waded through quite a bit of the
C
> > startup libraries that are automatically included.
>
> Not to mention the level of testing you get to do when you think
it's
> working! Sounds like fun over all though.
>
> > I have my code running, but when I enable the timer interrupt,
local
> > variables in main are getting corrupted. I assume this is by the
> > timer isr, because when I turn it off, I don't have any problems.
>
> What are the scope of the variables in the isr? How is your stack
> pointer set up (I'm not familiar with C since I only do assembly,
but
> it sounds like the stack pointer is walking on things).
>
> > I use the 'interrupt( SIG, func )' method of registering my isr,
so I
> > figured that I wouldn't need to worry about variable corruption.
All
>
> All that does is take the address of func and put it in the correct
SIG
> vector location in the interrupt table. It doesn't tell the
compiler
> anything about variables.
>
> > the function does is increment a counter and then return. I want
to
> > setup a 500us timer interrupt, so that I can wait for certain
amounts
> > of time in my main loop before continuing on. Currently my main
loop
> > is just sequencing the lights on the dev kit, but I need to get
the
> > timer isr running without cloberring my local variables in main().
> >
> > I am just wondering if there is anything else that I need to do
> > prevent this from happening. I appreciate any help or or advice
you
> > can give.
>
> Make sure the scope of your variables is clear to the compiler.
Another
> option is to find out if you can allocate registers to the isr to
force
> the compiler to do what is normally done in assembler: you use the
> alternate register set for interrupts and the regular register set
for
> foreground. I don't know how to do that, but there should be some
kind of
> compiler flag for it.

Try registering your interrupt using the 'interrupts()' function.
This does what Mike alluded to - uses the alternate register set. >
> Patience, persistence, truth,
> Dr. mike

Reply by Bhaskar Thiagarajan ●August 12, 20032003-08-12
The interrupts() type makes use of a library that uses
alternate registers. So I guess I'm a little puzzled
on how R0 is clobbered because R0 is never used
(rather should never be used) in the ISR. So it
shouldn't get corrupted.
However, ADI has, in the past, a record of having bugs
in exactly this sort of thing in their libraries.
Usually someone reports this quickly.
I don't use the 21161, so I don't know if this is
really a bug.
Yes - keep looking. Try stepping into the ISR and
watch the alternate register set get invoked. Also try
stepping through the transition from the program into
the ISR.

Good luck and let us know if you find anything.

Note that the stupid moderators of this group have set
the default reply address to the poster and not the
group (adsp@yahoogroups). Please reply to the group so
that everyone benefits.

Cheers
Bhaskar --- rallen_prsch911 <> wrote:
> I changed to that form of registration, and it
> didn't help. I tried
> making the variables in main() file global, so they
> would be on the
> heap, but one is still getting clobbered.
>
> It looks like somewhere along the interrupt line,
> either the register
> does not get saved/restored or the wrong register
> file is used, but
> when I come back from interrupt, My value is
> supposed to be in R0,
> but there is an address from the DM() based
> interrupt vector table.
> The value is 0x53FF6, which looks to be some kind of
> pointer to the
> stack.
>
> I am able to repeat the problem reliably. After a
> restart, the third
> time I return from the interrupt, the value gets
> clobbered. It just
> so happens that the interrupt occurs right after the
> function call
> that gets the value that is updated in the ISR. The
> value is sitting
> in R0 ready to be put into memory and the ISR comes
> along. When it
> gets back, R0 has that pointer in it.
>
> I am going to keep looking.
>
> Thanks,
>
> Robert Allen
> Senior Software Engineer
> Goodrich Sensor Systems >
> --- In , "bhaskar_thiagarajan"
> <bhaskar_thiagarajan@y...> wrote:
> > --- In , Mike Rosing
> <eresrch@e...> wrote:
> > > On Tue, 12 Aug 2003, rallen_prsch911 wrote:
> > >
> > > > I am using the 21161N. I have one of the
> development kits, and
> am
> > > > trying to get a skeleton C application
> running. I started out
> > with
> > > > just a main.c in my project, but then started
> adding all of the
> > > > library files that the compiler wants to add.
> The main reason
> for
> > > > this is that my actual project is a flight
> critical avionics
> > system,
> > > > and I need to understand and have requirements
> for all code in
> the
> > > > project. This means that I have waded through
> quite a bit of
> the
> > C
> > > > startup libraries that are automatically
> included.
> > >
> > > Not to mention the level of testing you get to
> do when you think
> > it's
> > > working! Sounds like fun over all though.
> > >
> > > > I have my code running, but when I enable the
> timer interrupt,
> > local
> > > > variables in main are getting corrupted. I
> assume this is by
> the
> > > > timer isr, because when I turn it off, I don't
> have any
> problems.
> > >
> > > What are the scope of the variables in the isr?
> How is your stack
> > > pointer set up (I'm not familiar with C since I
> only do assembly,
> > but
> > > it sounds like the stack pointer is walking on
> things).
> > >
> > > > I use the 'interrupt( SIG, func )' method of
> registering my
> isr,
> > so I
> > > > figured that I wouldn't need to worry about
> variable
> corruption.
> > All
> > >
> > > All that does is take the address of func and
> put it in the
> correct
> > SIG
> > > vector location in the interrupt table. It
> doesn't tell the
> > compiler
> > > anything about variables.
> > >
> > > > the function does is increment a counter and
> then return. I
> want
> > to
> > > > setup a 500us timer interrupt, so that I can
> wait for certain
> > amounts
> > > > of time in my main loop before continuing on.
> Currently my
> main
> > loop
> > > > is just sequencing the lights on the dev kit,
> but I need to get
> > the
> > > > timer isr running without cloberring my local
> variables in main
> ().
> > > >
> > > > I am just wondering if there is anything else
> that I need to do
> > > > prevent this from happening. I appreciate any
> help or or
> advice
> > you
> > > > can give.
> > >
> > > Make sure the scope of your variables is clear
> to the compiler.
> > Another
> > > option is to find out if you can allocate
> registers to the isr to
> > force
> > > the compiler to do what is normally done in
> assembler: you use the
> > > alternate register set for interrupts and the
> regular register
> set
> > for
> > > foreground. I don't know how to do that, but
> there should be
> some
> > kind of
> > > compiler flag for it.
> >
> > Try registering your interrupt using the
> 'interrupts()' function.
> > This does what Mike alluded to - uses the
> alternate register set.
> >
> >
> > >
> > > Patience, persistence, truth,
> > > Dr. mike
>


__________________________________


Reply by Bhaskar Thiagarajan ●August 12, 20032003-08-12
Please respond to and not my
personal email address.

I've thought about not using the libraries at one
point but it will soon get out of hand and you are
down to assembler level very soon.IN this one instance
it may be ok but it isn't very good for future
maintenance and upgradability.

Have you considered programming in assembly only? If
you are willing to stray from straight C, might as
well take a big jump.

Cheers
Bhaskar --- rallen_prsch911 <> wrote:
> I am wondering if I would be better off if I bypass
> all of the
> library code, and just insert a call to my interrupt
> handler in the
> actual vector table at 0x40010, use the #pragma
> interrupt, and be
> done with it. I don't like having to rely on all of
> these library
> functions to get my system up and running. Their
> code is not
> documented very well, and there is certainly no
> explanation as to why
> it does what it does. That makes my job of making
> sure its necessary
> a lot harder.
>
> Any thoughts???
>
> Robert Allen
> Senior Software Engineer
> Goodrich Sensor Systems
>
> --- In , "bhaskar_thiagarajan"
> wrote:
> > --- In , Mike Rosing
> <eresrch@e...> wrote:
> > > On Tue, 12 Aug 2003, rallen_prsch911 wrote:
> > >
> > > > I am using the 21161N. I have one of the
> development kits, and
> am
> > > > trying to get a skeleton C application
> running. I started out
> > with
> > > > just a main.c in my project, but then started
> adding all of the
> > > > library files that the compiler wants to add.
> The main reason
> for
> > > > this is that my actual project is a flight
> critical avionics
> > system,
> > > > and I need to understand and have requirements
> for all code in
> the
> > > > project. This means that I have waded through
> quite a bit of
> the
> > C
> > > > startup libraries that are automatically
> included.
> > >
> > > Not to mention the level of testing you get to
> do when you think
> > it's
> > > working! Sounds like fun over all though.
> > >
> > > > I have my code running, but when I enable the
> timer interrupt,
> > local
> > > > variables in main are getting corrupted. I
> assume this is by
> the
> > > > timer isr, because when I turn it off, I don't
> have any
> problems.
> > >
> > > What are the scope of the variables in the isr?
> How is your stack
> > > pointer set up (I'm not familiar with C since I
> only do assembly,
> > but
> > > it sounds like the stack pointer is walking on
> things).
> > >
> > > > I use the 'interrupt( SIG, func )' method of
> registering my
> isr,
> > so I
> > > > figured that I wouldn't need to worry about
> variable
> corruption.
> > All
> > >
> > > All that does is take the address of func and
> put it in the
> correct
> > SIG
> > > vector location in the interrupt table. It
> doesn't tell the
> > compiler
> > > anything about variables.
> > >
> > > > the function does is increment a counter and
> then return. I
> want
> > to
> > > > setup a 500us timer interrupt, so that I can
> wait for certain
> > amounts
> > > > of time in my main loop before continuing on.
> Currently my
> main
> > loop
> > > > is just sequencing the lights on the dev kit,
> but I need to get
> > the
> > > > timer isr running without cloberring my local
> variables in main
> ().
> > > >
> > > > I am just wondering if there is anything else
> that I need to do
> > > > prevent this from happening. I appreciate any
> help or or
> advice
> > you
> > > > can give.
> > >
> > > Make sure the scope of your variables is clear
> to the compiler.
> > Another
> > > option is to find out if you can allocate
> registers to the isr to
> > force
> > > the compiler to do what is normally done in
> assembler: you use the
> > > alternate register set for interrupts and the
> regular register
> set
> > for
> > > foreground. I don't know how to do that, but
> there should be
> some
> > kind of
> > > compiler flag for it.
> >
> > Try registering your interrupt using the
> 'interrupts()' function.
> > This does what Mike alluded to - uses the
> alternate register set.
> >
> >
> > >
> > > Patience, persistence, truth,
> > > Dr. mike
>


__________________________________


Reply by bhaskar_thiagarajan ●August 13, 20032003-08-13
--- In , Bhaskar Thiagarajan
<bhaskar_thiagarajan@y...> wrote:
> The interrupts() type makes use of a library that uses
> alternate registers. So I guess I'm a little puzzled
> on how R0 is clobbered because R0 is never used
> (rather should never be used) in the ISR. So it
> shouldn't get corrupted.
> However, ADI has, in the past, a record of having bugs
> in exactly this sort of thing in their libraries.
> Usually someone reports this quickly.
> I don't use the 21161, so I don't know if this is
> really a bug.

Check this link out and see if your problem is related to this
anomaly.
http://tinyurl.com/jtyj
Look for anomaly # 8784

Cheers
Bhaskar > Yes - keep looking. Try stepping into the ISR and
> watch the alternate register set get invoked. Also try
> stepping through the transition from the program into
> the ISR.
>
> Good luck and let us know if you find anything.
>
> Note that the stupid moderators of this group have set
> the default reply address to the poster and not the
> group (adsp@yahoogroups). Please reply to the group so
> that everyone benefits.
>
> Cheers
> Bhaskar > --- rallen_prsch911 <rallen_prsch911@y...> wrote:
> > I changed to that form of registration, and it
> > didn't help. I tried
> > making the variables in main() file global, so they
> > would be on the
> > heap, but one is still getting clobbered.
> >
> > It looks like somewhere along the interrupt line,
> > either the register
> > does not get saved/restored or the wrong register
> > file is used, but
> > when I come back from interrupt, My value is
> > supposed to be in R0,
> > but there is an address from the DM() based
> > interrupt vector table.
> > The value is 0x53FF6, which looks to be some kind of
> > pointer to the
> > stack.
> >
> > I am able to repeat the problem reliably. After a
> > restart, the third
> > time I return from the interrupt, the value gets
> > clobbered. It just
> > so happens that the interrupt occurs right after the
> > function call
> > that gets the value that is updated in the ISR. The
> > value is sitting
> > in R0 ready to be put into memory and the ISR comes
> > along. When it
> > gets back, R0 has that pointer in it.
> >
> > I am going to keep looking.
> >
> > Thanks,
> >
> > Robert Allen
> > Senior Software Engineer
> > Goodrich Sensor Systems
> >
> >
> >
> > --- In , "bhaskar_thiagarajan"
> > <bhaskar_thiagarajan@y...> wrote:
> > > --- In , Mike Rosing
> > <eresrch@e...> wrote:
> > > > On Tue, 12 Aug 2003, rallen_prsch911 wrote:
> > > >
> > > > > I am using the 21161N. I have one of the
> > development kits, and
> > am
> > > > > trying to get a skeleton C application
> > running. I started out
> > > with
> > > > > just a main.c in my project, but then started
> > adding all of the
> > > > > library files that the compiler wants to add.
> > The main reason
> > for
> > > > > this is that my actual project is a flight
> > critical avionics
> > > system,
> > > > > and I need to understand and have requirements
> > for all code in
> > the
> > > > > project. This means that I have waded through
> > quite a bit of
> > the
> > > C
> > > > > startup libraries that are automatically
> > included.
> > > >
> > > > Not to mention the level of testing you get to
> > do when you think
> > > it's
> > > > working! Sounds like fun over all though.
> > > >
> > > > > I have my code running, but when I enable the
> > timer interrupt,
> > > local
> > > > > variables in main are getting corrupted. I
> > assume this is by
> > the
> > > > > timer isr, because when I turn it off, I don't
> > have any
> > problems.
> > > >
> > > > What are the scope of the variables in the isr?
> > How is your stack
> > > > pointer set up (I'm not familiar with C since I
> > only do assembly,
> > > but
> > > > it sounds like the stack pointer is walking on
> > things).
> > > >
> > > > > I use the 'interrupt( SIG, func )' method of
> > registering my
> > isr,
> > > so I
> > > > > figured that I wouldn't need to worry about
> > variable
> > corruption.
> > > All
> > > >
> > > > All that does is take the address of func and
> > put it in the
> > correct
> > > SIG
> > > > vector location in the interrupt table. It
> > doesn't tell the
> > > compiler
> > > > anything about variables.
> > > >
> > > > > the function does is increment a counter and
> > then return. I
> > want
> > > to
> > > > > setup a 500us timer interrupt, so that I can
> > wait for certain
> > > amounts
> > > > > of time in my main loop before continuing on.
> > Currently my
> > main
> > > loop
> > > > > is just sequencing the lights on the dev kit,
> > but I need to get
> > > the
> > > > > timer isr running without cloberring my local
> > variables in main
> > ().
> > > > >
> > > > > I am just wondering if there is anything else
> > that I need to do
> > > > > prevent this from happening. I appreciate any
> > help or or
> > advice
> > > you
> > > > > can give.
> > > >
> > > > Make sure the scope of your variables is clear
> > to the compiler.
> > > Another
> > > > option is to find out if you can allocate
> > registers to the isr to
> > > force
> > > > the compiler to do what is normally done in
> > assembler: you use the
> > > > alternate register set for interrupts and the
> > regular register
> > set
> > > for
> > > > foreground. I don't know how to do that, but
> > there should be
> > some
> > > kind of
> > > > compiler flag for it.
> > >
> > > Try registering your interrupt using the
> > 'interrupts()' function.
> > > This does what Mike alluded to - uses the
> > alternate register set.
> > >
> > >
> > > >
> > > > Patience, persistence, truth,
> > > > Dr. mike
> > __________________________________
>




Reply by Kenneth Porter ●August 13, 20032003-08-13
--On Tuesday, August 12, 2003 4:03 PM +0000 rallen_prsch911
<> wrote:

> I have my code running, but when I enable the timer interrupt, local
> variables in main are getting corrupted. I assume this is by the
> timer isr, because when I turn it off, I don't have any problems.

Sounds like a dispatcher bug. You don't say which version of the tools you're
using. Use "cc21k -version" to find out. (6.2.3 seems to be pretty stable.)
There have been some bugs in the dispatchers in the past involving a register
not getting restored (a DAG register, I think), so get the latest interim
release from the FTP site for your major version and install it.



Reply by Jaime Andres Aranguren Cardona ●August 13, 20032003-08-13
Hello Bhaskar,

Where does the tinyurl.com website comes from? What's
that related to? C'mon, who invented that? what a good
tool!!!

I think it would be a nice idea to have it spreaded
all around newsgroups, maybe in the FAQs. Could you
please tell it to the comp.dsp people? Maybe, as it
was my case, many don't know about it!!!

Kindest regards,

JaaC

--- bhaskar_thiagarajan
<> wrote:
> --- In , Bhaskar Thiagarajan
> <bhaskar_thiagarajan@y...> wrote:
> > The interrupts() type makes use of a library that
> uses
> > alternate registers. So I guess I'm a little
> puzzled
> > on how R0 is clobbered because R0 is never used
> > (rather should never be used) in the ISR. So it
> > shouldn't get corrupted.
> > However, ADI has, in the past, a record of having
> bugs
> > in exactly this sort of thing in their libraries.
> > Usually someone reports this quickly.
> > I don't use the 21161, so I don't know if this is
> > really a bug.
>
> Check this link out and see if your problem is
> related to this
> anomaly.
> http://tinyurl.com/jtyj
> Look for anomaly # 8784
>
> Cheers
> Bhaskar > > Yes - keep looking. Try stepping into the ISR and
> > watch the alternate register set get invoked. Also
> try
> > stepping through the transition from the program
> into
> > the ISR.
> >
> > Good luck and let us know if you find anything.
> >
> > Note that the stupid moderators of this group have
> set
> > the default reply address to the poster and not
> the
> > group (adsp@yahoogroups). Please reply to the
> group so
> > that everyone benefits.
> >
> > Cheers
> > Bhaskar
> >
> >
> > --- rallen_prsch911 <rallen_prsch911@y...> wrote:
> > > I changed to that form of registration, and it
> > > didn't help. I tried
> > > making the variables in main() file global, so
> they
> > > would be on the
> > > heap, but one is still getting clobbered.
> > >
> > > It looks like somewhere along the interrupt
> line,
> > > either the register
> > > does not get saved/restored or the wrong
> register
> > > file is used, but
> > > when I come back from interrupt, My value is
> > > supposed to be in R0,
> > > but there is an address from the DM() based
> > > interrupt vector table.
> > > The value is 0x53FF6, which looks to be some
> kind of
> > > pointer to the
> > > stack.
> > >
> > > I am able to repeat the problem reliably. After
> a
> > > restart, the third
> > > time I return from the interrupt, the value gets
> > > clobbered. It just
> > > so happens that the interrupt occurs right after
> the
> > > function call
> > > that gets the value that is updated in the ISR.
> The
> > > value is sitting
> > > in R0 ready to be put into memory and the ISR
> comes
> > > along. When it
> > > gets back, R0 has that pointer in it.
> > >
> > > I am going to keep looking.
> > >
> > > Thanks,
> > >
> > > Robert Allen
> > > Senior Software Engineer
> > > Goodrich Sensor Systems
> > >
> > >
> > >
> > > --- In ,
> "bhaskar_thiagarajan"
> > > <bhaskar_thiagarajan@y...> wrote:
> > > > --- In , Mike Rosing
> > > <eresrch@e...> wrote:
> > > > > On Tue, 12 Aug 2003, rallen_prsch911 wrote:
> > > > >
> > > > > > I am using the 21161N. I have one of the
> > > development kits, and
> > > am
> > > > > > trying to get a skeleton C application
> > > running. I started out
> > > > with
> > > > > > just a main.c in my project, but then
> started
> > > adding all of the
> > > > > > library files that the compiler wants to
> add.
> > > The main reason
> > > for
> > > > > > this is that my actual project is a flight
> > > critical avionics
> > > > system,
> > > > > > and I need to understand and have
> requirements
> > > for all code in
> > > the
> > > > > > project. This means that I have waded
> through
> > > quite a bit of
> > > the
> > > > C
> > > > > > startup libraries that are automatically
> > > included.
> > > > >
> > > > > Not to mention the level of testing you get
> to
> > > do when you think
> > > > it's
> > > > > working! Sounds like fun over all though.
> > > > >
> > > > > > I have my code running, but when I enable
> the
> > > timer interrupt,
> > > > local
> > > > > > variables in main are getting corrupted.
> I
> > > assume this is by
> > > the
> > > > > > timer isr, because when I turn it off, I
> don't
> > > have any
> > > problems.
> > > > >
> > > > > What are the scope of the variables in the
> isr?
> > > How is your stack
> > > > > pointer set up (I'm not familiar with C
> since I
> > > only do assembly,
> > > > but
> > > > > it sounds like the stack pointer is walking
> on
> > > things).
> > > > >
> > > > > > I use the 'interrupt( SIG, func )' method
> of
> > > registering my
> > > isr,
> > > > so I
> > > > > > figured that I wouldn't need to worry
> about
> > > variable
> > > corruption.
> > > > All
> > > > >
> > > > > All that does is take the address of func
> and
> > > put it in the
> > > correct
> > > > SIG
> > > > > vector location in the interrupt table. It
> > > doesn't tell the
> > > > compiler
> > > > > anything about variables.
> > > > >
> > > > > > the function does is increment a counter
> and
> > > then return. I
> > > want
> > > > to
> > > > > > setup a 500us timer interrupt, so that I
> can
> > > wait for certain
> > > > amounts
> > > > > > of time in my main loop before continuing
> on.
> > > Currently my
> > > main
> > > > loop
> > > > > > is just sequencing the lights on the dev
> kit,
> > > but I need to get
> > > > the
> > > > > > timer isr running without cloberring my
> local
>
=== message truncated === =====

Jaime Andr Aranguren Cardona

__________________________________

Reply by Mike Rosing ●August 13, 20032003-08-13
On Tue, 12 Aug 2003, Bhaskar Thiagarajan wrote:

> Please respond to and not my
> personal email address.

Hitting the "reply to all" button will do that automaticly.

> I've thought about not using the libraries at one
> point but it will soon get out of hand and you are
> down to assembler level very soon.IN this one instance
> it may be ok but it isn't very good for future
> maintenance and upgradability.
>
> Have you considered programming in assembly only? If
> you are willing to stray from straight C, might as
> well take a big jump.

Programming in assembler requires a lot more comments than
a high level language. It gives you complete control
of the processor and all bugs are your fault. The macro
preprocessor of C can make your life a lot simpler by allowing
you to create your own language for each specific application.

The assembler language on the 21xxx is pretty high level for
actual dsp applications. You can squeeze more power out
of a dsp by understanding the machine architecture compared to what a
C compiler can do. But it takes a long time.

Since what you want to do is flight critical, and peoples lives depend
on things being right, I'd think total control of the processor would
be important.

> --- rallen_prsch911 <> wrote:
> > I am wondering if I would be better off if I bypass
> > all of the
> > library code, and just insert a call to my interrupt
> > handler in the
> > actual vector table at 0x40010, use the #pragma
> > interrupt, and be
> > done with it. I don't like having to rely on all of
> > these library
> > functions to get my system up and running. Their
> > code is not
> > documented very well, and there is certainly no
> > explanation as to why
> > it does what it does. That makes my job of making
> > sure its necessary
> > a lot harder.
> >
> > Any thoughts???
> >
> > Robert Allen

Patience, persistence, truth,
Dr. mike



Reply by rallen_prsch911 ●August 13, 20032003-08-13
I agree that assembly allows complete control, but there are a few
drawbacks:

1. Development time is increased, especially when learning a new
processor architecture, assembly dialect, register set, etc.

2. Code is much more difficult to understand, even with comments.
It's been about 7 or 8 years since I have written much assembly
language, and when I look at the library code, it takes a very long
time to A) figure what is being done and B) why it is being done.
This could be fixed by great documentation, but from my experience,
management is pushing to get the design done and damn the
documentation. They only want the documentation done when the
FAA/JAA start asking for it. Then you get 10 contractors in who
don't know anything about the code or design and write the
documentation, because there isn't time for the designers to do it.

3. The certification authorities actually don't want to see much
assembly language, because they think there is a greater chance of
having defects that are not detected. I don't know if this is true
or not. I think all software can be tested thoroughly. It all
depends on who is writing the tests.

I am not against having assembly language in my product, but I want
the assembly that is there to be well understood and documented, so
that the next guy won't have to yank his hair out trying to figure
out what I was doing. :-)

UPDATE: I ran the code through the simulator, and it doesn't screw
up on the 3rd time to the ISR. I just quickly ran it, so I don't
know what the difference is. I am still looking.

Robert Allen
Senior Software Engineer
Goodrich Sensor Systems

--- In , Mike Rosing <eresrch@e...> wrote:
> On Tue, 12 Aug 2003, Bhaskar Thiagarajan wrote:
>
> > Please respond to and not my
> > personal email address.
>
> Hitting the "reply to all" button will do that automaticly.
>
> > I've thought about not using the libraries at one
> > point but it will soon get out of hand and you are
> > down to assembler level very soon.IN this one instance
> > it may be ok but it isn't very good for future
> > maintenance and upgradability.
> >
> > Have you considered programming in assembly only? If
> > you are willing to stray from straight C, might as
> > well take a big jump.
>
> Programming in assembler requires a lot more comments than
> a high level language. It gives you complete control
> of the processor and all bugs are your fault. The macro
> preprocessor of C can make your life a lot simpler by allowing
> you to create your own language for each specific application.
>
> The assembler language on the 21xxx is pretty high level for
> actual dsp applications. You can squeeze more power out
> of a dsp by understanding the machine architecture compared to what
a
> C compiler can do. But it takes a long time.
>
> Since what you want to do is flight critical, and peoples lives
depend
> on things being right, I'd think total control of the processor
would
> be important.
>
> > --- rallen_prsch911 <rallen_prsch911@y...> wrote:
> > > I am wondering if I would be better off if I bypass
> > > all of the
> > > library code, and just insert a call to my interrupt
> > > handler in the
> > > actual vector table at 0x40010, use the #pragma
> > > interrupt, and be
> > > done with it. I don't like having to rely on all of
> > > these library
> > > functions to get my system up and running. Their
> > > code is not
> > > documented very well, and there is certainly no
> > > explanation as to why
> > > it does what it does. That makes my job of making
> > > sure its necessary
> > > a lot harder.
> > >
> > > Any thoughts???
> > >
> > > Robert Allen
>
> Patience, persistence, truth,
> Dr. mike