wip

ch.existing_solutions.tex

@@ -1,32 +1,32 @@
 \chapter{Existing Solutions}
 
-The idea of making it easier to interact with low level hardware from a PC is not new. Several solutions to this problem have been developed over the past years, each with its own advantages and drawbacks. Some of the existing solutions will be presented in this section.
+The idea of making it easier to interact with low level hardware from a PC is not new. Several solutions to this problem have been developed over the past years, each with its own advantages and drawbacks. Some of the existing solutions will be presented in this chapter to give the reader some idea about the current possibilities.
 
 \section{Bus Pirate}
 
-\todo{pictures}
+\todo[inline]{pictures}
 
-http://dangerousprototypes.com/blog/about/
+%http://dangerousprototypes.com/blog/about/
 
-Bus Pirate, developed by \todo{link}Ian Lesnet at Dangerous Prototypes and manufactured by Seeed Studio\todo{link}, is a "tinkering kit" providing access to hardware interfaces like SPI, I$^2$C, USART and 1-Wire (those will be described later  \todo{link to actual place}), as well as frequency measurement and direct pin access.
+Bus Pirate, developed by \todo{link}Ian Lesnet at Dangerous Prototypes and manufactured by Seeed Studio\todo{link}, is a USB-attached device providing access to hardware interfaces like SPI, I$^2$C, USART and 1-Wire (those will be described later  \todo{link to actual place}), as well as frequency measurement and direct pin access.
 
-The board aims to make it easy for the user to familiarize themself with new chips and modules; it also provides a range of programming interfaces for flashing microcontroller firmwares and memories. It communicates with the PC using a FTDI USB-serial bridge
+The board aims to make it easy for the 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 PC using a FTDI USB-serial bridge
 
 Bus Pirate is open source and in scope it is similar to what we want to achieve here. It can be scripted and controlled from languages like Python or Perl, connects to USB and provides a wide selection of hardware interfaces.
 
-The board is based on a PIC16 microcontroller running at 32\,MHz. Its analog/digital converter (ADC) only has a resolution of 10 bits (1024 levels). There is no digital/analog converter (DAC) available on the chip, making applications that require a varied output voltage more difficult. Another limitation of the board is its low number of GPIO pins which may be insufficient for certain applications, such as multi-channel sampling, parallel interfaces, or connecting multiple different devices at once.
+The board is based on a PIC16 microcontroller running at 32\,MHz. Its analog/digital converter (ADC) only has a resolution of 10 bits (1024 levels). There is no digital/analog converter (DAC) available on the chip, making applications that require a varied output voltage more difficult. Another limitation of the board is its low number of GPIO pins, which may be insufficient for certain applications, such as multi-channel sampling, parallel interfaces, or connecting multiple different devices at once. The Bus Pirate, at the time of writing, can be purchased for a price similar to some Raspberry Pi models.
-
-Those limitations, however, hardly impede on Bus Pirate's primary purpose, which is to provide an easy access to digital buses.
 
 \section{Raspberry Pi}
 
 \todo[inline]{link, pictures}
 
-Another device worth mentioning, albeit of a very different kind, is the Raspberry Pi. It is a belief of the author that the inclusion of a GPIO (\textit{general purpose I/O}) header on the Raspberry Pi mini-computers was a significant factor in their success in the hobbyist circles and school environments. This GPIO header exposes various hardware interfaces to user programs running on the computer.
+Another device worth mentioning, albeit of a different kind, is the Raspberry Pi. All models of the Raspberry Pi include a GPIO header which can be directly controlled by user applications. The pins broken out to this header can be used as general purpose I/O and some have alternate functions such as SPI or I$^2$C.
+
+The responsibility of controlling the attached external hardware lies on the user application, which also commonly provides the user interface, which greatly simplifies the development process. The control application can be written in almost any programming language. Python is a popular choice thanks to its simplicity, but it's by no means the only way to interact with the pins.
 
-The responsibility of controlling the experimental hardware then lies on the user application which also provides the user interface, much simplifying the development process. The control application can be written in almost any programming language the experimenter chooses; the most popular choices appear to be Python and JavaScript. The embedded firmware, should an external microcontroller be used instead, would typically have to be written in C, C++, or assembly.
+The Raspberry Pi is commonly used in primary schools as a low-cost PC alternative that encourage students' interest in electronics and science. The board is, further, often built into more permanent projects that make use of its powerful processor, such as camera traps for wildlife observations. 
 
-A disadvantage of using a Raspberry Pi's GPIO header is that the experiments would have to be conducted directly on the mini-computer instead of using the more powerful computer the researchers already have available\footnote{An exception may be the use of such a device in developing countries, where the Raspberry Pi serves as a low-cost PC on its own.}. This introduces complications with data export or remote control. Further, should the experiment use a software package like MATLAB, installing it on the ARM-based Raspberry Pi may prove problematic.
+The Raspberry Pi could be used for the quick evaluations or experiments we want to perform with GEX, however they would either have to be performed directly on the mini-computer itself (with attached monitor and keyboard), or use some form of remote access. 
 
 \section{The Firmata protocol}
 
@@ -41,8 +41,12 @@ Implementing the Firmata protocol in a universal hardware interfacing module wou
 
 \section{Professional DAQ modules}
 
-There are several offerings from professional laboratory instrument manufacturers, however their common property is a very high price. This renders them inaccessible for users with a limited budget, such as hobbyists or students who would like to keep such a device for personal use. An example falling into this category is the National Instruments "I²C/SPI Interface Device", which also includes several GPIO lines. 
+A range of professional tools that would fulfill our needs exist on the market,
+however their common property is a high price. This makes them inaccessible for users with a limited budget, such as hobbyists or students who would like to keep such a device for personal use. An example falling into this category is the National Instruments "I²C/SPI Interface Device", which also includes several GPIO lines, or some of the Total Phase I²C/SPI gadgets which sell for about \$300 a piece. 
+
+The performance GEX can provide will certainly be far inferior to those professional tools, however this drawback is balanced by its greater flexibility and for most applications it should be perfectly sufficient, and at a fraction of the cost.
 
 \todo[inline]{http://www.ni.com/en-gb/shop/select/i2c-spi-interface-device} 
 
-The decoding of hardware buses like USART, SPI or I²C is a common feature in digital storage oscilloscopes, as is the sampling of digital channels with "logic analyzer" add-ons. They are valuable debugging tools, but hardly ever provide a way to interact with the bus beyond passively intercepting an ongoing communication.
+\todo[inline]{pictures}
+

ch.freertos.tex

@@ -0,0 +1,2 @@
+\chapter{FreeRTOS}
+

ch.requirements.tex

@@ -8,7 +8,7 @@ The work's main objective is the implementation of a reconfigurable embedded fir
 
 Every project needs a memorable name. During the development, the name "GEX" was chosen, an acronym originating in the term \textit{GPIO Expander}, which, although not describing its scope perfectly, alludes to the project's primary purpose of providing low level GPIO capabilities to personal computers. The term GEX may be used through the text to refer to the whole project or hardware modules developed for it.
 
-\section{Expected Use-Cases}
+\section{Expected Use Cases}
 
 First, we must consider in which situations the module could be helpful. As we explained in the introduction, GEX should allow the user to connect digital sensors and electronic circuits to a PC and work with them using high level application software.
 
@@ -54,11 +54,53 @@ Some sensors have a variable frequency or a pulse-width modulated (PWM) output.
 
 \section{User Interface}
 
-USB will be the primary way of connecting the module to a PC. Thanks to USB's flexibility, GEX can present itself to the computer as any kind of device, or even multiple devices at once. 
+USB will be the primary way of connecting the module to a PC. Thanks to USB's flexibility, it can present itself to the computer as any kind of device or even multiple devices at once.
+
+The most straightforward method of interfacing the board is by passing binary messages in a fashion similar to USART. This can be done either using a "Virtual COM port" driver (the CDC/ACM class), or through a raw access to the corresponding USB endpoints. Using a raw access avoids potential problems with the operating system's driver interfering or not recognizing the device correctly; on the other hand, having GEX appear as a serial port makes it easier to integrate it into existing platforms that have a good serial port support (such as National Instruments LabWindows CVI or MATLAB).
+
+The module should be reconfigurable. Given the settings are almost always going to be tied on the connected external hardware, it would be practical to have an option to store them permanently in the microcontroller's non-volatile memory.
+
+We could load those settings into GEX using the serial interface, and indeed this should be implemented for its flexibility. The serial interface may be, in some form, also used for the wireless connection. However, having the power of USB at our disposal, we can make the board appear as a mass storage device and expose the configuration as text files. This approach, inspired by ARM mbed\footnote{A similar mechanism is used for flashing firmware images to mbed-enabled development kits}, avoids the need to create a configuration utility and it can work cross-platform thanks to using the same driver as a real removable disk. Further, we can expose any useful information (such as a README file with instructions, or a pin-out reference) using this virtual disk as separate files.
+
+\section{Form Factor and MCU Selection}
+
+It has been established that the designed device should be small and easily portable. It should support USB and wireless connection to a PC. Further, a plain UART interface should be offered in place of USB; this makes it easier to integrate GEX into other systems or use development kits fitted with a USB-UART converter.
+
+The following protocols and features should be implemented as a minimum; Other functions may be added based on input from prototype testing in model situations. 
+
+\begin{itemize}
+	\item Low level hardware functions
+		\begin{itemize}
+			\item I/O pin direct access
+			\item Input pin change reporting
+			\item Single pulse generation
+			\item PWM signal generation
+			\item Analog/Digital converter (analog input)
+			\item Digital/Analog converter (analog output)
+			\item Frequency measurement
+			\item Pulse measurement
+		\end{itemize}
+	\item Common hardware interfaces
+		\begin{itemize}
+			\item SPI
+			\item I$^2$C
+			\item UART/USART
+		\end{itemize}
+	\item Low level support for proprietary buses
+		\begin{itemize}
+			\item Dallas 1-Wire
+			\item NeoPixel (addressable LED strips)
+		\end{itemize}
+\end{itemize}
+
+Considering the requirements, availability, and cost, the STM32F072 microcontroller will be used for the first prototypes, with the expectation of later porting the project to more powerful or power-efficient devices, like the STM32L072, STM32F103, STM32F303, or other STM32 microcontrollers. 
+
+The STM32F072 is a Cortex M0 device with 128\,KiB of flash memory, 16\,KiB of RAM and running at up to of 48\,MHz. It is equipped with a USB Full Speed peripheral block, a 12-bit ADC and DAC, a number of general purpose timers/counters, SPI, I$^2$C, and USART peripherals. It further supports a crystal-less USB operation, using the USB SOF packet for synchronization.
+
+To utilize the time frame available for this work effectively, only the STM32F072 firmware will be initially developed, while making sure the planned future expansion will be as straightforward as possible.
+
+\todo[inline]{info about form factor choices + some sketches}
 
-The most straightforward method of interfacing the board is by passing binary messages in a fashion similar to USART. This can be done either using a "Virtual COM port" driver (the CDC/ACM class), or through a raw access to the corresponding USB endpoints. Using a raw access avoids potential problems with the operating system's driver interfering or not recognizing the device correctly; on the other hand, having GEX appear as a serial port makes it easier to integrate into older development platforms that have a good serial port support (such as National Instruments LabWindows CVI).
 
-As for configuring the module, given the possible permanent nature of the experimental setups built with it, it makes sense to store the settings inside its flash memory; it should at the same time be possible to temporarily change them as needed. 
 
-We could load those settings using the serial interface, and indeed this should be implemented for its flexibility. The serial interface will be, in some form, also used for the wireless connection. However, having the power of USB at our disposal, we can make the board appear as a mass storage device and expose the configuration as text files. This approach, inspired by ARM mbed\footnote{A similar mechanism is used for flashing firmware images to mbed-enabled development kits}, avoids the need to create a configuration utility and can work cross-platform thanks to using the same driver as a real removable disk. Further, we can expose any useful information (such as a README file with instructions, or a pin-out reference) using this virtual disk as separate files.
 

ch.usb.tex

@@ -1,9 +1,11 @@
 \chapter{Universal Serial Bus}
 
-This chapter presents an overview of the USB Full Speed interface, with focus on the features used in the GEX firmware. USB is a versatile but complex interface, thus explaining it in its entirety is beyond the scope of this text. References to external materials which explain the protocol in greater detail will be provided for the interested reader.\todo{add those refs}
+This chapter presents an overview of the \textit{Universal Serial Bus} (USB) \textit{Full Speed} interface, with focus on the features used in the GEX firmware. USB is a versatile but complex interface, thus explaining it in its entirety is beyond the scope of this text. References to external materials which explain the protocol in greater detail will be provided for the interested reader.\todo{add those refs}
 
 \section{Basic Principles and Terminology}
 
+%TODO add a diagram of the hierarchical topology
+
 USB is a hierarchical bus with a single master (\textit{host}) and multiple slave devices. A 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. 
 
 Endpoints can be either unidirectional or bidirectional; the direction from the host to a function is called \textit{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.
@@ -22,11 +24,22 @@ The endpoint transfer type and other characteristics, together with other inform
 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.
 %TODO add reference to the document
 
+%TODO fix: massive gap here
+
 %function - https://technet.microsoft.com/en-us/library/cc939102.aspx
 
+\newpage
+\input{fig.gex-descriptors}
+
 \section{USB Physical Layer}
 
-USB uses differential signaling with NRZI encoding (\textit{Non Return to Zero Inverted}) and bit stuffing. The encoding, together with frame formatting, checksum verification, retransmission, and other low level aspects of the USB connection are entirely handled by the USB 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 PCB design.
+USB uses differential signaling with NRZI encoding (\textit{Non Return to Zero Inverted}, fig. \ref{fig:nrzi}) and bit stuffing. The encoding, together with frame formatting, checksum verification, retransmission, and other low level aspects of the USB connection are entirely handled by the USB 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 PCB design.
+
+\begin{wrapfigure}[4]{r}{0.4\textwidth}
+	\centering
+	\includegraphics[width=0.3\textwidth]{img/usb-nrzi-diagram.png}
+	\caption{\label{fig:nrzi}NRZI encoding example}
+\end{wrapfigure}
 
 The USB cable contains 4 conductors:
 
@@ -37,14 +50,23 @@ The USB cable contains 4 conductors:
 	\item Ground
 \end{itemize}
 
-D+ and D-- are commonly labeled DP and DM. The differential pair should be routed in parallel and keep approximately the same length. The USB speed is determined by the presence of a 1.5\,k$\Omega$ pull-up resistor to 3.3\,V on one of the data lines: for Low Speed, D-- is pulled high, for Full Speed it's the D+ line. The polarity of the differential signals is inverted depending on the used speed. Some microcontrollers integrate the correct pull-up resistor inside the USB block, removing the need for an external resistor.
+The data lines, D+ and D--, are also commonly labeled DP and DM. This differential pair should be routed in parallel and kept at approximately the same length.
 
-When the function needs the host to re-enumerate it, that is, reload the descriptors and re-attach the correct drivers, it can momentarily remove the pull-up resistor. In the case of an internal pull-up, this can be done by flipping a control bit. An external resistor could be connected through a transistor to facilitate re-enumeration, or it might be driven directly by a GPIO pin.
+USB revisions are, where possible, backwards compatible, often even keeping the same connector shape. The bus speed is negotiated 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 (fig. \label{fig:usb-pullup-fs}), for Low Speed the pull-up is on the D-- line. The polarity of the differential signals is inverted depending on the used speed. Some microcontrollers integrate the correct pull-up resistor inside the USB block, removing the need for an external resistor.
+
+
+\begin{figure}
+	\centering
+	\includegraphics[width=\textwidth]{img/usb-pullup-fs.png}
+	\caption{\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}
+\end{figure}
+
+When a function needs the host to re-enumerate it, that is, 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. In the case of an internal pull-up, this can be done by flipping a control bit. An external resistor could be connected through a transistor to facilitate re-enumeration, or it might be driven directly by a GPIO pin. 
 
 %https://www.eevblog.com/forum/projects/driving-the-1k5-usb-pull-up-resistor-on-d/
 %http://www.beyondlogic.org/usbnutshell/usb2.shtml
 
-The V$_\mathrm{BUS}$ line provides a power supply to the function in the case of \textit{bus-powered} devices. \textit{Self-powered} devices can leave this pin unconnected and instead use an external power supply. The current that can be drawn from the V$_\mathrm{BUS}$ line is configured using a descriptor and should not be exceeded. However, this limitation is often not enforced, especially when USB hubs are used, and can't be relied upon as a safety measure.
+The V$_\mathrm{BUS}$ line supplies power to the function in the case of a \textit{bus-powered} device. \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.
 
 \section{USB Classes}
 
@@ -89,6 +111,8 @@ Since it's creation, the USB specification expected that each function will have
 
 To use the IAD, the function's class must be set to 239 (EFh), subclass 2, protocol 1 (in the top level descriptor), so the OS knows to look for the presence of IADs before binding drivers to any interfaces. 
 
+% TODO link to some references..
+
 In GEX, the IAD is used to tie together the CDC and ACM interfaces while leaving out the 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 MSC and CDC/ACM implementations.
 
 %http://www.usb.org/developers/docs/whitepapers/iadclasscode_r10.pdf

document_config.tex

@@ -11,6 +11,8 @@
 \usepackage{siunitx}
 \usepackage{sectsty}
 \usepackage{titlecaps}
+\usepackage{cprotect}
+\usepackage{framed}
 
 \usepackage{bigfoot} % verbatin in footnote
 

fig.gex-descriptors.tex

@@ -0,0 +1,138 @@
+\hspace*{-1.5em}
+\begin{minipage}[t]{0.5\textwidth}\scriptsize
+\begin{verbatim}
+Device Descriptor:
+  bLength                18
+  bDescriptorType         1
+  bcdUSB               2.00
+  bDeviceClass          239 Miscellaneous Device
+  bDeviceSubClass         2 
+  bDeviceProtocol         1 Interface Association
+  bMaxPacketSize0        64
+  idVendor           0x0483 STMicroelectronics
+  idProduct          0x572a 
+  bcdDevice            0.01
+  iManufacturer           1 MightyPork
+  iProduct                2 GEX
+  iSerial                 3 0029002F-42365711-32353530
+  bNumConfigurations      1
+  Configuration Descriptor:
+    bLength                 9
+    bDescriptorType         2
+    wTotalLength           98
+    bNumInterfaces          3
+    bConfigurationValue     1
+    iConfiguration          0 
+    bmAttributes         0x80
+      (Bus Powered)
+    MaxPower              500mA
+    Interface Descriptor:
+      bLength                 9
+      bDescriptorType         4
+      bInterfaceNumber        0
+      bAlternateSetting       0
+      bNumEndpoints           2
+      bInterfaceClass         8 Mass Storage
+      bInterfaceSubClass      6 SCSI
+      bInterfaceProtocol     80 Bulk-Only
+      iInterface              4 Settings VFS
+      Endpoint Descriptor:
+        bLength                 7
+        bDescriptorType         5
+        bEndpointAddress     0x81  EP 1 IN
+        bmAttributes            2
+          Transfer Type            Bulk
+          Synch Type               None
+          Usage Type               Data
+        wMaxPacketSize     0x0040  1x 64 bytes
+        bInterval               0
+      Endpoint Descriptor:
+        bLength                 7
+        bDescriptorType         5
+        bEndpointAddress     0x01  EP 1 OUT
+        bmAttributes            2
+          Transfer Type            Bulk
+          Synch Type               None
+          Usage Type               Data
+        wMaxPacketSize     0x0040  1x 64 bytes
+        bInterval               0
+    Interface Association:
+      bLength                 8
+      bDescriptorType        11
+      bFirstInterface         1
+      bInterfaceCount         2
+      bFunctionClass          2 Communications
+      bFunctionSubClass       2 Abstract (modem)
+      bFunctionProtocol       1 AT-commands (v.25ter)
+      iFunction               5 Virtual Comport ACM
+\end{verbatim}
+\end{minipage}\hspace{1em}
+\begin{minipage}[t]{0.5\textwidth}\scriptsize
+\begin{verbatim}
+    Interface Descriptor:
+      bLength                 9
+      bDescriptorType         4
+      bInterfaceNumber        1
+      bAlternateSetting       0
+      bNumEndpoints           1
+      bInterfaceClass         2 Communications
+      bInterfaceSubClass      2 Abstract (modem)
+      bInterfaceProtocol      1 AT-commands (v.25ter)
+      iInterface              5 Virtual Comport ACM
+      CDC Header:
+        bcdCDC               1.10
+      CDC Call Management:
+        bmCapabilities       0x00
+        bDataInterface          2
+      CDC ACM:
+        bmCapabilities       0x06
+          sends break
+          line coding and serial state
+      CDC Union:
+        bMasterInterface        1
+        bSlaveInterface         2 
+      Endpoint Descriptor:
+        bLength                 7
+        bDescriptorType         5
+        bEndpointAddress     0x83  EP 3 IN
+        bmAttributes            3
+          Transfer Type            Interrupt
+          Synch Type               None
+          Usage Type               Data
+        wMaxPacketSize     0x0008  1x 8 bytes
+        bInterval             255
+    Interface Descriptor:
+      bLength                 9
+      bDescriptorType         4
+      bInterfaceNumber        2
+      bAlternateSetting       0
+      bNumEndpoints           2
+      bInterfaceClass        10 CDC Data
+      bInterfaceSubClass      0 
+      bInterfaceProtocol      0 
+      iInterface              6 Virtual Comport CDC
+      Endpoint Descriptor:
+        bLength                 7
+        bDescriptorType         5
+        bEndpointAddress     0x02  EP 2 OUT
+        bmAttributes            2
+          Transfer Type            Bulk
+          Synch Type               None
+          Usage Type               Data
+        wMaxPacketSize     0x0040  1x 64 bytes
+        bInterval               0
+      Endpoint Descriptor:
+        bLength                 7
+        bDescriptorType         5
+        bEndpointAddress     0x82  EP 2 IN
+        bmAttributes            2
+          Transfer Type            Bulk
+          Synch Type               None
+          Usage Type               Data
+        wMaxPacketSize     0x0040  1x 64 bytes
+        bInterval               0
+\end{verbatim}
+\end{minipage}\vspace{-1em}
+\begin{figure}[H]
+	\cprotect\caption{USB descriptors of a GEX prototype, read using \verb|lsusb -vd vid:pid|}
+\end{figure}

img/usb-nrzi-diagram.txt

@@ -0,0 +1,3 @@
+https://mobilewill.us/wp-content/uploads/2016/04/Introduction20to20USB203.020Protocol.pdf
+Introduction to SuperSpeed USB 3.0 Protocol
+Ankur Tomar & Edmund Lim – Global Technology Centre, Volume 1, April 2011

img/usb-pullup-fs.txt

@@ -0,0 +1,3 @@
+USB ENGINEERING CHANGE NOTICE
+Pull-up/pull-down resistors
+Universal Serial Bus Specification Revision 2.0

thesis.tex

@@ -20,6 +20,10 @@
 \input{ch.requirements}
 \input{ch.existing_solutions}
 \input{ch.usb}
+\input{ch.freertos}
+\input{ch.fat16}
+\input{ch.gex_units}
+\input{ch.prototype1_hw}
 
 \appendix % začátek příloh