Function Called In More That One Execution Thread:

[tobik 0]

Bug description:

If a method is called in main () and interrupt () then we get an error

Function called in more that one execution thread:

 

Steps to reproduce:

static char ch;
char read_eeprom (char addr) {...}
void interrupt ()
{
   ...
   char ch2 = read_eeprom (2);
   ...
} 
void main ()
{
   ch = read_eeprom (1);        // Initialization
   set_bit   (intcon, GIE);  // Enable interrupts
   while (1)
       sleep ();
}

 

Expected behaviour:

There could be a warning but no error.

 

Reproduceable:

always

 

SourceBoost DE version: 5.6.1

Compiler: BoostC

Compiler version: 1.1 alpha

[Guest Dave]

Tobias.

 

Sorry this is not a bug, its by design

 

It could be considered a current limitation.

 

You may or may not be aware of where a conventional C-compiler normally stores it local variables, it uses the stack.

 

The PIC16 has only a tiny stack that can hold anything other than return addresses, the PIC18 has a bigger stack but its still very small and creates a large code overhead if it was to be used for storage and retreival of data.

 

So instead all the location for local data are calculated by the linker, it works out what the stack would look like. It then allocates memory for storage of this data.

It builds what is sometimes called a software stack. This is all done before the program runs on the target device, which means the code is very effecient.

 

It is effecient in two ways:

1) Memory space is re-used between different functions, just like a convection stack.

2) Access to the memory needs a minimal number of instructions, because its address is know before the code runs.

 

 

Q: So why do we get this error?

A: To save local data getting corrupted.

 

The error could be made just a warning, but the result would be some code very likely to fail, do some bizare things. The error is meant to save you and me from some code that could be quite flakey.

 

Imagine what happens if a function in the main is being called an interrupt occurs. The code is suspended and execution pops off to the interrupt routine.

Now if the interrupt routine calls the same routine the same memory locations get used as by the function being called by the main routine. The interrupt routine will changed the data used in the main routine function call resulting in apparent data corruption as fair as the main routine is concerned.

 

There are other possibilities for data corruption when accessing variables shared between interrupt and main routines. Maybe you can now image what they may be.

These data sharing issues exist if you are programming multi-thread applications under windows, timer events on your Allen Bradley ControlLogix PLC or interrupts on your little PIC chip.

 

Some other interrupt routine points to note:

1) Generally interrupt routines want to be as short as possible, to reduce the impact on the back ground code, and to allow the interrupt to be ready for the next event.

2) Calling subroutines from within an interrupt routine is not so good, as this is starting to make a long interrupt routine.

3) Be careful with data shared between routines, and interrupt can occur an any time, consider disabling interrupts when accessing shared data to gurantee the data is locked until access is complete.

 

Theses are only "Daves general rules" (all I can think of right now )

 

 

There is a way round it, declare the required function inline .

Any inline function has a copy of it code inserted exactly where it is used. So it can make the code longer, but as the code exists multiple times each can address different software stack memory.

 

 

Hope you manage to read this far and it all makes sense.

And that this explains things and helps you understand this limitation.

 

 

Regards

Dave

[tobik 0]

Dave

 

Thank you for the explanation. I well understand your point of view. Even if my example show a valid situation for calling routines from differend "threads" you are right there are lots of different situations leading to errors.

 

So lets call that a limitation. I will workaraound it.

 

Thank you,

Tobias

[Guest Dave]

Tobias,

 

Declare the required function(s) as inline.

 

Regards

Dave