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
See the FAQ Doxygen brief information for more information about Doxygen.
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.
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.
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.