S. Marsanne

Sharing some coding and debugging style (part 1)

Discussion created by S. Marsanne Employee on Dec 16, 2016

There are many way to write source code and debug it.

For the ones who would like to look around, compare and grab what makes sense for your own use...

Here is one to share: mine  just grab what looks handy to you.


1. When declaring a function, put a meaninful comment on the same line.

Why? ==>  Searching with "find in file, or grep" only one line will popup... make it count!

void MyFunction(void) { // this is the clue on what this function is


2. When having the choice between using enum or #define, use enum.

Why? ==> When debugging, the watch window will use the TEXT instead of the decimal equivalent. Also with enum, add one last item in the list which will be the... number of items! Can be handy when valid range check is implemented.


typedef enum {
} KeyStyle_t;


3. Creating a new C and H file, make the creation intuitive. If the file is MOTOR_CONTROL.H and MOTOR_CONTROL.C, add to the header file:


// put here your definition and extern variables


(You can use this _xxx_H_ in the C source code to know if the include file is there or not for conditional code at compile time.)


4. Use a single global header file which will #include all the user created ones.

Why? ==> It's easier to maintain and today compiler won't slow down due to this, adding a new C/H set of files can be done in one global header file. In Java language, there is no longer H files anyway.



5. In each C file, add a Test function which will be there and used when someone wants to reuse the file and test it. Use the file name to inspire the test function name... minimize dependencies for easy source code grab and reuse.


6. When using sensors or time and avoid using float variable, make the variable name meaningful.

Why? Can you guess the temperature in this example? s32 Temp_DegC_x100 = -12345 ? ==> -123.45 degreeC !


7. Some of the macros or types that are handy to me: (it may not be valid for strict coding rules)


Sharing some coding and debugging style (part 2) 

typedef int32_t s32; // because eyesight is a small visual area on the screen, I'm trying to shrink the text size horizontally
typedef int16_t s16;
typedef int8_t s8;

typedef uint32_t u32;
typedef uint16_t u16;
typedef uint8_t u8;

#ifndef Absolute_Difference
#define Absolute_Difference(x,y) ((( x ) < (y)) ? ((y) - ( x )) : (( x ) - (y)))
#ifndef Min
#define Min(x,y) ((( x ) < (y)) ? ( x ) : (y))
#ifndef Max
#define Max(x,y) ((( x ) > (y)) ? ( x ) : (y))

#define MakeItNoLessThan(a,b) if((a)<(b)) (a) = (b)
#define MakeItNoMoreThan(a,b) if((a)>(b)) (a) = (b)
#define countof(a)  (sizeof(a) / sizeof(*(a))) // how many elements in an array
#define min3(x,y,z) (((( x ) < (y)) && (( x ) < (z))) ? ( x ) : (((y) < (z)) ? (y) : (z)))
#define max3(x,y,z) (((( x ) > (y)) && (( x ) > (z))) ? ( x ) : (((y) > (z)) ? (y) : (z)))

#ifndef LOBYTE
#define LOBYTE(w) ((u8)(w))
#ifndef HIBYTE
#define HIBYTE(w) ((u8)(((u16)(w) >> 8) & 0xFF))
#define HIWORD(w) ((u16)(w>>16))
#define LOWORD(w) ((u16)(w))
#define MAKEWORD(b, a) ((u16)(((u8)(a)) | ((u16)((u8)(b))) << 8))
#define MAKEDWORD(d,c,b,a) ((u32)((u8)(a))) | (((u32)((u8)(b))) << 8) | (((u32)((u8)(c))) << 16) | (((u32)((u8)(d))) << 24)

#define ABS(x) ((x) < 0 ? -(x) : (x))
#define CLAMP(x,min,max) {if ((x) <= (min)) ( x ) = (min); else if (( x ) >= (max)) ( x ) = (max);}

#define S24_to_U32(a) ((a) & 0x00800000) ? ((a) & 0x003FFFFF) : ((a) & 0x003FFFFF)+0x00400000 /* positive */
// above is useful in pressure sensor and sensors using 24 bit sign data and need to convert it to 32 bit signed integer

// ((u32(*)(u32)) ==> Is a cast for a function pointer passing a 32 bit quantity and returning a 32 bit value
// for a long time, was trying to avoid using function pointers due to compiler/linker having hard time to optimise.
// now things have changed... to be continued if there are enough views on this tip and tricks.