more cps cleaning, "final"

ch.discussion.tex

@@ -47,7 +47,7 @@ To make the devices easy to reconfigure, the configuration options---such as, wh
 
 \section{Results and Possible Applications}
 
-The designed device, and the accompanying software stack, make a practical tool for the research and development in the field of embedded electronics, and may be used as a learning aid to demonstrate the timings and format of the various supported hardware buses. The inclusion of analog signal acquisition and generation features makes it possible to measure the analog characteristics of electronic components, or acquire data from physical phenomena. 
+The device we designed, and the accompanying software stack, make a practical tool for research and development in the field of embedded electronics, and may also be used as a learning aid to demonstrate the timings and format of the various supported hardware buses. The inclusion of analog signal acquisition and generation features makes it possible to measure the analog characteristics of electronic components, or acquire data from physical phenomena. 
 
 The use in automation offers itself thanks to the programmatic control from high level programming languages on the \gls{PC}; this has an advantage over programming the embedded firmware itself in that the user can focus on the behavior of the device they are developing, rather than having to deal with low level implementation details, such as memory management, or interrupt priority configuration. An inherent downside of this universal platform lies in greater latencies and lower performance than could be achieved with a custom embedded system.
 
@@ -67,7 +67,7 @@ It is clear that GEX does not pose a real threat to professional tools in terms
 
 While the objective of the work was achieved, we are aware of several limitations that must be acknowledged so that they can be addressed in future work.
 
-The chosen STM32F072 microcontroller proved sufficient for the verification of the design, and in many cases provides a sufficient performance. Future expansion of the project is, unfortunately, limited by its flash and \gls{RAM} capacity, which are already used at about 85\,\%, based on the size of the binary image and the amount of allocated memory. Further, the STM32F072 has a Cortex-M0 core without any hardware support for floating point arithmetics, making any calculations with those numbers slow and requiring additional library functions, further increasing the firmware image size. The modules' power consumption has not been measured or optimized, but the inclusion of a wireless interface predisposes them to be used in battery-powered applications; the microcontroller choice and the power supply design may need to be revised for efficient battery operation.
+The chosen STM32F072 microcontroller proved sufficient for the verification of the design, and in many cases provides sufficient performance. Future expansion of the project is, unfortunately, limited by its flash and \gls{RAM} capacity, which are already used at about 85\,\%, based on the size of the binary image and the amount of allocated memory. Further, the STM32F072 has a Cortex-M0 core without any hardware support for floating point arithmetics, making any calculations with those numbers slow and requiring additional library functions, further increasing the firmware image size. The modules' power consumption has not been measured or optimized, but the inclusion of a wireless interface predisposes them to be used in battery-powered applications; the microcontroller choice and the power supply design may need to be revised for efficient battery operation.
 
 Another limitation concerns the support software; our client libraries have not been tested on MS Windows, with Linux being the main development platform. The C library uses POSIX \gls{API} and UNIX-specific \gls{API} to manage the serial port, which is not portable. The Python library should work on MS Windows, provided libUSB is installed correctly. Further, on MS Windows prior to version 10, the virtual COM port connection requires the ``STM32 Virtual COM port driver'' to be manually installed and assigned in the Device Manager. 
 

ch.example_projects.tex

@@ -52,7 +52,7 @@ We used it to verify the duty cycle measurement functionality of the frequency c
 
 \section{Controlling the ``Micro Dot pHAT''}
 
-The ``Micro Dot pHAT'' add-on board was used to test GEX Zero's compatibility with pHATs. A photo of the pHAT on GEX Zero, together with example scripts, was presented in \cref{sec:ex_python_script}. While this board does not provide any useful functionality beyond displaying \gls{LED} patterns, it is a proof that third-party add-ons for the RPi Zero may be compatible with GEX, which introduces many interesting possibilities.
+The ``Micro Dot pHAT'' add-on board was used to test GEX Zero's compatibility with pHATs. A photo of the pHAT on GEX Zero, together with example scripts, was presented in \cref{sec:ex_python_script}. While this board does not provide any useful functionality beyond displaying \gls{LED} patterns, it proved that third-party add-ons for the RPi Zero may be compatible with GEX Zero, which introduces many interesting possibilities.
 
 \section{Capturing Transient Effects}
 

ch.fw_structure_toplevel.tex

@@ -28,7 +28,7 @@ All GEX hardware platforms have some common characteristics, illustrated in \cre
 	\item \textbf{Status \gls{LED}} -- periodic flashing every 3\,s indicates correct operation, continuous light a software error\footnote{The microcontroller will then automatically restart within a few seconds due to a watchdog timeout.}; other light patterns may be shown as feedback to user actions or received commands
 	\item \textbf{Reset button} -- resets the \gls{MCU}; this is particularly useful during firmware development as an alternative to re-connecting the \gls{USB} cable
 	\item \textbf{Lock button} -- enables or disables access to configuration files through the virtual mass storage device
-	\item \textbf{Boot button} -- when held during restart (that is, while the reset button is released), the \gls{DFU} mode~\cite{usbif-dfu} is activated and a new firmware image can be flashed over the \gls{USB} connection using \mono{dfu-util}~\cite{dfu-util} or other firmware update application
+	\item \textbf{Boot button} -- when held during restart (that is, while the reset button is released), the \gls{DFU} mode~\cite{usbif-dfu} is activated and a new firmware image can be flashed over the \gls{USB} connection using \mono{dfu-util}~\cite{dfu-util} or another firmware update application
 	\item \textbf{\gls{GPIO} header} -- a pin header exposing the \gls{MCU}'s \gls{GPIO} pins to be connected to external circuitry
 	\item \textbf{Communication interface} -- a connection to the host \gls{PC}; multiple options may be available to choose from, a direct \gls{USB} connection being the primary and always available option
 \end{itemize}
@@ -40,7 +40,7 @@ All GEX hardware platforms have some common characteristics, illustrated in \cre
 \begin{itemize}
 	\item \textbf{Direct \gls{USB} connection}
 		
-		This is the primary and most straightforward connection method. We use the \gls{CDCACM} and \gls{MSC} \gls{USB} classes to have the module appear as a virtual COM port and a mass storage device, as described in \cref{sec:usb_classes}. This method is the fastest of the three and works out-of-the-box on Linux and MacOS. On MS Windows it may require the right software driver to be installed and assigned manually\footnote{The STM32 virtual COM port driver~\cite{stm-vcom} has been tested to work with GEX on MS Windows version 7 and 8, though it must be manually assigned to the device in the Device Manager. MS Windows 10 and later should support \gls{CDCACM} as a virtual COM port natively.}.
+		This is the primary and most straightforward connection method. We use the \gls{CDCACM} and \gls{MSC} \gls{USB} classes to have the module appear as a virtual COM port and a mass storage device, as described in \cref{sec:usb_classes}. This method is the fastest of the three and works out-of-the-box on Linux and macOS. On MS Windows it may require the right software driver to be installed and assigned manually\footnote{The STM32 virtual COM port driver~\cite{stm-vcom} has been tested to work with GEX on MS Windows version 7 and 8, though it must be manually assigned to the device in the Device Manager. MS Windows 10 and later should support \gls{CDCACM} as a virtual COM port natively.}.
 	
 	\item \textbf{Hardware \gls{UART}}
 	
@@ -52,7 +52,7 @@ All GEX hardware platforms have some common characteristics, illustrated in \cre
 	
 \end{itemize}
 
-The \gls{USB} connection is always enabled first on start-up. GEX waits its for enumeration by the host \gls{PC}. When not enumerated in a few seconds, it concludes that the interface is not active and tries other enabled options. The wireless module, connected through \gls{SPI}, can be detected by reading one of its registers that should have a known value. A \gls{UART} interface cannot be tested so reliably, thus it is always considered active\footnote{A detection of the UART connection would be possible by measuring the Rx pin voltage, which should idle at a high level (here 3.3\,V). This was not implemented in the initial firmware version.}.
+The \gls{USB} connection is always enabled on start-up. GEX waits for its enumeration by the host \gls{PC}, and when not enumerated in a few seconds, it concludes that the interface is not active and tries other available options. The wireless module, connected through \gls{SPI}, can be detected by reading one of its registers that should have a known value. The \gls{UART} interface cannot be tested so reliably, thus it is always considered active\footnote{The UART connection could be tested by measuring the Rx pin voltage, which should assume high level (here 3.3\,V) when idle}.
 
 \section{Controlling GEX}
 

ch.hardware_realization.tex

@@ -319,9 +319,10 @@ The GEX Zero pin header's alternate functions had to match those on the RPi Zero
 
 \section{GEX Zero Errata}
 
-Unfortunately, neither the GEX Zero \gls{PCB} was flawless in the first revision. The errors are minor and will not interfere much in the usage of the module. Nonetheless, they should be corrected in the next revision:
+The GEX Hub \gls{PCB} had to be updated to correct some layout mistakes.
+Unfortunately, neither GEX Zero \gls{PCB} was flawless in the first revision. The errors should not interfere much in the usage of the module; nonetheless, they were fixed in the schematic for any future production of the board.
 
-\begin{itemize}[itemsep=0pt]
+\begin{itemize}
 	\item The \IIC pull-up resistor R8 is connected to PA8 instead of PB7. This can be fixed by cutting the trace near the \gls{GPIO} header and rewiring it, or using an external 1.8\,k$\Omega$ pull-up resistor on PB7, when the \IIC connection is required.
 	\item Pins PB14 and PB15 are swapped in the \gls{GPIO} header, making the SPI port incompatible with add-on boards using this interface. Luckily, there is another SPI port on the header, which is routed correctly, somewhat mitigating this mistake.
 \end{itemize}

ch.pc_software.tex

@@ -9,7 +9,7 @@ The structure of a GEX client library is in all cases similar:
 \begin{itemize}
     \item \textbf{USB or serial port access}
 
-        This is the only platform-dependent part of the library. Unix-based systems provide a standardized POSIX API to configure the serial port. A raw access to \gls{USB} endpoints is possible using the libUSB C library. Access to the serial port or \gls{USB} from C on MS Windows has not been investigated, but should be possible using proprietary APIs.
+        This is the only platform-dependent part of the library. Unix-based systems provide a standardized POSIX API to configure the serial port. Raw access to \gls{USB} endpoints is possible using the libUSB C library. Access to the serial port or \gls{USB} from C on MS Windows has not been investigated, but should be possible using proprietary APIs.
 
         Accessing the serial port or \gls{USB} endpoints from Python is more straightforward thanks to the cross platform libraries \textit{PySerial} and \textit{PyUSB}.
 
@@ -94,7 +94,7 @@ First, a client instance is created, receiving the transport as an argument. We
 
 The Python library can be accessed from MATLAB scripts thanks to MATLAB's two-way Python integration~\cite{matlabpy}. Controlling GEX from MATLAB may be useful when additional processing is required, e.g., with data from the \gls{ADC}; however, in many cases, an open-source alternative native to Python exists that could be used for the same purpose, such as the NumPy and SciPy libraries~\cite{numpyscipy}.
 
-The example in \cref{lst:matlab_api} (and \cref{fig:matlabpic}) demonstrates the use of MATLAB to calculate the frequency spectrum of an analog signal captured with GEX. The syntax needed to use the serial port transport (instead of a raw access to USB endpoints) is shown in a comment.
+The example in \cref{lst:matlab_api} (and \cref{fig:matlabpic}) demonstrates the use of MATLAB to calculate the frequency spectrum of an analog signal captured with GEX. The syntax needed to use the serial port transport (instead of raw access to USB endpoints) is shown in a comment.
 
 \begin{listing}
 	\begin{matlabcode}
@@ -134,7 +134,7 @@ The example in \cref{lst:matlab_api} (and \cref{fig:matlabpic}) demonstrates the
 
 The C library is more simplistic than the Python one; it supports only the serial port transport (\gls{UART} or \gls{CDCACM}) and does not implement asynchronous polling or the unit support drivers. The implemented features---the transport, a basic protocol handler, and payload building and parsing utilities---are sufficient for most applications, though less convenient than the Python library.
 
-This low-level library is intended for applications where the performance of the Python implementation is insufficient, or where an integration with existing C code is required. The full \gls{API} can be found in the library header files. A C version of the example Python script shown above, controlling an \gls{LED} matrix driver, is presented in \cref{lst:c_api_full}. 
+This low-level library is intended for applications where the performance of the Python implementation is insufficient, or where integration with existing C code is required. The full \gls{API} can be found in the library header files. A C version of the example Python script shown above, controlling an \gls{LED} matrix driver, is presented in \cref{lst:c_api_full}. 
 
 The payloads in this example are specified as binary strings, for simplicity. Two better methods of payload construction are available: using C structs, or taking advantage of the Payload Builder utility (bundled with TinyFrame).
 

ch.requirement_analysis.tex

@@ -32,7 +32,7 @@ Some sensors have variable frequency or \gls{PWM} output. To capture those signa
 
 \subsection{Logic Level Input and Output}
 
-We have covered some more advanced features, but skipped the simplest feature: direct access to \gls{GPIO} pins. Considering the latencies of \gls{USB} and the \gls{PC}'s \gls{OS}, this cannot be used reliably for ``bit banging'' custom protocols, unless they are tolerant to jitter, or very slow; however, we can still accomplish a lot with just changing logic levels---e.g., to control character displays with a parallel interface, or to emulate some interfaces that include a clock line. As mentioned in \cref{sec:uses_digital_ifaces}, many digital sensors and modules use plain \glspl{GPIO}, in addition to the communication bus, for out-of-band signaling or features like chip select or reset.
+We have covered some more advanced features, but skipped the simplest feature: direct  to \gls{GPIO} pins. Considering the latencies of \gls{USB} and the \gls{PC}'s \gls{OS}, this cannot be used reliably for ``bit banging'' custom protocols, unless they are tolerant to jitter, or very slow; however, we can still accomplish a lot with just changing logic levels---e.g., to control character displays with a parallel interface, or to emulate some interfaces that include a clock line. As mentioned in \cref{sec:uses_digital_ifaces}, many digital sensors and modules use plain \glspl{GPIO}, in addition to the communication bus, for out-of-band signaling or features like chip select or reset.
 
 \section{Connection to the Host Computer}
 
@@ -42,7 +42,7 @@ We have covered some more advanced features, but skipped the simplest feature: d
 
 The most straightforward method of interfacing the board is by passing binary messages in a fashion similar to \gls{UART}. This is possible either using a ``Virtual COM port'' driver, or through raw access to the corresponding \gls{USB} endpoints. Using raw access avoids potential problems with the \gls{OS}'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 into existing platforms that have good serial port support (such as National Instruments LabWindows~CVI, Visual C++ applications, or VBA macros).
 
-GEX may be used with development boards lacking a ``User'' \gls{USB} connector, such as STM32 Nucleo. In this case, either the board can be customized, or we use the built-in \gls{USB}/\gls{UART} converter; that requires the communication interface to be available also through hardware \gls{UART}. Another use-case is in battery-powered setups where a wired access is not possible or practical. For those cases the ideal solution is a wireless connection.
+GEX may be used with development boards lacking a ``User'' \gls{USB} connector, such as STM32 Nucleo. In this case, either the board can be customized, or we use the built-in \gls{USB}/\gls{UART} converter; that requires the communication interface to be available also through hardware \gls{UART}. Another use-case is in battery-powered setups where wired access is not possible or practical. For those cases the ideal solution is a wireless connection.
 
 \subsection{Configuration Files}
 

ch.summary.tex

@@ -6,6 +6,6 @@ The platform consists of a FreeRTOS-based firmware for the STM32F072 microcontro
 
 The devices are connected to the \gls{PC} by one of three interfaces: \gls{USB} as a virtual COM port or with raw endpoint access, a hardware \gls{UART}, or a radio link with the nRF24L01+ transceiver. Configuration is performed by editing INI files exposed in an emulated FAT16 file system through the \gls{USB} connection, or programmatically.
 
-The developed platform can be used as an learning aid, as an inexpensive development tool replacing professional laboratory equipment, or for automation purposes, taking advantage of its hardware interfacing capabilities to connect to multiple sensors and actuators.
+The developed platform can be used as a learning aid, as an inexpensive development tool replacing professional laboratory equipment, or for automation purposes, taking advantage of its hardware interfacing capabilities to connect to multiple sensors and actuators.
 
 Future development should focus on expanding support to other \gls{MCU} models, adding new features, improving the software libraries, and providing a more user-friendly control interface.

ch.tinyframe.tex

@@ -11,7 +11,7 @@ GEX can be controlled through a hardware \gls{UART}, the \gls{USB}, or over a wi
 
 GEX uses the \textit{TinyFrame}~\cite{tinyframerepo} framing library, developed, likewise, by the author, but kept as a separate project for easier re-use in different applications. The library implements frame building and parsing, including checksum calculation, and provides high-level \gls{API}.
 
-Both peers, GEX and the client library running on the host \gls{PC}, are at an equal level: either side can independently send a message at any time. The communication is organized in transactions; a transaction consists of one or more messages going in either direction. A message can be stand-alone, or chained to another, typically a request, using the frame ID field; this is the major advantage over text-based protocols, like AT commands, where all messages are independent and their relation to each other is not always clear.
+Both peers, GEX and the client library running on the host \gls{PC}, are on an equal level: either side can independently send a message at any time. The communication is organized in transactions; a transaction consists of one or more messages going in either direction. A message can be stand-alone, or chained to another, typically a request, using the frame ID field; this is the major advantage over text-based protocols, like AT commands, where all messages are independent and their relation to each other is not always clear.
 
 \section{Binary Payload Structure Notation}