Hi Victor,
You wrote to me:
VK> GW> I'll try. It's generally similar across all compilers that provide
VK> GW> interrupt support, and is not the same in C as C++.
VK>Yeah? What are the differences, I've noticed you need '...'
VK>as the parameters to the function in c++ but nothing in c,
VK>is there anything else?
I don't know the details, as I've only done it in pure C.
VK> VK>instruction. I would really like to be able to wait for an
VK> VK>interrupt to occur from within the interrupt function, but
VK> VK>waiting for it just makes it sit there forever.
VK> GW> You emphatically do not call an "interrupt" function and wait for the
VK> GW> interrupt to occur, rather the "interrupt" function should do the
VK>I think I've written that message a bit sloppily, what I
VK>meant is wait in one interrupt's function for a different
VK>one to occur which will have it's own function. But Just
VK>today I found that using that onmask/offmask stuff with the
VK>PIC, seems to fix the problem(After I'd already written a
VK>workaround :( ).
What you've written clarifies things a bit, but my comment still
stands. You do _NOT_ wait for an interrupt in an interrupt. There is no
guarantee that the required interrupt will occur before the interrupt
you are sitting in requires servicing again. You have to do it by
setting flags in global data space to show the status of the interrupts
that you can test.
I see in another message in the thread that you are doing much of your
processing inside the timer tick interrupt. This is potentially
dangerous, and you should only do what is _essential_ within a hardware
interrupt service routine. This should really be limited to
reading/writing data and setting/clearing status flags. With proper
design everything else can be done within the main program.
Why do you find it necessary to do so much within the timer tick
interrupt?
George
 * SLMR 2.1a * All Trademarks acknowledged (just in case ).
--- Maximus/2 3.01
---------------