Help on: How to avoid placing millions of software checkpoints

[rover8898]

Hello all,

I have a programming problem/challenge.
Let explain my scenario:

I have a C program (distributed accross many files and functions) that
is responsible for handling hardware. This piece of hardware (a
microcontroller) can do several lengthy procedures depending on the
commands it receives.
The problem arises when the hardware receives a "stop command". The
stop command demands that the hardware ceases its current action and
goes in sleep mode. Since, the stop command can be received at any
arbitary momment (beginning, middle or end of the current procedure), I
am forced to have checkpoints for the [reception of the stop cmd]
almost everywhere in my program. Every time a function is about to do
an action, I have to check if the stop flag was set. Hence, as you can
probably guess, placing stop flag checkpoints at every decision
junction is very tedious. Using interrupts doesn't seem to help me
either since any interrupt that is called will bring me back in the
program after it is is completed. If I was coding in assembler, i would
be able to use the "jump" (assembly equivalent of the "goto" statement)
statement to jump at the near-end of the program. However, the "goto
statement" in C has only file (or function, i forget which) scope, and
as such, does not help me much.
Does anyone know of a course of action that will lead to me not having
to place checkpoints all over the program?

Regards
Roger Bourne

[Hubble]

rover8898 schrieb:

Hello all,

I have a programming problem/challenge.
Let explain my scenario:

I have a C program (distributed accross many files and functions) that
is responsible for handling hardware. This piece of hardware (a
microcontroller) can do several lengthy procedures depending on the
commands it receives.
The problem arises when the hardware receives a "stop command". The
stop command demands that the hardware ceases its current action and
goes in sleep mode. Since, the stop command can be received at any
arbitary momment (beginning, middle or end of the current procedure), I
am forced to have checkpoints for the [reception of the stop cmd]
almost everywhere in my program. Every time a function is about to do
an action, I have to check if the stop flag was set. Hence, as you can
probably guess, placing stop flag checkpoints at every decision
junction is very tedious. Using interrupts doesn't seem to help me
either since any interrupt that is called will bring me back in the
program after it is is completed. If I was coding in assembler, i would
be able to use the "jump" (assembly equivalent of the "goto" statement)
statement to jump at the near-end of the program. However, the "goto
statement" in C has only file (or function, i forget which) scope, and
as such, does not help me much.
Does anyone know of a course of action that will lead to me not having
to place checkpoints all over the program?

Maybe you should have a look at signals (interrupts) and
setjmp/longjmp.

In short: -
- before the main loop, call if (setjmp(jmp_buf)==1) { ... };
main_loop().
- In the signal handler, call longjmp(jmp_buf,1);
- a signal (interrupt) will execute {...} and reenter main_loop()
with
a correct stack).

Hubble.

[Samuel Stearley]

So use an ISR that doesn't 'complete' till it gets the awake command.

The ISR doesn't have to return to the same point of code that the
return address says it should. It can return anywhere it wants !
int sleep_indicator = 0;
void command_executer(void)
{
while (1)
{
if (sleep_indicator)
__asm("halt"); /* or whatever cput asm instruction turns off the
cpu till an ISR */
else if (entries_in_command_queue 0 )
execute_command(pop_command_from_command_queue());
else
__asm("halt"); /* sleep if there is nothing in the command queue
*/
}
}

/* this will have to be done in asm */
void ISR_command_reciever_routine(void)
{
int tmp = read_command()

/* does the command tell us to sleep ?
if (tmp == SLEEP)
{
sleep_indicator = 1;
isr_return_address = command_executer:
return_from_isr();
}
/* is this a new command after having been asleep */
else if (sleep_indicator == 1)
{
sleep_indicator = 0;
isr_push_command_to_queue(tmp);
re_init_appropriate_globals();
return_address = command_executer;
return_from_isr();
}
/* else this is a new command during normal execution of another
command */
else
{
push_command_to_queue(tmp);
return_from_isr();
}
}






rover8898 wrote:

Hello all,

I have a programming problem/challenge.
Let explain my scenario:

I have a C program (distributed accross many files and functions) that
is responsible for handling hardware. This piece of hardware (a
microcontroller) can do several lengthy procedures depending on the
commands it receives.
The problem arises when the hardware receives a "stop command". The
stop command demands that the hardware ceases its current action and
goes in sleep mode. Since, the stop command can be received at any
arbitary momment (beginning, middle or end of the current procedure), I
am forced to have checkpoints for the [reception of the stop cmd]
almost everywhere in my program. Every time a function is about to do
an action, I have to check if the stop flag was set. Hence, as you can
probably guess, placing stop flag checkpoints at every decision
junction is very tedious. Using interrupts doesn't seem to help me
either since any interrupt that is called will bring me back in the
program after it is is completed. If I was coding in assembler, i would
be able to use the "jump" (assembly equivalent of the "goto" statement)
statement to jump at the near-end of the program. However, the "goto
statement" in C has only file (or function, i forget which) scope, and
as such, does not help me much.
Does anyone know of a course of action that will lead to me not having
to place checkpoints all over the program?

Regards
Roger Bourne

[rover8898]

Thank you both Samuel and Hubble.

Both are good solutions to my problem.
I like the setjmp.h's setjmp and longjmp instructions. They are what I
was initially looking for: a non-local goto.

However, looking at Samuel code made me realize that my code
architecture is wrong. Now: My command handling+exution is done outside
of an ISR. It uses as parameter the contents of the reception buffer.

What is should be: My command handling+exution should be in an ISR.
However it brings 2 questions to mind:
1. Will nested ISRs pose a problem ? I will have to pop the stack an
extra to void the previous command....
2. Will the fact that the ISR routine disables all interrupts upon
iwhen its commencement pose a problem?

Those are minor problems. I am certain I will be able to resolve them.
Thanks guys.

-Roger

[rover8898]

Hello again,

I looked at the setjmp/longjmp function description.
However, I can not discern if the setjmp/longjmp pair can cause stack
overflow problems.

Regards,
-Roger

Maybe you should have a look at signals (interrupts) and
setjmp/longjmp.

In short: -
- before the main loop, call if (setjmp(jmp_buf)==1) { ... };
main_loop().
- In the signal handler, call longjmp(jmp_buf,1);
- a signal (interrupt) will execute {...} and reenter main_loop()
with
a correct stack).

Hubble.

[Samuel Stearley]

1. Will nested ISRs pose a problem ? I will have to pop the stack an

extra to void the previous command....

Yes and thats a bug in my ISR code, There isn't a
re_init_appropriate_globals(); when the sleep command is encountered,
to re-init the user space stack.

2. Will the fact that the ISR routine disables all interrupts upon
iwhen its commencement pose a problem?

Yes that is a problem.
I hoped to avoid nested ISR issues and ISR disabling issues by having a
distinct isr_receiver and command_executer that communicate via some
variables. How does your micro-controller exit the disabled interupt
state? Is it tied to the return from ISR instruction or can it be done
without having to return from the ISR ?

another issue:
Suppose your code looks like:

void massive_isr_routine_that_does_everything(void)
{
int a= 10; /* init variable a which is kept in a stack frame */
int b= 45; /* init variable b which is kept in a stack frame */
int x= 67; /* init variable x which is kept is a stack frame */

/* reset the stack */
...

/* remove ISR execution protection */
...

/* normal code */
...
}
So when you reset the stack, what do you set it to? And you have
variables that were already initialized on the stack. They now need to
be initialized on the new stack.

Ok fine so you can change the code to read
void massive_isr_routine_that_does_everything(void)
{
int a; /* init variable a which is kept in a stack frame */
int b; /* init variable b which is kept in a stack frame */
int x; /* init variable x which is kept is a stack frame */

/* reset the stack */
...

a= 10; /* init variable a which is kept in a stack frame */
b= 45; /* init variable b which is kept in a stack frame */
x= 67; /* init variable x which is kept is a stack frame */

/* remove ISR execution protection */
...

/* normal code */
...
}
But how do you know its not being optimized into the first routine?
Another issue:
Suppose when there are no variables on the stack and you have to
re-init it to be 0x1000.
Now that there are 3 variables you'll have to re-init it to 0x1000 - 3
* sizeof(int)
Everytime you add a variable you need to know if its going to end up on
the stack and adjust the stack init appropriately.
Thats another reason I like having the command_reciever be a supreme
ISR in asm: it can re-init the user space stack pointer every time to
0x1000 without worrying about what command_executer is going to do with
it.

rover8898 wrote:

Thank you both Samuel and Hubble.

Both are good solutions to my problem.
I like the setjmp.h's setjmp and longjmp instructions. They are what I
was initially looking for: a non-local goto.

However, looking at Samuel code made me realize that my code
architecture is wrong. Now: My command handling+exution is done outside
of an ISR. It uses as parameter the contents of the reception buffer.

What is should be: My command handling+exution should be in an ISR.
However it brings 2 questions to mind:
1. Will nested ISRs pose a problem ? I will have to pop the stack an
extra to void the previous command....
2. Will the fact that the ISR routine disables all interrupts upon
iwhen its commencement pose a problem?

Those are minor problems. I am certain I will be able to resolve them.
Thanks guys.

-Roger