Kenneth M. Cruikshank
Arduino Programming Style

Introduction

Generally it is best to write code for a human to understand. That being said, what is clear to an experienced programmer may be gibberish to a novice. In programming Arduino, we are relatively limited (compared to modern PC's) in the resources we have, so succinct code is of value. However, since the purpose here is to help people learn, I will err towards the side of being verbose with my code! Some things I will do: Define any constants used in the code with #define. This will be done for ALL the register options, even if they are not used in the current code (I want people to start with the raw code, where they can see all the possibilities. Second, the #define constants will be named so that all the code I provide here could be put into a single program without conflict. That may make for longer names.

Functions and function wrappers. Sometimes it is useful to write a single group of functions that work with the I2C interface for reading and writing. Calling these functions alone may not be clear what sensor is acted on (although good naming of the #Define constants should make that clear. I have found it simpler for students at the start if the I2C read/write functions are wrapped in a sensor-specific function. Good in that you you change interface details, you just need to modify the wrapper function, bad for some students in that it seems like putting two function calls in where one would do is confusing. If you don't like the wrapper functions, then feel free to remove them!

Pausing

Sometimes it takes time for a sensor to get into the correct state. It is a good idea to put times pauses between

Variable and functions names

• User meaningful names
• The name length does not matter
• User Verb-Noun names for functions. It makes thing much clearer
• Think Ahead. The easiest way to combine chips into a single project (without going to the extent of creating your own libraries) is to copy and paste. Use names like "ReadALDH54()" rather than Read(). The odds are the second could cause conflicts. Read() does not follow the Verb-Noun construct anyway, so would be a bad functions name.

Debugging Statements

The Arduino console is used for debugging. It is simple to turn debugging on/off by the use of program directives

#define DEBUG true
               ...
               ...               
             #if DEBUG
             // Debug code goes here ... perhaps a print statement
             #endif

If you have multiple sensors, you can have multiple #define statements

#define DEBUG_PRESS true
#define DEBUG_ACCN false

This lets you debug one sensor at a time if needed. Since these decisions are made by the per-processor, these statements are not included are not compiled version, so are not sent to the sensor. If you turn off all the debugging, then that code will not take up space in the Arduino memory

General Program Layout

The code will be broken into a several regions. The advantage of doing it this way is that you focus on a single task at a time, and you have a consistent set of functions (now would be a good time to review "10 tips for a better programming experience").

• Program Constants and function prototypes
• Sensor Constants and function prototypes
• main()
• Program Functions
• Sensor Initialization Functions
• Sensor Read/Write Functions
• Sensor Calibration Functions
• Sensor Value Conversion Functions