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!
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".