AVR Freaks

You can do longjmp() and setjmp() in the foreground code. I have done it myself.

I definitely would not longjmp() out of an ISR().

There are better ways of doing things. You can abort a long function with a simple return().

You can raise an interrupt when you want to signal that you have finished something. However it is just as easy to set a flag.

And there is no problem with using goto() within a function. Sometimes it is tidy. You can always invent spurious loops to satisfy the purists.

David.

The bad flag could be set by an interrupt.
In all honesty, the slow function could just return early to main(). The advantage of longjmp() is when you want to abort a function that is deeply nested.

David.

Do you really need the foreground to calculate very fast?

Most apps can process the foreground at a leisurely pace.
Your interrupts need to be serviced promptly, but quite honestly do you need to calculate on every cycle ?

You can often use the result of your calculation some 5 or 10 periods later. Few realtime systems would notice.

Of course creating audio or some fast varying signal need prompt processing.

I would avoid gobbledygook if I can. Get the algorithm designed first. Only 'speed it up' if necessary.

David.

No, volatile is not sufficient as interrupts may occur halfway though updating a variable.

You can't mix assembler and C like that, CPU registers are used by the compiler and altering them in assembler except where permitted will result in undefined behaviour. What are you trying to do?

No.

Standard `setjmp/longjmp` functionality is designed to work in a very specific environment: a chain/stack of nested function calls `A -> B -> C -> D`. Somewhere at the bottom of that chain (in `A`) you called `setjmp`, and then at the top of that chain (in D) you can call `longjmp` to quickly return back to `A`. "Quickly" means jumping back through several layers of nested calls.

The critical point here is that at the moment when you call `longjmp` your target - `A` - is still sitting in the callstack, waiting for you to return. And that is what you do with `longjmp` - you return to `A`. Not in normal by in step-by-step fashion (through `B` and `C`), but jump over `B` and `C` directly to `A`. This is why the function is called `longjmp`. Any other use of `setjmp/longjmp` is illegal and will not do anything meaningful.

In your case interrupt handler is not called from `main`. `main` is a not a member of ISR's callstack. So, trying to jump to `main` from an ISR handler is not going to work.

Thanks.  I missed that. 

No.

Stop.

You don't know where your code was when your interrupt fired. If you leave the ISR via longjmp, you are not going back where you were before it was called. You're going to where setjmp was called.

Your problem isn't some subtlety of restoring things, it's that your idea makes no sense whatsoever. The idea of an interrupt is that your code is currently doing something, and then the interrupt happens, and when it's done, it resumes what it was doing previously. If you try to use a goto, or a longjmp, you are no longer resuming what you were doing previously.

Circumstances under which this would be reasonable: Nothing your program does matters to you, at all, and you don't care whether any of the code you wrote runs.

If it is possible that you care whether your program runs, then this is an idea which is completely, totally, wrong in every way.

It can get more complicated when you have preemptible tasks.  The OS gets control after interrupts.  It runs the highest priority task that is ready to run.

See the WG14 response to this matter:  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm

What you are saying is similar to what the original C standard (C89/90) was saying (and might also rely on additional guarantees made by POSIX at that time)

"As it bypasses the usual function call and return mechanisms, the longjmp function shall execute correctly in contexts of interrupts, signals and any of their associated functions. However, if the longjmp function is invoked from a nested signal handler (that is, from a function invoked as a result of a signal raised during the handling of another signal), the behavior is undefined."

However, even this spec was challenged by Defect Report 152: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_152.html

To which WG14 responded with

"The C Standard is clear enough as is. The longjmp function shall execute correctly when called from a non-nested signal handler invoked through calls to the raise or abort functions; if longjmp is called from a signal handler invoked by other means, or from a nested signal handler, the behavior is undefined."

(and the original wording was quietly removed from C standard).

So, according to this clarification from the very beginning using `longjmp` has only been allowed in signal handlers that were invoked manually, through `raise` or `abort` functions, not by "real" signals. 

The current C standard covers this issue with a more generic rule

"7.14.1.1 The signal function

5 If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static or thread storage duration that is not a lock-free atomic object other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than the abort function, the _Exit function, the quick_exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler."

As you can see, calling `longjmp` from asynchronous signal handlers remains illegal. Naturally, all this also applies to interrupt handlers invoked by actual interrupts.

Just going to chime in and say...

Even if it works, calling longjmp is probably a bad idea. Not because it won't work correctly, but because it makes it harder for the maintenance programmer to understand.

In general, ISRs should just set state and return. Now, sometimes setting that state is a complicated business and makes the ISR take a bit longer than we'd hope, but it will still return to the main program.

If the main program can't handle things quickly enough (before another ISR arrives), then you can put more processing in the ISR- do the calculations etc, in there, and store the results in volatile variables, + ready flags etc. Be careful not to create race conditions, but the main code can always disable interrupts while it reads the volatile variables (copy them into locals, then re-enable).

For example, if reading serial data, you might create a buffer in ram and have the ISR just stash the byte (attiny1 USART does not have a hardware buffer of more than one byte) and move the counter on, the main program can then stay busy doing whatever it's doing until it's ready to read the serial data.

There might also be cases where calling longjmp from a ISR leaves the hardware in an unexpected state- but knowing that a ISR might do that, you can always disable interrupts while doing some hardware operations.

Here is the Scheduler we used.

/*f*****************************************************************************
*
*          void Scheduler(Process_s *NextProcess)
* DESCRIPTION: Scheduler() uses ANSI setjmp macro to preserve process context.
*              If NextProcess argument is NULL, it searches for the next higher
*              priority ready-to-run process and switch to it Or simply returns
*              to NullProcess if no ready-to-run process is found.  If not NULL,
*              it simply take the NextProcess agrument and switch to such
*              process. Scheduler() uses ANSI longjmp macro to restore context
*              and switch to scheduled process.
* RETURNS:       void.
* ASSUMES: NextProcess must be a valid process or NULL.
*          Interrupts are disabled.  They will be enabled in Longjmp when returning
*          to the next ready task.
* HISTORY: Created 03/28/96 by David Leung
*     03/28/96 DKL: Initial Start Coding.
*****************************************************************************f*/

void Scheduler(Process_s *next_process_p)
{
Process_s *process_p;

#ifndef _TMS320C5XX
  if (setjmp(currentProcess_p->context_a)==0)
#else
  if (rtmkSetjmp(currentProcess_p->context_a)==0)
#endif /* _TMS320C5XX */

  {
    if (next_process_p)
      currentProcess_p = next_process_p;
    else  {           /* determine the NextProcess */
      for(process_p = process_a; process_p->awaitingSig; process_p++)
         ;
      if(process_p->awaitingResource_p)   {
         if(process_p->awaitingResource_p->ownerProcess_p->awaitingSig  ||
            process_p->awaitingResource_p->ownerProcess_p->awaitingResource_p) {
            for(; process_p->awaitingSig  ||  process_p->awaitingResource_p;
               process_p++)
               ;
            }
         else
            process_p = process_p->awaitingResource_p->ownerProcess_p;
         }
      currentProcess_p = process_p;
      }
#ifndef _TMS320C5XX
  longjmp(currentProcess_p->context_a, 1);
#else
  rtmkLongjmp(currentProcess_p->context_a, 1);
#endif /* _TMS320C5XX */
  }
}

This brings back memories.  The scheduler searches the processes from highest to lowest priority.  Notice the "if(process_p->awaitingResource_p" stuff.  I added that code to eliminate priority inversion.  If a process is waiting for a resource, the scheduler now runs the process that has the resource locked.  

I never heard of "priority inversion" but I knew the original code didn't make sense.  When I told the guy who downloaded this RTOS from Dr. Dobbs journal of what I did, he knew the term "priority inversion".  He said that is what caused several spacecraft to be lost that NASA tried to send to mars.  NASA should have hired me.  Maybe NASA gets their code from Dr. Dobbs journal too.

Here are RTMK.c and RTMK.h.   I also zipped up a lot of stuff that has headers that RTMK uses.  7zip creates a file that is one third the size of Microsoft's zip, but this forum won't allow the filename extension .7z.   (500k vs. 1500k)  If anyone wants it, should I add a .txt to the .7z extension or upload the .zip file or put it on OneDrive?
 

So what you (the OP) have, in effect is a process/task/thread that is running, and when an interrupt occurs, you want to abort that process and then restart it.

If I had to do this, I would implement it AS SUCH (in assembly language), saving the full context needed for the process involved, and restoring that context to restart the process.  This is "known science", used by various RTOS code. - no need to re-invent the wheel.    I would suspect that longjump() might miss some of the needed context, since it (probably?) operates at the "C" context level.  For example I wouldn't count on it restoring the "known zero" in R1, which will get trashed during a multi-byte multiply operation.

(On some architectures, it may be that longjump() does restore all necessary context to do this.  But from the quoted parts of the C specifications, it certainly seems that you can't count on it.)

(I'm not sure why people are so inclined to try to twist a HLL into doing work that a few relatively obvious lines of assembly language would accomplish.)