Applications like motor speed measurement and the reading of a \gls{VCO} or \gls{VCO}-based sensor's output demand a tool capable of measuring frequency. This can be done using a laboratory instrument such as the Agilent 53131A. A low-cost solution can be realized using a timer/counter peripheral of a microcontroller.
Applications like motor speed measurement or the use of sensors with \gls{PWM} output demand a tool capable of measuring frequency (and the duty cycle) of a signal. This can be done using laboratory instruments such as the Agilent 53131A. A low-cost solution can be realized using a timer/counter microcontroller peripheral.
\noindent
\noindent
Two basic methods to measure frequency exist~\cite{fcap-twotypes}, each with its advantages and drawbacks:
Two basic methods to measure frequency exist~\cite{fcap-twotypes}, each with its advantages and drawbacks:
@ -30,7 +30,7 @@ Our project is not meant to end with a tinkering tool that will be produced in a
\end{figure}
\end{figure}
\fi
\fi
Building on the experience with earlier embedded projects, an STM32 microcontroller shall be used. Those are \armcm devices with a wide range of hardware peripherals that appear be a good fit for the project. Low-cost evaluation boards are widely available that could be used as a hardware platform instead of developing a custom \gls{PCB}. STM32 microcontrollers are relatively cheap and already popular in the embedded hardware community; there is a real possibility of the project gathering a community around it and growing beyond what will be presented in this paper.
Building on the experience with earlier embedded projects, an STM32 microcontroller will be used. Those are \armcm devices with a wide range of hardware peripherals that appear be a good fit for the project. Low-cost evaluation boards are widely available that could be used as a hardware platform instead of developing a custom \gls{PCB}. STM32 microcontrollers are relatively cheap and already popular in the embedded hardware community; there is a real possibility of the project gathering a community around it and growing beyond what will be presented in this paper.
\iffalse
\iffalse
Besides the use of existing development boards, custom \glspl{PCB} will be developed in different form factors. The possibilities of wireless connection should be evaluated. This feature should make GEX useful for instance in mobile robotics or when installed in poorly accessible locations.
Besides the use of existing development boards, custom \glspl{PCB} will be developed in different form factors. The possibilities of wireless connection should be evaluated. This feature should make GEX useful for instance in mobile robotics or when installed in poorly accessible locations.
We developed an open source software and hardware platform providing access to low-level hardware buses and circuitry from user applications running on a \gls{PC}. The platform consists of an embedded firmware for the STM32F072 microcontroller, three hardware prototypes (two models of a \gls{GPIO} module, and a wireless gateway), and software libraries in programming languages C and Python. The Python library can be used in MATLAB scripts through the MATLAB/Python integration, or directly in Python, with the SciPy scientific calculations library. The firmware may be used with STM32 Discovery development boards, and can be relatively easily ported to other STM32 \gls{MCU} models.
We developed an open source software and hardware platform providing access to low-level hardware buses and circuitry from user applications running on a \gls{PC}. The platform consists of an embedded firmware for the STM32F072 microcontroller, three hardware prototypes (two models of a \gls{GPIO} module, and a wireless gateway), and software libraries in programming languages C and Python. The Python library can be used in MATLAB scripts through the MATLAB/Python integration, or directly in Python, with the SciPy scientific calculations library. The firmware may be used with STM32 Discovery development boards, and can be relatively easily ported to other STM32 \gls{MCU} models.
Read factory calibration constants from the \gls{MCU}'s \gls{ROM}
Read factory calibration constants from the \gls{MCU}'s \gls{ROM}. These are used to calculate real voltage or temperature from the ADC output word. The formulas can be found in Section 13.9 of the STM32F0~reference manual~\cite{f072-rm}.
&
&
\begin{cmdresp}
\begin{cmdresp}
\cfield{u16} V$_\mathrm{REF\_INT}$ voltage (raw ADC word)
\cfield{u16} VREFINT\_CAL (word)
\cfield{u16} ADC reference voltage (mV) during V$_\mathrm{REF\_INT}$ measurement
\cfield{u16}~VREFINT\_CAL\_VDD~(mV)
\cfield{u16} Temperature sensor voltage in point 1 (raw ADC word)
\cfield{u16} TS\_CAL1 (word)
\cfield{u16} Temperature sensor voltage in point 2 (raw ADC word)
\cfield{u16} TS\_CAL2 (word)
\cfield{u16} Temperature in point 1 (°C)
\cfield{u16} TS\_CAL1\_T (°C)
\cfield{u16} Temperature in point 2 (°C)
\cfield{u16} TS\_CAL2\_T (°C)
\cfield{u16}ADC reference voltage (mV) during temp. sensor calibration
@ -92,7 +92,7 @@ The \gls{MSC} specification~\cite{usbif-msco} defines multiple \textit{transport
For the mass storage device to be recognized by the host operating system, it must also implement a \textit{command set}. Most mass storage devices use the \textit{\gls{SCSI} Transparent command set}
For the mass storage device to be recognized by the host operating system, it must also implement a \textit{command set}. Most mass storage devices use the \textit{\gls{SCSI} Transparent command set}
\footnote{To confirm this assertion, the descriptors of five thumb drives and an external hard disk were analyzed using \verb|lsusb|. All but one device used the SCSI command set, one (the oldest thumb drive) used \textit{SFF-8070i}. A list of possible command sets can be found in~\cite{usbif-msco}}.
\footnote{To confirm this assertion, the descriptors of five thumb drives and an external hard disk were analyzed using \verb|lsusb|. All but one device used the SCSI command set, one (the oldest thumb drive) used \textit{SFF-8070i}. A list of possible command sets can be found in~\cite{usbif-msco}}.
Unfortunately, the \gls{SCSI} Transparent command set appears to have been deliberately left unspecified for license or copyright reasons (see discussion in~\cite{usb-tscsi-wtf} and the surrounding thread) and the protocol now used under this name is an industry standard without a clear definition. Some pointers may be found in~\cite{usb-tscsi} and by examining the source code of the USB Device driver library provided by ST Microelectronics.
Unfortunately, the \gls{SCSI} Transparent command set appears to have been deliberately left unspecified for license or copyright reasons (see discussion in~\cite{usb-tscsi-wtf} and the surrounding thread) and the protocol presently used under this name is an industry standard without a clear definition. Some pointers may be found in~\cite{usb-tscsi} and by examining the source code of the USB Device driver library provided by ST Microelectronics.
This command set lets the host read information about the attached storage device, such as its capacity, and check for media presence and readiness to write or detach. This is used, e.g., for the ``Safely Remove'' function, which ensures that all internal buffers have been written to the flash memory.
This command set lets the host read information about the attached storage device, such as its capacity, and check for media presence and readiness to write or detach. This is used, e.g., for the ``Safely Remove'' function, which ensures that all internal buffers have been written to the flash memory.
