Re: Floating point calculations on 16 uC
- From: Jonathan Kirwan <jkirwan@xxxxxxxxxxxxxx>
- Date: Sun, 28 Aug 2005 23:36:38 GMT
On 28 Aug 2005 07:32:34 -0700, "db" <dbahlmann@xxxxxxxxx> wrote:
>It's not 1 or 3. Number 2 could be possible but the float routines is
>not very big and I have about 6KB stack allocated. I have decreased
>stack size to 4KB to see if the problem gets worse but it stays the
>same. Any other possibilities? Thanks
You've assured us that changes in stack size do not appear to impact
the behavior. My own experience in areas like this are that they
occur when there is static variables involved in the floating point
routines and that the interrupt routines are modifying them in some
way. If you pre-empt an in-progress floating point operation that
depends on some temporary static region for its work and if the code
that pre-empts it also calls some function that re-uses this static
area, that's all that is needed.
It DOES NOT have to be the case that your interrupt procedures use the
floating point, though that is certainly a common source of problems
in this case. It may only be that some other library code also shares
this temporary static region for any purpose at all -- the only
requirement is that it does mess up the in-progress static areas being
used by the particular floating point code. That could just be a
common buffer used for many other purposes, such as atof() or gcvt()
or even something you might not expect at all.
I'd be spending some time looking over the floating point source code
-- which should be provided.
Jon
.
- References:
- Floating point calculations on 16 uC
- From: db
- Re: Floating point calculations on 16 uC
- From: Richard
- Re: Floating point calculations on 16 uC
- From: db
- Floating point calculations on 16 uC
- Prev by Date: Re: Floating point calculations on 16 uC
- Next by Date: Re: mA-hour meter
- Previous by thread: Re: Floating point calculations on 16 uC
- Next by thread: Re: Floating point calculations on 16 uC
- Index(es):
Relevant Pages
|