diff --git a/ch.existing_solutions.tex b/ch.existing_solutions.tex index b34d748..b22eec3 100644 --- a/ch.existing_solutions.tex +++ b/ch.existing_solutions.tex @@ -30,7 +30,7 @@ The Raspberry Pi could be used for the same quick evaluations or experiments we \begin{figure}[H] \centering \includegraphics[width=0.5\textwidth] {img/buspirate.jpg} - \caption{\label{fig:buspirate}Bus Pirate v.4 (picture by \textit{Seeed Studio})} + \caption{\label{fig:buspirate}Bus Pirate v.4 (photo taken from \cite{buspirate-product-page})} \end{figure} %http://dangerousprototypes.com/blog/about/ @@ -65,7 +65,7 @@ The performance GEX can provide may not always match that of those professional \includegraphics[width=.95\linewidth]{img/total-phase-spi-i2c.jpg} \caption{Total Phase SPI/\IIC Host "Aardwark"} \end{subfigure} - \caption[Professional tools that GEX can replace]{\label{fig:profidaq}An example of professional tools that GEX could replace in less demanding scenarios \textit{(pictures from National Instruments and Total Phase marketing materials)}} + \caption[Professional tools that GEX can replace]{\label{fig:profidaq}An example of professional tools that GEX could replace in less demanding scenarios \textit{(pictures taken from marketing materials: \cite{nidevice1, nidevice2, tphasedevice})}} \end{figure} %http://www.ni.com/en-gb/shop/select/i2c-spi-interface-device} diff --git a/ch.usb.tex b/ch.usb.tex index 2fccf92..482e511 100644 --- a/ch.usb.tex +++ b/ch.usb.tex @@ -1,6 +1,8 @@ \chapter{Universal Serial Bus} -This chapter presents an overview of the \gls{USB} Full Speed interface, with focus on the features used in the GEX firmware. \gls{USB} is a versatile but complex interface, thus explaining it in its entirety is beyond the scope of this text. References to external material which explains the protocol in greater detail will be provided where appropriate.\todo{add those refs} +This chapter presents an overview of the \acrfull{USB} Full Speed interface, with focus on the features used in the GEX firmware. \gls{USB} is a versatile and powerful interface which replaces several older technologies; for this reason its specification is very complex and going into all details is hardly possible. We will cover the basic principles and terminology of \gls{USB} and focus on the parts relevant for the GEX project. More information about the bus can be found in the official specification \cite{usbif-spec}, related documents published by the USB Implementers Forum, and other on-line resources \cite{usb-nutshell,usb-made-simple}. + +\section{Basic Principles and Terminology} \begin{figure}[h] \centering @@ -8,11 +10,11 @@ This chapter presents an overview of the \gls{USB} Full Speed interface, with fo \caption[USB hierarchical structure]{\label{fig:usb-hierarchy}The hierarchical structure of the USB bus} \end{figure} -\section{Basic Principles and Terminology} +\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}. -\todo[inline]{review and correct inaccuracies} +\subsection{Pipes and Endpoints} -\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}. Communication between the host and a function is organized into virtual channels called \textit{pipes}. Each pipe is identified by an \textit{endpoint} number. +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. \begin{figure}[h] \centering @@ -22,7 +24,9 @@ This chapter presents an overview of the \gls{USB} Full Speed interface, with fo Endpoints can be either unidirectional or bidirectional; the direction from the host to a function is called OUT, the other direction (function the host) is called IN. A bidirectional endpoint is technically composed of a IN and OUT endpoint with the same number. All transactions (both IN and OUT) are initiated by the host; functions have to wait for their turn. Endpoint 0 is bidirectional, always enabled, and serves as a \textit{control endpoint}. The host uses the control endpoint to read information about the device and configure it as needed. -There are four types of transfers: control, bulk, isochronous, and interrupt. Each endpoint is configured for a fixed transfer type: +\subsection{Transfer Types} + +There are four types of data transfers defined in \gls{USB}: control, bulk, isochronous, and interrupt. Each endpoint is configured for a fixed transfer type: \begin{itemize} \item \textit{Control} - initial configuration after device plug-in; also used for other aplication-specific control messages that can affect other pipes. @@ -31,92 +35,84 @@ There are four types of transfers: control, bulk, isochronous, and interrupt. Ea \item \textit{Interrupt} - low latency short messages, used for human interface devices like mice and keyboards \end{itemize} -The endpoint transfer type and other characteristics, together with other information about the device, such as the serial number, are defined in a \textit{descriptor table}. This is a tree-like binary structure defined in the function's memory. The descriptor table is loaded by the host to learn about the used endpoints and to attach the right driver to it. +\subsection{Interfaces and Classes} + +The function's endpoints are grouped into \textit{interfaces}. An interface describes a logical connection of endpoints, such as the reception and transmission endpoints that belong together. An interface is assigned a \textit{class} defining how it should be used. -The function's endpoints are grouped into \textit{interfaces}. An interface describes a logical connection of endpoints, such as the reception and transmission endpoint that belong together. An interface is assigned a \textit{class} defining how it should be used. Standard classes are defined by the USB specification to provide a uniform way of interfacing devices of the same type, such as human-interface devices (mice, keyboards, gamepads) or mass storage devices. The use of standard classes makes it possible to re-use the same driver software for devices from different manufacturers. The class used for the GEX's ``virtual COM port'' function was originally meant for telephone modems, a common way of connecting to the Internet at the time the first versions of USB were developed. A device using this class will show as \verb|/dev/ttyACM0| on Linux and as a COM port on Windows, provided the system supports it natively or the right driver is installed. +Standard classes are defined by the USB specification \cite{usb-class-list} to provide a uniform way of interfacing devices of the same type, such as human-interface devices (mice, keyboards, gamepads) or mass storage devices. The use of standard classes makes it possible to re-use the same driver software for devices from different manufacturers. -\todo[inline]{add reference to the document} +The class used for the GEX's ``virtual COM port'' function was originally meant for telephone modems, a common way of connecting to the Internet at the time the first versions of USB were developed. A device using this class will show as \verb|/dev/ttyACM0| on Linux and as a COM port on Windows, provided the system supports it natively or the right driver is installed. -% function - https://technet.microsoft.com/en-us/library/cc939102.aspx} +\subsection{Descriptors} +USB devices are introspectable, that is, the host can learn about a newly connected device automatically by probing it, without any user interaction. This is accomplished using a \textit{descriptor table}, a binary structure stored in the function and read by the host through the control endpoint (default pipe) after the device is attached. + +Each descriptor starts with a declaration of its length (in bytes), followed by its type, allowing the host to skip unknown descriptors without having to discard the rest of the table. The descriptors are logically nested and form a tree-like structure, but they are stored sequentially in the descriptor table and the lengths do no include sub-descriptors. + +The topmost descriptor holds information about the entire function, including the vendor and product IDs which uniquely identifies the device model. It is followed by a Configuration descriptor, grouping a set of interfaces. More than one configuration may be present and available for the host to choose from; however, this is rarely used or needed. Each configuration descriptor is followed by one or more interface descriptors, each with its class-specific sub-descriptors and/or endpoint descriptors. + +The descriptor table used by GEX is captured in figure \ref{fig:gex-descriptors} for illustration. The vendor and product IDs were obtained from the pid.codes repository \cite{pidcodes} providing free product codes to open source projects. The official way of obtaining the unique code involves high recurring fees (\$4000 per annum) to the USB Implementers Forum, Inc. and is therefore not affordable for non-commercial use; alternatively, a product code may be obtained from some \gls{MCU} vendors if their product is used in the device. \newpage + \input{fig.gex-descriptors} \section{USB Physical Layer} -\gls{USB} uses differential signaling with \gls{NRZI} encoding and bit stuffing (the insertion of dummy bits to prevent long intervals in the same \gls{DC} level). The encoding, together with frame formatting, checksum verification, retransmission, and other low level aspects of the \gls{USB} connection are entirely handled by the \gls{USB} physical interface block in the microcontroller's silicon; normally we do not need to worry about those details. What needs more attention are the electrical characteristics of the bus, which need to be understood correctly for a successful schematic and \gls{PCB} design. +\gls{USB} uses differential signaling with \gls{NRZI} encoding and bit stuffing (the insertion of dummy bits to prevent long intervals in the same \gls{DC} level). The encoding, together with frame formatting, checksum verification, retransmission, and other low level aspects of the \gls{USB} connection are entirely handled by the \gls{USB} physical interface block in the microcontroller's silicon. Normally we do not need to worry about those details; nonetheless, a curious reader may find more information in chapters 7 and 8 of \cite{usbif-spec}. What needs our attention are the electrical characteristics of the physical connection, which need to be understood correctly for a successful schematic and \gls{PCB} design. -\noindent The \gls{USB} cable contains 4 conductors: V$_\mathrm{BUS}$ (+5\,V), D+, D--, and \gls{GND}. The data lines, D+ and D--, are also commonly labeled DP and DM. This differential pair should be routed in parallel on the \gls{PCB} and kept at the same length. -\gls{USB} versions are often backwards compatible, even keeping the same connector shape. The bus speed to use is requested by the device using a 1.5\,k$\Omega$ pull-up resistor to 3.3\,V on one of the data lines: for Full Speed, D+ is pulled high (figure \ref{fig:usb-pullup-fs}), for Low Speed it's on D--. The polarity of the differential signals is inverted depending on the used speed. Some microcontrollers integrate the correct pull-up resistor inside the \gls{USB} block (including out STM32F072), removing the need for an external resistor. +\gls{USB} versions that share the same connector are backwards compatible. The desired bus speed is requested by the device using a 1.5\,k$\Omega$ pull-up resistor to 3.3\,V on one of the data lines: D+ pulled high for Full Speed (shown in figure \ref{fig:usb-pullup-fs}), D-- pulled high for Low Speed. The polarity of the differential signals is also inverted depending on the used speed, as the idle level changes. Some microcontrollers integrate the correct pull-up resistor inside the \gls{USB} peripheral block (including out STM32F072), removing the need for an external resistor. -\begin{figure} +\begin{figure}[h] \centering - \includegraphics[width=.8\textwidth]{img/usb-pullup-fs.png} - \caption[USB pull-ups]{\label{fig:usb-pullup-fs}Pull-up and pull-down resistors of a Full Speed function, as prescribed by the USB specification rev. 2.0} + \includegraphics[scale=1]{img/usb-resistors.pdf} + \caption[USB pull-ups]{\label{fig:usb-pullup-fs}Pull-up and pull-down resistors near the host and a Full Speed function, as prescribed by the USB specification rev. 2.0} \end{figure} -When a function wants to be re-enumerated by the host, which is needed to reload the descriptors and re-attach the correct drivers, it can momentarily remove the pull-up resistor, which the host will interpret as if the device was plugged out. With an internal pull-up this can be done by flipping a bit in a control register. An external resistor can be connected through a transistor controlled by a \gls{GPIO} pin. - -\todo[inline]{https://www.eevblog.com/forum/projects/driving-the-1k5-usb-pull-up-resistor-on-d/} -\todo[inline]{http://www.beyondlogic.org/usbnutshell/usb2.shtml} +When a function needs to be re-enumerated by the host, which causes a reload of the descriptor table and the re-attachment of software drivers, it can momentarily remove the pull-up resistor, which the host will interpret as if the device was disconnected. With an internal pull-up, this can be done by flipping a bit in a control register. An external resistor may be connected through a transistor controlled by a \gls{GPIO} pin. As discussed in \cite{eev-gpio-pu}, a GPIO pin might be used to drive the pull-up directly, though this has not been verified by the author. The V$_\mathrm{BUS}$ line supplies power to \textit{bus-powered} devices. \textit{Self-powered} devices can leave this pin unconnected and instead use an external power supply. The maximal current drawn from the V$_\mathrm{BUS}$ line is configured using a descriptor and should not be exceeded, but experiments suggest this is often not enforced. +\noindent More details about the electrical and physical connection may be found in \cite{usb-nutshell}, sections \textit{Connectors} through \textit{Power}. + \section{USB Classes} -This section explains the \gls{MSC} and the \gls{CDCACM} that are used in the GEX firmware. A list of all standard classes with a more detailed explanation can be found on the USB.org website at \url{http://www.usb.org/developers/defined\_class}.\todo{move to references} +This section explains the classes used in the GEX firmware. A list of all standard classes with a more detailed explanation can be found in \cite{usb-class-list}. \subsection{Mass Storage Class} The \gls{MSC} is supported by all modern operating systems (MS Windows, MacOS, GNU/Linux, FreeBSD etc.) to support thumb drives, external disks, memory card readers and other storage devices. -\todo[inline]{references} %http://www.usb.org/developers/docs/devclass_docs/Mass_Storage_Specification_Overview_v1.4_2-19-2010.pdf %http://www.usb.org/developers/docs/devclass_docs/usbmassbulk_10.pdf -The \gls{MSC} specification defines multiple \textit{transport protocols} that can be selected using the descriptors. For it's simplicity, the \gls{BOT} will be used. \gls{BOT} uses two bulk endpoints for reading and writing blocks of data and for the exchange of control commands and status messages. For the device to be recognized by the 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 TODO (usb spec overview)}. -The command set's commands let the host read information about the attached storage, 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 checks that all internal buffers have been written to Flash. - -\todo[inline]{links} - -% weird flash - SFF-8070i subclass - -% usb spec overview https://cscott.net/usb_dev/data/devclass/msco_v109.pdf +The \gls{MSC} specification \cite{usbif-msco} defines multiple \textit{transport protocols} that can be selected using the descriptors. For it's simplicity, the \gls{BOT} \cite{usbif-bot} will be used. \gls{BOT} uses two bulk endpoints for reading and writing blocks of data and for the exchange of control commands and status messages. -%https://bits4device.wordpress.com/2013/05/24/usb-mass-storage-class-msc-bulk-only-transfer-bot/ +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}}. -%http://janaxelson.com/mass_storage_faq.htm +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. -The \gls{MSC} together with the \gls{SCSI} command set are implemented in a \gls{USB} Device library provided by ST Microelectronics. The library also includes a basic \gls{CDCACM} implementation (see below). +This command set lets the host read information about the attached storage, 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 Flash. -In order to emulate a mass storage device without having a physical storage medium, we need to generate and parse the filesystem on-the-fly as the host \gls{OS} tries to access it. This will be discussed in chapter \ref{sec:fat16}. +In order to emulate a mass storage device without having a physical storage medium, we need to generate and parse the file system on-the-fly as the host \gls{OS} tries to access it. This will be discussed in chapter \ref{sec:fat16}. \subsection{CDC/ACM Class} \label{sec:cdc-acm} %https://www.keil.com/pack/doc/mw/USB/html/group__usbd__cdc_functions__acm.html -Historically meant for modem communication, this class is now the de facto standard way of making \gls{USB} devices appear as serial ports on the host \gls{OS}. The \gls{CDC} uses three endpoints: bulk IN and OUT, and an interrupt endpoint. +Historically meant for modem communication, \gls{CDCACM} is now the de facto standard way of making \gls{USB} devices appear as serial ports on the host \gls{OS}. Its specification can be found in \cite{usbif-cdc}. \gls{CDCACM} is a combination of two related classes, \gls{CDC} handling the data communication and \gls{ACM}, which defines control commands. Three endpoints are used: bulk IN, bulk OUT, and interrupt OUT. -\todo{verify this vvv} -The interrupt endpoint is used for control commands and notifications while the bulk endpoints are used for useful data. \gls{ACM} stands for \textit{Abstract Control Model} and it's a \gls{CDC}'s subclass that defines the control messages format. Since we don't use a physical UART and the line is virtual both on the PC and in the end device, the control commands can be ignored. +The interrupt endpoint is used for control commands, such as toggling the auxiliary lines of RS-232 or setting the baud rate. Since GEX does not translate the data communication to any physical UART, those commands are not applicable and can be silently ignored. -An interesting property of this class is that the bulk endpoints transport raw data without any wrapping frames. By changing the device class in the descriptor table to 255 (\textit{Vendor Specific Class}), we can retain the messaging functionality of the designated endpoints and access the device directly using e.g. libUSB, while the \gls{OS} will ignore it and won't try to attach any driver that could interfere otherwise. The same trick can be used to hide the mass storage class when not needed. +An interesting property of the \gls{CDC} class is that the bulk endpoints transport raw data without any wrapping frames. By changing the interface's class in the descriptor table to 255 (\textit{Vendor Specific Class}), we can retain the messaging functionality of the designated endpoints, while accessing the endpoints device directly using e.g. libUSB, without any interference from the \gls{OS}. This approach is also used to hide the \gls{MSC} interface when its not needed. \subsection{Interface Association: Composite Class} -Since it's creation, the \gls{USB} specification expected that each function will have only one interface enabled at a time. After it became apparent that there is a need for having multiple unrelated interfaces work in parallel, a workaround called the \gls{IAD} was introduced. \gls{IAD} is an entry in the descriptor table that defines which interfaces belong together and should be handled by the same software driver. - -To use the \gls{IAD}, the function's class must be set to 239 (0xEF), subclass 2 and protocol 1, so the \gls{OS} knows to look for the presence of \glspl{IAD} before binding drivers to any interfaces. - -% TODO link to some references.. - -In GEX, the \gls{IAD} is used to tie together the \gls{CDC} and \gls{ACM} interfaces while leaving out the \gls{MSC} interface which should be handled by a different driver. To make this work, a new \textit{composite class} had to be created as a wrapper for the library-provided \gls{MSC} and \gls{CDCACM} implementations. - -%http://www.usb.org/developers/docs/whitepapers/iadclasscode_r10.pdf - +Since it's creation, the \gls{USB} specification expected that each function will have only one interface enabled at a time. After it became apparent that there is a need for having multiple unrelated interfaces work in parallel, the \gls{IAD} \cite{usbif-iad} was introduced as a workaround. +The \gls{IAD} is an entry in the descriptor table that defines which interfaces belong together and should be handled by the same software driver. To use the \gls{IAD}, the function's class must be set to 239 (0xEF), subclass 2 and protocol 1 in the top level descriptor, so that the \gls{OS} knows to look for this descriptor before binding drivers to any interfaces. +In GEX, the \gls{IAD} is used to tie together the \gls{CDC} and \gls{ACM} interfaces while leaving out the \gls{MSC} interface which should be handled by a different driver. To make this work, a new \textit{composite class} had to be created as a wrapper for the library-provided \gls{MSC} and \gls{CDCACM} implementation. diff --git a/fig.gex-descriptors.tex b/fig.gex-descriptors.tex index 4bf2d30..9b86ad0 100644 --- a/fig.gex-descriptors.tex +++ b/fig.gex-descriptors.tex @@ -9,8 +9,8 @@ Device Descriptor: bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 - idVendor 0x0483 STMicroelectronics - idProduct 0x572a + idVendor 0x1209 InterBiometrics + idProduct 0x4c60 bcdDevice 0.01 iManufacturer 1 MightyPork iProduct 2 GEX @@ -134,5 +134,5 @@ Device Descriptor: \end{verbatim} \end{minipage}\vspace{-1em} \begin{figure}[H] - \cprotect\caption{USB descriptors of a GEX prototype obtained using \verb|lsusb -vd vid:pid|} + \caption{\label{fig:gex-descriptors}USB descriptors of a GEX prototype obtained using ``\mono{lsusb}''} \end{figure} diff --git a/img/CDC1.2_WMC1.1_012011.zip b/img/CDC1.2_WMC1.1_012011.zip new file mode 100644 index 0000000..b9f07e7 Binary files /dev/null and b/img/CDC1.2_WMC1.1_012011.zip differ diff --git a/img/usb-resistors.pdf b/img/usb-resistors.pdf new file mode 100644 index 0000000..9d104fa Binary files /dev/null and b/img/usb-resistors.pdf differ diff --git a/references/FAT16/fatgen103.pdf b/references/FAT16/fatgen103.pdf new file mode 100644 index 0000000..3259ef8 Binary files /dev/null and b/references/FAT16/fatgen103.pdf differ diff --git a/references/STM32/F072x8,xB.pdf b/references/STM32/F072x8,xB.pdf new file mode 100755 index 0000000..c0b1075 Binary files /dev/null and b/references/STM32/F072x8,xB.pdf differ diff --git a/references/STM32/F0x1,2,8 RM.pdf b/references/STM32/F0x1,2,8 RM.pdf new file mode 100755 index 0000000..62e81a8 Binary files /dev/null and b/references/STM32/F0x1,2,8 RM.pdf differ diff --git a/references/STM32/F103x8,B.pdf b/references/STM32/F103x8,B.pdf new file mode 100755 index 0000000..cbe5419 Binary files /dev/null and b/references/STM32/F103x8,B.pdf differ diff --git a/references/STM32/F10x ref manual.pdf b/references/STM32/F10x ref manual.pdf new file mode 100755 index 0000000..9be3ee0 Binary files /dev/null and b/references/STM32/F10x ref manual.pdf differ diff --git a/references/STM32/tscan/en.DM00085385.pdf b/references/STM32/tscan/en.DM00085385.pdf new file mode 100644 index 0000000..b5d7d4b Binary files /dev/null and b/references/STM32/tscan/en.DM00085385.pdf differ diff --git a/references/STM32/tscan/en.DM00087593.pdf b/references/STM32/tscan/en.DM00087593.pdf new file mode 100644 index 0000000..41363c9 Binary files /dev/null and b/references/STM32/tscan/en.DM00087593.pdf differ diff --git a/references/STM32/tscan/en.DM00087990.pdf b/references/STM32/tscan/en.DM00087990.pdf new file mode 100644 index 0000000..4b683f0 Binary files /dev/null and b/references/STM32/tscan/en.DM00087990.pdf differ diff --git a/references/STM32/tscan/en.DM00088471.pdf b/references/STM32/tscan/en.DM00088471.pdf new file mode 100644 index 0000000..af32fd0 Binary files /dev/null and b/references/STM32/tscan/en.DM00088471.pdf differ diff --git a/references/USB/www.lvr.com_mass_storage_faq.htm b/references/USB/www.lvr.com_mass_storage_faq.htm new file mode 100644 index 0000000..a4d0a22 --- /dev/null +++ b/references/USB/www.lvr.com_mass_storage_faq.htm @@ -0,0 +1,476 @@ + + + + + + + + + + + + + + + + +Jan Axelson's Lakeview Research + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ +
+ +Jan Axelson's Lakeview Research + +
+ + + + + + + +
+ + + +
+
+ + + + +

Home > USB Central > Mass Storage Page > + Mass Storage FAQ

+

Mass Storage FAQ

+

Also see:

+

Mass + storage page + +

+

General

+
+

How long can a device return NAK in a mass-storage + bulk transfer?

+

The mass-storage specification doesn't define a timeout + value. Hosts typically will wait 20-30 seconds.

+

Can my device's firmware read and store files when + the device isn't attached to a host?

+

Yes, if the firmware supports a file system such as FAT16 + or FAT32. Note that the mass-storage device should have only one mass-storage + master at a time. When the device is attached to and configured by a USB + host, the firmware shouldn't attempt to read or write to files on its + own.

+
+

SCSI

+
+

What is the SCSI transparent command set?

+

In the Mass Storage Class Specification Overview, Table + 2.1 says that devices with subclass code 06h implement the "SCSI + transparent command set." The SCSI specifications are available from + t10.org, but these documents don't + mention a transparent command set.

+

According + to the inventor of the subclass, subclass 06h means that the host should determine + the device type by issuing a SCSI INQUIRY command. In the returned INQUIRY + data, bits 4..0 of byte 0 specify a peripheral device type (PDT). The + SCSI Primary Commands (SPC) specification defines various PDTs and the + specifications they should comply with.

+

What value should I use for bInterfaceSubClass in + the interface descriptor?

+

New designs should use bInterfaceSubClass = 06h (SCSI transparent + command set). The device's response to a SCSI INQUIRY command is then + the single source where the device declares its command set (via the PERIPHERAL + DEVICE TYPE (PDT) and VERSION codes). A device should use a different + bInterfaceSubClass only if it must for some reason adhere to a command + set that has no PDT code (such as SFF-8070i). See the SPC document for + a list of PDTs.

+

What commands should my device support?

+

In the response to a SCSI INQUIRY command, a device returns + a PERIPHERAL DEVICE TYPE code and a VERSION code. For hard drives, flash + drives, and similar devices, PERIPHERAL DEVICE TYPE = 00h (direct access + block device) and VERSION = 04h (SPC-2) or 05h (SPC-3). The code in the + VERSION corresponds to a command set, and the command set's specification + lists mandatory commands.

+

In some cases, additional INQUIRY data can provide more + information, including vendor-specific data, but not every host will retrieve + more than the first 36 bytes of the response.

+

The SPC specification documents the INQUIRY command. Also + see the specification for your device type for any device-specific information + about the INQUIRY response.

+

In practice, many devices don't implement every mandatory + command and just concentrate on the commands used by any hosts the device + is likely to connect to.

+

The Mass + Storage Class Compliance Test Specification names required and optional + commands for different PDTs that want to pass USB-IF's mass-storage compliance + tests.

+

What is command 0x23 (23h)? I can't find it in the + SPC or SBC documents.

+

Command 23h is READ FORMAT CAPACITIES in the Multimedia + Commands (MMC) specification from t10.org.

+
+

Windows Specific

+
+

Can my device use the Reduced Block Command (RBC) + set?

+

Windows doesn't support RBC (bInterfaceSubClass 01h or 06h + and PDT = 0Eh), so if you design an RBC device, you'll need to provide + a driver for the host. The USB mass storage overview document from usb.org + incorrectly says that flash drives typically use RBC. Flash drives use + bInterfaceSubClass 06h (SCSI transparent command set) with PDT = 00h (direct-access + block device), the same as hard drives.

+

How can I determine the drive letter Windows has + assigned to a USB drive?

+

Three options:

+

1. Example code from Marc Reinig.

+

2. How + to get the usbdisk's drive letter properly. Using DeviceIoControl + to get a USB drive's letter. From f22_storm.

+

3. Usenet thread How + to match between physical usb device and its drive letter.

+
+ + + + + + + + + + +
+ +
+

Partner Links

+ + +

Embedded Programming
+Experts in embedded software development. Microchip Certified Consults.
+absolute-software.co.uk

+

USB Protocol Analyzers
+ ELLISYS protocol analyzers, generators, automated compliance solutions.
+www.ellisys.com

+

USBTrace - USB Analyzer
+ Software-based USB Protocol Analyzer. Easy-to-use and affordable.
+www.sysnucleus.com

+

Powerful USB Analyzer
+ Real-time USB 2.0 display & class decoding. See a video demo now.
+www.totalphase.com

+ +

USB to Ethernet Connector
+Share & access USB devices over local network or even Internet!
+www.eltima.com

+ +

USB Duplicator
+ Copy up to 77 USB Drives at once with a stand-alone USB Duplicator.
+ www.premiumusb.com

+

Creative Promo USB Drives
+ Custom designed promotional drives w/ branded printing and duplication.
+www.CreativeUSB.com

+

+

+ +

+ + + +

+ + +

+ + + +

+ +
+ +
+ + + + + + + + + \ No newline at end of file diff --git a/thesis.bib b/thesis.bib index 2c6fcf4..8486838 100755 --- a/thesis.bib +++ b/thesis.bib @@ -1,7 +1,366 @@ -@online{foo, - title = {Foo Bar}, - url = {https://foo.bar}, - urldate = {2016-05-08}, - language = {english} +% USB tutorials and articles + +@string{USBIF = {{USB Implementers Forum, Inc.}}} +@string{MSFT = {{Microsoft Corporation}}} +@string{STM = {{ST Microelectronics}}} + +@online{usb-nutshell, + title = {USB in a NutShell}, + author = {Craig Peacock}, + url = {https://www.beyondlogic.org/usbnutshell}, + urldate = {2018-05-12} +} + +@online{usb-made-simple, + title = {USB Made Simple}, + author = {{MQP Electronics Ltd.}}, + url = {http://www.usbmadesimple.co.uk/}, + year = {2008}, + urldate = {2018-05-12} +} + +@online{tty-usb-acm, + title = {What is the difference between /dev/ttyUSB and /dev/ttyACM?}, + author = {Samuel Tardieu}, + url = {https://rfc1149.net/blog/2013/03/05/what-is-the-difference-between-devttyusbx-and-devttyacmx/}, + year = {2013}, + urldate = {2018-05-12} +} + +@online{usb-tscsi, + title = {Mass Storage FAQ}, + author = {Jan Axelson}, + url = {http://janaxelson.com/mass_storage_faq.htm}, + year = {2013}, + urldate = {2018-05-12} +} + + +@online{usb-tscsi-wtf, + title = {Discussion in a USB storage driver development mailing list (site defunct, archived via Archive.org)}, + url = {https://web.archive.org/web/20071108121822/https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-September/000795.html}, + year = {2004}, + urldate = {2018-05-12} +} + +@online{usb-function, + title = {Windows 2000 Professional Resource Kit / USB Functions}, + author = MSFT, + url = {https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc939102(v%3dtechnet.10)}, + year = {2008}, + urldate = {2018-05-12} +} + + + +@online{usb-class-list, + title = {USB Class Codes}, + author = USBIF, + url = {http://www.usb.org/developers/defined_class}, + year = {2016}, + urldate = {2018-05-12} +} + +% USB specification + +@online{usbif-spec, + title = {Universal Serial Bus Specification}, + author = USBIF, + url = {http://www.usb.org/developers/docs/usb20_docs/}, + year = {2000}, + urldate = {2018-05-12} +} + +@online{usbif-msco, + title = {USB Mass Storage Class, Specification Overview}, + author = USBIF, + url = {http://www.usb.org/developers/docs/devclass_docs/Mass_Storage_Specification_Overview_v1.4_2-19-2010.pdf}, + year = {2010}, + urldate = {2018-05-12} +} + +@online{usbif-bot, + title = {USB Mass Storage Class, Bulk-Only Transport}, + author = USBIF, + url = {http://www.usb.org/developers/docs/devclass_docs/usbmassbulk_10.pdf}, + year = {1999}, + urldate = {2018-05-12} +} + +@online{usbif-cdc, + title = {Class definitions for Communication Devices 1.2}, + author = USBIF, + url = {http://www.usb.org/developers/docs/devclass_docs/CDC1.2_WMC1.1_012011.zip}, + year = {2010}, + urldate = {2018-05-12} +} + +@online{usbif-iad, + title = {USB Interface Association Descriptor, Device Class Code and Use Model}, + author = USBIF, + url = {http://www.usb.org/developers/docs/whitepapers/iadclasscode_r10.pdf}, + year = {2003}, + urldate = {2018-05-12} +} + +% Virtual FS + +@online{ms-fat, + title = {How FAT Works}, + author = MSFT, + url = {https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc776720(v=ws.10)}, + year = {2009}, + urldate = {2018-05-12} +} + +@online{daplink, + title = {Arm Mbed DAPLink source code repository}, + author = {{Arm Mbed}}, + url = {https://github.com/ARMmbed/DAPLink}, + year = {2018}, + urldate = {2018-05-12} +} + +@online{fat16-brainy, + title = {FAT16 Structure Information}, + author = {Jack Dobiash}, + url = {http://home.teleport.com/~brainy/fat16.htm}, + year = {1999}, + urldate = {2018-05-12} +} + +@online{fat16-maverick, + title = {FAT16 File System}, + author = {{LKT Software}}, + url = {http://www.maverick-os.dk/FileSystemFormats/FAT16_FileSystem.html}, + year = {1999}, + urldate = {2018-05-12} +} + +@online{fat16-phobos, + title = {A tutorial on the FAT file system}, + author = {Bob Eager}, + url = {http://www.tavi.co.uk/phobos/fat.html}, + year = {2017}, + urldate = {2018-05-12} +} + +@book{freertos-book, + title = {Mastering the FreeRTOS™ Real Time Kernel}, + subtitle = {A Hands-On Tutorial Guide}, + author = {Richard Barry}, + publisher= {Real Time Engineers Ltd.}, + url = {https://www.freertos.org/Documentation/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf}, + year = {2016}, + urldate = {2018-05-12} +} + +@manual{freertos-rm, + title = {The FreeRTOS™ Reference Manual}, + author = {{Real Time Engineers Ltd.}}, + publisher= {Real Time Engineers Ltd.}, + url = {https://www.freertos.org/Documentation/FreeRTOS_Reference_Manual_V10.0.0.pdf}, + year = {2018}, + urldate = {2018-05-12} +} + +@article{fat-lfn, + author = {{vinDaci}}, + title = {Long Filename Specification}, + year = {1998}, + url = {http://home.teleport.com/~brainy/lfn.htm}, + urldate = {2018-05-12} +} + +@techreport{fat-whitepaper, + author = MSFT, + title = {FAT: General Overview of On-Disk Format}, + url = {https://staff.washington.edu/dittrich/misc/fatgen103.pdf}, + year = {2000}, + urldate = {2018-05-12} +} + + +% STM32 + +@techreport{stm-timer-coockbook, + author = STM, + title = {AN4776: General-purpose timer cookbook}, + year = {2017}, + url = {http://www.st.com/resource/en/application_note/dm00236305.pdf}, + urldate = {2018-05-12} +} + +@techreport{stm-tsc-training, + author = STM, + title = {STM32L4 training: Touch Sensing Controller}, + year = {2017}, + url = {http://www.st.com/resource/en/product_training/stm32l4_peripheral_touchsense.pdf}, + urldate = {2018-05-12} +} + +% (couldnt find a proper link) +@techreport{stm-tsc-ppt, + author = STM, + title = {Touch Sensing Controller (TSC) presentation}, + year = {2015}, + url = {https://wenku.baidu.com/view/8472044a6137ee06eef9180c.html?re=view}, + urldate = {2018-05-12} +} + +@techreport{stm-tsc-an1, + author = STM, + title = {AN4299: Guidelines to improve conducted noise robustness on STM32F0 Series, STM32F3 Series, STM32L0 Series and STM32L4 Series touch sensing applications}, + year = {2018}, + url = {http://www.st.com/resource/en/application_note/dm00085385.pdf}, + urldate = {2018-05-12} +} + +@techreport{stm-tsc-an2, + author = STM, + title = {AN4310: Sampling capacitor selection guide for MCU based touch sensing + applications}, + year = {2015}, + url = {http://www.st.com/resource/en/application_note/dm00087593.pdf}, + urldate = {2018-05-12} +} + +@techreport{stm-tsc-an3, + author = STM, + title = {AN4312: Guidelines for designing touch sensing applications + with surface sensors}, + year = {2017}, + url = {http://www.st.com/resource/en/application_note/dm00087990.pdf}, + urldate = {2018-05-12} +} + +@techreport{stm-tsc-an4, + author = STM, + title = {AN4316: Tuning a STMTouch-based application}, + year = {2015}, + url = {http://www.st.com/resource/en/application_note/dm00088471.pdf}, + urldate = {2018-05-12} +} + + +% other articles +@article{all-about-dds, + title={All about direct digital synthesis}, + author={Eva Murphy, Colm Slattery}, + series={Ask The Application Engineer}, + volume={33}, + url={http://www.analog.com/media/en/analog-dialogue/volume-38/number-3/articles/all-about-direct-digital-synthesis.pdf}, + year={2004} +} + +@techreport{understanding-i2c, + author = {Jonathan Valdez, Jared Becker}, + title = {Understanding the I2C Bus}, + year = {2015}, + url = {http://www.ti.com/lit/an/slva704/slva704.pdf}, + urldate = {2018-05-12}, + organization = {Texas Instruments} +} + +@manual{i2c-spec, + title = {I2C-bus specification and user manual}, + author = {{NXP Semiconductors}}, + url = {https://www.nxp.com/docs/en/user-guide/UM10204.pdf}, + year = {2014}, + urldate = {2018-05-12} +} + +@manual{nrf-manual, + title = {nRF24L01+ Single Chip 2.4GHz Transceiver Product Specification v1.0}, + author = {{Nordic Semiconductor}}, + url = {http://www.nordicsemi.com/eng/content/download/2726/34069/file/nRF24L01P_Product_Specification_1_0.pdf}, + year = {2008}, + urldate = {2018-05-12} +} + +@manual{semtech-manual, + title = {SX1276/77/78/79 datasheet}, + author = {{Semtech Corporation}}, + url = {https://www.semtech.com/uploads/documents/DS_SX1276-7-8-9_W_APP_V5.pdf}, + year = {2016}, + urldate = {2018-05-12} +} + + +@manual{f072-rm, + title = {RM0091: STM32F0x1/STM32F0x2/STM32F0x8 reference manual}, + author = STM, + url = {http://www.st.com/resource/en/reference_manual/dm00031936.pdf}, + year = {2017}, + urldate = {2018-05-12} +} + +@manual{f072-ds, + title = {STM32F072x8/STM32F072xB datasheet}, + author = STM, + url = {http://www.st.com/resource/en/datasheet/stm32f072c8.pdf}, + year = {2017}, + urldate = {2018-05-12} +} + + +@manual{f103-rm, + title = {RM0008: STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx reference manual}, + author = STM, + url = {http://www.st.com/resource/en/reference_manual/cd00171190.pdf}, + year = {2009}, + urldate = {2018-05-12} +} + +@manual{f103-ds, + title = {STM32F103x8/STM32F103xB datasheet}, + author = STM, + url = {http://www.st.com/resource/en/datasheet/CD00161566.pdf}, + year = {2015}, + urldate = {2018-05-12} +} + +@online{pidcodes, + title = {pid.codes, a registry of USB PID codes for open source hardware projects}, + url = {http://pid.codes/}, + urldate = {2018-05-12} +} + +@online{eev-gpio-pu, + author = {{EEVblog Electronics Community Forum}}, + title = {pid.codes, a registry of USB PID codes for open source hardware projects}, + url = {https://www.eevblog.com/forum/projects/driving-the-1k5-usb-pull-up-resistor-on-d/}, + urldate = {2018-05-12} +} + + +% Figure sources + +@online{buspirate-product-page, + author = {{Seeed Technology Co.,Ltd.}}, + title = {Bus Pirate v4 product page}, + url = {https://www.seeedstudio.com/Bus-Pirate-v4-p-740.html}, + urldate = {2018-05-12} +} + +@online{nidevice1, + author = {{National Instruments}}, + title = {I²C/SPI Interface Device product page}, + url = {https://www.ni.com/en-gb/shop/select/i2c-spi-interface-device}, + urldate = {2018-05-12} +} + +@online{nidevice2, + author = {{National Instruments}}, + title = {USB-6008 product page}, + url = {http://www.ni.com/en-gb/support/model.usb-6008.html}, + urldate = {2018-05-12} +} + +@online{tphasedevice, + author = {{Total Phase, Inc.}}, + title = {USB-6008 product page}, + url = {https://www.totalphase.com/products/aardvark-i2cspi/}, + urldate = {2018-05-12} } diff --git a/thesis.pdf b/thesis.pdf index cdd39f8..a5c1df4 100644 Binary files a/thesis.pdf and b/thesis.pdf differ diff --git a/thesis.tex b/thesis.tex index 3c98cbd..4d1c3c4 100755 --- a/thesis.tex +++ b/thesis.tex @@ -8,7 +8,8 @@ \input{thesis.thanks} \input{thesis.declaration} -\addbibresource{thesis.bib} +%\addbibresource{thesis.bib} +\bibliography{thesis.bib} \input{thesis.acronyms} % --- vlastní dokument ---