Browse Source

cleanings

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

+ 7 - 5
ch.existing_solutions.tex View File

@@ -19,11 +19,11 @@ The idea of making it easier to interact with low-level hardware from a \gls{PC}
19 19
 	\caption{\label{fig:rpi}Raspberry Pi minicomputers}
20 20
 \end{figure}
21 21
 
22
-The Raspberry Pi's \gls{GPIO} header, a row of pins which can be directly controlled by user applications running on the minicomputer, was one of the inspirations behind GEX. It can be controlled using C and Python (among others) and offers \gls{GPIO}, \gls{SPI}, \gls{I2C}, \gls{UART}, and \gls{PWM}, with other protocols and functions easy to emulate thanks to the high speed of the system processor.
22
+The Raspberry Pi (\cref{fig:rpi}) is a low-cost minicomputer targeted at school environments and hobbyists. It is often used for home automation, as a simple web server, or built into projects that take advantage of its powerful processor, such as wildlife camera traps, or data acquisition devices with in-situ processing.
23 23
 
24
-The Raspberry Pi is used in schools as a low-cost PC alternative that encourage students' interest in \gls{STEM}. The board is often built into more permanent projects that make use of its powerful processor, such as wildlife camera traps, fish feeders etc.
24
+The board's \gls{GPIO} header, a row of pins supporting features such as \gls{SPI}, \gls{I2C}, \gls{UART}, or \gls{PWM}, directly accessible by user applications running on the minicomputer, was one of the inspirations behind GEX.
25 25
 
26
-The Raspberry Pi could be used for the same quick evaluations or experiments we want to perform with GEX, however they would either have to be performed directly on the minicomputer, with an attached monitor and a keyboard, or use some form of remote access (e.g., \gls{SSH}, or screen sharing).
26
+The Raspberry Pi's functionality clearly overlaps with features we wish to support in GEX. Its processor is powerful enough for a regular \gls{OS} with a graphical user interface, and after attaching a display and a keyboard, it can be used as a \gls{PC}. However, when we have a more powerful computer available and only want to extend it with the \gls{GPIO} header, having to use the Raspberry Pi seems inconvenient; this might be overcome with the use of screen sharing or \gls{SSH}, but a low-complexity solution like GEX certainly has its appeal.
27 27
 
28 28
 \section{Bus Pirate}
29 29
 
@@ -36,11 +36,13 @@ The Raspberry Pi could be used for the same quick evaluations or experiments we
36 36
 %http://dangerousprototypes.com/blog/about/
37 37
 
38 38
 % Dangerous Prototypes and manufactured by Seeed Studio\todo{link}
39
-Bus Pirate, a project by Ian Lesnet, is a USB-attached device providing access to hardware interfaces like \gls{SPI}, \gls{I2C}, \gls{USART}, and 1-Wire, as well as frequency measurement and direct pin access. The board aims to make it easy for users to familiarize themselves with new chips and modules; it also provides a range of programming interfaces for flashing microcontroller firmwares and memories. It communicates with the \gls{PC} using a FTDI USB-serial bridge.
39
+Bus Pirate~\cite{buspirate} is a USB-attached device providing access to hardware interfaces like \gls{SPI}, \gls{I2C}, \gls{USART}, and 1-Wire, as well as features like frequency measurement and direct pin access. The board aims to make it easy for users to familiarize themselves with unknown chips and modules; it also provides a range of programming interfaces to program microcontrollers and memory chips. The board communicates with the \gls{PC} using an FTDI USB-serial adapter.
40 40
 
41 41
 Bus Pirate is open source and is, in its scope, similar to GEX. It can be scripted and controlled from the PC, connects to USB and provides a wide selection of hardware interfaces.
42 42
 
43
-The board is based on a PIC16 microcontroller running at 32\,MHz. Its \gls{ADC} only has a resolution of 10 bits (1024 levels). There is no \gls{DAC} available on the chip, which makes applications that require a varied output voltage more difficult to implement. Another limitation of the board is its low number of \gls{GPIO} pins, which may be insufficient for certain applications. The Bus Pirate is available for purchase at around 30\,USD, a price comparable to some Raspberry Pi models.
43
+The board is based on a PIC16 microcontroller running at 32\,MHz. Its \gls{ADC} only has a resolution of 10 bits (1024 levels). There is no \gls{DAC} available on the chip, which makes applications that require a varied output voltage more difficult to implement. Another limitation of the board is its low number of \gls{GPIO} pins, which may be insufficient for certain applications; this, however, is not a hindrance to its main purpose as a bus analyzer and tinkering tool. 
44
+
45
+The Bus Pirate is available for purchase at around 30\,USD (at the time of writing), a price comparable to some Raspberry Pi models.
44 46
 
45 47
 \section{Professional DAQ Modules}
46 48
 

+ 7 - 7
ch.fw_structure.tex View File

@@ -2,20 +2,20 @@
2 2
 
3 3
 The firmware is built around a \textit{core framework} which provides services to units, such as the settings storage, resource allocation, message delivery, and periodic updates. In this chapter, we will focus on the structure of this framework and the services provided by it.
4 4
 
5
-\section{Internal Structure Block Diagram}
6
-
7
-The data flows and other internal logic of the firmware are depicted in \cref{fig:gex_internal}, with more explanation following in this chapter. The interchangeable role of the three communication interfaces can be clearly seen in the diagram, as well as the central role of the message queue, which decouples interrupts from the processing thread.
8
-
9 5
 \begin{figure}[h]
10 6
 	\centering
11 7
 	\includegraphics[width=\textwidth] {img/gex-internal.pdf}
12 8
 	\caption{\label{fig:gex_internal}Block diagram showing the internal logic in the GEX firmware}
13 9
 \end{figure}
14 10
 
11
+\section{Internal Structure Block Diagram}
12
+
13
+The data flows and other internal logic of the firmware are depicted in \cref{fig:gex_internal}, with more explanation following in this chapter. The interchangeable role of the three communication interfaces can be clearly seen in the diagram, as well as the central role of the message queue, which decouples interrupts from the processing thread.
14
+
15 15
 \noindent
16 16
 The framework provides the following services to units:
17 17
 
18
-\begin{itemize}
18
+\begin{itemize}[itemsep=0pt]
19 19
 	\item Hardware resource allocation (\cref{sec:res_allocation})
20 20
 	\item Settings storage and loading (\cref{sec:settings_storage})
21 21
 	\item Unit life cycle management (\cref{sec:units_function})
@@ -94,7 +94,7 @@ In \arm Cortex-M0 the interrupt handlers table, defining which routine is called
94 94
 
95 95
 Let us have a look at a sample interrupt handler, in this case serving four different \gls{DMA} channels, as is common in STM32 microcontrollers:
96 96
 
97
-\begin{minted}{c}
97
+\begin{ccode}
98 98
 void DMA1_Channel4_5_6_7_IRQHandler(void)
99 99
 {
100 100
     if (LL_DMA_IsActiveFlag_GI4(DMA1)) { /* handle DMA1 channel 4 */ }
@@ -102,7 +102,7 @@ void DMA1_Channel4_5_6_7_IRQHandler(void)
102 102
     if (LL_DMA_IsActiveFlag_GI6(DMA1)) { /* handle DMA1 channel 6 */ }
103 103
     if (LL_DMA_IsActiveFlag_GI7(DMA1)) { /* handle DMA1 channel 7 */ }
104 104
 }
105
-\end{minted}
105
+\end{ccode}
106 106
 
107 107
 It is evident that multiple units might need to use the same handler, even at the same time, since each \gls{DMA} channel is configured, and works, independently. GEX implements a redirection scheme to accomplish such interrupt sharing: all interrupt handlers are defined in one place, accompanied by a table of function pointers. When a unit driver wants to register an interrupt handler, it stores a pointer to it in this redirection table. Then, once an interrupt is invoked, the common handler checks the corresponding entry in the table and calls the referenced routine, if any. Conversely, when a unit driver de-initializes a unit, it removes all interrupt handlers it used, freeing the redirection table slots for other use.
108 108
 

+ 1 - 1
ch.fw_structure_toplevel.tex View File

@@ -40,7 +40,7 @@ All GEX hardware platforms have some common characteristics (\cref{fig:users_vie
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 serial 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} 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
 	

+ 2 - 2
ch.gex_units.tex View File

@@ -2,9 +2,9 @@
2 2
 
3 3
 This chapter describes all functional blocks (units) implemented in GEX, version 1.0. The term ``unit'' will be used here to refer to both unit types (drivers) or their instances where the distinction is not important.
4 4
 
5
-Each unit's description will be accompanied by a corresponding snippet from the configuration file, and a list of supported commands and events. The commands and events described here form the payload of TinyFrame messages 0x10 (Unit Request) and 0x11 (Unit Report), as described in \cref{sec:unit_requests_reports}.
5
+Each unit's description will be accompanied by a corresponding snippet from the configuration file, and a list of supported commands and events. The commands and events described here form the payload of TinyFrame messages \CmdUnitRequest and \CmdUnitReport, as described in \cref{sec:unit_requests_reports}.
6 6
 
7
-The number in the first column of the command (or event) tables, marked as ``Code'', is the command number (or report type) used in the payload to identify how the message data should be treated. When the request or response payload is empty, it is omitted from the table. The same applies to commands with no response, in which case adding 0x80 to the command number triggers a SUCCESS response after the command is finished.
7
+The number in the first column of the command (or event) tables, marked as ``Code'', is the command number (or report type) used in the payload to identify how the message data should be treated. When the request or response payload is empty, it is omitted from the table. The same applies to commands with no response, in which case adding 0x80 to the command number triggers a type \CmdSuccess response after the command is finished.
8 8
 
9 9
 \section{General Notes}
10 10
 

+ 90 - 87
ch.hardware_realization.tex View File

@@ -2,13 +2,13 @@
2 2
 
3 3
 \section{GEX on a STM32 Discovery Board}
4 4
 
5
-It has been proposed earlier in the text that STM32 Nucleo and Discovery development boards might serve as the hardware platform for this project. Indeed, a Discovery board with the STM32F072 was used to development a major part of the GEX firmware. This inexpensive board may be used to try GEX without having access to the custom hardware.
5
+It has been proposed earlier in the text that STM32 Nucleo and Discovery development boards might serve as the hardware platform for this project. Indeed, a Discovery board with the STM32F072 was used to develop a major part of the GEX firmware, and the firmware remains compatible with it. This inexpensive board may be used to try GEX without the custom hardware.
6 6
 
7 7
 \subsection{Discovery STM32F072 Configuration and Pin Mapping}
8 8
 
9
-This Discovery board is fitted with four \glspl{LED} on \gls{GPIO} pins PC6 through PC9, in a compass arrangement. The ``north'' \gls{LED}, PC6, is used as the GEX status indicator. The ``User'' button, connected to PA0, is mapped as the GEX Lock button, controlling the settings storage.
9
+The Discovery board is fitted with four \glspl{LED} on \gls{GPIO} pins PC6 through PC9, in a compass arrangement. The ``north'' \gls{LED}, PC6, is used as the GEX status indicator. The ``User'' button, connected to PA0, is mapped as the GEX Lock button, controlling the settings storage.
10 10
 
11
-We advise the reader, as a potential user of this discovery board, to review its schematic diagram (found in its documentation~\cite{disco-f072}) and ensure the solder-jumpers are configured correctly:
11
+We advise the reader, as a potential user of the board, to review its schematic diagram (found in the documentation~\cite{disco-f072}) and ensure the solder-jumpers on the back side are configured correctly:
12 12
 
13 13
 \begin{itemize}
14 14
 	\item Jumpers SB20 and SB23 must be closed to enable the User \gls{USB} connector.
@@ -18,7 +18,7 @@ We advise the reader, as a potential user of this discovery board, to review its
18 18
 	\item Jumpers SB27 through SB32 should be closed to connect the \gls{GPIO} pins normally dedicated to the touch sensing strip to the board's header.
19 19
 \end{itemize} 
20 20
 
21
-Capacitors C26, C27, and C28 are sampling capacitors for the \gls{TSC}. There are, unfortunately, no jumpers available to disconnect them, and they interfere in high-speed signals on the used pins (PA3, PA7, PB1). The only solution, when those pins are needed for another purpose, is to desolder the capacitors.
21
+Capacitors C26, C27, and C28 are sampling capacitors for the \gls{TSC}. There are, unfortunately, no jumpers available to disconnect them, and they interfere in high-speed signals on the used pins (PA3, PA7, and PB1). The only solution, when those pins are needed for another purpose, is to desolder the capacitors.
22 22
 
23 23
 An accelerometer \gls{IC} L3GD20 is fitted on the board, attached to SPI2 on pins PB13 (\gls{SCK}), PB14 (\gls{MISO}), and PB15 (\gls{MOSI}), with \gls{NSS} on pin PC0, and pins PC1 and PC2 used for interrupt flags. This chip cannot be disconnected or disabled and it is difficult to remove; care must be taken to avoid its interference on the used pins.
24 24
 
@@ -26,15 +26,7 @@ An accelerometer \gls{IC} L3GD20 is fitted on the board, attached to SPI2 on pin
26 26
 
27 27
 GEX Hub was the first custom \gls{PCB} designed for GEX. It uses the same microcontroller as the Discovery board, thus the firmware modifications needed to make it work with this new platform were minimal. The schematic diagram is attached in \hyperref[apx:gex_hub]{Appendix A}.
28 28
 
29
-The Hub board provides access to all the \gls{GPIO} pins\footnote{With the exception of pins used by USB and the Lock button.} through three flat-cable connectors, one for each port; they also contain a ground and power supply connection to make the attachment of external boards or a breadboard easier, requiring just one cable. The use of flat cables, however, is not mandatory---the flat cable connectors are based on the standard 2.54\,mm-pitch pin headers, allowing the user to use widely available ``jumper wires''.
30
-
31
-\subsection{GEX Hub Errata}
32
-
33
-The first revision of the Hub board (\cref{fig:gexhub1}) proved functional and helped us validate the power supply design, but contained one layout error that had to be manually fixed (the boot jumper and the programming header footprints, on the left side of the board, had too fine pitch and could not be populated).
34
-
35
-The second, updated revision of the board (\cref{fig:gexhub2}) removes the two problematic footprints altogether; a reorganization in the \gls{GPIO} connectors allowed them to be moved together with the other pins. The Boot jumper was meant to be closed during normal operation, to avoid it getting lost. Since revision 2 moved the boot pin into the top connector, this had to be changed; the jumper logic was inverted by changing its pull-up resistor to a pull-down. The bootloader is now activated by inserting a jumper into the connector, shorting the Boot pin (labeled ``B'') to the adjacent 3.3\,V pin.
36
-
37
-A restart is required, in all cases, for the boot jumper changes to take effect. Revision 2 adds a flat reset button on the back side of the board for this purpose, so the \gls{USB} cable no longer needs to be re-connected to reset the \gls{MCU} in order to flash a new firmware version.
29
+The Hub board provides access to all the \gls{GPIO} pins\footnote{With the exception of pins used by USB and the Lock button.} through three flat-cable connectors (IDC), one for each port; they also contain a ground and power supply connection to make the attachment of external boards or a breadboard easier, requiring just one cable. The use of flat cables, however, is not mandatory---the flat cable connectors are based on the standard 2.54\,mm-pitch pin headers, allowing the user to use widely available ``jumper wires''.
38 30
 
39 31
 \begin{figure}[h]
40 32
 	\centering
@@ -51,6 +43,18 @@ A restart is required, in all cases, for the boot jumper changes to take effect.
51 43
 	\caption[The GEX Hub module]{\label{fig:gexhub} Two revisions of the GEX Hub module, rev. 2 shown with the boot jumper and one flat cable.}
52 44
 \end{figure}
53 45
 
46
+\subsection{GEX Hub Errata}
47
+
48
+The first revision of the Hub board (\cref{fig:gexhub1}) proved functional and helped us validate the power supply design and test the firmware, but contained one layout error that had to be manually fixed---the boot jumper and the programming header footprints, on the left side of the board, had too fine pitch and could not be populated.
49
+
50
+An updated revision 2 of the board (\cref{fig:gexhub2}), manufactured together with the GEX Zero \glspl{PCB} (\cref{sec:gzero}), removes the two problematic footprints altogether; a reorganization in the \gls{GPIO} connectors allowed them to be moved together with the other pins. 
51
+
52
+The Boot jumper was meant to be closed during normal operation, to avoid it getting lost. Since revision 2 moved the boot pin into the top connector, this had to be changed; the jumper logic was inverted by changing its pull-up resistor to a pull-down. The bootloader is now activated by inserting a jumper into the connector, shorting the Boot pin (labeled ``B'') to the adjacent 3.3\,V pin.
53
+
54
+A restart is required, in all cases, for the boot jumper changes to take effect. Revision 2 adds a flat reset button on the back side of the board for this purpose, making the firmware update process more straightforward.
55
+
56
+\section{GEX Zero}\label{sec:gzero}
57
+
54 58
 \begin{figure}[h]
55 59
 	\centering
56 60
 	\includegraphics[width=.85\textwidth]{img/photo-zero-picase.jpg} \\
@@ -59,20 +63,18 @@ A restart is required, in all cases, for the boot jumper changes to take effect.
59 63
 	\caption[The GEX Zero module]{\label{fig:gexzcases}GEX Zero in the official Raspberry Pi Zero case and an aftermarket acrylic case}
60 64
 \end{figure}
61 65
 
62
-\section{GEX Zero}
63
-
64
-Our desire to re-use the form factor of the Raspberry Pi (RPi) Zero to exploit the existing accessory market has been mentioned already in \cref{sec:formfactors}. It was brought to fruition with GEX Zero, the second realized GEX prototype. Its design involved several challenges given by constraints imposed by this form factor:
66
+Our desire to re-use the form factor of the Raspberry Pi (RPi) Zero to exploit the existing accessory market has been mentioned already in \cref{sec:formfactors}. It was brought to fruition with GEX Zero, the second realized GEX prototype (\cref{fig:gexzcases}). Its design involved several challenges given by constraints imposed by this form factor:
65 67
 
66 68
 \begin{itemize}
67
-	\item It must be a one-sided board, with no components on the bottom; this is needed for acrylic cases which sit flatly against the \gls{PCB}, with a cut-out for the pin header.
68
-	\item Buttons and the USB connector have to exactly align with connectors on the RPi Zero to fit the openings in its cases.
69
-	\item The board size is fixed, and rather small; we used only two layers to save production cost, but this proved a significant challenge when routing connections to the pin header.
70
-	\item To make use of the Raspberry Pi add-on boards, called HATs or pHATs, a particular organization of the pin header is required. We discuss this in more detail below.
69
+	\item It had to be a one-sided board, with no components on the bottom; this is needed for acrylic cases which sit flatly against the \gls{PCB}, with a cut-out for the pin header.
70
+	\item Buttons and the USB connector had to exactly align with connectors on the RPi Zero to fit the openings in its cases.
71
+	\item The board size was fixed, and rather small; we used only two layers to save production cost, but this proved a significant challenge when routing connections to the pin header.
72
+	\item To make use of the Raspberry Pi add-on boards, called HATs or pHATs, a particular organization of the pin header was required. We'll discuss this in more detail below.
71 73
 \end{itemize}
72 74
 
73 75
 \subsection{Pin Assignment}
74 76
 
75
-Like our STM32 microcontroller, the Broadcom processor on the RPi multiplexes its \gls{GPIO} pins with alternate functions, and, likewise, each function is available only on a small selection of pins. The usual alternate function assignments of the RPi \gls{GPIO} header can be found in~\cite{piheader} and~\cite{piheaderxyz}, and are reproduced in \cref{tbl:pi_assignmenets}.
77
+Like our STM32 microcontroller, the Broadcom processor on the RPi multiplexes its \gls{GPIO} pins with alternate functions, and, likewise, each function is available only on a small selection of pins. The usual alternate function assignments of the RPi \gls{GPIO} header can be found in~\cite{piheader} and~\cite{piheaderxyz}.
76 78
 
77 79
 \begin{figure}[h]
78 80
 	\centering
@@ -82,6 +84,7 @@ Like our STM32 microcontroller, the Broadcom processor on the RPi multiplexes it
82 84
 	\caption[GEX Zero back side]{\label{fig:gexz}Pin assignment diagram on the back side of GEX Zero}
83 85
 \end{figure}
84 86
 
87
+\iffalse
85 88
 {
86 89
 	\def\ptcw{.07\textwidth}
87 90
 	\def\rpnl{\newline \footnotesize}
@@ -240,77 +243,77 @@ Like our STM32 microcontroller, the Broadcom processor on the RPi multiplexes it
240 243
 		\caption[Raspberry Pi GPIO header]{\label{tbl:pi_assignmenets}Raspberry Pi GPIO header (split into two lines), top view of the board, oriented with the USB connectors facing away from the user. ``$\ast$''~marks pins without important alternate functions.}
241 244
 	\end{table}
242 245
 }
243
-
244
-The GEX Zero pin header's alternate functions should match those on the RPi Zero header, so that the existing add-on boards can be used without modifications. By inspecting the alternate function tables in the STM32F072 datasheet~\cite{f072-ds}, we found a layout that fulfills this requirement almost perfectly. The final assignment is shown in \cref{tbl:gz_rpi_compare}, and the full schematic diagram is attached in \hyperref[apx:gex_zero]{Appendix B}.
245
-
246
-\gls{GPIO} ports A and B are fully exposed in the header, with the exception of pins PA11 and PA12 that are routed to the USB connector. The remaining positions were filled pith pins from port C. The omitted ``ID \IIC'' port on pins 27 and 28 is used by the RPi Zero to read configuration from an EEPROM chip on some add-on boards. As this is the only use of the \IIC port, its lack is not a big limitation.
247
-
248
-
249
-\begin{table}[h]
250
-	  \begin{tabularx}{\textwidth}{W{.1\textwidth}XX|W{.1\textwidth}XX}
251
-	    	\toprule
252
-	    	\textbf{Pin} & \textbf{RPi} & \textbf{GEX Zero} &
253
-	    	\textbf{Pin} & \textbf{RPi} & \textbf{GEX Zero} \\
254
-	    	
255
-	    	\midrule
256
-	    	\textbf{1} & \leavevmode\color{red}3.3\,V & -- &
257
-	    	\textbf{2} & \leavevmode\color{red}5\,V & -- \\
258
-	    	\textbf{3} & \IIC SDA & PB7 (SDA1) & 
259
-	    	\textbf{4} & \leavevmode\color{red}5\,V & -- \\
260
-	    	\textbf{5} & \IIC SCL & PB6 (SCL1) & 
261
-	    	\textbf{6} & \leavevmode\color{blue}GND & -- \\
262
-	    	\textbf{7} & $\ast$ & PA8 (MCO) & 
263
-	    	\textbf{8} & UART TX & PB10 (TX3) \\
264
-	    	
265
-	    	\midrule
266
-	    	\textbf{9} & \leavevmode\color{blue}GND & --
267
-	    	& \textbf{10} & UART RX & PB11 (RX3) \\
268
-	    	\textbf{11} & UART RTS & PB1 (RTS3)
269
-	    	& \textbf{12} & PWM & PB8 \\
270
-	    	\textbf{13} & $\ast$ & PA10 
271
-	    	& \textbf{14} & \leavevmode\color{blue}GND & -- \\
272
-	    	\textbf{15} & $\ast$ & PB9
273
-	    	& \textbf{16} &  $\ast$ & PA0 (FCAP)\\
274
-	    	
275
-	    	\midrule
276
-	    	\textbf{17} & \leavevmode\color{red}3.3\,V & --
277
-	    	& \textbf{18} &  $\ast$ & PA1 \\
278
-	    	\textbf{19} & SPI MOSI & PB5 (MOSI1)
279
-	    	& \textbf{20} & \leavevmode\color{blue}GND & -- \\
280
-	    	\textbf{21} & SPI MISO & PB4 (MISO1)
281
-	    	& \textbf{22} &  $\ast$ & PA2 (TX2) \\
282
-	    	\textbf{23} & SPI SCK & PB3 (SCK1)
283
-	    	& \textbf{24} &  $\ast$ & PA3 (RX2) \\
284
-	    	
285
-	    	\midrule
286
-	    	\textbf{25} & \leavevmode\color{blue}GND & --
287
-	    	& \textbf{26} &  $\ast$ & PA4 (DAC$_1$) \\
288
-	    	\textbf{27} & ID \IIC SDA & PB2 
289
-	    	& \textbf{28} & ID \IIC SCL & PA5 (DAC$_2$) \\
290
-	    	\textbf{29} & $\ast$ & PC10 (TX4)
291
-	    	& \textbf{30} & \leavevmode\color{blue}GND & -- \\
292
-	    	\textbf{31} & $\ast$ & PC11 (RX4)
293
-	    	& \textbf{32} & PWM & PA7 \\
294
-	    	
295
-	    	\midrule
296
-	    	\textbf{33} & PWM & PB0 
297
-	    	& \textbf{34} & \leavevmode\color{blue}GND & -- \\
298
-	    	\textbf{35} & SPI MISO & PB14~(MISO2)
299
-	    	& \textbf{36} &  $\ast$ & PA6 (CTS3) \\
300
-	    	\textbf{37} & $\ast$ & PB12
301
-	    	& \textbf{38} & SPI MOSI & PB15~(MOSI2)\\
302
-	    	\textbf{39} & \leavevmode\color{blue}GND & -- 
303
-	    	& \textbf{40} & SPI SCK & PB13 (SCK2)\\
304
-	    	\bottomrule 
305
-	    \end{tabularx}
246
+\fi
247
+
248
+The GEX Zero pin header's alternate functions had to match those on the RPi Zero header, so that the existing add-on boards can be used without modifications. By inspecting the alternate function tables in the STM32F072 datasheet~\cite{f072-ds}, we found a layout that fulfills this requirement almost perfectly. The final assignment is shown in \cref{tbl:gz_rpi_compare}, and the full schematic diagram is attached in \hyperref[apx:gex_zero]{Appendix B}.
249
+
250
+\begin{table}
251
+	\begin{tabularx}{\textwidth}{W{.1\textwidth}XX|W{.1\textwidth}XX}
252
+		\toprule
253
+		\textbf{Pin} & \textbf{RPi} & \textbf{GEX Zero} &
254
+		\textbf{Pin} & \textbf{RPi} & \textbf{GEX Zero} \\
255
+		
256
+		\midrule
257
+		\textbf{1} & \leavevmode\color{red}3.3\,V & -- &
258
+		\textbf{2} & \leavevmode\color{red}5\,V & -- \\
259
+		\textbf{3} & \IIC SDA & PB7 (SDA1) & 
260
+		\textbf{4} & \leavevmode\color{red}5\,V & -- \\
261
+		\textbf{5} & \IIC SCL & PB6 (SCL1) & 
262
+		\textbf{6} & \leavevmode\color{blue}GND & -- \\
263
+		\textbf{7} & $\ast$ & PA8 (MCO) & 
264
+		\textbf{8} & UART TX & PB10 (TX3) \\
265
+		
266
+		\midrule
267
+		\textbf{9} & \leavevmode\color{blue}GND & --
268
+		& \textbf{10} & UART RX & PB11 (RX3) \\
269
+		\textbf{11} & UART RTS & PB1 (RTS3)
270
+		& \textbf{12} & PWM & PB8 \\
271
+		\textbf{13} & $\ast$ & PA10 
272
+		& \textbf{14} & \leavevmode\color{blue}GND & -- \\
273
+		\textbf{15} & $\ast$ & PB9
274
+		& \textbf{16} &  $\ast$ & PA0 (FCAP)\\
275
+		
276
+		\midrule
277
+		\textbf{17} & \leavevmode\color{red}3.3\,V & --
278
+		& \textbf{18} &  $\ast$ & PA1 \\
279
+		\textbf{19} & SPI MOSI & PB5 (MOSI1)
280
+		& \textbf{20} & \leavevmode\color{blue}GND & -- \\
281
+		\textbf{21} & SPI MISO & PB4 (MISO1)
282
+		& \textbf{22} &  $\ast$ & PA2 (TX2) \\
283
+		\textbf{23} & SPI SCK & PB3 (SCK1)
284
+		& \textbf{24} &  $\ast$ & PA3 (RX2) \\
285
+		
286
+		\midrule
287
+		\textbf{25} & \leavevmode\color{blue}GND & --
288
+		& \textbf{26} &  $\ast$ & PA4 (DAC$_1$) \\
289
+		\textbf{27} & ID \IIC SDA & PB2 
290
+		& \textbf{28} & ID \IIC SCL & PA5 (DAC$_2$) \\
291
+		\textbf{29} & $\ast$ & PC10 (TX4)
292
+		& \textbf{30} & \leavevmode\color{blue}GND & -- \\
293
+		\textbf{31} & $\ast$ & PC11 (RX4)
294
+		& \textbf{32} & PWM & PA7 \\
295
+		
296
+		\midrule
297
+		\textbf{33} & PWM & PB0 
298
+		& \textbf{34} & \leavevmode\color{blue}GND & -- \\
299
+		\textbf{35} & SPI MISO & PB14~(MISO2)
300
+		& \textbf{36} &  $\ast$ & PA6 (CTS3) \\
301
+		\textbf{37} & $\ast$ & PB12
302
+		& \textbf{38} & SPI MOSI & PB15~(MOSI2)\\
303
+		\textbf{39} & \leavevmode\color{blue}GND & -- 
304
+		& \textbf{40} & SPI SCK & PB13 (SCK2)\\
305
+		\bottomrule 
306
+	\end{tabularx}
306 307
 	\caption[Comparison of the RPI Zero and GEX Zero GPIO headers]{\label{tbl:gz_rpi_compare}
307
-		Comparison of the RPI Zero and GEX Zero GPIO header pin assignments. Names in parentheses represent STM32F072 alternate functions (e.g., MISO1 is the MISO pin of the SPI peripheral 1). ``$\ast$''~marks pins without important alternate functions that could be assigned arbitrarily in the GEX Zero header. All power pins are identical in both headers.
308
+		Comparison of the RPi Zero and GEX Zero GPIO header pin assignments. Names in parentheses represent STM32F072 alternate functions (e.g., MISO1 is MISO of the first SPI peripheral). ``$\ast$''~marks pins without important alternate functions that could be assigned arbitrarily in the GEX Zero header. All power pins are identical in both headers.
308 309
 	}
309 310
 \end{table}
310 311
 
312
+\gls{GPIO} ports A and B are fully exposed in the header, with the exception of pins PA11 and PA12 that are routed to the USB connector. The remaining positions were filled pith pins from port C. The omitted ``ID \IIC'' port on pins 27 and 28 is used by the RPi Zero to read configuration from an EEPROM chip on some add-on boards. As this is the only use of the \IIC port, its lack is not a big limitation.
313
+
311 314
 \section{GEX Zero Errata}
312 315
 
313
-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.
316
+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:
314 317
 
315 318
 \begin{itemize}[itemsep=0pt]
316 319
 	\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.
@@ -319,7 +322,7 @@ Unfortunately, neither the GEX Zero \gls{PCB} was flawless in the first revision
319 322
 
320 323
 \section{Wireless Gateway} \label{sec:rfgateway}
321 324
 
322
-The wireless gateway was designed as a ``\gls{USB} dongle'', using the \gls{USB} type A connector (\cref{fig:gwxgw}). It is fitted with a STM32F103 microcontroller, selected for its low cost and availability in small packages (in this case LQFP48). The nRF24L01+ module is partly sticking outside the board outline, allowing the \gls{PCB} to be smaller (and thus cheaper to manufacture), while reducing interference between components and copper plating on the board and the antenna. The schematic diagram of the wireless gateway is attached in \hyperref[apx:gex_wgw]{Appendix C}.
325
+The wireless gateway was designed as a ``\gls{USB} dongle'', using the \gls{USB} type A connector (\cref{fig:gwxgw}). It is fitted with an STM32F103 microcontroller, selected for its low cost and availability in small packages (in this case LQFP48). The nRF24L01+ module is partly sticking outside the board outline, allowing the \gls{PCB} to be smaller (and thus cheaper to manufacture), while reducing interference between components and copper plating on the board and the antenna. The schematic diagram of the wireless gateway is attached in \hyperref[apx:gex_wgw]{Appendix C}.
323 326
 
324 327
 Beyond the use with GEX, the gateway is a versatile tool which could be programmed with a different firmware and serve other purposes, e.g., as a wireless connection between two computers, to scan the radio spectrum for interference in order to find a clear channel, or to communicate with other devices that use the nRF24L01+ transceiver. The chosen microcontroller, unfortunately, does not include a USB bootloader, so a SWD programmer is required to change the firmware; SWD is routed to the pin header next to the wireless module.
325 328
 

+ 10 - 2
ch.hw_buses.tex View File

@@ -95,7 +95,7 @@ The bus supports multi-master operation, which leads to the problem of collision
95 95
 
96 96
 \section{1-Wire} \label{sec:theory_1wire}
97 97
 
98
-The 1-Wire bus, developed by Dallas Semiconductor (acquired by Maxim Integrated), uses a single, bi-directional data line, which can also power the slave devices in a \textit{parasitic mode}, reducing the number of required wires to just two (compare with 3 in \gls{I2C} and 5 in \gls{SPI}, all including \gls{GND}). The parasitic operation is possible thanks to the data line resting at a high logic level most of the time, charging an internal capacitor.
98
+The 1-Wire bus, developed by Dallas Semiconductor (acquired by Maxim Integrated), uses a single, bi-directional data line (\cref{fig:1w_topology}), which can also power the slave devices in a \textit{parasitic mode}, reducing the number of required wires to just two (compare with 3 in \gls{I2C} and 5 in \gls{SPI}, all including \gls{GND}). The parasitic operation is possible thanks to the data line resting at a high logic level most of the time, charging an internal capacitor.
99 99
 
100 100
 1-Wire uses an open-drain connection for the data line, similar to \gls{I2C}, though the protocol demands it to be connected directly to V$_dd$ in some places when the parasitic mode is used; this is accomplished using an external transistor, or by reconfiguring the GPIO pin as output and setting it to 1, provided the microcontroller is able to supply a sufficient current.
101 101
 
@@ -130,17 +130,25 @@ Since 1-Wire is a proprietary protocol, there is a much smaller choice of availa
130 130
 
131 131
 \section{NeoPixel} \label{sec:theory_neo}
132 132
 
133
-NeoPixel is a marketing name of the \textbf{WS2812} and compatible intelligent \gls{LED} drivers that are commonly used in ``addressable \gls{LED} strips''. Additional technical details about the chips and their protocol may be found in the WS2812B datasheet~\cite{neopixel-ds}. These chips include the control logic, PWM drivers and the \gls{LED} diodes all in one 5$\times$5\,mm SMD package.
133
+NeoPixel is a marketing name of the \textbf{WS2812} and compatible intelligent \gls{LED} drivers that are commonly used in ``addressable \gls{LED} strips'' (\cref{fig:neopic}).  These chips include the control logic, PWM drivers and the \gls{LED} diodes all in one 5$\times$5\,mm SMD package.
134 134
 
135 135
 The NeoPixel protocol is unidirectional, using only one data pin. The \gls{LED} drivers are chained together. Ones and zeros are encoded by pulses of a defined length on the data pin; after the color data was loaded into the \gls{LED} string, a longer ``reset'' pulse (low level) is issued by the bus master and the set colors are displayed. The timing constraints are listed in \cref{fig:ws2812_dia}.
136 136
 
137 137
 The NeoPixel timing is sensitive to pulse length accuracy; a deviation from the specified timing may cause the data to be misinterpreted by the drivers. Some ways to implement the timing use hardware timers or the \gls{I2S} peripheral. An easier method that does not require any additional hardware resources beyond the \gls{GPIO} pin is to implement the timing using delay loops in the firmware; care must be taken to disable interrupts in the sensitive parts of the timing; it may be advantageous to implement it in assembly for a tighter control.
138 138
 
139
+\iffalse
139 140
 \begin{figure}[h]
140 141
 	\centering
141 142
 	\includegraphics[width=.5\textwidth] {img/ws2812b-detail.jpg}
142 143
 	\caption{\label{fig:ws2812_detail}A close-up photo of a WS2812B pixel, showing the LED driver IC}
143 144
 \end{figure}
145
+\fi
146
+
147
+\begin{figure}[h]
148
+	\centering
149
+	\includegraphics[width=.7\textwidth] {img/npxdriven.jpg}
150
+	\caption{\label{fig:neopic}GEX prototype driving a strip of 5 NeoPixels}
151
+\end{figure}
144 152
 
145 153
 \begin{table}[h]
146 154
 	\centering

+ 1 - 1
ch.hw_functions.tex View File

@@ -139,7 +139,7 @@ Capacitive sensing is a sequential process described in the following steps:
139 139
 
140 140
 \begin{enumerate}
141 141
 	\item The sampling capacitor is discharged by connecting its free end to \gls{GND}.
142
-	\item The sensing pad is connected to V$_\mathrm{dd}$ (+3.3\,V) and, acting as a capacitor, charged to this voltage. It stores a small amount of charge, depending on its capacitance---this is the variable property we are trying to measure.
142
+	\item The sensing pad is connected to V$_\mathrm{DD}$ (+3.3\,V) and, acting as a capacitor, charged to this voltage. It stores a small amount of charge, depending on its capacitance---this is the variable property we are trying to measure.
143 143
 	\item The free terminals of the two capacitors (the sensing pad and the sampling capacitor) are connected together and their voltages reach an equilibrium as a portion of the stored charge leaves the sensing pad and flows into the bigger capacitor.
144 144
 	\item The steps (2) and (3) are repeated until the sampling capacitor's voltage exceeds a fixed threshold (set to a half of the supply voltage). The number of cycles needed to charge the sampling capacitor corresponds to the capacitance of the sensing pad.
145 145
 \end{enumerate}

+ 2 - 2
ch.introduction.tex View File

@@ -2,12 +2,12 @@
2 2
 
3 3
 Prototyping, design evaluation, and the measurement of physical properties in experiments make a daily occurrence in the engineering praxis. Those tasks often involve the generation and sampling of electrical signals coming to and from sensors, actuators, and other circuitry.
4 4
 
5
-Recently, a wide range of intelligent sensors became available thanks to the drive to miniaturization in the consumer electronics industry. Those devices often provide sufficient accuracy and precision while keeping the circuit complexity and cost low. In contrast to analog sensors, here the signal conditioning and processing circuits are built into the sensor itself, and we access it using a digital connection.
5
+Recently, a wide range of intelligent sensors became available thanks to the drive to miniaturization in the consumer electronics industry (\cref{fig:some_sensors}). Those devices often provide sufficient accuracy and precision while keeping the circuit complexity and cost low. In contrast to analog sensors, here the signal conditioning and processing circuits are built into the sensor itself, and we access it using a digital connection.
6 6
 
7 7
 \begin{figure}[H]
8 8
 	\centering
9 9
 	\includegraphics[width=0.8\textwidth] {img/inteligent-sensors.jpg}
10
-	\caption[A collection of intelligent sensors and devices]{A collection of intelligent sensors and devices, most on breadboard adapters: (from the top left) a waveform generator, a gesture detector, a LoRa and two Bluetooth modules, an air quality and pressure sensor, a CO$_2$ sensor, a digital compass, an accelerometer, a GPS module, a camera, an ultrasonic range finder, a humidity sensor, a 1-Wire thermometer, a color detector, and an RGB LED strip}
10
+	\caption[A collection of intelligent sensors and devices]{\label{fig:some_sensors}A collection of intelligent sensors and devices, most on breadboard adapters: (from the top left) a waveform generator, a gesture detector, a LoRa and two Bluetooth modules, an air quality and pressure sensor, a CO$_2$ sensor, a digital compass, an accelerometer, a GPS module, a camera, an ultrasonic range finder, a humidity sensor, a 1-Wire thermometer, a color detector, and an RGB LED strip}
11 11
 \end{figure}
12 12
 
13 13
 If we wish to conduct experiments with those integrated modules, or just familiarize ourselves with a device before using it in a project, we need an easy way to interact with them. It would also be convenient to have direct access to low-level hardware, be it analog signal sampling, generation, or even just the access to logic inputs and outputs. However, advances in computer technology, namely the advent of the \gls{USB}, lead to the disappearance of low-level computer ports, such as the printer port (LPT), that would provide an easy way of doing so.

+ 1 - 1
ch.requirement_analysis.tex View File

@@ -90,7 +90,7 @@ To effectively utilize the time available for this work, only the STM32F072 firm
90 90
 
91 91
 \section{Form Factor Considerations} \label{sec:formfactors}
92 92
 
93
-While the GEX firmware can be used with existing evaluation boards from ST Microelectronics (see \cref{fig:discovery} for an example of one such board), we wish to design and realize a few custom hardware prototypes that will be smaller and more convenient to use.
93
+While the GEX firmware can be used with existing evaluation boards from ST Microelectronics (\cref{fig:discovery}), we wish to design and realize a few custom hardware prototypes that will be smaller and more convenient to use.
94 94
 
95 95
 Three possible form factors are drawn in \cref{fig:ff_sketches}. The use of a common connector layout and pin assignments, here Arduino and Raspberry Pi, makes it possible to reuse add-on boards from those platforms. When we copy the physical form factor of another product, in this example the Raspberry Pi Zero, we can further take advantage of existing enclosures designed for it.
96 96
 

+ 2 - 2
ch.source_and_porting.tex View File

@@ -1,6 +1,6 @@
1 1
 \chapter{Working with the GEX Source Code}
2 2
 
3
-\begin{wrapfigure}[21]{r}{0.4\textwidth}
3
+\begin{wrapfigure}[20]{r}{0.4\textwidth}
4 4
 	\scriptsize\vspace{-3em}
5 5
 	\begin{verbatim}
6 6
 ├── build
@@ -33,7 +33,7 @@
33 33
 └── Makefile
34 34
 	\end{verbatim}
35 35
 	\vspace{-1em}
36
-	\caption{\label{fig:repo_structure} The general structure of the source code repository}
36
+	\caption{\label{fig:repo_structure} General structure of the source code repository}
37 37
 \end{wrapfigure}
38 38
 
39 39
 Understanding the GEX source code layout is important before attempting to implement any changes or to port it to a different microcontroller type. The directory layout is shown in \cref{fig:repo_structure}. 

+ 1 - 1
ch.tinyframe.tex View File

@@ -136,7 +136,7 @@ A read or write transaction can be aborted by a frame \CmdBulkAbort at any time,
136 136
 \begin{figure}
137 137
 	\centering
138 138
 	\includegraphics[scale=1.5]{img/bulk-read-write.pdf}
139
-	\caption{\label{fig:bulk_rw}A diagram of the bulk read and write transaction.}
139
+	\caption{\label{fig:bulk_rw}The bulk read and write transactions}
140 140
 \end{figure}
141 141
 
142 142
 \subsection{Bulk Read}

+ 22 - 10
ch.unit.adc.tex View File

@@ -1,10 +1,22 @@
1 1
 \section{ADC Unit}
2 2
 
3
-The analog/digital converter unit is one of the most complicated and powerful units implemented in the project. The unit can measure the voltage on an input pin, either as its immediate value, or averaged with exponential forgetting. Isochronous sampling is available as well: it is possible to capture a fixed-length block of data on demand, or as a response to a triggering condition on any of the enabled input pins. The \gls{ADC} must continuously sample the inputs to make the averaging and level based triggering possible; as a consequence, a pre-trigger buffer is available that can be read together with the block of samples following a trigger. The \gls{ADC} unit can also be switched to a continuous streaming mode, a block capture which continues indefinitely, until the host decides to stop the stream.
3
+The analog/digital converter unit is one of the most complicated and powerful units implemented in the project.
4 4
 
5
-It is possible to activate any number of the 16 analog inputs of the \gls{ADC} peripheral simultaneously, together with the internal input channels. The maximum continuous sampling frequency, which reaches 70\,ksps with one channel, lowers with an increasing number of enabled channels, as the amount of data to transfer host increases. Those high speeds are achievable in shorter block captures, taking advantage of the (configurable) data buffer. A streamed or too long block capture may be aborted after the buffer is exhausted.
5
+The unit can measure the voltage on an input pin, either as its immediate value, or averaged with exponential forgetting. The smoothing formula is ($y$--averaged output, $t$--sample number, $k$--smoothing factor, $u$--raw measured value):
6 6
 
7
-\todo[inline]{add a diagram}
7
+\begin{equation}
8
+	y[t] = (1-k)\cdot y[t-1] + k\cdot u[t]
9
+\end{equation}
10
+
11
+Isochronous sampling is available as well: it is possible to capture a fixed-length block of data on demand, or as a response to a triggering condition on any of the enabled input pins. The \gls{ADC} must continuously sample the inputs to make the averaging and level based triggering possible, which is implemented using \gls{DMA}; as a consequence, a pre-trigger buffer is available that can be read together with the block of samples following a trigger (\cref{fig:adc_dma}). The \gls{ADC} unit can also be switched to a continuous streaming mode, a block capture which continues indefinitely, until the host decides to stop the stream.
12
+
13
+It is possible to activate any number of the 16 analog inputs of the \gls{ADC} peripheral simultaneously, together with the internal input channels. The maximum continuous sampling frequency, which reaches 70\,ksps with one channel, lowers with an increasing number of enabled channels, as the amount of data to transfer host increases. Those high speeds are achievable in shorter block captures, taking advantage of the (configurable) data buffer. An ongoing capture may be terminated by the unit after the buffer is exhausted.
14
+
15
+\begin{figure}[h]
16
+	\centering
17
+	\includegraphics[scale=1]{img/adc-dma-buf.pdf}
18
+	\caption{\label{fig:adc_dma}Principle of DMA-based ADC sampling. The buffer is continually filled with new samples; when the triggering condition is hit, the historical records from the buffer are sent as a pre-trigger buffer, and a block capture begins. The following samples are sent to the host when either half of the buffer is filled, or the required number of samples have been sent. The sampling never stops, ensuring a pre-trigger buffer is always ready.}
19
+\end{figure}
8 20
 
9 21
 \subsection{ADC Configuration}
10 22
 
@@ -44,7 +56,7 @@ avg_factor=500
44 56
 	&
45 57
 	\begin{cmdpld}
46 58
 		\cfield{u32} pre-trigger length
47
-		\cfield{u8} triggering edge (1-falling, 2-rising, 3-forced)
59
+		\cfield{u8} triggering edge (1--falling, 2--rising, 3--forced)
48 60
 		\cfield{u8} stream serial number
49 61
 		\cfield{u16[]} pre-trigger data
50 62
 	\end{cmdpld}
@@ -123,16 +135,16 @@ avg_factor=500
123 135
 
124 136
 	20 &
125 137
 	\cname{SETUP\_TRIGGER}
126
-	Configure the triggering level and other trigger parameters. This command does \textit{not} arm the trigger!
138
+	Configure the triggering level and other trigger parameters. This command does \textit{not} arm the trigger.
127 139
 	&
128 140
 	\begin{cmdreq}
129 141
 		\cfield{u8} source channel number
130 142
 		\cfield{u16} triggering level
131
-		\cfield{u8} active edge (1-falling, 2-rising, 3-any)
143
+		\cfield{u8} active edge (1--falling, 2--rising, 3--any)
132 144
 		\cfield{u32} pre-trigger sample count
133 145
 		\cfield{u32} post-trigger sample count
134 146
 		\cfield{u16} hold-off time (ms)
135
-		\cfield{u8} auto re-arm (0,1)
147
+		\cfield{bool} auto re-arm
136 148
 	\end{cmdreq}
137 149
 	\\
138 150
 
@@ -140,7 +152,7 @@ avg_factor=500
140 152
 	Arm the trigger for capture.
141 153
 	&
142 154
 	\begin{cmdreq}
143
-		\cfield{u8} auto re-arm (0, 1, 255-no change)
155
+		\cfield{u8} auto re-arm (0, 1, 255--no change)
144 156
 	\end{cmdreq}
145 157
 	\\
146 158
 
@@ -173,10 +185,10 @@ avg_factor=500
173 185
 	& \\
174 186
 
175 187
 	28 & \cname{SET\_SMOOTHING\_FACTOR}
176
-	Set the smoothing factor ($\times10^3$). %TODO add the formula
188
+	Set the smoothing factor ($\times10^3$). 1000 corresponds to $k=1$.
177 189
 	&
178 190
 	\begin{cmdreq}
179
-		\cfield{u16} smoothing factor 0-1000
191
+		\cfield{u16} smoothing factor 0--1000
180 192
 	\end{cmdreq}
181 193
     \\
182 194
 

+ 1 - 1
ch.unit.do.tex View File

@@ -45,7 +45,7 @@ open-drain=
45 45
 	& \begin{cmdreq}
46 46
 		\cfield{u16} pins to pulse
47 47
 		\cfield{bool} active level
48
-		\cfield{u8} scale: 0-ms, 1-$\mu$s
48
+		\cfield{u8} scale: 0--ms, 1--$\mu$s
49 49
 		\cfield{u16} duration
50 50
 	\end{cmdreq}
51 51
 

+ 3 - 3
ch.unit.fcap.tex View File

@@ -103,7 +103,7 @@ Some commands include optional parameter setting. Using 0 in the field keeps the
103 103
 	5 & \cname{FREECOUNT\_START}
104 104
 	Clear and start the pulse counter
105 105
 	& \begin{cmdreq}
106
-		\cfield{u8} *prescaller (1,2,4,8)
106
+		\cfield{u8} *prescaller (1, 2, 4, 8)
107 107
 	\end{cmdreq} \\
108 108
 
109 109
 	6 & \cname{MEASURE\_SINGLE\_PULSE}
@@ -150,13 +150,13 @@ Some commands include optional parameter setting. Using 0 in the field keeps the
150 150
 	21 & \cname{SET\_PRESCALLER}
151 151
 	Set prescaller for the direct mode
152 152
 	& \begin{cmdresp}
153
-		\cfield{u8} prescaller (1,2,4,8)
153
+		\cfield{u8} prescaller (1, 2, 4, 8)
154 154
 	\end{cmdresp} \\
155 155
 
156 156
 	22 & \cname{SET\_INPUT\_FILTER}
157 157
 	Set input filtering (a hardware feature designed to ignore glitches)
158 158
 	& \begin{cmdresp}
159
-		\cfield{u8} filtering factor (0-15, 0=off)
159
+		\cfield{u8} filtering factor (0--15, 0=off)
160 160
 	\end{cmdresp} \\
161 161
 
162 162
 	23 & \cname{SET\_DIR\_MSEC}

+ 1 - 2
ch.unit.touch.tex View File

@@ -39,7 +39,7 @@ g2_ch=
39 39
 # ...
40 40
 \end{inicode}
41 41
 
42
-
42
+\newpage
43 43
 \subsection{Touch Sense Events}
44 44
 
45 45
 \begin{cmdlist}
@@ -51,7 +51,6 @@ g2_ch=
51 51
     \end{cmdpld} \\
52 52
 \end{cmdlist}
53 53
 
54
-%\newpage
55 54
 \subsection{Touch Sense Commands}
56 55
 
57 56
 \begin{cmdlist}

+ 6 - 2
ch.unit.usart.tex View File

@@ -4,9 +4,13 @@ The \gls{USART} unit provides access to one of the microcontroller's \gls{USART}
4 4
 
5 5
 Most \gls{USART} parameters available in the hardware peripheral's configuration registers can be adjusted to match the application's needs. The peripheral is capable of driving RS-485 transceivers, using the \gls{DE} output for switching between reception and transmission.
6 6
 
7
-The unit implements asynchronous reception and transmission with \gls{DMA} and a circular buffer. Received data is sent to the host in asynchronous events when a half of the buffer is filled, or after a fixed timeout from the last received byte. The write access is, likewise, implemented using \gls{DMA}.
7
+The unit implements asynchronous reception and transmission with \gls{DMA} and a circular buffer (\cref{fig:uart_rx_dma}). Received data is sent to the host in asynchronous events when a half of the buffer is filled, or after a fixed timeout from the last received byte. The write access is, likewise, implemented using a \gls{DMA} buffer.
8 8
 
9
-\todo[inline]{add a diagram of the dma-based reception}
9
+\begin{figure}[h]
10
+	\centering
11
+	\includegraphics[scale=1]{img/uart-dma.pdf}
12
+	\caption{\label{fig:uart_rx_dma}Principle of DMA-based UART reception. Interrupt is generated in the half and at the end of the buffer, at which point the write pointer wraps back to the beginning.}
13
+\end{figure}
10 14
 
11 15
 \subsection{USART Configuration}
12 16
 

+ 2 - 2
ch.usb.tex View File

@@ -10,11 +10,11 @@ This chapter presents an overview of the \acrfull{USB} Full Speed interface, wit
10 10
 	\caption[USB hierarchical structure]{\label{fig:usb_hierarchy}The hierarchical structure of the USB bus}
11 11
 \end{figure}
12 12
 
13
-\gls{USB} is a hierarchical bus with a single master (\textit{host}) and multiple slave devices. A \gls{USB} device that provides functionality to the host is called a \textit{function}~\cite{usb-function}.
13
+\gls{USB} is a hierarchical bus (\cref{fig:usb_hierarchy}) with a single master (\textit{host}) and multiple slave devices. A \gls{USB} device that provides functionality to the host is called a \textit{function}~\cite{usb-function}.
14 14
 
15 15
 \subsection{Pipes and Endpoints}
16 16
 
17
-Communication between the host and a function is organized into virtual channels called \textit{pipes} connecting to the device's \textit{endpoints}, identified by endpoint numbers.
17
+Communication between the host and a function is organized into virtual channels called \textit{pipes} connecting to the device's \textit{endpoints}, identified by endpoint numbers. Pipes and endpoints are a high level abstraction of the connection between the host and a device  (\cref{fig:usb_logical}).
18 18
 
19 19
 \begin{figure}[h]
20 20
 	\centering

+ 2 - 2
ch.wireless.tex View File

@@ -85,7 +85,7 @@ A pair of these radio modules can form a bidirectional data connection, function
85 85
 	\vspace{-1em}
86 86
 	\centering
87 87
 	\includegraphics[scale=0.9]{img/rf-gw.pdf}
88
-	\caption{A block diagram of the wireless connection}
88
+	\caption{Wireless connection block diagram}
89 89
 \end{wrapfigure}
90 90
 
91 91
 The gateway presents itself to the host as a \gls{CDCACM} device, much like the GEX modules themselves (here called \textit{nodes}) when connected over \gls{USB}. However, the standard GEX communication protocol cannot be used directly, as the gateway itself needs to be managed through the interface, and it can connect to more than one GEX module at once, necessitating an addressing scheme. This problem could be solved by adding a side channel, additional \gls{USB} endpoints, to interact with the gateway itself; that option was not explored further, but it is clear that it would compromise our ability to use the simple virtual COM port \gls{USB} driver. 
@@ -97,7 +97,7 @@ The gateway has a 4-byte \textit{network ID}, a number derived from the \gls{MCU
97 97
 
98 98
 The gateway protocol, when used to communicate with a node, encapsulates the raw binary data sent to or from connected nodes; the wrapped TinyFrame protocol remains unchanged.
99 99
 
100
-All messages sent to or from the gateway are a multiple of 64 bytes long, padded with zeros if shorter. A message starts with a control byte determining its type, as summarized in the following table listing the structure of all supported messages.
100
+All messages sent to or from the gateway are a multiple of 64 bytes long, padded with zeros if shorter. A message starts with a control byte determining its type, as summarized in the following table, listing the structure of all supported messages.
101 101
 
102 102
 \newpage
103 103
 {

+ 6 - 0
document_config.tex View File

@@ -109,3 +109,9 @@
109 109
 	\fancyhf[lef,rof]{\thepage}%
110 110
 }
111 111
 
112
+
113
+
114
+\usepackage{float}
115
+\floatstyle{plaintop}
116
+\restylefloat{table}
117
+\usepackage[tableposition=top]{caption}

BIN
img/adc-dma-buf.pdf View File


BIN
img/npxdriven.jpg View File


BIN
img/uart-dma.pdf View File


+ 7 - 0
thesis.bib View File

@@ -418,6 +418,13 @@
418 418
 	urldate = {2018-05-12}
419 419
 }
420 420
 
421
+@online{buspirate,
422
+	author = {Ian Lesnet},
423
+	title = {Bus Pirate},
424
+	url = {http://dangerousprototypes.com/docs/Bus_Pirate},
425
+	urldate = {2018-05-20}
426
+}
427
+
421 428
 @online{nidevice1,
422 429
 	author = {{National Instruments}},
423 430
 	title = {I²C/SPI Interface Device},

BIN
thesis.pdf View File