AVR Freaks

The GOTO violates the setup and restore operations at the beginning and end of the ISR. THese happen before the first line of written code and after the last line of written code.

My recommendation: if you want to do something like that, do not mess with c!
Jim

I think setjmp and longjmp were invented to let K&R handle 64K pages in the PDP11 they were using to write unix in the early 70s. I agree it might make a good error/restart catchall. One of these old unix dudes could tell us where he has seen setjmp and longjmp used.

Take a step back and say exactly what it is your are trying to achieve here. Why would you want an interrupt to ever do anything but simply return to the point where the interrupt occurred? What you are proposing is actually worse than simple goto code in that it's an interaction from a different thread of execution.

The implication of all this is that you have not flowcharted your design and you are trying to paper over some "hole" that has occurred because you haven't thought the design through in the first place.

I have a feeling that what you are saying is "if some condition happens in the interrupt then cancel some delay I'm part way through". If that's the case then instead of:

do something like:

or perhaps:

or one of the many other ways you could arrange to break out early from a loop if some condition occurs. In this case your "latency" is only as much as 1ms.

I edited above while you typed - you may want to read my edit. Is it really something like breaking out of a long delay you are actually trying to achieve here?

No, either put the jump label at the end of the ISR and to a jump to that.

Or, use David's suggestion of a return() which, behind the scenes, will do the same thing.

Never jump out of the ISR. You will have very big problems. Why make problems when the solution is so easy?

Jim

Dare I even mention it but another option is to use an RTOS. That does allow you to effectively run several programs at once so the more reactive stuff (like servicing the user interface) can still run even if some heavy maths is churning away in the background (and you already decided to ignore its result when it finished anyway). However this is only marginally less pretty than jumping about!

It's certainly true that your minimal "atomic unit" is going to be something like a call to sin() and even if you abort when it returns it may have just started and could do several hundred, even thousand cycles, before control gets back to a point where you could abort.

I wonder if an OS would let you completely "delete" then restart the "heavy math" thread once you decided that what it was doing was pointless - that might get you back quicker than waiting for the longest atomic step to complete.

Then do not use C!

Jim

David,

But if you were willing to act on the interrupt flag why bother with jumping all over the place. Just:

but I think OP is saying the problem is:

and even if he breaks that into:

then it could have disappeared off down the rabbit hole for many hundreds of cycles because while(lots) really is "lots".

Put some numbers on the table. Exactly how many cycles do you have between "doing A" and switching to "doing B" in the mainline code when something occurs in the ISR to force the switch.

You talk about naked ISRs, no RETI and other ill advised actions to save 1 machine cycle but it could be 10's of cycles before you are back to main() and 100's before a current action can be cancelled. So exactly how many cycles do you have? If a sin() took another 500 cycles to complete would it be the end of the world?

I disagree on both counts. The flag has to be tested first (at least one clock), then the branch (one clock if the branch is within range of a brne, and more if you need to use rjmp or jmp). In C, there will likely be a load from memory which may be as little as 2 clocks, and the rest would likely be the same as assembler.

 

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.

ISR+longjmp works as expected, in particular SREG and SP are saved in jmpbuf. And longjmp is designed to jump right out of a call tree (including any level of IRQs).
.
You are trying to implement timeout like in Java where an exception is thrown when a timer triggers.
.
The alternative would be to clutter up your funcs' code with tests an returns if the condition is true, which is not very nice either.
.
Advantage of longjmp is that it keeps your funcs clean and in addition is zero overhead until actually performed, and even then it's just around 40 ticks or so.
.
Main disadvantage of longjmp is that you need cleanup of your funcs internal state which you don't know, as you don't know when exactly the IRQ triggers.
.
And longjmp is not very common, hence there might be some bias against it.

The avr-libc routines also save/restore the call-saved registers, cf. the .irp code. setjmp behaves like a function, i.e. clobbers the call-used regs so that any local whose lifetime crosses setjmp will survive.

 

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.

With AVRs and avr-gcc, I'd be surprised if longjump did not work almost as expected.

The lack of a RETI could be a problem, but since SREG gets restored, all should be ok.

We are not in the realm of C-standard signal-handlers.

We are closer to the realm of PINB |= 4 .

In any case, avr-gcc's ISRs are not C-standard things.

That said, ISR+longjump is not a documented avr-gcc thing either.

If ISR+longjump works for you,

my suggestion is to get the source for it.

Use said source instead of the library version.

That way you might not be affected by updates.

BTW my recollection is that the way to handle register-trashing

by longjmp is to call setjmp from a function that does nothing else

but return the value was wrong.

 

Edit: corrected BTW ....

TI-RTOS is one of the RTOS for an event processing framework.

QP/C: TI-RTOS Kernel (SYS/BIOS)

 

Restoring R1 is not needed because it can only be non-zero during a multi-instruction pattern. You cannot call longjmp (or setjmp for that matter) from within a multi-instruction pattern.
.
If you ever have R1 non-zero between multi-instruction patterns then your program ([inline] asm) is trash.
.
The only thing that does not work as expected are global registers: they are restored but should rather behave like static storage, i.e. retain their values across longjmp.
.
Restoring RAMPx is not needed because GCC assumes they are all 0 and ISR prologue inits them with 0 (except in the case when there is RAMPZ and no RAMPD, content of RAMPZ is of no concern then). (There are some GCC issues with RAMPx handling though, but that's not anything longjmp is to be blamed for.)
.
EIND is also not restored, but that's no issue because GCC assumes that EIND never changes during program execution anyway.

I did but folks seemed to be having so much fun ;-)