gex-thesis/ch.requirements.tex

\chapter{Goals and Requirements}

This chapter discusses the project requirements and presents our expectations of the final outcome.

The work's main objective is the implementation of a reconfigurable embedded firmware, a physical module providing the required digital buses, signal generation and acquisition capabilities, and the PC libraries to work with it. It's expected that several prototypes of the hardware platform will be developed to evaluate different form factors.

\section{Project Name}

Every project needs a memorable name. During the development, the name "GEX" was chosen, an acronym originating in the term \textit{GPIO Expander}, which, although not describing its scope perfectly, alludes to the project's primary purpose of providing low level GPIO capabilities to personal computers. The term GEX may be used through the text to refer to the whole project or hardware modules developed for it.

\section{Expected Use Cases}

First, we must consider in which situations the module could be helpful. As we explained in the introduction, GEX should allow the user to connect digital sensors and electronic circuits to a PC and work with them using high level application software.

This could be used to get familiar with a new chip or a module before using it in some hardware project, to measure characteristic curves of a component, to collect experimental data from a test setup, or, for instance, to control a positioning motor.

The applications can have a temporary character, a simple setup that is used once and then dismantled, or a more permanent one. An example of the latter could be students' laboratory tasks where the measurement setup is prepared beforehand by an instructor. Another example could be the use of GEX as a data acquisition module for process or environment monitoring.

The module should either be directly attached to the PC via a USB port, or controlled wirelessly (possibly powered by a battery or a solar cell). A wireless connection can find use in mobile robotic projects where the wired attachment isn't practical, or when used outdoors or in hardly accessible places.

\section{Supported Hardware Interfaces}

The project's scope is very broad and it's hardly possible to enumerate all the use cases. To achieve the greatest flexibility, it appears as a good strategy to divide the features into smaller functional blocks that can be used independently or combined as needed.

\subsection{Direct Digital Input/Output}

The most basic interaction with hardware is simply changing the logic levels of output pins, and reading input pins. With this feature alone it would be possible to analyze logic circuits, trigger some transient effect we want to observe using an oscilloscope, sense a button push, drive LED displays and more. Almost anything digital that doesn't require precise or fast timing\footnote{We're limited by the latencies of USB and the PC software.} could be achieved by this simple function.

To make this feature more versatile, it should be possible to receive an asynchronous event on a pin state change, avoiding the need for polling loops in the control application.

\subsection{Common Digital Buses}

A popular way to attach peripheral devices to a microcontroller are hardware buses, the most well known of which are SPI (\textit{Serial Peripheral Interface}), I$^2$C (or IIC, \textit{Inter-Integrated-Circuit}) and USART (\textit{Universal Synchronous Asynchronous Receiver Transmitter}). There is a hardware support in most microcontrollers for those buses, removing the burden of precise timing from the firmware.

More information about those interfaces can be found in later chapters. \todo{link to actual place}

\subsection{Specialized Buses}

Some devices exist that use their own proprietary protocol, usually to reduce the number of data pins. An example of this group is the Dallas Semiconductor\footnote{Acquired by Maxim Integrated in 2001} 1-Wire bus, used by the popular DS18x20 digital thermometers. Another such protocol is used by some types of addressable LED strips.

A common characteristic of those buses is that they require precise timing and have no native hardware support in the microcontroller. We can't use the direct GPIO access here due to latencies and jitter; those protocols need a custom low level routine in the firmware that performs such "bit banging" more accurately.

\subsection{Analog Input/Output}

Microcontrollers typically include a 10-12 bit ADC (\textit{Analog to Digital Converter}), often accompanied by a DAC (\textit{Digital to Analog Converter}), its output counterpart. In the lack of a real DAC, the analog output, albeit with worse dynamic parameters, can be realized using a PWM signal (\textit{Pulse Width Modulation}, pulse train) followed by a low-pass filter.

While we mainly focused on digital interfaces thus far, providing means of generating and capturing analog signals is also valuable. This capability makes it possible to read sensors with voltage output and it can substitute a simple oscilloscope when sampled periodically at a sufficient speed.

The analog output and input together can be used for automated characterization of electronic components, or for analog feedback regulation. Should the analog output be modulated, we could further use them to measure frequency-dependent characteristics, such as the frequency response of analog filters.

\subsection{Frequency Measurement and Generation}

Some sensors have a variable frequency or a pulse-width modulated (PWM) output. To capture those signals and convert them to a more useful digital value, we can use the Input Capture or External Clock function of a general purpose timer/counter in the used microcontroller. Those timers have a wide range of possible configurations and can be also used for pulse counting or PWM generation.

\section{User Interface}

USB will be the primary way of connecting the module to a PC. Thanks to USB's flexibility, it can present itself to the computer as any kind of device or even multiple devices at once.

The most straightforward method of interfacing the board is by passing binary messages in a fashion similar to USART. This can be done either using a "Virtual COM port" driver (the CDC/ACM class), or through a raw access to the corresponding USB endpoints. Using a raw access avoids potential problems with the operating system's driver interfering or not recognizing the device correctly; on the other hand, having GEX appear as a serial port makes it easier to integrate it into existing platforms that have a good serial port support (such as National Instruments LabWindows CVI or MATLAB).

The module should be reconfigurable. Given the settings are almost always going to be tied on the connected external hardware, it would be practical to have an option to store them permanently in the microcontroller's non-volatile memory.

We could load those settings into GEX using the serial interface, and indeed this should be implemented for its flexibility. The serial interface may be, in some form, also used for the wireless connection. However, having the power of USB at our disposal, we can make the board appear as a mass storage device and expose the configuration as text files. This approach, inspired by ARM mbed\footnote{A similar mechanism is used for flashing firmware images to mbed-enabled development kits}, avoids the need to create a configuration utility and it can work cross-platform thanks to using the same driver as a real removable disk. Further, we can expose any useful information (such as a README file with instructions, or a pin-out reference) using this virtual disk as separate files.

\section{Form Factor and MCU Selection}

It has been established that the designed device should be small and easily portable. It should support USB and wireless connection to a PC. Further, a plain UART interface should be offered in place of USB; this makes it easier to integrate GEX into other systems or use development kits fitted with a USB-UART converter.

The following protocols and features should be implemented as a minimum; other functions may be added based on input from prototype testing in model situations.

\begin{itemize}
	\item Low level hardware functions
		\begin{itemize}
			\item I/O pin direct access
			\item Input pin change reporting
			\item Single pulse generation
			\item PWM signal generation
			\item Analog/Digital converter (analog input)
			\item Digital/Analog converter (analog output)
			\item Frequency measurement
			\item Pulse measurement
		\end{itemize}
	\item Common hardware interfaces
		\begin{itemize}
			\item SPI
			\item I$^2$C
			\item UART/USART
		\end{itemize}
	\item Low level support for proprietary buses
		\begin{itemize}
			\item Dallas 1-Wire
			\item NeoPixel (addressable LED strips)
		\end{itemize}
\end{itemize}

Considering the requirements, availability, and cost, the STM32F072 microcontroller will be used for the first prototypes, with the expectation of later porting the project to more powerful or power-efficient devices, like the STM32L072, STM32F103, STM32F303, or other STM32 microcontrollers.

The STM32F072 is a Cortex M0 device with 128\,KiB of flash memory, 16\,KiB of RAM and running at up to of 48\,MHz. It is equipped with a USB Full Speed peripheral block, a 12-bit ADC and DAC, a number of general purpose timers/counters, SPI, I$^2$C, and USART peripherals. It further supports a crystal-less USB operation, using the USB SOF packet for synchronization.

To utilize the time frame available for this work effectively, only the STM32F072 firmware will be initially developed, while making sure the planned future expansion will be as straightforward as possible.

\todo[inline]{info about form factor choices + some sketches}