Barr Group FacebookBarr Group TwitterBarr Group LinkedInBarr Group Vimeo

The capstone programming project for Barr Group's Embedded Software Boot Camp and Embedded Software Training in a Box is the development of a simulated dive computer for use in Scuba. The capstone project very purposefully builds upon the code from the smaller programming exercises in the course. This project is intended to be educational and fun while also demonstrating important RTOS features and their pros and cons as tools for good software design. Notably this project also reflects many real-world issues associated with safety-critical SCUBA diving equipment.

The project makes use of the following hardware resources on the development board:

  • Inputs: Buttons SW1 and SW2 and Potentiometer VR1 (via A/D)
  • Outputs: LEDs 4-15, the LCD, and the Speaker (via PWM)

Requirements

A complete implementation of the project should conform to Barr Group's Embedded C Coding Standard and these requirements:

  • Upon reset:
    • The display shall default to meters and meters/minute.
    • The diver shall be presumed to be at the surface (depth 0).
    • The diver shall be presumed not to have been under water yet.
    • The tank shall be presumed to have 50 liters of compressed air.
  • At the surface:
    • Attempts to ascend shall be ignored (you should display 0 for ascent rate).
    • Pressing or holding button SW1 shall cause air to be added to the tank, in 5 liter increments, until the maximum capacity of 2,000 liters is reached.
    • lapsed dive time shall not increment.
  • At all times:
    • LED4 shall blink a continuous 3 Hz software health indicator (placeholder for a watchdog).
    • The LCD shall display:
      • Line 1: A brand name of your choosing (max 12 chars).
      • Line 3: Current depth ("DEPTH:"), in user selectable units "M" or "FT".
      • Line 4: Rate ("RATE:") of ascent ("+") or descent ("-"), in units of meters/min ("M") or feet/min ("FT").
      • Line 5: Amount of compressed air ("AIR:") in cylinder, in liters ("L").
      • Line 6: Elapsed dive time ("EDT:") in H:MM:SS format.
      • Line 8: Highest priority active alarm (e.g., "Alarm: HIGH").
    • Each press of button SW2 shall toggle the units of displayed depth and rate.
  • While diving:
    • The rate of descent/ascent (-50 to +50 meters/min) shall be determined as:
      • Descending: Potentiometer readings from 0 to 499 map from -50 to 0.
      • Neutral: Potentiometer readings of 500 to 523 map to 0.
      • Ascending: Potentiometer readings 524 to 1,023 map from 0 to +50.
    • The following alarm conditions shall be signaled by prioritized speaker tones:
      • Highest Priority: Insufficient air to safely ascend from current depth!
      • Medium Priority: The current ascent rate is dangerous (> 15 m/min)!
      • Lowest Priority: The current depth exceeds the safe maximum (40 m)!

Starting Points

To reduce the complexity of the exercise and maximize focus on the proper use of RTOS features, the following code is provided in scuba.c and scuba.h:

  • Constants for the maximum safe ascent rate and maximum safe depth.
  • Macro MM2FT() converts millimeters to feet.
  • Macro ADC2RATE() maps 10-bit ADC range 0 to 1023 to -50 to +50.
  • Macro depth_change_in_mm(ascentrate_in_m_min) calculates half a second of depth change based on the current ascent rate reading.
  • Function uint16_t gas_rate_in_cl(depth_in_mm) returns the amount of air consumed in half a second at the current depth. (Turns out it’s not constant!)
  • Function uint16_t gas_to_surface_in_cl(depth_in_mm) calculates the minimum amount of air necessary to ascend safely from the current depth, using numerical integration.

Related Ideas

Once you're done with the above, here are some additional related project ideas:

  • Test Interface. Using an RS-232 cable, establish a communications link between your development kit and a PC. Implement a command-response protocol, perhaps allowing the PC to run automated dive computer test sequences. For example, if connected on dive computer reset, the PC would be able to provide a sequence of scripted ADC samples (at simulated 500 ms intervals) and button presses and would receive the display value responses.
  • Tilt-Sensor. Experiment with the 3-axis accelerometer. This is the technology behind Wii remotes and motion-sensitive smartphone apps. Perhaps you could sense one of those axes of tilt instead of the potentiometer to simulate ascent and descent in the dive computer.