Hi Dmitry,
Thanks for the feedback.
Dmitry wrote:
Steve,
there is a thing which seems wrong:
file x1126.html, topic 'variable agruments list'.
The note there is probably incorrect.
Actually, any type of calls allowed within ISR --
I'm using, for example, printf() in timer A iterrupts (not real-time bits ;).
OK, I removed the warning.
Another thing I thought about it (which probably has been hidden by my poor
english) is:
The ISR can accept arguments. Do not ask what for.
Anyway, one can call ISR from parent code and pass some arguments to ISR.
The ISR will accept arguments and will perform an appropriate actions
(returning to the middle of nowhere). As we know on interrupts r2 being
pushed to the stack and stack pointer decrements by two. GCC minds this fact
and will grab arguments from stack (if necessary) thinking that r2 been
pushed. However if ISR being called from normal user process, r2 left behind.
So, gcc will get second argument from stack instead of first, third instead of
second and so on. Nothing much else. Arguments passed via registers will
behave as expected.
Why I've done ISRs accepting params? I dunno. probably cause of nothing to do
:)
I can't think of any practical use for this, but I have added a note
that it is possible to have an argument list.
Another this with calls within ISR is a performance hit:
Any call (in general) clobbers r12 - r15. So, even if a tiny call being
performed within ISR, gcc saves r12-r15 on stack. For example:
---------------
uint32_t localtime;
void incloctime()
{
localtime++;
}
interrupt(vector) isr()
{
incloctime();
}
------------------
will result isr() saving r12-r15 when none of them being used.
That is an important point. I have added it.
Another things:
There were some changes about returning from main(). Please check.
Were do I look for this information? I worked from the material
currently on the web site.
