York Jong's Library tagged C →  View Popular

7，按照LSB格式把两个字节转化为一个Word

#define  FLIPW( ray ) ( (((word) (ray)[0]) * 256) + (ray)[1] )

8，按照LSB格式把一个Word转化为两个字节

#define  FLOPW( ray, val ) \

  (ray)[0] = ((val) / 256); \

  (ray)[1] = ((val) & 0xFF)

9，得到一个变量的地址（word宽度）

#define  B_PTR( var )  ( (byte *) (void *) &(var) )

#define  W_PTR( var )  ( (word *) (void *) &(var) )

>

10，得到一个字的高位和低位字节

#define  WORD_LO(***)  ((byte) ((word)(***) & 255))

#define  WORD_HI(***)  ((byte) ((word)(***) >> 8))

16，返回数组元素的个数

#define  ARR_SIZE( a )  ( sizeof( (a) ) / sizeof( (a[0]) ) )

18，对于IO空间映射在存储空间的结构，输入输出处理

  #define inp(port)         (*((volatile byte *) (port)))

  #define inpw(port)        (*((volatile word *) (port)))

  #define inpdw(port)       (*((volatile dword *)(port)))

  #define outp(port, val)   (*((volatile byte *) (port)) = ((byte) (val)))

  #define outpw(port, val)  (*((volatile word *) (port)) = ((word) (val)))

  #define outpdw(port, val) (*((volatile dword *) (port)) = ((dword) (val)))

A third integer promotion rule that is often overlooked concerns
expressions that contain both signed and unsigned integers. In this case,
signed integers are promoted to unsigned integers. Although this makes
sense, it can present problems in our eight-bit environment, where the
unsigned integer rules. For example:

void demo(void)

{

UINT a = 6;

INT b = -20;

(a+b > 6) ?
puts(“More than 6”) : puts(“Less than or
equal to 6”);

}

If you run this program, you may be surprised to find that the output is
“More than 6.”

• Check your compiler documentation. It may allow you to specify
via a command line switch that enumerated types be put into the smallest
possible data type. The downside is, of course, compiler-dependant code

• Accept the inefficiency as an acceptable trade-off for
readability

• Dispense with
enumerated types and resort to lists of manifest
constants

many compiler vendors have
seen the light, and allow you to disable the ANSI automatic integer
promotion rules. However, you’re then stuck with compiler-dependant
code.

Alternatively, you can resort to very clumsy casting, and hope that
the compiler’s optimizer works out what you really want to do. The
extent of the casting required seems to vary among compiler vendors. As a
result, I tend to go overboard:

res = (CHAR)((CHAR)a
+ (CHAR)b);

one needs to use the following declaration:

volatile UCHAR status_register _at_ 0xE000;

status_register =
XBYTE[0xE000];

Here, however, examination of the XBYTE macro shows that volatile is
assumed:

#define XBYTE ((unsigned char volatile xdata*) 0)

Use of assert

The assert() macro is commonly used on PC platforms, but almost never used
on small embedded systems. There are several reasons for this:

• Many reputable compiler vendors don’t bother to supply
an assert macro

• Vendors that do supply the macro often provide it in an almost
useless form

• Most embedded systems don’t support a stderr
to which
the error may be printed

Assert #1

This example assumes that you have no spare RAM, no spare port pins, and
virtually no ROM to spare. In this case, assert.h becomes:

#ifndef assert_h

#define assert_h

#ifndef NDEBUG

#define
assert(expr) \

if (expr) {\

while (1);\

}

#else

#define assert(expr)

#endif

#endif

Assert #2

This case is the same as assert #1, except that in #2 you have a spare port
pin on the microcontroller to
which an error LED is attached. This LED is
lit if an error occurs, thus giving you instant feedback that an assertion
has failed. Assert.h now becomes:

#ifndef assert_h

#define assert_h

#define ERROR_LED_ON() /* Put
expression for turning LED on here */

#define INTERRUPTS_OFF() /* Put
expression for interrupts off here */

#ifndef NDEBUG

#define
assert(expr) \

if (expr) {\

ERROR_LED_ON();\

INTERRUPTS_OFF();\

while (1);\

}

#else

#define
assert(expr)

#endif

#endif

Assert #3

This example builds on assert #2. But in this case, we have sufficient RAM
to define an error message buffer, into which the assert macro can
sprintf() the exact failure. While debugging on an ICE, if a permanent
watch point is associated with this buffer, then breaking the ICE will give
you instant information on where the failure occurred. Assert.h for this
case becomes:

#ifndef assert_h

#define assert_h

#define ERROR_LED_ON() /* Put
expression for
turning LED on here */

#define INTERRUPTS_OFF()/* Put
expression for interrupts off here */

#ifndef NDEBUG

extern
char error_buf[80];

#define assert(expr) \

if (expr) {\

ERROR_LED_ON();\

INTERRUPTS_OFF();\

sprintf(error_buf,”Assert failed: “ #expr “ (file %s
line %d)\n”, __FILE__, (int) __LINE__ );\

while (1);\

}

#else

#define assert(expr)

#endif

#endif

Recursion

Recursion is a wonderful technique that solves certain problems in an
elegant manner. It has no place on an eight-bit microcontroller.

Variable length argument lists

You should avoid variable length argument lists because they too rely on a
stack-based approach to passing variables. What about sprintf() and its
cousins, you all cry? Well, if possible, you should consider avoiding the
use of these library functions.

Passing lots of parameters to a function on an 8-bit machine is not a great idea. Here are some things you can try to get around this limitation:








• Group data into structures and pass a pointer to the structure.
• If you need to pass four chars, you can group them as a union of four chars and one long and then pass the long. (Not pretty, but it works.)

Parameter ordering

This is a limitation that often surprises people. Consider a function foo() that requires a char, an int, and a generic pointer to be passed to it.

void foo(char a, int b, int *c);

This will result in all six bytes (one for a, two for b, and three for c) being passed in registers. However, rearranging the parameter order to:

void bar(int *c, int b, char a);

will result in only five bytes being passed in registers, with parameter a being passed in a fixed memory location. This results in a significant performance hit.

Function calling summary

Take a hard look at all of your function prototypes. The following changes will usually result in worthwhile performance increases:










1. Convert generic pointer arguments to typed pointer arguments.
2. Make sure that any bit or structure arguments are passed last.
3. Notwithstanding #2, don't pass structures!
4. Minimize the number of arguments-but not at the expense of violating rule 3.
5. Look at the ordering of your parameters to see if a reordering will result in all (or more) of the parameters being passed in registers.
6. Experiment! If you have a function that is called regularly, experiment with the order of its parameters. You may be surprised at the gains you realize.
7. If you need to assign a structure from a function call, then return the structure instead of a pointer to the structure.

From the preceding examples, we can come up with a few rules of thumb for decision-making:










1. Avoid the use of the ternary operator.
2. When testing for TRUE / FALSE, omit all explicit tests and rely on the compiler to cast the variable to a Boolean.

From the preceding examples, we can come up with a few rules of thumb for calling one of N functions:










1. If consistent execution time is important, use an array of function pointers. But if the number of indices is greater than six and the indices are contiguous, use a switch statement.
2. If code size is important, always use an array of function pointers.
3. If average execution time is of paramount concern, then you have to do some analysis:
4. For six or fewer choices, use an if-else chain.
5. For more than six choices, where the choices are contiguous, use a switch statement.
6. For all other cases, use an array of function pointers.
7. If you have a situation where the number of choices may be altered over time, and especially if the choices may become noncontiguous, then use an array of function pointers. This will prevent big changes in performance from small changes in code.

To summarize, the memcpy() routine has the following handicaps:














• Needs eight bytes to be passed in registers
  
• Uses a 16-bit looping index-even when eight bits will do
  
• Determines at run time the memory spaces to use
  
• Has to return a value
  
• Hand optimized assembly language
  
• If the 8051 derivative has two DPTR registers (a common extension to many 8051 families), then the function can make use of this to dramatically improve performance for XDATA-XDATA or CODE-XDATA moves.

1. The memcpy() function requires about 56 to 64 cycles of setup time. This is a lot, and is attributable to the number of registers to be loaded and the fact that the memory spaces are determined at run time.
2. The most efficient method of coding one's own copying data routine seems to be the most straightforward, namely a for-loop with arrays (test 8). This is another example of where the simplest coding construct works best. It's also notable that the array-based code is faster than pointer-based code. So much for the adage of "pointers are faster than array subscripting."
3. If we compare the for-loop to memcpy(), the break-even point occurs around seven bytes in most cases. So if you have to copy more than seven bytes, use memcpy(). Otherwise use a for-loop.
4. The big exception is when doing XDATA-XDATA moves on an 8051 with a single DPTR register. In this case, we are comparing the results of test 4a with test 8. Here memcpy() is always slower than the for-loop. Of course, if you need to copy more than 256 bytes, this result doesn't hold. Notwithstanding this, I still find this result pretty amazing.















If speed is what you need, then use these results. However, if you are copying blocks of data around as part of system initialization, I urge you to consider code size, readability and maintainability before making your decision. Indeed, if code size is your prime consideration, you may want to avoid memcpy(), even if you use it in multiple places. The reason for this is quite subtle. It takes about 19 bytes of code to call memcpy() (the compiler has to load eight registers). In addition, the actual library code is 246 bytes. By comparison, the code size for Test 5 is only 16 bytes, while the code size for Test 8 is 30 bytes. You'd have to duplicate this code numerous times to equal the code required by memcpy.