summaryrefslogtreecommitdiff
path: root/doc/MPU/inputs/OperatingSystem.tex
diff options
context:
space:
mode:
Diffstat (limited to 'doc/MPU/inputs/OperatingSystem.tex')
-rw-r--r--doc/MPU/inputs/OperatingSystem.tex114
1 files changed, 114 insertions, 0 deletions
diff --git a/doc/MPU/inputs/OperatingSystem.tex b/doc/MPU/inputs/OperatingSystem.tex
new file mode 100644
index 0000000..bfdd415
--- /dev/null
+++ b/doc/MPU/inputs/OperatingSystem.tex
@@ -0,0 +1,114 @@
+% --------------------------------------
+% CHAPTER: Operating System
+% --------------------------------------
+
+\section{Operating System}
+\label{sec:Operating System}
+
+The software running on the MPU is based on a preemtive real time operating systems
+and manages the tasks the satellite has to fulfill.
+The Operating system, on which the whole software is based on, is FreeRTOS. %\hyperlink{http://www.freertos.org}{FreeRTOS}.\\
+
+\url{http://www.freertos.org}
+
+\subsection{FreeRTOS}
+
+FreeRTOS is a preemtive multitasking real time operating sytem. It provides methods for
+creating and sceduling tasks and implements queues and semaphores for communication
+between, and synchronisazion of the tasks.
+
+\subsection{MPU Tasks}
+
+The MPU gets commands from the low level control interface IHU and from the Hackled Handheld
+Transceiver.
+The IHU sends mainly commands which are related to the power management, whereby the Hackeld
+Handheld Transceiver is the command communication interface between the satellite and a base
+station on earth.
+The satellite has to send its bacon signal permanently. This way it can be located in space.
+When the satellite gets in communication distance to a base station on earth, a special signal
+is sent to the satellite which is received by the IHU via the Hacked Handheld Scanner. The IHU
+then tells the MPU to swith on the Hacked Handheld Transceiver. From now on a communication
+between the base station and the satellite is possible.
+
+The satellite can receive configuration commands and data request commands from the base
+station. The configuration commands are used to set parameters like e.g. the sampling rate
+of the microphone (piezzo element), or to set parameters for the camera, as well as to tell
+the satellite when and how often to take pictures.
+
+\subsubsection{Messages}
+The communication inside the operatin system is based on a message system. Tasks can send messages to each others.
+
+FreeRTOS provides with an object called xQueue. This is used to communnicate between tasks in
+FreeRTOS. An xQueue is primarily a void pointer which can be sent to a task. This pointer can
+point to any address in the memory. In this implementation xQueues are used to point to
+structures which represent "Messages".
+
+\begin{lstlisting}
+typedef struct
+{
+ void *pData;
+ Sender_t Sender;
+}Message_t;
+\end{lstlisting}
+
+A message consists of a pointer to the data which shall be sent and an identifier of the
+sender. The Sender type is just an enumeration of the tasks that want to communicate with
+each others.
+
+\subsubsection{Kernel Process Task}
+The Kernel Process Task is reponsible for dispatching the jobs and assigning them to the
+according tasks.
+Each time a communication interface (UART, SPI, I2C) receives data, its interrupt service
+routine notifies the Communication Process about this event. The Communication Process
+collects all arriving data and when a comand is completely received, the Kernel Process Task
+is notified, gets the command via a message, checks this command and sends the respective
+message to the task which is responsible for the execution of the command.
+
+\subsubsection{IHU Process Task}
+It seems that the IHU Process Task is not needed, so it will be taken out of the operating
+system.
+Actually the Internal Householding Unit IHU is providing the satellite with energy which is a
+rather limited ressource. Therefore it is necessary to implement some kind of protocol to
+manage the energy consumtion of all satellite components. This IHU Process Tasks was ment to
+handle this protocol, but right now it looks like if this task is taken over by the Kernel
+Processing Task.
+
+\subsubsection{Communication Process Task}
+This tasks purpose is to receive commands and send responses over the respecting interface
+(UART, SPI, I2C).
+When ever a byte arrives at one of the interfaces, the respective interrupt service routine
+ISR is triggert. The ISR copies the received byte to a buffer and if the end of frame EOF
+character is received, it sends a message to the communication task. The communication task
+then analyses the received frame and informs the Kernel Process Task.
+The Communication Task can also receive messages from other tasks. These messages contain data
+frames that shall be sent via one of the interfaces. When such a message is received by the Communication Task, it sends the messages data over the respective interface.
+
+\subsubsection{Alien Encounter Process Task}
+The Alien Encounter Task is waiting for a message which is sent by the interrupt service
+routine of the according external interrupt. When ever an alien is passing by the satellite
+who is willing to press the Alien Encounter Button, and also can manage to do so, an external
+interrupt is triggert.
+
+\subsubsection{Light Sensor Process Task}
+The Light Sensor Process Task is responsible for handling light sensor related jobs.
+The light sensors are placed such way that they detect light in all three dimmensions in
+relation to the satellites local coordinate system. When sampling the intensity of light
+for these directions it shall be possible to calculate the satellites, especially the cameras
+orintation related to sun and earth. This should help to decide at which moment a picture of
+the earth can be taken. The sampling rate of the light sensors can be adjusted and is
+depending of the angular velocity of the satellites rotation.
+
+\subsubsection{Camera Process Task}
+The Camera Process Task handels all camera related jobs. It triggers the camera to take
+pictures and reads the cammeras data (pictures) from the cameras memory to a buffer. When
+ever the buffer is filled, this task sends a message to the Memory Process Task to store the
+data in the SD-Card.
+
+\subsubsection{Memory Process Task}
+The responsibility of the Memory Process Task is to read and write data from and to the
+SD-Card. This task can receive messages from any other task.
+If a message sender wants to write data to the SD-Card, the Memory Process Task reads the
+data from the message and sends it to the SD-Card. If a task wants to read data from the
+SD-Card, the Memory Process Task reads the desired data from the SD-Card and writes it to a
+message which is then sent to the requesting task.
+