> WOW, i didn't think the question would lead to all of this. I'll try not
to
> ask anymore difficult questions. To those who proposed solutions and
> actually helped i thank you. To the rest, you might want to sit back, have
a
> few drinks and pull your egos out of your a.s.

I think that the discussion has been more about the "why are you doing it
this way" aspect of it. From what you wrote somewhere in the middle of the
discussion about why you wanted to do it, I see that there is a "more
structured way" of doing it that produces cleaner code.

The method you are proposing has no real advantage over the interrupt
routine setting a flag to show that new parameters have arrived - in fact I
see your method as having a disadvantage, think about what happens when some
of the parameters have changed as the ADC portion does another conversion
when part way through a parameter change.

Essentially having the non-interrupt code check a parameter change flag at
some defined point in the loop, and update all parameters at that time will
actually keep your code more in sync than you realise. I seriously doubt
that you can send parameters to the PIC with such precision that you will
affect a specific conversion.

As others have pointed out, there are times when stack manipulation is
desirable or necessary, but your application does not present itself as
being one of these times. A rethink about how the code interacts between the
parameter change code and the conversion code is clearly required. This is
why your original question invoked all this discussion.

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist