We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I had searched in the Discussion Forum for the whole moring but I couldn't find the right way to solve the problem I met,so I send this message hoping you guys can help me!Thanks in advance:-)My problem is as follows: 1.I want to define a macro,which is similar like function.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) 2.here's the definition of this macro: #define Macro_TestRxEnd(sbit Header_flag,uchar Header,uchar Tailer) \ { \ Return_flag = 0; \ if (!Header_flag) \ { \ if (Rxbuf == Header) \ { \ Header_flag = 1; \ ptRxBuf++; \ } \ else \ { ptRxBuf = xBuf; } \ else \ { \ if (Rxbuf == Tailer) \ { Return_flag = 1; } \ } 3.then the compile result is : Error C304: Bad Macro Parameter List so can anyone help me find out the right way to define such a long macro? I'm waiting for your good ideas earnestly!
This is basic 'C' stuff - nothing specifically to do with Keil! "I want to define a macro,which is similar like function" This is really quite dangerous. Macros can look like functions, but behave very differently - there are many pitfalls, some of which are discussed in K&R. "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. There is a general rule-of-thumb that one should try to keep Interrupt Service Routines (ISRs) "small" - meaning that the amount of code executed during the interrupt service should be minimised. Putting your code into a Macro will not help in this respect! In fact, If the code is so large that you think you need a macro for it, the overhead of calling a function is probably insignificant! "3.then the compile result is : Error C304: Bad Macro Parameter List" Of course it's bad: open your 'C' textbook - macro parameters do not have type specifiers! As I said, macros can be dangerous because they look like functions, but don't behave like functions. You have already fallen into one such trap before you've even started - do you really want to dig yourself (and the rest of your team, and their successors) more traps to fall into...? I think you should re-think your approach!
""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.