The firmware for the weatherbox project is modular platform-agnostic program. It is designed to be versatile in the sense that it can be easily adapted for any changes to the current generations, without affecting the processes of another generation and to be modular enough to support implementation of new generations and hardware. This page is designed to aid the maintenance and development of the firmware.

• Programming
  1. GitHub
  2. Coding medium (Recommended: Git Bash)
• Testing
  1. Arduino IDE
  2. Arduino board (For Apple / Uploading capabilities)
  3. Arduino USB cable
  4. Generation board (Request from Hardware teams)
  5. Flood light (For solar irradiance sensor)
• Transmitting/Receiving
  1. XCTU software
  2. A pair of properly configured XBees
  3. XBee shield
  4. Mini USB cable
  5. XBee breakout board

The firmware code is broken into four main modules:

1. Configuration Module
2. Sensor Module
3. Transmit Module
4. Utility Module

These modules are designed in a way such that they're independent of each other for lower level testing purposes. When the dependencies are put into place (i.e. the Transmit module calls functions from the Sensor module), they can also be tested incrementally. The only major dependence is in the Configuration Module when testing the other modules on a particular generation.

This module controls what generation the firmware is being run on. It handles the necessary pin configurations and function pointer assignments.

Pin Changes

• Change the software pin number in accordance with the hardware pin number

Generation Configuration

• In config.h file, un-comment the definition for the macro corresponding to the generation name
• Comment-out the definitions for the other generations

New Generation

• Each new generation needs:
  1. Macro corresponding to its name under the Generation Declarations
  2. A conditional compilation wrapper (#ifdef and #endif) containing its pin configurations
• All generations should use the same pin naming convention to keep consistency
• If a generation does not use a declared pin (i.e. _ADDR_BARO for Apple):
  1. Declare the pin at the bottom of the declarations with value 0 and comment “Not used”
• For consistency, use the same order of pin configurations as the previous generations, with the unused pins listed at the bottom
• In Gen_config(), a wrapper assigning the function pointers to the correct sensor functions

New Function Pointers

• Must be declared as extern in config.h (declared normally in the .ino)
• Set up to be configured to the appropriate functions based on the generation declaration

Generation Version Updates

• Correct the version # in the top comment box
• Correct the version # for the macro (i.e. Apple 3.4 → APPLE_VERSION 34)

This module contains the functions that initialize and poll data from the sensors. For the newer generations, it uses the I2C line, so knowing the addresses of the components is important. The I2C addresses of a component can be found in their data sheets.

Sensor Libraries

• When a generation is implementing a new sensor, be sure to find the corresponding Arduino Library for that sensor
• The provided libraries handle the complexities of using I2C
• Allows us to simplify our functions to contain a simple function call to the library's functions and apply scaling factors

Scaling Factors

• Two primary uses:
  1. Saving significant digits for accuracy
  2. Convert the ADC value to a meaningful value (i.e. A 16-bit ADC returns a value ranging between 0 and 32767)
• These values need to be associated with an actual voltage value
• Scaling values can be derived based on the component's data sheet
• Include hardware designs choices (such as a voltage divider)

I2C

• Addresses can be found in the component's data sheet
• If the component doesn't have a pre-made library (to handle I2C):
  1. Use the Wire library to manage I2C

Objects

• Some libraries require you to create instances of an object to communicate with that component
• In the .h declare it as an extern
• in the .cpp declare it normally
• Keep any object initialization in the corresponding Sensors_Init() function

This module contains the necessary functions for transmissions. This includes clearing/initializing the packets, filling the packet with data, transferring the packet into a payload, and transmitting the payload. Relies on the XBee library.

Transmission Methods

• UART
  1. Converts data into a string
  2. The string is copied into the payload (bit by bit)
  3. Transmitted using XBees
  4. Allocates a portion of the string to indicate the data (“Data_Description:” “<Data>”)
• BINARY
  1. Collects data into a struct
  2. Struct is copied to the payload (bit by bit)
  3. Transmitted using XBees
  4. Bits that correspond to the data are in the order of the struct
• Both are not named properly and give the wrong impression

XBee Configurations

• XBees must have the same pan ID
  1. Use a unique pan ID for a testing network
• Must be in API Mode 2 (with escaping)

Test Functions

• There are two test functions (one for each type of transmission)
• They fill a packet with hard coded information
• Used to verify the packet sends without corruption

New Transmission Methods

• Create a new set of functions:
  1. Clearing the packet (if it uses a different packet type)
  2. Transmitting the packet
  3. Real packet construction
  4. Test packet construction
• Create function pointers (in Configuration Module) to reflect the new addition

Globals

• Packet types are global variables
• XBee object is also global

Objects

• XBee library requires you to create an instance of the XBee object, XBeeAddress object, and ZBTxRequest object for transmission
• XBee object
  1. Declared as a global in the main (.ino)
  2. Declared as a global extern in the header (.h)
• XBeeAddress object
  1. Used to indicate address of the receiving XBee on the network (same pan ID)
  2. Uses function call XBeeAddress64(x, y);
  3. Using x = y = 0 in the function call broadcasts the packet to the network and will be received by any XBee configured to be a receiver
• ZBTxRequest object
  1. Used to create generate a request to transfer the packet
  2. Uses function call ZBTxRequest(address, payload, payload_length)
  3. The address is the address created by the XBeeAddress64() function

Schema

• Structs used for BINARY transmission method
• Currently 3 schemas:
  1. schema_3 - For Cranberry and Dragonfruit
  2. schema_5 - For Power Save mode (health diagnostic packet)
  3. schema_7 - For Apple (with
• Contained in schema.h
• Numbering convention determined by packet decryption scripts

This module provides miscellaneous functions that the other modules might need. It also includes all the macro definitions such as constants, voltage thresholds, and true/false macros. It also includes various health functions and power management functions that manage the health and mode of operation for the weatherbox. Low pass filter functions are also included here.

Macro Definitions

• Contained in utilities.h
• Voltage thresholds were acquired from the original Apple code
• Variable for “alpha” for low pass filter also acquired from original Apple code

Health Management

• Includes functions to:
  1. Measure battery voltage
  2. Create an initial sample of battery voltages
  3. Compare battery voltage against certain thresholds
  4. Transmit battery voltage data
  5. Transmit health packets specifically while in “power save” mode (will explain under Power Management)

Power Management

• Configures the power state mode
  1. Normal Routine if battery voltage is above threshold; power save routine otherwise
• Power state includes:
  1. XBee sleep state
  2. Sensors sleep state
• When changing power state of XBee or sensors, be sure use the sync function to write to the digital pins on the board

Low Pass Filter

• Used for managing battery voltage

When updating the Firmware certain procedures must be taken into account to ensure conflicts don't occur and the changes in modules are reflecting in the main Firmware directory and vice versa.

1. Always do a pull from your test branch before working on code
2. Always test compile and/or test with hardware after any changes are implemented
3. Always commit your changes with meaningful comments
4. Always push your commits before you stop working
5. Never work directly off the master branch
6. Follow the same commenting syntax for new functions

Notice the following (about the master branch):

• 5 directories
  1. Moving_Average - Unused functions in there (do not worry about this directory)
  2. REIS_Weatherbox - The directory containing the full integration of all modules, utilities module is also contained completely here
  3. Sensor_Code - Directory to test changes and improvements to the sensor module
  4. Transmit_Code - Directory to test changes and improvements to the transmit module
  5. libraries - directory that contains all the libraries needed to run the Firmware
• Code from Sensor_Code and REIS_Weatherbox need to be identical to each other by the end of the update (before a commit)
• Code from Transmit_Code and REIS_Weatherbox need to be identical to each other by the end of the update (before a commit)
• This involves a lot of “cp-ing” (copying)

Work off of particular branches or create a new branch when doing an update.

New Branch:

When creating a new branch, make sure that it is branched off of the code contained in master and not off of another branch.

Naming:

• Use meaningful names
• If the branch is used to resolve an Issue, name the branch:
  • issue-#
  • where # is the issue's number as listed on GitHub
• If the branch is for testing a new feature, name the branch:
  • test/<feature>
  • <feature> will denote what new functionality is being updated

Completion:

Submit a pull request to master when the feature is completed, tested, and verified.

• If a change occurs in Sensor_Code or Transmit_Code be sure that the change is reflected in REIS_Weatherbox
• config.h is shared by ALL directories, thus any changes to it must be reflected in all three directories.
• Some lines of code are commented out for certain files in Sensor_Code and Transmit_Code
  1. Be sure the corresponding lines are commented out for the particular directory
  2. In REIS_Weatherbox ensure that all lines are uncommented
  3. This occurs because some functionalities are not used when testing the modules individually
  4. Affected Files:
     • config.h
     • config.cpp
     • transmit.h
• This will further be expanded with Unit Test directories (before implementation into the other codes)

Verifying that the code compiles does not necessarily mean that it will work as intended. Each module should be tested on each generation to validate its functionality. However, testing each individual module and confirming that they work separately, does not confirm that the modules will work together. Therefore we must also test full integration with each generation, the most important test before deployment.

Necessary Components:

• Apple board
• Arduino IDE
• Arduino board USB
• Charged battery
• Floodlight (for Solar Irradiance & Temperature)

Test Environment:

1. Connect the Apple board to the computer using the USB
2. In Arduino IDE, under Tools check:
   • Board is set to Arduino UNO
   • Port is set to the specific USB port that the programmer is plugged into
   • Programmer is set to AVRISP mkII
3. In config.h verify that only macro “APPLE” is defined
4. Run a test compile to ensure libraries are found and no compile-time errors occur
5. Upload program to board

Expected Results (Inside SCEL room):

1. Once the upload is complete, open the Serial Monitor (Ctrl+Shift+M)
2. Sensor readings will appear here every ~6 seconds
3. Use the floodlight to verify that solar irradiance and temperature vary (humidity may be affected as well)
4. Readings:
   • Battery mV = ~4095 (Compare to battery source level)
   • Solar Irr mV = ~5000 (Depends on floodlight intensity)
   • Humidity pct = ~50 (Depends on floodlight intensity, and weather)
   • Panel mV = ~6000 (Depends on floodlight intensity)
   • Temp decic = ~26 (Compare to actual temperature)
   • Pressure pa = ~101000

Necessary Components:

• Cranberry board
• Arduino IDE
• FTDI & cable
• Charged battery
• Floodlight (for Solar Irradiance & Temperature)
• ICSP programmer (if “burn the bootloader” wasn't previously run)

Test Environment:

• If the bootloader was not burnt
  1. Connect the ICSP device to the computer and board
  2. Open Arduino IDE
  3. Select the board Arduino 3.3V 8MHz
  4. Select the correct programmer (AVRISP mkII)
  5. Burn the bootloader
• With the bootloader burnt
  1. Connect the FTDI programmer to the computer and board
  2. In Arduino IDE, under Tools check:
     • Board is set to Arduino 3.3V 8MHz
     • Port is set to the specific USB port that the programmer plugged into
     • Programmer is set to AVRISP mkII
  3. In config.h verify that only macro “CRANBERRY” is defined
  4. Run a test compile to ensure libraries are found and no compile time errors occur
  5. Upload program to board

Expected Results (Inside SCEL room):

1. Once the upload is complete, open the Serial Monitor (Ctrl-Shift-M)
2. Sensor readings will appear here ~every 6 seconds
3. Use the floodlight to verify that solar irradiance and temperature vary (humidity may be affected as well)
4. Readings:
   • Battery mV = ~4095 (Compare to battery source level)
   • Solar Irr mV = ~5000 (Depends on floodlight intensity)
   • Humidity pct = ~50 (Depends on floodlight intensity, and weather)
   • Panel mV = ~6000 (Depends on floodlight intensity)
   • Temp decic = ~26 (Compare to actual temperature)
   • Pressure pa = ~101000

Necessary Components:

• Dragon Fruit board
• Arduino IDE
• FTDI & cable
• Charged battery
• Floodlight (for Solar Irradiance & Temperature)
• ICSP programmer (if “burn the bootloader” wasn't previously run)

Test Environment:

• If the bootloader was not burnt
  1. Connect the ICSP device to the computer and board
  2. Open Arduino IDE
  3. Select the board Arduino UNO
  4. Select the correct programmer (AVRISP mkII)
  5. Burn the bootloader
• With the bootloader burnt
  1. Connect the FTDI programmer to the computer and board
  2. In Arduino IDE, under Tools check:
     • Board is set to Arduino UNO
     • Port is set to the USB port with the programmer plugged into it
     • Programmer is set to AVRISP mkII
  3. In config.h verify that only macro “DRAGONFRUIT” is defined
  4. Run a test compile to ensure libraries are found and no compile time errors occur
  5. Upload program to board

Expected Results (Inside SCEL room):

1. Once the upload is complete, open the Serial Monitor (Ctrl-Shift-M)
2. Sensor readings will appear here ~every 6 seconds
3. Use the floodlight to verify that solar irradiance and temperature vary (humidity may be affected as well)
4. Readings:
   • Battery mV = ~4095 (Compare to battery source level)
   • Solar Irr mV = ~5000 (Depends on floodlight intensity)
   • Humidity pct = ~50 (Depends on floodlight intensity, and weather)
   • Panel mV = ~6000 (Depends on floodlight intensity)
   • Temp decic = ~26 (Compare to actual temperature)
   • Pressure pa = ~101000

Necessary Components:

• Apple board
• Arduino IDE
• FTDI & cable
• XCTU software
• Charged battery
• XBee breakout board and USB
• Two properly configured XBees *See “Configuring XBees” under “Resources”
• ICSP programmer (if “burn the bootloader” wasn't previously run)

Test Environment:

• If the bootloader was not burnt
  1. Connect the ICSP device to the computer and board
  2. Open Arduino IDE
  3. Select the board Arduino UNO
  4. Select the correct programmer (AVRISP mkII)
  5. Burn the bootloader
• With the bootloader burnt
  1. Plug the battery and the Xbee(Router) into the Apple board
  2. Attach the Xbee(Coordinator) to the Xbee breakout board and plug that into your computer using the USB cable
  3. Open XCTU on your computer
     • Click “Add Device” and select the corresponding USB port that your XBee is plugged into
     • Switch to the “Console” and “Connect” the Xbee to the network
     • Observe the Console log for packets to be received
  4. Connect the Apple board to the computer using the USB
  5. In Arduino IDE, under Tools check:
     • Board is set to Arduino UNO
     • Port is set to the specific USB port that the programmer is plugged into
     • Programmer is set to AVRISP mkII
  6. In config.h verify that only macro “APPLE” is defined
  7. Run a test compile to ensure libraries are found and no compile-time errors occur
  8. Upload program to board

Expected Results:

• Console log should display “Received Packet” in red font ever ~5 seconds
• UART should contain the string “test yes”
• BINARY should contain:
  • Some API packet coding identification
  • Schema number: 01
  • Hex code for the Microcontroller address
  • Hex code for up time of the program
  • Hex code for overflow (if occurred) otherwise: 00
  • Hex code for n count: 0A
  • Hex code for Battery mV: 01
  • Hex code for Panel mV: 02
  • Hex code for Pressure: 04
  • Hex code for Temperature: 05
  • Hex code for Humidity: 06
  • Hex code for Solar Irradiance: 03

Necessary Components:

• Cranberry board
• Arduino IDE
• FTDI & cable
• XCTU software
• Charged battery
• XBee breakout board and USB
• Two properly configured XBees *See “Configuring XBees” under “Resources”
• ICSP programmer (if “burn the bootloader” wasn't previously run)

Test Environment:

• If the bootloader was not burnt
  1. Connect the ICSP device to the computer and board
  2. Open Arduino IDE
  3. Select the board Arduino 3.3V 8MHz
  4. Select the correct programmer (AVRISP mkII)
  5. Burn the bootloader
• With the bootloader burnt
  1. Plug the battery and the Xbee (Router) into the Cranberry board
  2. Turn on the Cranberry board by flipping the switch to “ON”
  3. Attach the XBee (Coordinator) to the XBee breakout board and plug that into your computer using the USB cable
  4. Open XCTU on your computer
     • Click “Add Device” and select the corresponding USB port that your XBee is plugged into
     • Switch to the “Console” and “Connect” the XBee to the network
     • Observe the Console log for packets to be received
  5. Connect the FTDI programmer to the computer and board
  6. In Arduino IDE, under Tools check:
     • Board is set to Arduino 3.3V 8MHz
     • Port is set to the specific USB port that the programmer plugged into
     • Programmer is set to AVRISP mkII
  7. In config.h verify that only macro “CRANBERRY” is defined
  8. Run a test compile to ensure libraries are found and no compile time errors occur
  9. Upload program to board

Expected Results:

• Console log should display “Received Packet” in red font every ~5 seconds
• UART should contain the string “test yes”
• BINARY should contain:
  • Some API packet coding identification
  • Schema number: 01
  • Hex code for the Microcontroller address
  • Hex code for up time of the program
  • Hex code for overflow (if occurred) otherwise: 00
  • Hex code for n count: 0A
  • Hex code for Battery mV: 01
  • Hex code for Panel mV: 02
  • Hex code for Pressure: 04
  • Hex code for Temperature: 05
  • Hex code for Humidity: 06
  • Hex code for Solar Irradiance: 03

Necessary Components:

• Dragon Fruit board
• Arduino IDE
• FTDI & cable
• XCTU software
• Charged battery
• XBee breakout board and USB
• Two properly configured XBees *See “Configuring XBees” under “Resources”
• ICSP programmer (if “burn the bootloader” wasn't previously run)

Test Environment:

• If the bootloader was not burnt
  1. Connect the ICSP device to the computer and board
  2. Open Arduino IDE
  3. Select the board Arduino UNO
  4. Select the correct programmer (AVRISP mkII)
  5. Burn the bootloader
• With the bootloader burnt
  1. Plug the battery and the XBee (Router) into the Dragon Fruit board
  2. Turn on the Dragon Fruit board by flipping the switch to “ON” (Switch should be flipped towards the battery)
  3. Attach the XBee (Coordinator) to the XBee breakout board and plug that into your computer using the USB cable
  4. Open XCTU on your computer
     • Click “Add Device” and select the corresponding USB port that your XBee is plugged into
     • Switch to the “Console” and “Connect” the XBee to the network
     • Observe the Console log for packets to be received
  5. Connect the FTDI programmer to the computer and board
  6. In Arduino IDE, under Tools check:
     • Board is set to Arduino UNO
     • Port is set to the USB port with the programmer plugged into it
     • Programmer is set to AVRISP mkII
  7. In config.h verify that only macro “DRAGONFRUIT” is defined
  8. Run a test compile to ensure libraries are found and no compile time errors occur
  9. Upload program to board

Expected Results:

• Console log window should display “Received Packet” in red font every ~5 seconds
• UART should contain the string “test yes”
• BINARY should contain:
  • Some API packet coding identification
  • Schema number: 01
  • Hex code for the Microcontroller address
  • Hex code for up time of the program
  • Hex code for overflow (if occurred) otherwise: 00
  • Hex code for n count: 0A
  • Hex code for Battery mV: 01
  • Hex code for Panel mV: 02
  • Hex code for Pressure: 04
  • Hex code for Temperature: 05
  • Hex code for Humidity: 06
  • Hex code for Solar Irradiance: 03

This test should only be done once both the sensor module and transmit modules tests have been completed and the results verified. This also assumes that the “burn the bootloader step” has already been executed.

Necessary Components:

• Apple board
• Arduino IDE
• FTDI & cable
• XCTU software
• XBee breakout board and USB
• Two properly configured XBees *See “Configuring XBees” under “Resources”
• Charged Battery
• Floodlight (for Solar Irradiance & Temperature)

Test Environment:

1. Plug the battery and the Xbee(Router) into the Apple board
2. Attach the Xbee(Coordinator) to the Xbee breakout board and plug that into your computer using the USB cable
3. Open XCTU on your computer
   • Click “Add Device” and select the corresponding USB port that your XBee is plugged into
   • Switch to the “Console” and “Connect” the Xbee to the network
   • Observe the Console log for packets to be received
4. Connect the Apple board to the computer using the USB
5. In Arduino IDE, under Tools check:
   • Board is set to Arduino UNO
   • Port is set to the specific USB port that the programmer is plugged into
   • Programmer is set to AVRISP mkII
6. In config.h verify that only macro “APPLE” is defined
7. Run a test compile to ensure libraries are found and no compile-time errors occur
8. Upload program to board

Expected Results:

• Using XCTU:
  1. In the Console log, verify that a packet is being received
  2. Examine the data within the received packet
     • Data will be in Hexadecimal
     • Requires conversion
  3. Data (within the REIS room) should be similar to the expected results of the Sensor Module Test
• With decryption script (XBee (Router) is connected to a computer with the decryption script running):
  1. Verify that a packet is being recieved
  2. Examine the converted data
  3. Data (within the REIS room) should be similar to the expected results of the Sensor Module Test

Necessary Components:

• Cranberry board
• Arduino IDE
• FTDI & cable
• XCTU software
• XBee breakout board and USB
• Two properly configured XBees *See “Configuring XBees” under “Resources”
• Charged Battery
• Floodlight (for Solar Irradiance & Temperature)

Test Environment:

1. Plug the battery and the Xbee (Router) into the Cranberry board
2. Turn on the Cranberry board by flipping the switch to “ON”
3. Attach the XBee (Coordinator) to the XBee breakout board and plug that into your computer using the USB cable
4. Open XCTU on your computer
   • Click “Add Device” and select the corresponding USB port that your XBee is plugged into
   • Switch to the “Console” and “Connect” the XBee to the network
   • Observe the Console log for packets to be received
5. Connect the FTDI programmer to the computer and board
6. In Arduino IDE, under Tools check:
   • Board is set to Arduino 3.3V 8MHz
   • Port is set to the specific USB port that the programmer plugged into
   • Programmer is set to AVRISP mkII
7. In config.h verify that only macro “CRANBERRY” is defined
8. Run a test compile to ensure libraries are found and no compile time errors occur
9. Upload program to board

Expected Results:

• Using XCTU:
  1. In the Console log, verify that a packet is being received
  2. Examine the data within the received packet
     • Data will be in Hexadecimal
     • Requires conversion
  3. Data (within the REIS room) should be similar to the expected results of the Sensor Module Test
• With decryption script (XBee (Router) is connected to a computer with the decryption script running):
  1. Verify that a packet is being recieved
  2. Examine the converted data
  3. Data (within the REIS room) should be similar to the expected results of the Sensor Module Test

Necessary Components:

• Dragon Fruit board
• Arduino IDE
• FTDI & cable
• XCTU software
• XBee breakout board and USB
• Two properly configured XBees *See “Configuring XBees” under “Resources”
• Charged Battery
• Floodlight (for Solar Irradiance & Temperature)

Test Environment:

1. Plug the battery and the XBee (Router) into the Dragon Fruit board
2. Turn on the Dragon Fruit board by flipping the switch to “ON” (Switch should be flipped towards the battery)
3. Attach the XBee (Coordinator) to the XBee breakout board and plug that into your computer using the USB cable
4. Open XCTU on your computer
   • Click “Add Device” and select the corresponding USB port that your XBee is plugged into
   • Switch to the “Console” and “Connect” the XBee to the network
   • Observe the Console log for packets to be received
5. Connect the FTDI programmer to the computer and board
6. In Arduino IDE, under Tools check:
   • Board is set to Arduino UNO
   • Port is set to the USB port with the programmer plugged into it
   • Programmer is set to AVRISP mkII
7. In config.h verify that only macro “DRAGONFRUIT” is defined
8. Run a test compile to ensure libraries are found and no compile time errors occur
9. Upload program to board

Expected Results:

• Using XCTU:
  1. In the Console log, verify that a packet is being received
  2. Examine the data within the received packet
     • Data will be in Hexadecimal
     • Requires conversion
  3. Data (within the REIS room) should be similar to the expected results of the Sensor Module Test
• With decryption script (XBee (Router) is connected to a computer with the decryption script running):
  1. Verify that a packet is being recieved
  2. Examine the converted data
  3. Data (within the REIS room) should be similar to the expected results of the Sensor Module Test

Unit testing and the error code library go hand in hand. We will apply unit testing to test and improve each small unit of our firmware. With each test we will have an associated error code that can be used to indicate if that test failed during full operation.

Unit testing is to examine each unit of the code separately. For our implementation we want to examine the lowest level of each module, the basic function calls. They are not meant to find bugs or detect regressions in the code. These are used to design and develop robust components of our modules.

Designing:

• Consider what could go wrong with the function
  • Obtaining high end values
  • Obtaining low end values
  • Something not executing
  • Array size mismatch (for transmission, packet → payload)
  • Memory Overflow
  • etc.
• Determine a counter-measure for if it was to occur
  • Anything to prevent the entire program from breaking

Implementing:

• Use a test branch with clear indication that its for unit testing
• Implement the test with one function at a time
• Force the error to occur with
  • Hard coded values
• Verify that the program reacts properly and the correct error code is returned
• Each unit test must be implemented and tested one at a time
• DO NOT try to cascade unit tests with one execution/run of the code
• Must be verified on each generation

General Notes for Unit Testing

• Unit Testing is separate from manual testing/integration
  • Unit testing is generally used to describe the behavior of your programs
  • Manual testing/integration testing is used to find bugs
• It is generally extremely beneficial for programmers to have a good “suite” of unit tests
• The programmer designs the pre-conditions for the test
  • Observe how the program behaves with the given pre-conditions
  • Downfall to this method, won't detect problems triggered by pre-conditions you didn't anticipate
• If a unit's behavior changes, the unit tests for that specific unit must also change, vice-versa.
• Unit tests should not contain any knowledge or assumptions about the other parts of code, such that changes to other parts of the code does not make other unit tests fail/give bad results; make each test independent of others
• Any given behavior should be specified in one and only one unit test
• Only observe the core behavior of each unit
• Generally, unit tests are a design specification of how a certain behavior should work, NOT a list of observations of everything the code happens to do
• The overall architecture of your code should support testing units before using unit tests

The Error Code Library will expand off of the unit tests. It does this in such a manner that if the test fails (i.e. the function does something undesirable) an error code will be presented. It can be presented in one of two ways:

1. In place of a certain sensor data, indicated by being a negative value, when running at a larger scale
2. Returned from the function with the failed test

Option (1) is for the case of the full integration running, but something goes wrong at one point. This method is to allow the operation of the code to continue, but signifying an error has occurred. Option (2) is for unit testing.

Error Code:

• Error codes shall be a negative 3 digit number
• The code shall be structured as follows: ABC
  • A (hundreds place) = Module
  • B (tens place) = Function
  • C (ones place) = Specific error

Error Flag:

• Schemas should include an error flag that is initially set to FALSE (0)
• It will get set to TRUE (1) if an error occurs
• This will be used to be the fastest way to detect an error has occurred
• Other Proposal:
  • Flag will be 0 for no error
  • Flag will contain the error code value (positive) in place of having the sensor value slots hold a negative value
  • Benefits:
    1. Won't have to change the types (unsigned vs signed) of the struct data
    2. The addition of the flag variable will already be taking another byte in the struct
  • Drawbacks:
    1. Won't be clear what function failed unless looking at the Error Code Library
    2. If multiple errors occur, cannot save all of the associated error codes
    3. Difficult to track from the function itself to the packet construction to put the code in there (diminishes modularity)

Contributing authors:

Created by rwalser on 2016/04/25 08:32.