Glad if I can be of any help, Tim
So with this code there really is no option but to do it all in the interrupt routine
So be it then. Sometimes you're stuck with what you're stuck with!
the only thing that should not really be there is the div routines. The multiply are all hardware so really will not be an issue
That's a big assumption. Compiled for the PIC18 almost none of the multiplies invoke the hardware multiplier... they use software routines.
You've broken a lot of the statements up into simple expressions, and that can tend to help a lot, but it's always hard to guess what's going on behind the scenes.
For example, statements like
- Code: Select all
AverageTopSensor = AverageTopSensor + RawUpperLevelArray(i)
will almost always require the use of temp frame variables while it calculates the address of the array item and reads it to do the calc.
The compiler does a very good job at tracking subroutine calls and frame variable usage under normal situations. What it can't track is how stuff inside an ISR interacts with the other code since the ISR can occur asynchronously at any time. It leaves it up to you to tell it. If everything was a flat model w/out ram reuse that would be easier, but then you run out of ram pretty quick.
Trying to compile for a PIC24 by debugging code on a PIC18 is not going to work too well. The compilers/chips are just too different. It's always painful learning the tricks and bumps of a different language/implementation, so I feel your pain.
...why my simple tick flag was getting corrupted. I moved it out of the structure and it worked
I'm a bit tied up right now, but I took a quick glance at the difference between having 'Hz1TickUpdated as Flags.Booleans(7)' in the NC_state struct vs on it's own and I didn't see much difference. The other booleans in the program move around and are allocate different bits, but I'd have to take a closer look to see why one works and the other didn't. It wasn't obvious.