Mini-Project 1: Temperature Warn Device

This mini-project focuses on the implementation of a temperature warn device. You will work in a team of two and combine what you have learnt in the lectures and tutorials throughout the semester into an application. For the first part of the project, the requirements are clearly defined and must be fulfilled for a passing grade. In the second part, you will have the opportunity to implement additional features to achieve the maximum grade. A catalogue of ideas for additional features is provided at the end of the project description. Feel free to implement your own ideas.

Objectives
  • Creating a STM32 MCU project based on the template

  • A clean development flow with version control

  • Read and write on digital GPIOs

  • Using integrated on-chip circuits like timers

  • Using communication interfaces like UART

  • Communicating with external ICs via SPI

  • Measure sensor data in a defined sample rate

  • Using interrupts for a deterministic system

Outcomes
  • How to apply a common version control workflow with Git

  • Work together in a team using a Git repository

  • (Using LaTeX for a report)

  • Generate Doxygen documentation

  • Calculate decimal values from signed magnitude representation

  • Read in data with SPI

  • Send data out over UART

Grading

The project will count towards your final grade. A project with no additional functionality can achieve a sufficient grade (4) up to the grade 6. It is possible to get an additional bonus of at most 5%, by implementing additional features.

Danger

If you do not hand in the required documents on time, you will be awarded zero points.

Completeness of the project and project management (4.5%)

  • All files contain a Doxygen file header (file, author, date, brief, copyright…)

  • Repository contains a properly structured and descriptive README.md file

  • Use of a common git workflow

  • All functions include Doxygen comments with a description of the arguments. Doxy file created to generate html documentation

  • Proper .gitignore file excluding all unnecessary files like build targets or doxygen html output.

  • Short report (5 - 8 pages) following the IMRaD structure

See also

Design (2%)

  • Naming of variables, structures, functions, files, etc.

  • Based on the stm32f446x_template

  • Software concepts/code structure

  • Algorithmic aspects

Functionality (3.5%)

  • No compile warnings and errors

  • All minimal requirements met

  • Correct functionality at runtime

Documents to be submitted

You must provide all the documents necessary for the use (user perspective) and development (developer perspective) of your application in the Gitlab project repository provided.

Important

Only the files that were in the last correct push on the master branch, with a correct version tag, will be taken into account.

  • Source Code:

    • Your source code without any build and executable files

    • Based on the stm32f446x_template

  • Short report:

    Short report in the IMRaD style:

    • Abstract

    • Introduction

    • Methods

    • Results

    • Discussion

    Written in LaTeX based on the BFH-short-report template.

  • README.md

    • Project description

    • Authorship

    • Build dependencies of the project

    • Instructions on how to use

  • Doxygen configuration:

    • Configure Doxyfile to build html output

    • Only the Doxyfile is used, not the generated output (this is a build artefact that must be excluded)

Important

It must be possible to compile and flash the project for the MCU integrated on a system, based on the BFH_FBS_CS2024 virtual machine. If it is not possible to compile or flash the MCU, we have no basis for evaluating the functionality.

Git workflow

As in a real software project, you should assign a version number to each version on the master branch. Remember the usual way of versioning, v<major>.<minor>.<patch>.

See also

See the Git Workflow FAQ for more information about a proper git workflow and versioning.

Requirements

Your temperature logger kit will be used as a temperature warn device. The device will warn the users when a temperature from the left thermocouple exceeds a defined value. The warning system consists of the speaker and the RGB-LED on the mbed application shield. Controlled is the device with the joystick and with a connection to a host computer. In case of an error of the device (e.g. an error with reading the temperature), the device changes into error mode. The error mode is exited automatically when the error was resolved. The minimal requirements for the device are listed below:

Reading Temperature

The temperature is read from the CH I (left) thermocouple with the MAX 31855 Thermocouple Digital Converter which can be read with the SPI communication protocol. The temperature has to be extracted from the received message and converted from twos complement into a MCU readable value. The temperature has to be read with a frequency of \(1\,\text{Hz}\).

Device Warning

If the temperature exceeds a defined temperature, the device will warn the environment visually and acoustically. For the visual part, the RGB-LED is used. The color of the LED depends on the temperature:

  • limit temperature - current temperature > 5° -> green permanently

  • limit temperature - current temperature <= 5° && > 0 -> yellow permanently

  • limit temperature - current temperature <= 0° -> red flashing with a frequency of \(2\,\text{Hz}\)

In case the device is in error mode, the LED color is permanently red.

The speaker should warn the people when the limit temperature is exceeded. The frequency of the speaker is permanently \(10\,\text{kHz}\) at the maximum volume.

Controlling

The device can be controlled with the joystick and via UART from a host computer. The different functionalities are described in the followed subsections.

Joystick Control

If an alarm has been triggered, it can be cancelled with the joystick center button. The system of how to get the state of the button is up to you. Describe in the report why you have chosen the implemented approach.

UART Control

With the UART communication, the device communicates with a host computer or home warn system. The protocol is command based, with a colon as separation and with additional arguments separated by a comma. This results in the following schematic:

<command>: <arg1>, <arg2>, ... \n

With this system, the minimal required commands with the arguments are defined in the followed table.

UART Host Commands

Command

Message

Answer

Description

Get temperature

gT:\n

#Temperature: dd.dd\n

Gets the current temperature from the device in degree

Set limit temperature

sL:dd.dd\n

#Limit Temperature: dd.dd\n

Overwrites the limit temperature

Get limit temperature

gL:\n

#Limit Temperature: dd.dd\n

Gets the current limit temperature

Acknowledge warning

q:\n

#Alarm acknowledged\n

Acknowledges a received alarm

In addition to the commands from the host computer, the MCU can also send some status messages.

MCU Status Messages

Status

Message

Frequency

Description

Alarm

alarm: <dd.dd>\n

Once when the temperature >= limit temperature

Sends the alarm with the current temperature

Alarm acknowledged by the button

buttonAck:\n

Once when the alarm is acknowledged with the button

Returns that the alarm was acknowledged by button

Alarm finished

alarmReset: <dd.dd>\n

Once after an alarm when temperature < limit temperature

Returns that the temperature recovered below limit

Device in error mode

error:\n

When the device changes into the error state

Informs the host that the device is in error state and the temperature cannot be surveilled

Additional features

The implementation of additional features is required to get the bonus of 5%. Of course, you do not have to implement all of them. Feel free to implement other features as well.

Concerning the grading, the achievable percentage is shown in the parentheses. The same criteria are applied as for the basic features and the maximum bonus is 5%. If you provide your own additional features, they will be graded based on the invested programming effort.

The features will depend on the solution you provide for a minimum implementation.

  • LED (1%)

    • Floating color for current temperature

      Change the system of the LED colors from three states to a floating transition from green to red in the range of 5° to the limit temperature.

  • Error detection (2%)

    • LED Error Code

      The data from the MAX 31855 Thermocouple Digital Converter provides three possible errors. Use the LED with different flashing frequencies (but not the alarm frequency) or colour codes for the corresponding fault.

    • UART information

      Add to the error mode status message the current detected error of the device.

  • Speaker sound (1%)

    The speaker can be used to play notes at the correct frequencies. This can be used to create well-known melodies for playing the warn sound.

  • Developer options (2%)

    Activate/ deactivate the developer mode. A method possible method could be a special joystick combination. For example: Left, Left, Right, Right, Up. Display it with a special color on the RGB-LED. New functions are possible in this mode:

    • Debug messages

      Extend the function with comments on the UART to send debug messages on every event.

    • Hardware test

      Hardware such as joystick, LED and the speaker can be tested by directly signaling the current input with the LED in a specific colour or send the state as a comment to the host.

  • Enable second channel (2%)

    • Use both as reference

      Enable the second channel (right) and return a warning when the difference between the first and second channel is to high.

    • Second device

      Use the second channel like a second device. Use the same user interface hardware like the button, LED and speaker. Use the currently higher temperature to control the LED. Add to the UART protocol the channel to the commands and state messages as an argument.

Attention

Be sure to document the functionality and describe the use of your application and features well. No points will be awarded for features that are not documented.