% !TEX root = master.tex
\subsection{Software Design}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/UseCase}
	\caption[Use Case]{Basic Use Case of Software}
	\label{fig:UseCase}
\end{figure}
\autoref{fig:UseCase} is the use case diagram for the basic software interface of the Smart Table. It demonstrates the main to states the external application has and its accompanying effects on the tables control loop.

\subsubsection{Software Block Diagram}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/ClassDiagram}
	\caption[Class Diagram]{Class Diagram of High Level Design of Software}
	\label{fig:ClassDiag}
\end{figure}
A object oriented style of distinct modules will be incorporated into the high level design of the software which will ease the issues with transferring code and concurrent access.The high level overview of this concept for the Smart Table is shown in \autoref{fig:ClassDiag}. Also additionally the clean distinction between modules can be observed from the high level design thus it can be inferred the project will take advantage of modern project designs arising from multiple headers and multilevel file designs.

\subsubsection{Display Output Driving}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/DisplayDriving}
	\caption[Display Driving]{Control Flow of the Graphical Display Module}
	\label{fig:DisplayDriver}
\end{figure}
The display driver is a key point in the software design as it is a timer sensitive and computationally expensive process. The key points of the high level design shown in \autoref{fig:DisplayDriver} are the usage of the inbuilt timer modules to control the software flow at key points and to reduce the possibly of timing errors arising from other methods such as cycle counting or offloading the process onto and external module like the SPI communication interface. As such the system shall implement a timing system in which the graphics unit pushes data onto a buffer that additionally is a buffer for the actual output data that is concurrently modified. This will be done with the implementation of interrupts from the timing module and as such is a cycle independent system and is easily modified and expanded upon. The implementation of the dual buffer system allows for seamless transitions and additionally helps with possible race conditions cause by the dual core, dual cache, dual buffer system.

\subsubsection{Simplex Noise Generation}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/simplexExample}
	\caption[Simplex Noise]{Simulated Output of Smart Table with additional Simple Noise Overlay}
	\label{fig:SimplexNoise}
\end{figure}
Implemented within the graphics processing control block is a Simplex Noise shader overlay that is overlaid onto certain algorithms. Simplex noise is a method devising for the generation of n-dimensional noise that is similar to Perlin noise. The main differences between these two methods is the visual look, fewer artifacts, and a lower computational overhead. This method is a procedural function that is useful for adding visual flair to images and a sense of movement depending on implementations. As such this method is vital to the Smart Table implementation as a visual display shader to add additional value to the product. Displayed in \autoref{fig:SimplexNoise} 

\subsubsection{Procedural Image Generation}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/VisualOutputExample}
	\caption[Simulated Procedual Image Output]{Simulated Output of Smart Table using Procedural Generation}
	\label{fig:ProceduralImage}
\end{figure}
Implemented within the graphics processing control block are methods used for the procedural generation of images. Shown in \autoref{fig:ProceduralImage} is a simulated output of the methods used in the image generation upon the Smart Table. The images shall be implemented using procedural methods due to the ease of scaling, memory concerns, and the visual interest that can be easily added by usage of such methods. As such various methods such as the implementation of shaders and blending shall be used in the procedural image generation code blocks and shall be optimized to the highest amount possible due to the computation cost of such methods.

\subsubsection{Microcontroller Software Interaction}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/SoftwareFlow}
	\caption[UML-Diagram]{Information Transfer Diagram and Control Between Modules}
	\label{fig:UMLDiag1}
\end{figure}
The information and software flow shown in \autoref{fig:UMLDiag1} demonstrates parts of the design that must be considered in implementation of the device as it is a dual-core device which entails a number of interesting technical challenges to overcome. As such the concept of threading in the real-time system must be considered and a cpu scheduling additionally must be implemented for proper system and software control. As such the careful design of shared memory interfaces and consideration of race conditions will be key in the successful design of the finished Smart Table project and the operation in a clean way.

\paragraph{Time and Date}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/TimeandDate}
	\caption[Time Date Software]{Time and Date Software High Level Design}
	\label{fig:TimeDateUML}
\end{figure}
The time and date functionally requires the implementation of an external device to deliver the information needed for the function as shown in \autoref{fig:TimeDateUML}. The implementation of an "on-board" module to obtain the information was considered by the cost and complexity of such a module forced the team to abandon this pursuit. As such a pseudo client-server architecture for this add-on feature was decided as it could be implemented in the user facing software implementation. The core idea of this implementation is that the user application will pull the local device data of the time and date and send that to the microcontroller and thus once received the Smart Table will process and generate the required visual output image in response to the push request.

\paragraph{Snake-Like Game}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/Snake-LikeGame}
	\caption[Snake Game Control]{High Level Design for Control of Snake-Like Game}
	\label{fig:SnakeUML}
\end{figure}
The snake like game requires a client server design as well. Due to cost overruns and design constraints of implementing a controller into the table or by using third party hardware, the decision to turn the user's device into a control system was decided upon. As such the user's device will act as a controller and generate the interface upon it for visual feedback on the game, while concurrently the user can also look at the Smart Table as the visual output of the snake game will be mirrored upon it, this is shown in \autoref{fig:SnakeUML}. As such the main data that will be sent to the table is position data of the snake and any object data to be rendered, thus keeping total transmission costs down and partially offloading the heavy data generation.

\paragraph{Color Controls}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/ColorControls}
	\caption[Color Controls]{Information Transfer Diagram and Control Between Color Modules}
	\label{fig:ColorControls}
\end{figure}
The color controls shall essentially act as a shader function on-top the basic pattern functions that will be generated. As such the color controls will be partially implemented on both devices in a synergistic configuration to allow for minimal latency and data transfer as demonstrated in \autoref{fig:ColorControls}. In effect they will essentially be a mode selection option overlapped with the normal operations.  

\subsubsection{User Interface}
\begin{figure}[!htb]
	\centering
	\includegraphics[width=1.0\linewidth]{img/flowchartpoop/UserInterface}
	\caption[User Interface]{Example of User Interface for User Facing Application}
	\label{fig:UserInterface}
\end{figure}
The user interface shall be a bare bones application developed with ease of use and optimization in mind as shown in \autoref{fig:UserInterface}. As the total throughput to the microelectronic is low, the optimization of packets must be controlled carefully through the application of dynamic programming ideals.

\subsection{Design Summary}
In essence the design of the total software system will be object oriented optimized design that focus on key ideals of dynamic programming and various streamlining techniques to an nonpareil environment for the user. As such the total computational cost must be kept in mind during the software implementation phase and thus will be carefully calculated to keep costs down and user interaction speeds high.

