% !TEX root = master.tex
\subsection{Prototype Expectations}
The build procedure is detailed in detail above in section 4.1.2 Board manufacturing considerations. In this section, the potential for failure at several steps will be detailed, and any of these failures will be coupled with a contingency plan in order to diminish the impact that the failure will have on the overall time line already set for the project. As the entire project is on a particularly tight schedule, it is important that any an all issues be planned for and a plan written up to avoid them. 

\subsubsection{Potential Hardware Issues}
The most common issues when working on a project of this scope are typically time delays from parts. If a particular part is needed for any application, and it is not available for some number of weeks, this causes a bottle neck in the production of the project and causes serious issues when it comes to producing the completed package on time. In an extremely time limited project such as this one, time is considered more valuable than money. This issue can be avoided by ensuring that no procedure on the board can be accomplished only by a single part. Currently, it does not appear that this is the case with our build, as all the parts are very generic and can have many substitutions that can be made.

 Another issue of similar origin is ordering a part that is non operational, or ordering a part that is then destroyed through improper soldering or heating, or through unintentional use causing a catastrophic malfunction. This second type of issue is typically solved by ordering several more parts than are neccessary, then eating this cost as a time insurance. The value of the extra parts far outweighs the potential for providing a late project in Senior Design II. 
 
 When designing the board, careful attention to detail must be taken in order to provide a correct design to the board manufacturer and the stencil manufacturer. As mentioned above in section 4.1.2, the stencil and board manufacturing cost is by far the most expensive component. This expense is seen in both time and monetary value. In eagle, it is very important to ensure beyond a shadow of a doubt that every single trace, plane, and pad on the board is impeccably placed so that the physical printed circuit board is perfectly produced by the various companies on the first try. The companies that produce the board and stencil will only do exactly as we ask, so if we ask them to do the wrong thing, we will have to eat the time and monetary costs, which will be significant. 
 
 Catastrophic failures were mentioned before in this section, but will be expanded here. Typically, we do not expect a well designed project to fail, but even with proper design, a lack of discipline when producing the final product can lead to a failure that costs time to resolve. There are two steps to prevent a failure that destroys parts, or even entire boards forcing a significant amount of time and money to be spent in order to resolve. Firstly, as discussed in the above paragraph, impeccable attention to detail is necessary for preventing any problems in the final board production. Experience is key here, as several mistakes that have been made between the various participants in this group lend an insight towards what issues may be seen in design. 
 
 One of the more common issues one can expect in design is an incorrect ranking of nested planes. If you have two planes (such as ground and Vcc) that are nested within each other, careful consideration needs to be taken to their rank. Rank is defined as plane priority when the board is manufactured. If a nested plane has a smaller rank than the plane that is surrounding it, the plane will be swallowed by the larger board. in our example above with a Vcc plane and a Ground plane, you would short the power rail to the ground rail and destroy the board and potentially your supply. Typically Eagle is very good at catching many of the other accidental shorting errors by using a design rule check, so such errors will not be discussed here. However, the ranked planes issue is not caught by eagle, so careful attention  must be paid to this potential issue.  In a similar vein, if any particular part is mislabeled in the library, a catastrophic issue can be introduced (a brief discussion on libraries can be found in section 3 - design). If, for example, the library for the microchip mislabels the ground pin as the Vcc pin, you can quite easily destroy the chip.
 
 A more common catastrophic failure has to do not with design malfunctions, but rather incorrect handling of a perfectly valid board. When soldering parts to the board, especially with small pitch devices such as the microprocessor or the bluetooth module, it is possible to accidentally short two of the pins or pads together. Even with a steady hand, a microscope and years of experience, it is still very easy to accidentally make an undetectable mistake where a connection is made where it should not be made. This is not always catastrophic, for example you could just disable some functionality of the device or disrupt communication by adding noise. However, as discussed above, shorting power to ground is almost always a catastrophic failure. These issues with soldering can be eliminated by using the pick and place technique combined with an oven, which provides machine accuracy rather than a human hand which has far more potential for error. More insidious and difficult to catch problems can easily arise in testing however, which are normally very difficult to detect. For example, static electricity is a huge issue when working with active semi conductor devices. In Florida, the issue of static electricity is not a huge problem, because the humidity in the air prevents it from being so prevalent. That being said, certain steps can be taken to completely eliminate the possibility for this phenomenon to occur, such as wearing anti static bracelets that are properly connected to a ground source when handling any printed circuit board. 
 
 Another issue that can happen with regards to mishandling the board include working with stranded wire near the board. If a stranded wire manages to be stripped and then cut near the board, very small diameter conductive wire filaments can fall onto the board causing shorts between small pitch devices. This can be resolved typically by blowing compressed air onto the board, blowing away any bits of wire without damaging the device. However, if this is not caught before powering on the device, failures can occur. A last thought about catastrophic failures with regards to mishandling has to do with the final mounted location of the board. This may seem like an obvious consideration, but it is worth discussing here. If the mounting location is conductive (which we do not expect it to be, but this may change), it is important to properly isolate the board from the conductive mounting surface so that you do not short wildly across the board. This can be done with tape or other rubber insets. As the saying goes an ounce of prevention is worth a pound of cure, so steps will be taken to avoid these issues. As long as we do our part in regards to proper handling of the board, none of the issues discussed above should arise.

\subsubsection{Potential Software Issues}
As with any software based projects there are many potential issues that must be taken into account and more-so due to the software being implemented on a device with highly limited resources and debugging capabilities. As such there are a few key elements to be designed for and checked against, being as show in \autoref{fig:Overflow} the issues of buffer overflow causing undefined behavior.  
 \begin{figure}[!htb]
	\centering
	\includegraphics[width=0.7\linewidth]{img/flowchartpoop/OverflowData}
	\caption[Software Issues]{Demonstration of Undefined Behavior due to Buffer Overflow}
	\label{fig:Overflow}
\end{figure}
Buffer overflow is an issue that arises from the the lack of additional space for a program to expand into or the lack of buffer safeguards for when an (i.e) integer hits it's maximum limit and thus overflows into the neighboring address. As such both of these issues cause extremely unpredictable results and behavior and can cause a number seeming unrelated issues crop up, thus making this near impossible to debug for. Therefore, due to this issues, care must be given early on to mitigate any such problems and to avoid the possibilities entirely by adding in safeguards into the code.  Additionally race conditions must be planned for an accounted for, these are when concurrent access to the same device or address happens. While initially this does not seem odd, but the issue is easy to understand when a read/write cycle is observed. Assume two operations are accessing the same address of memory, one has a read command, the other a write; as such the read command is dependent upon if the write command executes before or after in the information it retrieves. Therefore if the read command's calling function is critically dependent upon the return information the desired behavior is almost most assuredly going to be completely irrevocably incorrect. There are a number of other possible issues that can arise from the compiler and various systems being used on, but the issues shall be mitigated by the production of the code being on one standardize system to help avoid this issue. 

\subsubsection{Prototype Constraints}

There are various economic and social constraints to be attended to in regards to this project. In order to perform several of the functions we desire in terms of physical production of the product, we require a stencil. The stencil is a fairly expensive part, typically around \$200. As a result, even though this price has been included into the budget for the product, it may be desirable to hand solder as many of the parts as possible. This being said, the fine pitch devices will likely restrict the ability to hand solder the parts onto the board. Hand soldering such parts could lead to accidental shorts which could damage the board in the worst case, or cause unreliable behavior in the best case. The size of the board is not unlimited as well, for monetary reasons as well. Although technically from a physical perspective, the board could be as big as the bottom of the table, this is limited by the price of such a board from the board manufacturer. That being said, it is not relevant to have an arbitrarily large board because long thin traces, such as the ones on an arbitrarily large board, would act as antennas. We are using bypass capacitors to handle shorting of AC interference patterns, however it is not desirable in our communication lines to have any interference. As a result, we do want to keep the board as small as possible with the shortest trace length for each connection.

From a social standpoint, the board is currently only going to be implemented as a one player solution for several reasons, discussed below. It is important to understand that from a technology aspect, there is no limit on having several users access the device at the same time. The code that we are implementing allows for an arbitrary amount of foreign connections to the device. However, the limit comes when it is considered that the board is only 16 x 8 pixels. This severely limits the amount of space allowed for several people to be playing at once. There would be too much overlap, and as a result the usability of the product would not be optimal. It is possible to overcome this social limitation in two ways, only one of which is practical for our use. The first, non practical solution, is to add more LED pixels to the project. As a result of this implementation, the resolution would be increased and there would be more space for more people to be included in the experience. The second solution is a software solution. This is to come up with a more clever way of applying our 512 pixels to allow multiple people to play at once. For example, a way of allowing two players to interact in a limited space is to include a version of snake where two players could compete for the food, and if they contact each other they would lose the game. Several solutions to the multiple player problem likely exist, and it is an issue that we would like to at least attempt to tackle in the implementation of the software of our product.