@ -79,7 +79,7 @@ Future development of the project should focus on expanding the number of suppor
The client libraries need to be tested on other operating systems, and the C library may be expanded to provide a higher level of comfort to the user. The client library could further be reimplemented in more programming languages, such as Java or \CS, and graphical applications could be developed to make GEX more approachable to users less familiar with programming.
The client libraries need to be tested on other operating systems, and the C library may be expanded to provide a higher level of comfort to the user. The client library could further be reimplemented in more programming languages, such as Java or \CS, and graphical applications could be developed to make GEX more approachable to users less familiar with programming.
GEX Zero, with the Raspberry Pi Zero form factor, introduced the possibility of using Raspberry Pi add-on boards. It would be interesting to test the compatibility with more such existing boards, and further to explore the possibility of designing custom ones. An add-on board could, for instance, add access to the \gls{DALI} bus, RS-485, \gls{CAN}, or Ethernet.
GEX Zero, with the Raspberry Pi Zero form factor, introduced the possibility of using Raspberry Pi add-on boards. It would be interesting to test the compatibility with more such existing boards, and further try designing custom ones. An add-on board could, for instance, add access to the \gls{DALI} bus, RS-485, \gls{CAN}, or Ethernet.
@ -72,7 +72,7 @@ This method of lightning detection should be regarded as a mere curiosity withou
\begin{figure}[b]
\begin{figure}[b]
\centering
\centering
\includegraphics[scale=1.2]{img/thundertrap.pdf}
\includegraphics[scale=1.2]{img/thundertrap.pdf}
\caption{The ``lightning trap'' circuit}
\caption{The circuit used for lightning detection}
\label{fig:lightningtrap}
\label{fig:lightningtrap}
\end{figure}
\end{figure}
@ -90,7 +90,7 @@ This method of lightning detection should be regarded as a mere curiosity withou
\begin{subfigure}{.5\textwidth}
\begin{subfigure}{.5\textwidth}
\includegraphics[width=\textwidth]{img/strike4}
\includegraphics[width=\textwidth]{img/strike4}
\end{subfigure}
\end{subfigure}
\caption[Captured lightning strikes]{Lightning strike-generated bursts of energy captured by the ADC unit. Note the X-axis value 500 where the bursts start: that was the configured pre-trigger length}
\caption[Captured lightning strikes]{Lightning strike-generated bursts of energy captured by the ADC unit at 60\,kS/s (shown as raw ADC words). Note the X-axis value 500 where the bursts start: that was the configured pre-trigger length.}
@ -36,7 +36,7 @@ FreeRTOS provides binary and counting semaphores, mutexes, and queues, which wil
\item\textbf{Counting semaphores} represent available resources in a resource pool, a set of software or hardware resources used by tasks. The pool is accompanied by a counting semaphore on which tasks wait for a resource to become available, and then subtract the semaphore value. After a resource is no longer needed by the task, the semaphore is incremented again and another task can use it.
\item\textbf{Counting semaphores} represent available resources in a resource pool, a set of software or hardware resources used by tasks. The pool is accompanied by a counting semaphore on which tasks wait for a resource to become available, and then subtract the semaphore value. After a resource is no longer needed by the task, the semaphore is incremented again and another task can use it.
\item\textbf{Mutexes} (locks) are similar to semaphores, but they must be taken and released in the same task. We use them to
\item\textbf{Mutexes} (locks) are similar to semaphores, but they must be taken and released in the same task. We use them to
guard an exclusive access to a resource, typically a hardware peripheral or a shared memory area. When a mutex is taken, any other tasks trying to take it too enter become Blocked. A Blocked task waiting for a mutex is resumed once this becomes available, at which point the task becomes its owner and is resumed.
guard exclusive access to a resource, typically a hardware peripheral or a shared memory area. When a mutex is taken, any other tasks trying to take it too enter become Blocked. A Blocked task waiting for a mutex is resumed once this becomes available, at which point the task becomes its owner and is resumed.
\item\textbf{Queues} are used for passing messages between tasks, or from interrupts to tasks. Both the sending and receiving of queue messages can block the task until the operation becomes possible. A queue handing task is often simply a loop which tries to read from the queue with an infinite timeout and processes the received data once the reading succeeds.
\item\textbf{Queues} are used for passing messages between tasks, or from interrupts to tasks. Both the sending and receiving of queue messages can block the task until the operation becomes possible. A queue handing task is often simply a loop which tries to read from the queue with an infinite timeout and processes the received data once the reading succeeds.
@ -75,7 +75,7 @@ Our desire to re-use the form factor of the Raspberry Pi (RPi) Zero to exploit t
\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.
\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.
\item Buttons and the USB connector had to exactly align with connectors on the RPi Zero to fit the openings in its cases.
\item Buttons and the USB connector had to exactly align with connectors on the RPi Zero to fit the openings in its cases.
\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.
\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.
\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.
\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 will discuss this in more detail below.
@ -45,7 +45,7 @@ RS-232 uses the \gls{UART} framing, but its levels are different: logical 1 is r
Transmission and reception on the \gls{SPI} bus happen simultaneously. A bus master asserts the \gls{SS} pin of a slave it wishes to address and then sends data on the \gls{MOSI} line while receiving a response on \gls{MISO}. The slave normally responds with 0x00 or a status register as the first byte of the response, before it can process the received command. A timing diagram is shown in \cref{fig:spi_timing}, including two configurable parameters: \gls{CPOL} and \gls{CPHA}.
Transmission and reception on the \gls{SPI} bus happen simultaneously. A bus master asserts the \gls{SS} pin of a slave it wishes to address and then sends data on the \gls{MOSI} line while receiving a response on \gls{MISO}. The slave normally responds with 0x00 or a status register as the first byte of the response, before it can process the received command. A timing diagram is shown in \cref{fig:spi_timing}, including two configurable parameters: \gls{CPOL} and \gls{CPHA}.
\gls{SPI} devices often provide a number of control, configuration and status registers that can be read and written by the bus master. The first byte of a command usually contains one bit that determines if it is a read or write access, and an address field selecting the target register. The slave then either stores the following \gls{MOSI} byte(s) into the register, or sends its content back on \gls{MISO} (or both simultaneously).
\gls{SPI} devices often provide a number of control, configuration and status registers that can be read and written by the bus master. The first byte of a command usually contains one bit that determines if it is a read or write request, and an address field selecting the target register. The slave then either stores the following \gls{MOSI} byte(s) into the register, or sends its content back on \gls{MISO} (or both simultaneously).
{\let\clearpage\relax\chapter{Content of the Attached CD}}
The attached CD (or archive, when downloaded in electronic form) contains source code of the embedded firmware, the client libraries, hardware projects, schematics, and material relating to the paper itself.
\begin{minipage}[t]{.45\textwidth}
\begin{Verbatim}
├── Firmware
├── Hardware
│ ├── GEX HUB
│ ├── GEX Zero
│ ├── GEX Radio Dongle
│ └── Zero+Hub+Dongle panel
├── Software
│ ├── gex_client_c
│ └── gex_client_py
├── Photos
└── Thesis
├── Diagrams
├── References
├── Source
└── GEX_Thesis.pdf
\end{Verbatim}
\end{minipage}
\begin{minipage}[t]{.55\textwidth}
\textbf{Firmware source code and binaries}\\
\textbf{Hardware projects, schematics, gerbers}\\
\null{\quad}GEX Hub\\
\null{\quad}GEX Zero\\
\null{\quad}Wireless gateway\\
\null{\quad}Panelized gerbers for manufacturing\\
\textbf{Documentation photos}\\
\textbf{Client libraries}\\
\null{\quad}C library\\
\null{\quad}Python library\\
\textbf{Thesis materials}\\
\null{\quad}Draw.io diagram data \\
\null{\quad}Referenced papers and documents \\
\null{\quad}\LaTeX\xspace source code, figures \\
\null{\quad}Electronic form of the thesis
\end{minipage}
\section*{Updates On-line}
Please note that the project is open-source and will continue to be developed and expanded after the submission of the paper. The attached source code and firmware images may not be up-to-date with the latest corrections and improvements.
\noindent
The full electronic text, the attachments disk image, and the latest source code may be obtained at the following URLs:
