Function Called In More Than One Execution Thread

[Alex Finnon 0]

 

I have been trying to write a common LCD routine when an interppt occurs on a 18F452, my snipit compiles but will not build due to the topic error.

 

I have removed the DELAYS etc for ease of reading

 

 

 

Failure

Error: Function called in more than one execution thread: LCD_Clear

Exit code was -2.

Removing target: Clock.hex

Failed to locate output file 'Clock.hex'

Done

 

Failed

 

here is the code

 

// Display Routine

 

#include <system.h>

 

 

#include <lcd_driver.h> // include the LCD template code

 

 

#pragma CLOCK_FREQ 4000000

 

 

 

 

void interrupt( )

{

#ifdef _PIC16

portb++;

#else

latb++;

#endif

 

lcd_clear();

lprintf( "F01:%5d", 6666);

 

// generate formated output a check its as expected

 

clear_bit( intcon, T0IF ); //clear TMR0 overflow flag

}

 

 

 

void main()

{

adcon1 = 00001110b;

lcd_setup();

trisb = 0; //configure port B

 

#ifdef _PIC16

portb = 0; //clear port B

 

option_reg = 7; //set prescaler

 

#else

latb = 0; //clear port B

 

// configure Timer0

set_bit( t0con, TMR0ON ); //enable timer

clear_bit( t0con, T08BIT ); //set 16-bit mode

clear_bit( t0con, T0CS ); // select internal clock

clear_bit( t0con, PSA ); // select prescaler

set_bit( t0con, T0PS0 ); // set 1:64 prescale ratio

clear_bit( t0con, T0PS1 );

set_bit( t0con, T0PS2 );

#endif

// enable interrupts

 

lcd_clear();

lprintf( "F01:%5d", 9999 );

 

set_bit( intcon, T0IE ); //enable TMR0 overflow bit

set_bit( intcon, GIE );

 

 

while( 1 );

}

[Dave 0]

Alex Finnon,

 

Error: Function called in more than one execution thread: LCD_Clear

This error is generated because a function can only be called by one execution thread.

void main() and all functions call from it are considered to be in one execution thread. void interrupt() and all functions call from it are considered to be in another execution thread. There is also a third execution thread which starts at void interrupt_low() if you have a PIC18.

 

A function can't be called in more than one execution thread or its software stack data will become corrupted.

 

For example lprintf may only be part way through when its called again from the interrupt routine.

 

If you get this error, its usually because of a mistake or a sign of not such good programming practise. In you case you are trying to write the LCD in the interrupt routine, interrupt routine are normally short and sweet, leaving long operations to the main execution thread.

 

I hope that helps.

 

Regards

Dave

[Picxie 0]

Calling any functions during an interrupt on a PIC16 are not a good idea (be aware that reading from a rom table has a hidden function call)

The PIC16 has a fixed stack seven deep, the interrupt uses one position on the stack , this leaves only six layers of function call from main().

 

Better is to have a service function in the background loop and trigger it by setting a flag in the interrupt.

 

Picxie

[Picxie 0]

Oh yes, NEVER HAVE A DELAY IN YOUR INTERRUPT!!!! write this in reverse on your forehead and put a mirror on top of your monitor to remind yourself!

[Alex Finnon 0]

Thanks people for putting me on the right track

[a1960yoldm 0]

-This limitation really piss me off.

 

I understood the reason on setting this limitation. But, the limitation did already pull me out from using Boosc on my application which need to use a large look up table from different threads( main & interrupt). To duplicate the LUT(look up table) is not possible due to ROM size limitation.

 

- It is compiler's responsibility to warn users on using function call from different threads.

- It is not compiler's responsibity to take away the possibility for users to full ultilize PIC capabilities.

 

Pls remove the limitation asap. I will not recommend to use BoostC if the limitation still there.

[Pavel 0]

I have initiated discussion of this issue in our development team. I will post the outcome once we come to any conclusion.

 

Regards,

Pavel

[Picxie 0]

-This limitation really piss me off.

 

I understood the reason on setting this limitation. But, the limitation did already pull me out from using Boosc on my application which need to use a large look up table from different threads( main & interrupt). To duplicate the LUT(look up table) is not possible due to ROM size limitation.

 

- It is compiler's responsibility to warn users on using function call from different threads.

- It is not compiler's responsibity to take away the possibility for users to full ultilize PIC capabilities.

 

Pls remove the limitation asap. I will not recommend to use BoostC if the limitation still there.

<{POST_SNAPBACK}>

 

 

Perhaps a way to turn this feature off for those occasions when you just have to do it.

 

Another possibility...

 

How about the ability to make a function synchronized OR a way to make a code block atomic.

[Dave 0]

a1960yoldm,

 

This limitation really piss me off.

Um, I don't think the use of bad language helps, we much prefer phrases like "I could do with help..., I would benifit if..."

 

I understood the reason on setting this limitation. But, the limitation did already pull me out from using Boosc on my application which need to use a large look up table from different threads( main & interrupt). To duplicate the LUT(look up table) is not possible due to ROM size limitation.

 

- It is compiler's responsibility to warn users on using function call from different threads.

- It is not compiler's responsibity to take away the possibility for users to full ultilize PIC capabilities.

To date the feature has save several programmers from themselves (me included in that).

 

The whole problem is down to the software stack.

Each thread of execution has its own stack, so which should be used for a given routine if its is shared? - Answer nether can be used as sharing the same stack space will potentially cause corruption.

 

The function itself could have its own little software stack, to prevent any corruption of other stacks.

 

Before the function was called, some kind of interlocking would be necessary, so that call can't be interrupted or re-entrency would occur.

 

Pls remove the limitation asap. I will not recommend to use BoostC if the limitation still there.

More pleasantries - thankyou

 

The solution to this problem is still underconsideration.

 

Regards

Dave

[a1960yoldm 0]

a1960yoldm,

 

This limitation really piss me off.

Um, I don't think the use of bad language helps, we much prefer phrases like "I could do with help..., I would benifit if..."

I am sorry about the bad lanquage. I just want to express my disappointment about this Limitation.

 

I understood the reason on setting this limitation. But, the limitation did already pull me out from using Boosc on my application which need to use a large look up table from different threads( main & interrupt). To duplicate the LUT(look up table) is not possible due to ROM size limitation.

 

- It is compiler's responsibility to warn users on using function call from different threads.

- It is not compiler's responsibity to take away the possibility for users to full ultilize PIC capabilities.

To date the feature has save several programmers from themselves (me included in that).

 

The whole problem is down to the software stack.

Each thread of execution has its own stack, so which should be used for a given routine if its is shared? - Answer nether can be used as sharing the same stack space will potentially cause corruption.

 

The function itself could have its own little software stack, to prevent any corruption of other stacks.

 

Before the function was called, some kind of interlocking would be necessary, so that call can't be interrupted or re-entrency would occur.

Thank to Dave's valuable opinion. This is the solutions to prevent causing problem with programmer's effort (not just make it impossible from the compiler). Perhaps a setup file (Boostclink.ini???) with a line to enable/disable this limitation (factory set to "enable") will be okay. Don't you think so.

 

Pls remove the limitation asap. I will not recommend to use BoostC if the limitation still there.

More pleasantries - thankyou

 

The solution to this problem is still underconsideration.

Regards

Dave

<{POST_SNAPBACK}>

I hope the decision will come out timely and positively. However, Thank to all prompt response.

[Dave 0]

a1960yoldm,

 

I hope the decision will come out timely and positively. However, Thank to all prompt response.

What is the timescale of your needs?

 

Regards

Dave

[a1960yoldm 0]

a1960yoldm,

 

I hope the decision will come out timely and positively. However, Thank to all prompt response.

What is the timescale of your needs?

 

Regards

Dave

<{POST_SNAPBACK}>

Dave, It is better to have it within this month. Is it possible??

 

Regards,C.Y. (from Taiwan)

[Dave 0]

a1960yoldm,

 

Dave, It is better to have it within this month. Is it possible??

Yes it is possible.

We need to establish how we will make this work.

 

Regards

Dave

[a1960yoldm 0]

a1960yoldm,

 

Dave, It is better to have it within this month. Is it possible??

Yes it is possible.

We need to establish how we will make this work.

 

Regards

Dave

<{POST_SNAPBACK}>

 

Dave,

Thanks a lot. Pls let me know if any good news.

 

Regards,C.Y.

[Picxie 0]

We need to establish how we will make this work.

 

Regards

Dave

<{POST_SNAPBACK}>

 

Off the top of my head.

A function modifier word

eg

 

multithread void fun(char param)

{}

 

have two/(three pic18) entry and exit points points with seperate context which point to a common body. all local vars accessible by indirection

[a1960yoldm 0]

We need to establish how we will make this work.

 

Regards

Dave

<{POST_SNAPBACK}>

 

Off the top of my head.

A function modifier word

eg

 

multithread void fun(char param)

{}

 

have two/(three pic18) entry and exit points points with seperate context which point to a common body. all local vars accessible by indirection

<{POST_SNAPBACK}>

 

There are more to be cared if only depend on a powerful compiler. Like, how to handle global variables. One threads modified it but don't be expected by the others, It is terrible. So that, I think if a powerful compiler can't be expected, than a disciplined programmer shall involved.

 

Regards,CY

[bsdvodsky 0]

I just ran into this error using BoostC v6.40 (PIC18)...

 

Has an elegant solution been decided upon/implemented yet?

[Dave 0]

bsdvodsky,

 

I just ran into this error using BoostC v6.40 (PIC18)...

 

Has an elegant solution been decided upon/implemented yet?

<{POST_SNAPBACK}>

In BoostC V6.55 this error has been down graded to a serious warning.

You need to be very careful, and don't just ignore this error as there is a high probability that you will corrupt the software stack unless you ensure that the function can't be re-entered during its execution.

 

Regards

Dave

[PeterJL 0]

bsdvodsky,

 

I just ran into this error using BoostC v6.40 (PIC18)...

 

Has an elegant solution been decided upon/implemented yet?

<{POST_SNAPBACK}>

 

Pls remove the limitation asap. I will not recommend to use BoostC if the limitation still there.

 

 

 

 

Dave

Let's not get too excited here. One can pay out A$1000 for HiTech PICC and try calling the same function from inside and outside an interrupt. Same limitation, similar error message.

The local C gods (ie. C acquired with university degree rather than self-taught) shake their heads when they see the rubbish code I have managed to get working inside an ISR. I'm told that the "correct" approach is to modify flags, clear the interrupt and get the hell out of it as soon as possible, then use other code to deal with the flagged conditions.

Does a compiler warning that indicates that I have written rubbishy amateurish code consititute a limitation of the compiler, or of me?

Regards

PeterJL

[Dave 0]

PeterJL,

Dave

Let's not get too excited here. One can pay out A$1000 for HiTech PICC and try calling the same function from inside and outside an interrupt. Same limitation, similar error message.

I'm certainly not getting too excited (although its hard not to ).

The local C gods (ie. C acquired with university degree rather than self-taught) shake their heads when they see the rubbish code I have managed to get working inside an ISR. I'm told that the "correct" approach is to modify flags, clear the interrupt and get the hell out of it as soon as possible, then use other code to deal with the flagged conditions.

Only being in the ISR for a short period of time is generally the best thing to do, otherwise the rest of your code is suspended, waiting for some CPU time.

This is only a general rule, for some applications I can imagine being in the ISR code for a long period, but that would be the right thing for that application.

Does a compiler warning that indicates that I have written rubbishy amateurish code consititute a limitation of the compiler, or of me?

The reason that this error has been reduced to a serious warning is because there are definately times when you may want to call a function from the main thread of execution and from an interrupt service routine. For example you may want to call a function during initialisation (before interrupts are enabled) and then in an ISR, but the two times the function is called cannot overlap.

 

The warning is no measure of the quality of the code. If you see the warning its best to check you code is structured correctly and that you avoid the software stack corruption issue, or you may create some rare and hard to find problems.

 

Regards

Dave