setjmp/longjmp or work-arounds

[gustnado]

I have an application where I wait for user input at many places in the code. I want a built-in timeout that takes me back to a spot in my mainline.

setjmp/longjmp are used for this in standard C, but I found a thread indicating that they may not work in PCH. I need to work with both 16F and 18F series processors.

Do they work in both compilers?

If not, is there a workaround using embedded assembler?

If I can't find this sort of solution, I have to return an impossible value (0, for example) and then test for it every place I go to read a character, which would greatly increase the size of the code!

Advice sought. I am new to PIC and new to CCS.

Thanks
_________________
The best weather is bad weather

[PCM programmer]

Can you provide a link to the thread that says they don't work in PCH ?

[gustnado]

Yes -

http://www.ccsinfo.com/forum/viewtopic.php?t=18754&highlight=setjmp

Thanks
_________________
The best weather is bad weather

[gustnado]

I found this since my last response:

http://www.ccsinfo.com/forum/viewtopic.php?t=19923&highlight=setjmp

An answer by "guest" says:

---------------

r = setjmp(env); Standard C function (requires setjmp.h)
longjmp(env,val); Standard C function (requires setjmp.h)

Use these functions with GREAT caution. Note as well that setjmp and
longjmp do not clean up the stack on 12 and 14 bit parts.

----------------

This is a bit alarming, as I plan to use this capability on both 14 and 16 bit parts. If it does not "clean up the stack," what do I do?

Traditional C compilers maintain a runtime stack with local variables on it, so "cleaning the stack" involves backup up that pointer. I believe these CCS compilers, since they use a compile-time function tree, simply hard allocate those variables in RAM, sharing those that cannot (according to the tree) be active at the same time. In that case, resetting the CPU stack pointer to the top should be adequate (assuming setjmp was called from the top level), since there is no local variable stack.

Is this the case? What would the code look like?
_________________
The best weather is bad weather

[PCM programmer]

CCS doesn't have any example programs for the setjmp.h file.
Normally, CCS would have something like EX_SETJMP.C, but
I don't see one.

I went to this guy's page and modified his "if-else.c" setjmp
example slightly, so it would work with CCS.
http://linuxgazette.net/issue90/raghu.html
It appears to work OK with PCM vs. 3.223 with a 16F877, but
it did not work with PCH vs. 3.188 with a 18F458. I don't have
the latest version of PCH, to test it.

If CCS doesn't have a EX_SETJMP.C file to test it, how do
they know if SETJMP.H works ?

[gustnado]

I have it working okay on a 18F452.

It's in the middle of a bunch of code, so I'll just post snippets:

#include "setjmp.h"

jmp_buf set_jmp_env;

main() {
....
if(!setjmp(set_jmp_env)) {
printf(sendChar,"Going for getTimedChar\r\n");
c = getTimedChar();
printf(sendChar,"Got %c\r\n", c);
...
} else {
printf("longjump happened\r\n");
}
.....
}

int getTimedChar() {
....
if (input_timer_setting_secs && !input_timer_countdown_secs) {
longjmp(set_jmp_env, 0xa5);
}
.....
}

Now if I could just get interrupt driven USART receive working, I would be happy


_________________
The best weather is bad weather

[PCM programmer]

[gustnado]

I am running PCH Version 3.223.

I have no idea if longjmp/setjmp will work with PCM. If not, I've got a big problem. Unfortunately, I have no way to test it - all I have is a little test board that came with the PCH development kit, and it has an 18F452 on it.

Regarding interrupts, maybe you can point me to an example. I'll put a separate post here with my code.

Thanks
_________________
The best weather is bad weather

[gustnado]

FYI, I got the interrupt routine working, so no help needed.

It helps to read the data register with a "*" in front of the address of the input data fsf
_________________
The best weather is bad weather

[PCM programmer]

[gustnado]

Thanks. It looks like it should do the job, then.
_________________
The best weather is bad weather

[gustnado]

The example works fine in PCH/18F452, but in my application, where things are more complex and the longjmp takes place well down in a subroutine call hierarchy, it doesn't work right - it causes restarts sometimes and other times does not - all to the same input!

Because longjmp uses a stack, which makes it complex and the assembly code hard to follow, I am going to give up on it, assume there is a good reason that it is not in the compiler book and examples, and write my own simple one in assembly language.

My tentative conclusion, after a lot of fiddling, is that setjmp/longjmp is possibly flawed in a subtle way. With the code slightly different it would always go to the right place but setjmp always returned 0, even when a longjmp(jmp_buf, 2) was taken. The code around it now looks like:

[PCM programmer]

It is in the manual. Download the Feb. 2005 manual. Use the
search engine of Acrobat Reader to search for: setjmp

It's in there, in several places.

[gustnado]

You are correct, although it is not in the expected location - the alphabetical list of functions with descriptions. I missed it because I was using the printed version of the same manual. Thanks for the pointer.

However, there is my experience and that of the other person's where longjmp apparently frequently causes restarts on the 18f series.

Should I report this as a possible bug?
_________________
The best weather is bad weather

[PCM programmer]

Sure. If you can give CCS a complete (but short) test program
that allows them to easily see the problem, then your chances
of getting them to fix it are much better. Also give them your
compiler version.