@ -6,45 +6,76 @@ The objective of this work was to develop an extensible platform allowing the us
We based the \textit{GEX} platform around STM32 microcontrollers from ST Microelectronics and developed the initial version for the STM32F072. This \gls{MCU} was chosen for its native \gls{USB} Full Speed support, its interesting set of peripheral blocks, and because it is a relatively recent model in the STM32F series, expecting it to be mature and without major flaws. A wireless connection was planned together with \gls{USB} and hardware \gls{UART}, for which we chose the nRF24L01+ transceiver from Nordic Semiconductor.
In total, three custom hardware modules have been developed and realized for the project: GEX Hub, GEX Zero, and the wireless gateway. GEX Hub verified the designed schematic and general functionality of the module, after first testing the firmware on a STM32 Discovery development board. GEX Zero is more advanced and compact than GEX Hub, also offering wireless connectivity for field experiments; we re-used the form factor of the Raspberry Pi Zero for this board, which makes it compatible with many existing enclosures and add-on boards. In addition to custom hardware, the GEX firmware may be used with STM32 development boards (``STM32F072B-DISCO'').
The initial version of the project presented in this paper provides access to digital communications interfaces \gls{SPI}, \gls{I2C}, \gls{USART}, and 1-Wire, is capable of loading data into NeoPixel RGB \gls{LED} strips and \gls{SIPO} shift registers, and implements additional measurement and signal generation features---analog signal acquisition, waveform generation, frequency, phase, and duty cycle measurement, and \gls{PWM} output.
We developed a transaction-based binary protocol that is used by all three communication interfaces. As the implementation of the protocol would be an inconvenience for the user, we also developed software libraries in languages C and Python that implement it and provide high level access to the hardware module. It has been tested and verified that the Python library can be used from MATLAB scripts, should the user need MATLAB, e.g., for data processing or visualization.
To make the devices easy to reconfigure for the user, the configuration options---such as, which features to enable and what pins to use for them---are represented by entries in INI configuration files. The user can access these files through a virtual mass storage with an emulated FAT16 file system presented to the host \gls{PC} on the \gls{USB} port. Because the file system emulation relies on a certain pattern of behavior from the host, it may not work well in all cases. This is mitigated by making the files accessible also through the communication interface.
In total, three custom hardware modules have been developed and realized for the project: GEX Hub, GEX Zero, and the wireless gateway. GEX Hub verified the designed schematic and general functionality of the module. GEX Zero is more advanced and compact than GEX Hub, also offering wireless connectivity for field experiments; we re-used the form factor of the Raspberry Pi Zero for this board, which makes it compatible with many existing enclosures and add-on boards. In addition to custom hardware, the GEX firmware may be flashed to STM32 development boards (``STM32F072B-DISCO'').
\noindent
The initial version of the project supports the following hardware buses and functions:
\begin{itemize}[itemsep=1pt]
\item\textbf{Digital input} with asynchronous pin change detection
\item\textbf{Digital output} with pulse generation support
\item\textbf{Digital communication interfaces:}
\begin{itemize}
\item\textbf{\gls{SPI}} with up to 16 slaves and multicast support
\item\textbf{\gls{I2C}} master
\item\textbf{\gls{USART}} with optional RS-485 driver support
\item\textbf{1-Wire} master, implementing the \gls{ROM} Search algorithm
\end{itemize}
\item\textbf{Frequency, pulse width, and duty cycle measurement}
\item Isochronous sampling: fixed sample count, or a continuous stream
\item Threshold-based triggering with a pre-trigger buffer
\end{itemize}
\item\textbf{Analog signal generation}
\begin{itemize}
\item Sine, triangle, sawtooth, or rectangle waveform generation using \gls{DDS}
\item\gls{DC} level output
\end{itemize}
\end{itemize}
We developed a transaction-based binary protocol that is used by all three communication interfaces. Software libraries implementing this protocol have been developed in programming languages C and Python. It has been tested and verified that the Python library may be integrated into MATLAB scripts, should the user need MATLAB, e.g., for data processing or visualization.
To make the devices easy to reconfigure, the configuration options---such as, which features to enable and what pins to use for them---are presented by entries in INI configuration files. The user can edit these files in a virtual \gls{USB} mass storage device with an emulated FAT16 file system. Because the emulation relies on a certain pattern of behavior from the host, it may not work reliably in all cases. This is mitigated by making the files accessible also through the communication interface.
\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 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.
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.
As the GEX platform is open source~\cite{gex-gh}, our solution may be freely expanded and adapted to support other hardware platforms, to add new features, or to further optimize its performance. The platform is modular and may be extended by adding new, independent functional blocks.
As the GEX platform is open source, with all source code and hardware materials made available on GitHub~\cite{gex-gh}, our solution may be freely expanded and adapted to support other hardware platforms, to add new features, or to further optimize its performance.
\section{Comparison with Existing Solutions}
The integration of the \gls{PC} with low-level hardware is an appealing idea that has already been explored in several alternative solutions, which we listed in \cref{sec:prior_art}. It is our belief that the project offers enough unique features and qualities to find its place among the competition.
The integration of the \gls{PC} with low-level hardware is an appealing idea that has been explored in several alternative solutions, which we listed in \cref{sec:prior_art}. It is our belief that the GEX project offers enough unique features and qualities to find its place among the competition.
Compared to the Raspberry Pi, GEX is less powerful and cannot be used as a stand-alone device without the host \gls{PC}. However, it is more straightforward to use, the required configuration is minimal, and it offers features not available in the Raspberry Pi, such as the \gls{ADC} and \gls{DAC}.
The Bus Pirate excels as a bus analyzer and general purpose device and implements features we did not explore in this project, while having much fewer \gls{GPIO} pins, a lower resolution of the \gls{ADC}, and completely missing a \gls{DAC}. The two projects serve a slightly different purposes and appear to be complementary.
The Bus Pirate excels as a bus analyzer and general purpose device and implements features we did not explore in this project, while having much fewer \gls{GPIO} pins, a lower resolution of the \gls{ADC}, and completely misses a \gls{DAC}. The two projects serve a slightly different purposes and appear to be complementary.
It is clear that GEX does not pose a real threat to professional tools in terms of performance, but even at the prototype cost it is significantly more affordable. By integrating many diverse features, it can replace several such tools at once when its performance is sufficient for the particular application.
It is clear that GEX does not pose a real threat to professional tools in terms of performance, but even at the prototype cost it is significantly more affordable. By integrating many diverse features, GEX can replace several instruments at once, allowing the creation of more advanced measurement systems in a compact form.
\section{Limitations}
Our solution was designed with the expectation that the users are familiar with programming and the requirement to develop a control script or application will not pose a problem. However, is not universally true and some users who might benefit from the platform will be left unable to use it without a more user-friendly interface.
Our solution was designed with the expectation that the users are familiar with programming, and the requirement to develop a control script or application would not pose a problem. However, that is not universally true, and some users who might benefit from the platform will not be able to use it without a more user-friendly interface.
The STM32F072 microcontroller proved sufficient for the verification of the designed architecture, and in most 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. Its power consumption has not yet been measured or optimized, but the inclusion of a wireless connection capability predisposes the device 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 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.
Another limitation concerns the support software; our client libraries have not been tested on MS Windows, with Linux being the development platform. The C library uses POSIX \gls{API} and is not portable to the non-conforming \gls{OS}. 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 functionality requires the ``STM32 Virtual COM port driver'' to be manually installed and assigned in the Device Manager.
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.
\section{Future Development}
Future development of the project might focus on expanding the number of supported hardware platforms, in order to overcome the limitations of the used microcontroller model. In particular the STM32L series of low-power devices should be investigated, as it may be a better choice when a battery-based operation is needed. The hardware implementation should further be revised to maximize power efficiency.
Future development of the project might focus on expanding the number of supported hardware platforms in order to overcome the limitations of the used microcontroller model. In particular the STM32L series of low-power devices should be investigated, as it may be a better choice when a battery-based operation is needed. The hardware implementation should further be revised to maximize power efficiency.
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 library could be ported to more programming languages, such as Java or \CS, and graphical applications could be developed to make the device 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.
@ -53,16 +53,22 @@ The Boot jumper was meant to be closed during normal operation, to avoid it gett
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.
\caption[GEX Zero compared to Raspberry Pi Zero]{\label{fig:zpicompare}Comparison of Raspberry Pi Zero (top) with GEZ Zero (bottom), before soldering the header, buttons, and the wireless module.}
\caption[The GEX Zero module]{\label{fig:gexzcases}GEX Zero in the official Raspberry Pi Zero case and an aftermarket acrylic case}
\caption[The GEX Zero module]{\label{fig:gexzcases}GEX Zero in the official Raspberry Pi Zero case, and an aftermarket acrylic case. The acrylic case is a better choice, as the button and the side connector are easier accessible, and the pin-out diagram on the back side of the board can be read without removing it.}
\end{figure}
\section{GEX Zero}\label{sec:gzero}
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:
\begin{itemize}
@ -322,7 +328,7 @@ Unfortunately, neither the GEX Zero \gls{PCB} was flawless in the first revision
\section{Wireless Gateway}\label{sec:rfgateway}
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}.
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)\footnote{ Ironically, the STM32F103 is more powerful than the \gls{MCU} used in GEX Zero and GEX Hub. Porting GEX to this platform is planned for future development.}. 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}.
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.
@ -41,7 +41,15 @@ Three transport implementations have been developed:
\item\mono{gex.TrxRawUSB} -- similar to \mono{gex.TrxSerialThread}, but using raw USB endpoint access
\end{itemize}
The wireless gateway is accessed by wrapping either of the transports in an instance of \mono{gex.DongleAdapter} before passing it to \mono{gex.Client}.
To use the wireless gateway, wrap either low-level transport in \mono{gex.DongleAdapter}. The adapter configures the gateway and converts the regular protocol to the right format.
\begin{pythoncode}
# Gateway connection example
transport = gex.DongleAdapter(gex.TrxRawUSB(remote=True), slave=42)
@ -126,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}. Readers might point out that this example is unnecessarily obtuse, and that the payloads could be constructed in a more readable way. Indeed, two better methods of payload construction are available: one using C structs, and the other taking advantage of the Payload Builder utility bundled with TinyFrame, which is included in the library package.
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}. The payloads in this example are represented 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).
We have developed an open-source software and hardware platform providing high-level user applications running on a \gls{PC} with access to \gls{GPIO} pins, hardware buses, and signal acquisition and generation functions.
We have developed an open-source software and hardware platform providing high-level user applications running on a \gls{PC} with access to \gls{GPIO} pins, common hardware buses, and signal acquisition and generation functions.
The platform consists of a FreeRTOS-based firmware for the STM32F072 microcontroller, custom hardware modules, and support software libraries for programming languages C and Python, the latter also compatible with MATLAB. The firmware may be used with the custom hardware, or with existing STM32 development boards.
The platform consists of a FreeRTOS-based firmware for the STM32F072 microcontroller, custom hardware module designs (including realized prototypes), and support software libraries for programming languages C and Python, the latter also compatible with MATLAB. The firmware may be used with the custom hardware, or with existing STM32 development boards.
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.
\noindent
The following features are available, implemented as independent functional blocks that can be enabled in any combination:
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.
\begin{itemize}[itemsep=1pt]
\item\textbf{Digital input} with asynchronous pin change detection
\item\textbf{Digital output} with pulse generation support
\item\textbf{Digital communication interfaces:}
\begin{itemize}
\item\textbf{\gls{SPI}} with up to 16 slaves and multicast support
\item\textbf{\gls{I2C}} master
\item\textbf{\gls{USART}} with optional RS-485 driver support
\item\textbf{1-Wire} master, implementing the \gls{ROM} Search algorithm
\end{itemize}
\item\textbf{Analog signal acquisition}
\begin{itemize}
\item Immediate or averaged voltage measurement
\item Isochronous sampling: fixed sample count, or a continuous stream
\item Threshold-based triggering with a pre-trigger buffer
\end{itemize}
\item\textbf{Analog signal generation}
\begin{itemize}
\item Sine, triangle, sawtooth, or rectangle waveform generation using \gls{DDS}
The developed platform may 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.
Future development may focus on expanding support to other \gls{MCU} models, adding new features, improving the software libraries, and providing a more user-friendly control interface.
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.
