OpenHornet
|
This manual is about writing software for the OpenHornet project. It shows how to write, document and test your software.
The starting point of every new software sketch is the OHSketchTemplate folder. Please copy the whole folder. There are some test.skip files inside there who are needed for the travis-ci testing. Once copied delete the sample function from the OHSketchTemplate.ino. Then change all the @tags with your own information.
The Sketches are named according to the System Architecture drawing found in the OH documentation. The first part of the name is the OH No. found in the drawing. It is the number beneath the Board type.
e.g: 1A2A for the Master Arm Panel. (Not 1A2A1A).
The No. is followed by a minus sign "-" (without space). Then the name of the component the sketch is for. The name is written in uppercase and with underscores "\_" instead of spaces.
e.g: 1A2A-MASTER_ARM_PANEL for the Master Arm Panel.
If the Sketch is for more than one component. Meaning that the board controls more than one component, use the name of the first component the sketch is for (the upper most component in the System Architecture drawing).
It is imperative that all the code you write is documented. We use doxygen as API documentation generator. So all the comments have to be doxygen compatible. Otherwise they will not show up in the documentation.
We use Javadoc style comment markup. Since it is the easiest to read for humans.
The following is an example of how to document code:
This is the standard file header of OH. It has to be used as is in every sketch written for the OH Software.
The Sketch summary comments should be on top of the file, right after the Header and looks like this:
The elements in the summary are the following:
The @file has to have the exact same name as the filename. Including the file extension.
The author of the Sketch. If more than one person was working on the sketch, the authors shall be listed in a comma separated list. With the original author at first place.
The date the sketch was last modified.
The version of the sketch. To see how the versioning of sketches works, see "Versioning" in this document.
Every untested sketch has to have a "This sketch is based on a wiring diagram, and was not yet tested on hardware" warning.
A brief description of the sketch.
A more detailed description of the sketch
Function documentations should look like this:
Doxygen then takes this and generates a Function documentation looking like this:
Functions should be commented as seen above. It is important that every function you write is commented like this. Otherwise it will not show up in the API documentation. The comment structure is as followed:
The comment has to start with /**
and then a new line with a single *
. Then you write a very short description of what the function will do. The short description has to end with a dot .
or a blank like.
This is the main description of your function. Write in detail what your function does.
Each parameter the function uses is documented with a @param
tag. After the tag there is a space and then the name of the parameter. Then another space and then the description of the parameter.
The return parameter, if there is any, is documented with a @returns
parameter. The return parameter needs no name. So after a space you can write the description of the parameter.
The insides of a function are a black box to doxygen. It is important that you comment the code inside a function nevertheless. This has to be done for other coders who might have to work with your code. Comments inside a function are done with a simple //
before the comment.
All sketches who run as slave on the RS485 bus have to have a slave ID (DCSBIOS_RS485_SLAVE). That slave ID has to be unique on the RS485 bus the sketch runs on. But they can be the same for different buses (Every RS485 master has it's own bus). The slave ID is given according to the last number in the sketch number.
e.g 1A2A (Master Arm Panel) has to have the slave ID 2 e.g 1A4A (L Warning Indicator) has to have the slave ID 4
The version number consists of three digits.
eg: 1.4.2
Those three numbers are release.feature.change
Sketches who are untested have to have a leading "u" before the version number and "(untested)" behind the version no.
eg: u.1.4.2 (untested)
Before you upload anything, please check if your sketch compiles in your Arduino editor. If it does, check if doxygen compiles with your local doxygen installation.
Once those local tests are successfully, upload your sketch to the OpenHornet Sandbox and see if the travis-ci tests are successful. If they are, your sketch is ready to be uploaded to the main repo.
(The OpenHornet Sandbox should be seen as an extension of local testing. Be aware that this is only a Sandbox. Code will not persist there and can be removed at any time.)
You can get access to the OpenHornet Sandbox by asking Balse (Balse#3320 on Discord).
Travis CI is a continuous integration testing engine. It is connected with the OpenHornet Sandbox (and with the main repo). If Travis detects a change in the repo, it automatically starts working. Basically it starts a virtual environment, clones the repo into that environment and then tries to compile the code. If the code compiles successfully and there where no errors detected, it automatically updates the Doxygen documentation and uploads it back to the repo.
Travis uses a Adafruit script to carry out its tests. You can find the script here: Travis-CI-Arduino
By default Travis tests the code on the following platforms:
Since OpenHornet only uses Arduino NANO (same as Arduino UNO for testing) and Arduino MEGA, all other tests should be skipped. This is done by including a *.test.skip file inside the directory the sketch resides. For example: esp8266.test.skip would skip the ESP8266 test. The necessary *.test.skip files are included in the sketch template folder.
Make sure that you include a uno.test.skip file for sketches who can only run on Arduino MEGA. Like the RS485 bus masters for example.
Arduino Libraries who are included in your sketch need to be installed inside travis in order for the tests to work. You find a list of already included libraries in the "Supported Software" section of this manual. If you need anther library installed, ask Balse (Balse#3320 on Discord). He will install the library for you.