Since the beginning a lot of work has been done on the communication software, mainly because we build this part of the software from scratch on, meaning no ‘com.c’ or ‘easy’ sending of communicating with earth for coordinates and temperature. This was done so that we could completely understand what we were doing and design the software exactly as we wanted it. Furthermore there are parts in the communication software nowhere to be encountered in the rest of the code, so this was a very learning experience.
The way that sending is implemented in our code.
The communication software has been elaborated since we first started. A very schematic overview of the software is given in the figure at the bottom. Here the different lines represent dependencies on each other. The lines that run between the bricks or between a specific brick and the earth pc represent IR communication. This is done using the Lego Network Protocol (lnp.h).
Software
On the Master brick a listeninginterrupt is installed, this is a so called software interrupt routine, meaning it cannot be controlled by the user and will be called every time that there is IR communication (figure below.
Therefore no CPU intensive code can be included here, as this will result in system failure. This interrupt copys data to a specified location and will set a flag triggering the wait_event in the processing thread. This way cpu load is manageable.
Looking at the picture at the bottom, the master interrupt receives information from the earth pc as well as the Slave brick. To ensure that IR communication is not overflooded every time the brick communicates with earth, for the temperature or to receive coordinates, the Slave brick is told to stop sending by means of controlling a wait_event on the Slave brick. This can be seen in the figure looking at the com_temp and com_earth functions. These functions send out a signal controlling the SENDING variable shown in the Slave brick. This variable is the trigger for the wait_event within the Sending thread.
The Processing Thread on the Master will process all the information and will set some global variables (COORDINATES or LIGHT_ACT). Furthermore it sets a semaphore called ALIVE to the value of 1 every time it executes. Looking at the figure the Watchdog thread is also connected to this semaphore, this thread will set the value to 0 every time it runs, furthermore it runs at a set frequency and it will count the times it runs when ALIVE is 0. When more than three instances occur it will set the NO_COM variable to 1. This is the sign for the Master brick that all communication is lost and all driving is stopped.
Returning to the Slave brick there is a Backup Thread that will monitor how long the Sending Thread has been shut down. After a specified time the SENDING variable is set to 1 again, resulting in triggering the wait_event and firing up the Sending Thread. This is a built in safety to make sure that sending is reinitiated even when the START commando from the Master brick for some reason has not been received.
Figure 1: Software overview
Function usage
Within the rest of the code when include the given communication files the use can call two functions. Com_earth() will result in getting coordinates from the earth pc, returning FINISHED or NOT_FINISHED. Com_temp(value), will send the value as a temperature to the earth, also returning FINISHED or NOT_FINISHED. This way we can check whether communication is successful.
