HELP:How to define a complex MACRO?

""It will be used in my communction interrupt service routine (so you can see that why I don't choose to call a function to realize it)"

No, I don't see that at all."

Think about the lack of an 'inline' keyword and you'll understand.

"Think about the lack of an 'inline' keyword and you'll understand."

No - you've lost me there!

Maggie Chen: "It will be used in my communction interrupt service routine (so you can see that why I don't choose to call a function to realize it)"

Me: "No, I don't see that at all."

Actually, I don't see the point of the macro or a function at all: it's not a huge piece of code - why not just write it as straight code??

"No - you've lost me there!"

If you call a function from an ISR and from elsewhere in the code you have to make it reentrant. If you use a macro the code is compiled inline and the problem disappears.

"If you call a function from an ISR and from elsewhere in the code you have to make it reentrant."

OK - back with you now!

Yes, that's true.

However, it looks to me like this bit of code should be used in the ISR only (recognising the start/end of a packet in the data stream?) - in which case there's no particular problem with having it in a function (other than the call overhead, which I don't think should be too significant in this case?)

Having said that, if I am right, I don't see the point in using either a function or a macro - I don't see why it shouldn't just go verbatim straight in the ISR.

Maybe the OP could enlighten us...?

"However, it looks to me like this bit of code should be used in the ISR only"

Quite possibly, I had just assumed the reason for making is a macro was to avoid the very popular 'multiple call to segment' warning and all its associated hazards.

I work on 32-bit RISC systems with vast amounts of memory and stack space, but I mostly work on very small 4-bit and 8-bit systems with very limited amounts of memory and stack space. For example some PICs have an 8-level hardware return stack and some have only 2 levels, so I am very familiar with call/interrupt nesting awareness and using memory efficiently. That said, I think you are being a bit too conservative in this regard with respect to an 8051-based system. If you are that tight on memory then you could be destined for trouble despite your efforts to save a call from within an ISR. Give your ISR room to breathe. Don't get me wrong, I eschew unnecessary calls from ISRs too, but I also don't obscure my code by using macros (inappropriately) either.

By "obscure", I mean that your protocol frame tests are not that complex and by using macros (at least as you have presented them) you are actually doing yourself and your successors a disservice by obscuring direct data object manipulation and side effects. Let's say you fix the macro parameter typing, you are still using "xBuf", "Rxbuf", "ptRxBuf", and "Return_flag" inside the macro, hiding their use from a reader. In this case you are much better off just laying it all out explicitly in the ISR so that one can see exactly what is being used and affected.

Keeping ISRs small refers to keeping the execution paths short and overall time spent in the ISR short. You could have a mile-long switch/case statement in your ISR with each case having a simple body and it would be considered "small". So look again, switch on "framemode", a few conditional statements, and you're done! That's "small".

"each frame has their own frame header and tailer."

Yes, but all messages have the same format, I presume:
1. A header;
2. a body;
3. a tail.
I would structure the ISR on this basis, rather than try to detect each message type independently...

"If you guys don't mind,I suggest that let's forget all other things only for 1minute except putting focus on finding the right way to write a multi-statement macro that can be successfully compiled."

I do mind!
Dan has said it too: using macros here is unnecessary and too risky - so don't do it
I don't want to help you shoot yourself in the foot!

Dan has now pointed out another common macro pifall - so, I'll say again:
"You have already fallen into two such traps before you've even started - do you really want to dig yourself (and the rest of your team, and their successors) even more traps to fall into...?"

Ancient proverb say: Man at bottom of deep hole should stop digging!

"...all messages have the same format, I presume:
1. A header;
2. a body;
3. a tail.
I would structure the ISR on this basis..."

Something like this:

void isr( void )
{
    static bit           in_message = 0; // Set to 1 after a header has been detected;
                                         // Cleared to 0 when a trailer is detected;
                                         // Thus it indicates when we are within the body
                                         // of a message

    static unsigned char msg_type;       // Records the last-received header;
                                         // So, when in_message is set, this indicates the
                                         // type of message currently in progress.

    if( in_message )
    {   // We're within the body of a message;
        // ie, a Header has previously been detected.
        // Check if this is now the end of the message
        if( Rxbuf == Tailer )
        {   // It's the end of the message
            in_message = 0;
        }
        else
        {   // It's not the end of the message;
            // handle a message-body character
            // (possibly depending on msg_type?)
        }
    }
    else
    {   // Not currently within the body of a message;
        // Check if this is a header
        switch( Rxbuf )
        {
            case A_Header:  // It's the start of an "A" frame:
                            in_message = 1;
                            msg_type   = Rxbuf;
                            break;
            case B_Header:  // It's the start of a "B" frame:
                            in_message = 1;
                            msg_type   = Rxbuf;
                            break;
            case C_Header:  // It's the start of an "C" frame:
                            in_message = 1;
                            msg_type   = Rxbuf;
                            break;
            default:        // Not the start of a frame - Do nothing!
                            break;
        }
    }
}

:-)special thanks to Dan and Andy for shareing your experience to me and other friends,you both have a kind heart and a preciseness attitude toward work[from Andy's saying that he do mind even for 1minute,so I guess you are preciseness :-)
Just as the Chinese ancient proverb say: Among any three people walking, I will find something to learn for sure.Today I learn a lot from you.And I've accepted Andy's strong advice that not to use macor in this condition.As to the point:
but all messages have the same format, I presume:
1. A header;
2. a body;
3. a tail.
I would structure the ISR on this basis, rather than try to detect each message type independently...
The ISR need to tell the main program which frame is received now,that is to return relative flags, so if not detect each message type independently,how can the ISR translated frame message to main program? By your way,the ISR can only tell the main program that a total frame is received,but the main has to test the rxbuf(header) again to find out the kind of frame.

During this weekend I can't come here to read the later responses and write back,so please allow me to reply next Monday:-)Wish you all have a good weekend!

A.W. Neil,thank you the same:-)I'll read your ideas carefully and send back next Monday,see you!Looking forward to more ideas(maybe not only limited to the original message) ^-^