Locating 2 parameters at the same address

"of course not, with no local variables what I asked you to do was to show it "with a few local variables" as you stated would be no problem"

So I take it that you didn't pursue the finding of a solution yourself.

I did say that my little code snippet was the starting point. Just consider/remember that parameters and variables do not have to be stored in memory - Hint, no mention of registers.

Please remember, I did say in the same paragraph:

"Of course there are limitations."

And note that for this part, at least, I didn't say there would be 'no problem'.

Anyway ... I do not consider this part of the discussion to be particularly important and I'm not going to get dragged any further into it.

"Would you like to establish a _habit_ of crossing the road at a dangerous spot for 10 other people, when you know that the risk involved is significant"?

the answer to that would depend on many different factors:

1) if the pay-off is sufficient, I would;
2) if the 10 other people understand their risks they are taking, I would;
3) if we are prepared for the risk, we would;
...

it is stupid to say "there is risk so don't do it". we all take risks, one way or another. sometimes wisely and others not so.

there is nothing wrong with taking risks. you just need to plan out the pros / cons and be good at it. that's essentially what IB said, in a more generic form.

it is stupid to say "there is risk so don't do it". we all take risks, one way or another. sometimes wisely and others not so.

It is not necessarily stupid to say "there is risk so don't do it".
There is a risk going very fast on a curvy road, to an inexperienced driver I'd say "there is risk so don't do it", to a NASCAR driver I would not.

Erik

Ron,

I'm the original poster here and I thank you for your post of AP note 129. While my original post didn't confess that I'm using function pointers, this clearly explains how I can get into trouble invoking (sorry, that's a C# term I've adopted) a function from a pointer. This also explains how to fix it.

I don't really follow all the discussion above regarding ISRs. Does the linker make sure that ISRs (and their associated call trees) never overlay anything else? It seems like it would have to.

"There is a risk going very fast on a curvy road, to an inexperienced driver I'd say "there is risk so don't do it", to a NASCAR driver I would not."

but that's precisely what IB said: "there is nothing wrong with doing X if you understand what you are doing" aka your NASCAR example.

the converse of what IB said would be "don't do X if you are an inexperienced driver".

you guys really really need to improve your reading comprehension.

I don't really follow all the discussion above regarding ISRs. Does the linker make sure that ISRs (and their associated call trees) never overlay anything else? It seems like it would have to.

it does, except when it runs into it's trouble with function pointers.

There is nothing inherintly wrong with using function pointers with C51 (or any code for the '51) but the mechanisms required makes it bug prone and less maintainable. Thus I (and many others) have a '51 specific coding style that avoids function pointers.

Erik

"you guys really really need to improve your reading comprehension."

So now it's "you guys"? Why the generalization? It seldom helps an argument. How much credibility would you give to the statement: "Everyone knows that all bikers are criminals"?

Forums are good places for blanket statements, but blanket exceptions always miss caveats. If you included every caveat in the post, you would reproduce the manual ;)

an 8051 is not a re-entrant device. If you call a function with local variables, say foo(), and an ISR occurs, and calls foo() - the ISR's version of foo() could stomp on the values in Registers R0 - R7 if you are not careful.

So calling a function from both main and an interrupt, or a low priority and high priority interrupt you introduce a possible failure point in your code. It is generally not recommended - but there are situation where it will make sense.

Common workaround are (from least to most preferred):

-Create a re-entrant Stack - every time the function is called, its registered are handled by a separate stack

http://www.keil.com/support/man/docs/c51/c51_le_reentrantfuncs.htm

- Create a foo_for_ISR and a foo_for_main

- Make all variables global for that foo()

- Try to hand code the function in assembly, and attempt to put safeguards in

- Switch to a RTOS, such as RTX, and instead have the ISR send a signal, and have a task which calls foo() handle the timing.

Folks, I think you are gallantly galloped way, way off the beaten path if the original poster is posting summary's like "A helpful post"

I love a good name calling and the pedantic arguments session, but maybe it would be better to create a new thread next time we want to do this? I do not think it was benefiting the OP.

Scratch that, I bet we can get this done without the name calling, especially the dreaded "s" word (sardine).

I find it curious that the App Note's method (using the OVERLAY command) doesn't even make it to your Top 5 Workarounds.

Re-entrancy is not my problem. I'm not calling "foo()" from two places. The issue is that foo()'s parameters are overlaid with bar()'s parameters. And in the middle of running bar() an interrupt happens. Unbeknownst to the linker, the ISR called foo().

In my situation, where all the design and 98% of the coding is complete, the OVERLAY command seems the easiest to implement. Next next best option would be to call the functions explicitly rather than by pointer.

"I find it curious that the App Note's method (using the OVERLAY command) doesn't even make it to your Top 5 Workarounds."

but why use such a simple solution when more convoluted ones exist? how can we possibly justify our existence if a simple OVERLAY command does what we can do in a month's time?

not to mention our ego for sophistication.

:)

Overlay solves the 'Linker missed a relationship between 2 functions" issue.

Once you solve that - you may not know it yet - you will have to solve the re-entrancy issue.

If you are calling foo() via main() and via an ISR, (and if foo has local variables) you have introduced a failure point.

To see start the debugger and run to foo()

while in foo, go to Peripherals -> Interrupt. Find your Interrupt and set its flag.

Pay attention to the Registers window, especially the values of R0-R7. Note how the ISR's version of foo will step on these values.

I understand that the OVERLAY command doesn't solve re-entrancy. I understand that the C51 is basically non-re-entrant. Ok. I get it. As I said, I do not think re-entrancy is my problem.

The OVERLAY command should work very nicely for me. However I still don't have it working. I feel like a 2nd grader who keeps getting is homework returned "incomplete".

Without posting lengthy code, here is the function I'm calling via pointer from an ISR. (I don't need the local variable - I just threw it in there to ensure that the problem isn't limited to parameters.)

static U8 InhalationSampleHandler( U16 u16Sample )
{
        U8 u8InhalationSampleHandlerLocal;
...

Below are excepts from the linker and you'll see that addresses 26H & 28H are overlaid among several functions. I did include the Overlay command to specify that my ISR calls InhalationSampleHandler(). You'll also see that I included ?C_C51STARTUP ~ ?PR?_INHALATIONSAMPLEHANDLER?INHALATION as an attempt to solve the warning WARNING L15: MULTIPLE CALL TO SEGMENT, but it didn't help much.

BL51 BANKED LINKER/LOCATER V5.12              07/18/2011  11:39:17  PAGE 1


BL51 BANKED LINKER/LOCATER V5.12, INVOKED BY:
Z:\TOOLS\SOFTWARE\KEIL\BL51.EXE Z:\MicroDose\Phase2\Software\FB_CPU_Init.obj,
Deleted for bevity
>> -21-02-xx.out RS (256) PL (68) PW (78) XDATA (?XD?SETTINGS (0X0)) CODE (?CO
>> ?VERSION (0X7FC0)) OVERLAY (?PR?ADC_ISR?ADC ! ?PR?_INHALATIONSAMPLEHANDLER?
>> INHALATION, ?C_C51STARTUP ~ ?PR?_INHALATIONSAMPLEHANDLER?INHALATION)


Deleted for bevity

  -------         ENDPROC       FLASH_VERIFY
  -------         PROC          _FLASH_WRITE_BYTE
  D:0026H         SYMBOL        pu8Address
  D:0028H         SYMBOL        u8Data

Deleted for bevity

  -------         ENDPROC       INHALATION_DETECTED
  -------         PROC          _INHALATIONSAMPLEHANDLER
  D:0026H         SYMBOL        u16Sample
  -------         DO
  D:0028H         SYMBOL        u8InhalationSampleHandlerLocal
  -------         ENDDO

Deleted for bevity

  -------         PROC          SLEEP_NOW
  -------         DO
  D:0026H         SYMBOL        u8Save_ADC0CN
  D:0027H         SYMBOL        u8Save_P0MDIN
  D:0028H         SYMBOL        u8Save_P1MDIN


*** WARNING L12: NO REFERENCE BETWEEN SEGMENTS
    SEGMENT1: ?PR?_INHALATIONSAMPLEHANDLER?INHALATION
    SEGMENT2: ?C_C51STARTUP


*** WARNING L15: MULTIPLE CALL TO SEGMENT
    SEGMENT: ?PR?_INHALATIONSAMPLEHANDLER?INHALATION
    CALLER1: ?PR?ADC_ISR?ADC
    CALLER2: ?C_C51STARTUP

Found the problem and fixed it. I had to remove the connection between the function that passed the function pointer from the function itself. This is explained in the App Note. (I was thrown off by the cryptic warning from the linker.)

Now both the parameter and local are unique in the data segment.

Call me happy.

"Found the problem and fixed it."

how about this little piece of code:

#include <regx51.h>
#include <intrins.h>

//test to see if var1/var2 overlay creates problems.
//if var1/var2 overlaid incorrectly, P2 will be pulled down to 0 periodically.
//otherwise, P2 = 0x22+1;

#define NOP()                   _nop_()
#define NOP2()                  {NOP(); NOP();}
#define NOP4()                  {NOP2(); NOP2();}
#define NOP8()                  {NOP4(); NOP4();}
#define NOP16()                 {NOP8(); NOP8();}
#define NOP32()                 {NOP16(); NOP16();}
#define NOP64()                 {NOP32(); NOP32();}
#define NOP128()                {NOP64(); NOP64();}
#define NOP256()                {NOP128(); NOP128();}


void sub1(unsigned char var1) {
        var1=0;                                                 //reset var1/var2
        if (var1) var1=0;                               //make sure var1 is always 0
        //P2=var1;                                              //make sure tmr0 is working
}

void sub2(unsigned char var2) {
        var2=var2+1;                                    //increment var1/var2
        if (var2==0) var2=1;                    //make sure var2 is never zero
        NOP256(); NOP256();                             //delay 512 ticks - create opportunity for tmr0 to fire at least once
        P2=var2;                                                //output var2 on P0
}

void tmr0_isr(void) interrupt TF0_VECTOR {
        sub1(0);                                                //call sub1 periodically to reset var1/var2
}

int main(void) {
        TR0=0;                                                  //turn off tmr0
        TMOD = (TMOD & 0xf0) | 0x02;        //tmr0 in mode 2 (auto reload tl0 with th0
        TH0=-100;                                               //tmr strikes every 100 ticks
        TL0=TH0;
        ET0=1;                                                  //enable tmr0 interrupt
        TR0=1;                                                  //turn on tmr0
        EA=1;                                                   //enable global interrupt

        while (1) {
                sub2(35);
        }
}

it follows the example you gave earlier, except that it uses a tmr isr to fire sub1() periodically.

you can play with the compiler settings to get var1/var2 to overlay. what do you think you will get on P2?