School of Science Computer Science
20COA202 Embedded Systems Programming Coursework specification
Iain Phillips
Document history
Version Comment
1.0 released to students
1.1 clarification on inputted vs stored data
1.2 clarification on Types
1.3 improved protocol for SOFT menus
1.4 clarification top/first floor
1.5 clarification on sending to the serial monitor
1.6 updates to the S, M and Q enhancements
1 Introduction
This coursework forms 100% of the assessment for this module.
2 The home controller 2.1 Specification
Semester 2 2020-2021
Date
22nd Feb 2021 23nd Feb 2021 23nd Feb 2021 3rd Mar 2021 23rd Mar 2021 25th Mar 2021 29th Mar 2021
You are provided with an Arduino and an shield containing an LCD display and a set of buttons: UP, DOWN, LEFT, RIGHT, SELECT. You are required to program this as if it were controlling a number of aspects of home automation.
2.2 The Home
Your Arduino will form a control panel for the home. A home consists of a number of floors, each floor with a number of rooms and each room with a number of devices, e.g. lights, temperature sensors, etc. Your Arduino will store a description of the home devices and provide an interface to read and set particular aspects of home automation. You are not writing the full home control system, simply the user interface. You will provide a facility to send the data stored over the serial monitor (as if) to the main control system.
2.3 Basic feature set
2.3.1 Specification (loose)
1. The house:
i. This house will consist of the following rooms and devices: • first floor
– bedroom 1
1
– bedroom 2
– bathroom • ground floor
– kitchen
– hall
– living room
ii. Each room has one light called “Light” and one heater called “Heat”. Each of these can have a level (brightness or temperature), on time and o time.
2. The system:
• A menu based system that allows scrolling through the house by floor and room and setting the light and temperature values for each room.
• On startup your program must write the string BASIC followed by a new line to the Serial Monitor.
• A menu item on the same menu level as floor selection that allows the stored data to be written in a human readable form to the serial monitor output. This format must be of the form:
Floor/Room/Type/Name/Action:VAL
where:
– Floor is either First or Ground
– Room is bedroom 1 etc as in the list above
– Type is either Heat or Light depending on application
– Name is either the name of the device – assume Main for the BASIC implementation. – Action replaced by On, Off or Level
– VAL is either (depending on the Action):
a time of the form HH.MM (Hours, Minutes) in 24-hour clock an integer level in the range 0-100.
2.3.2 Your work will include:
• A suitable data structure to represent this house.
• FSM code that allows the levels, on and o times to be set for each of the devices to be set.
• A mechanism to send the current levels, on and o times to the Serial Monitor in a defined format. • Writing the word BASIC to the Serial Monitor.
2.4 Extensions
2.4.1 General
Each of these extensions allows you to demonstrate knowledge over and above the basic specification. If you implement anything beyond the basic specification then on startup you code must no longer write BASIC and write the following to the Serial Monitor followed by a new line character.
• The word ENHANCED followed by colon.
• This must be followed by each of the enhancement descriptors separated by commas. There is a
separate descriptor for each of the potential extensions.
• End with a newline.
2.4.2 Features
Possible extension features for you to implement:
1. Lamps (descriptor: LAMP). This tests the extendability of your data structure.
Provide for a number of lamps around the house. These should be integrated by incorporating the word “Lamp” and a name for each lamp. In the export protocol, an example form would be:
Floor/Room/Lamp/Table/On: 09.00
2
2. Outside facilities (descriptor: OUTSIDE). *This tests the extendability of your data structure.**
Provide for the outside rooms to be included. Do this by adding a new Floor called Outside and garden watering controller (on time and o time). Water would be a new Type. Also provide for a garage with a light, i.e.:
Outside/Garden/Water/Main/On: 09.00
Outside/Garage/Light/Main/On: 19.00
3. Querying (descriptor: QUERY). This tests your ability to monitor the serial port in parallel with the buttons on the Arduino.
Monitor the serial port and if a Q character is received followed by a newline send the current state (on, o and levels) back the serial port using the format above.
4. Query memory use (descriptor: MEMORY) This tests your ability to monitor the memory use of your code. This can only be implemented if you have implemented the QUERY extension.
If a single M character is received followed by a newline over the serial port return data including the amount of RAM unused.
5. Soft Menus (descriptor: SOFT) This tests the flexibility of your data structure. This can only be implemented if you have implemented the QUERY extension.
Provide for a description of the house to be sent over the serial monitor rather than hard coded into the program. This will be done by sending an S character, followed by a sentence to describe the house. The sentence consists of a set of device descriptors separated by commas and terminated by a full stop. The sentence can include newline characters, which are to be to be treated as commas. Consecutive commas must be treated as a single comma. There is no character between the S and the house descriptor.
The protocol to describe the device descriptors has been designed to be short so a number of rooms can be entered (after the initial S) in single lines entered on the Serial Monitor. This saves problems sending large chunks of data across the serial interface. The first line received after booting starting with an S indicates a new configuration is being loaded to replace what is already there. Each subsequent line starting with an S should be considered a new room (or set of rooms) to be added to the house configuration.
There may be communication errors across the link. You need not overcome these, but you should be aware that they might happen of them – especially if, say, the final full stop is missing.
Device descriptors are defined as follows: A sequence of characters of the form FRT, FRTN or FRTNQ with the meaning of F, R, T, N and Q defined according to the list below:
• F: floor
– G Ground
– F First
– O Outside • R: room
– K Kitchen
– B Bathroom
– L Lounge
– 1, 2, 3, 4 Bedrooms 1-4 – G Garage
– R Garden
– P Play Room
– H Hall
• T: type
– L for Light
– A for Lamp – H for Heat
– W for Water
• N: the name of the device: the following are supported: – M Main (if omitted, then this should be assumed)
3
– C Ceiling
– D Desk
– B Bed
– P Cupboard – W Wall
• Q is a qualifier and optional. It must not be used if the previous setting is omitted. It takes the values:
– 1 one
– 2 two
– 3 three etc – L left
– R right
For example F2ABL means first floor, bedroom 2, lamp, bed left. A more comprehensive example is below:
OGW,OGLC,OGHW,GPH,GPL,GPLD,GKH,GKLC,GKLP1,GKLP2,GKH,GKLC,
GLHM,GLLC,GSHM,GSLC,GHHM,GHLC,GLHM,GLLC,F1HM,F1LC,F1LD,F1AB,
F2HM,F2LC,F2ABL,F2ABR,F3HM,F3LC,F3LB,F3HM,F3LC,F3LD,F4LM1,F4LM2.
You could write some Python to expand these.
6. Storing in the EEPROM (descriptor: EEPROM) This tests for your ability to program the EEPROM.
This can only be implemented if you have implemented the QUERY extension
Store the house description into the EEPROM so that it doesn’t need to reloaded over the serial port each time. If a valid house description exists already in the Flash, then write VALID to the Serial port (with a newline) after the new line of the ENHANCED descriptor string.
Remember you have very few byes of EEPROM, so you’ll have to be clever with how you arrange use of the available space.
2.5 Implementation
1. you must use (one or more) Finite State Machines to implement this specification and these must be described in your final deliverable.
2. you must implement the protocols exactly as described. If you feel anything is not clear, then please ask. We may use automated testing of your code.
3 Deliverables
This is an individual coursework. Plagiarism detection software will be used on both the documentation and the source code as an initial check to see where collusion or copying have taken place.
Your submission needs to include the following:
• Source code of your implementation: a single .ino file submitted to LEARN.
• A written report—submitted as a PDF to Gradescope. Template files are available; use of these is
compulsory and details of page tagging will be on LEARN. 3.1 Source code
Submit this as the actual .ino file, not copy-pasted into the report. 3.2 Written report
A template for the report is available on the Learn page in markdown, Word and LaTeX—your choice. But remember the final submission must be as a PDF. You must use the provided template—see LEARN.
4
3.3 Test plan
The test plan is a detailed instruction that shows us how to test all the features in your software. It must alternate between user actions (via Arduino buttons or the serial monitor) and intended behaviour of the Arduino (on the display or over the serial monitor).
In the assessment, we will sit down and follow your test plan to see whether you have implemented all features (of course, we will also try out other things). If we need to see the output across the serial port, then mention this clearly.
But make sure that the test plan covers every feature that you implemented, otherwise we might miss it.
4
Further information
You may only use the following libraries (as identified by their header files):
– Wire.h
– Adafruit_RGBLCDShield.h
– utility/Adafruit_MCP23017.h – EEPROM.h
– avr/eeprom.h
– TimerOne.h
Your code has to consist of a single .ino file, which needs to compile using the Arduino IDE. If the code fails to compile in this environment, then you risk failing the module.
Your code has to work with the Arduino Uno and LCD shield that we issued to you. In particular, if you develop your code on a di erent type of Arduino or with a di erent type of shield, you risk failing this module.
We will use various types of software for code similarity detection to compare each submission to all others, to submissions from previous years, and to code from other sources. Please be reminded that this is a individual assessment, which means that group work is not permitted.
Grading scheme
5
•
• •
•
Most marks are expected to fall into a scale between 40 (“scraped pass”) and 80 (“impressive”). These are explained in the grading descriptors below.
There are two components to the marking the running code and the documentation. The quality of your test plan feeds into both components. The distribution of the marks is 60:40 Code:Documentation.
Significantly fewer marks will be awarded if compulsory instructions are not followed, for example, not using the template, using other libraries that those specified above.
5.1 Code
• A (80+) – The project significantly exceeds the minimal specification in the amount of features and in the technical challenge behind these features. All features have been realised at an excellent level. The project is the culmination of a full design process with the implementation carried out at a high-quality level.
• B (70) – The project significantly exceeds the minimal specification in the amount of features or in the technical challenge behind these features. The project implementation and testing have been well executed with some aspects at an excellent level.
• C (60) – The minimal feature set and some non-trivial extra features have been realised at an adequate level. The project implementation and testing have been achieved at an adequate level. The interface is easy to understand after some explanation.
• D (50) – The minimal feature set and some minor extra features have been realised a mostly adequate level. Enough has been done, but nothing is very exciting and the overall achievement is mediocre.
5
• E (40) – The minimal feature set has been realized at a somewhat adequate level. The overall implementation and testing of the project is rudimentary.
• F (<40) - Not even the minimum feature set working and nothing to make up for this.
5.2 Documentation
• A (80+) The documentation is beautiful and describes all aspects of the implementation well.
• B(70) The documentation is very good, including all details, but lacks in presentation and under- standing.
• C(60) The documentation includes most of what is necessary, but misses some vital meaning.
• D(50) The documentation describes some aspects well, but these aspects only form up to 50% of what is required.
• E(40) The documentation is barely adequate.
• F(<40) Something worse.
6