Browse Source

more cps cleaning, "final"

Ondřej Hruška 1 year ago
parent
commit
bc0844e716
Signed by: Ondřej Hruška <ondra@ondrovo.com> GPG key ID: 2C5FD5035250423D

+ 2 - 2
ch.discussion.tex View File

@@ -47,7 +47,7 @@ To make the devices easy to reconfigure, the configuration options---such as, wh
47 47
 
48 48
 \section{Results and Possible Applications}
49 49
 
50
-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. 
50
+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. 
51 51
 
52 52
 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.
53 53
 
@@ -67,7 +67,7 @@ It is clear that GEX does not pose a real threat to professional tools in terms
67 67
 
68 68
 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.
69 69
 
70
-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.
70
+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.
71 71
 
72 72
 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. 
73 73
 

+ 1 - 1
ch.example_projects.tex View File

@@ -52,7 +52,7 @@ We used it to verify the duty cycle measurement functionality of the frequency c
52 52
 
53 53
 \section{Controlling the ``Micro Dot pHAT''}
54 54
 
55
-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.
55
+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.
56 56
 
57 57
 \section{Capturing Transient Effects}
58 58
 

+ 3 - 3
ch.fw_structure_toplevel.tex View File

@@ -28,7 +28,7 @@ All GEX hardware platforms have some common characteristics, illustrated in \cre
28 28
 	\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
29 29
 	\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
30 30
 	\item \textbf{Lock button} -- enables or disables access to configuration files through the virtual mass storage device
31
-	\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
31
+	\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
32 32
 	\item \textbf{\gls{GPIO} header} -- a pin header exposing the \gls{MCU}'s \gls{GPIO} pins to be connected to external circuitry
33 33
 	\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
34 34
 \end{itemize}
@@ -40,7 +40,7 @@ All GEX hardware platforms have some common characteristics, illustrated in \cre
40 40
 \begin{itemize}
41 41
 	\item \textbf{Direct \gls{USB} connection}
42 42
 		
43
-		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.}.
43
+		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.}.
44 44
 	
45 45
 	\item \textbf{Hardware \gls{UART}}
46 46
 	
@@ -52,7 +52,7 @@ All GEX hardware platforms have some common characteristics, illustrated in \cre
52 52
 	
53 53
 \end{itemize}
54 54
 
55
-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.}.
55
+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}.
56 56
 
57 57
 \section{Controlling GEX}
58 58
 

+ 3 - 2
ch.hardware_realization.tex View File

@@ -319,9 +319,10 @@ The GEX Zero pin header's alternate functions had to match those on the RPi Zero
319 319
 
320 320
 \section{GEX Zero Errata}
321 321
 
322
-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:
322
+The GEX Hub \gls{PCB} had to be updated to correct some layout mistakes.
323
+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.
323 324
 
324
-\begin{itemize}[itemsep=0pt]
325
+\begin{itemize}
325 326
 	\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.
326 327
 	\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.
327 328
 \end{itemize}

+ 3 - 3
ch.pc_software.tex View File

@@ -9,7 +9,7 @@ The structure of a GEX client library is in all cases similar:
9 9
 \begin{itemize}
10 10
     \item \textbf{USB or serial port access}
11 11
 
12
-        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.
12
+        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.
13 13
 
14 14
         Accessing the serial port or \gls{USB} endpoints from Python is more straightforward thanks to the cross platform libraries \textit{PySerial} and \textit{PyUSB}.
15 15
 
@@ -94,7 +94,7 @@ First, a client instance is created, receiving the transport as an argument. We
94 94
 
95 95
 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}.
96 96
 
97
-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.
97
+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.
98 98
 
99 99
 \begin{listing}
100 100
 	\begin{matlabcode}
@@ -134,7 +134,7 @@ The example in \cref{lst:matlab_api} (and \cref{fig:matlabpic}) demonstrates the
134 134
 
135 135
 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.
136 136
 
137
-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}. 
137
+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}. 
138 138
 
139 139
 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).
140 140
 

+ 2 - 2
ch.requirement_analysis.tex View File

@@ -32,7 +32,7 @@ Some sensors have variable frequency or \gls{PWM} output. To capture those signa
32 32
 
33 33
 \subsection{Logic Level Input and Output}
34 34
 
35
-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.
35
+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.
36 36
 
37 37
 \section{Connection to the Host Computer}
38 38
 
@@ -42,7 +42,7 @@ We have covered some more advanced features, but skipped the simplest feature: d
42 42
 
43 43
 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).
44 44
 
45
-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.
45
+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.
46 46
 
47 47
 \subsection{Configuration Files}
48 48
 

+ 1 - 1
ch.summary.tex View File

@@ -6,6 +6,6 @@ The platform consists of a FreeRTOS-based firmware for the STM32F072 microcontro
6 6
 
7 7
 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.
8 8
 
9
-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.
9
+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.
10 10
 
11 11
 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.

+ 1 - 1
ch.tinyframe.tex View File

@@ -11,7 +11,7 @@ GEX can be controlled through a hardware \gls{UART}, the \gls{USB}, or over a wi
11 11
 
12 12
 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}.
13 13
 
14
-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.
14
+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.
15 15
 
16 16
 \section{Binary Payload Structure Notation}
17 17
 

BIN
thesis.pdf View File