diff options
author | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2011-01-09 18:37:11 +0000 |
---|---|---|
committer | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2011-01-09 18:37:11 +0000 |
commit | a236d30ab4764c205dea249a82f790730902d62a (patch) | |
tree | 696f0a0c11f72a822aed10b9c21e4c8ab7b41f26 | |
parent | f0d6a1e75dfe8f9a2ce65100725d889a97275f75 (diff) | |
download | nuttx-a236d30ab4764c205dea249a82f790730902d62a.tar.gz nuttx-a236d30ab4764c205dea249a82f790730902d62a.tar.bz2 nuttx-a236d30ab4764c205dea249a82f790730902d62a.zip |
Add LCD driver documentation
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@3239 42af7a65-404d-4744-a932-0658087f49c3
-rw-r--r-- | nuttx/Documentation/NuttxPortingGuide.html | 368 |
1 files changed, 282 insertions, 86 deletions
diff --git a/nuttx/Documentation/NuttxPortingGuide.html b/nuttx/Documentation/NuttxPortingGuide.html index c392167ed..c2ed3b4d1 100644 --- a/nuttx/Documentation/NuttxPortingGuide.html +++ b/nuttx/Documentation/NuttxPortingGuide.html @@ -118,10 +118,11 @@ <a href="#i2cdrivers">6.3.3 I2C Device Drivers</a><br> <a href="#serialdrivers">6.3.4 Serial Device Drivers</a><br> <a href="#fbdrivers">6.3.5 Frame Buffer Drivers</a><br> - <a href="#mtddrivers">6.3.6 Memory Technology Device Drivers</a><br> - <a href="#sdiodrivers">6.3.7 SDIO Device Drivers</a><br> - <a href="#usbhostdrivers">6.3.8 USB Host-Side Drivers</a><br> - <a href="#usbdevdrivers">6.3.9 USB Device-Side Drivers</a><br> + <a href="#lcddrivers">6.3.6 LCD Drivers</a><br> + <a href="#mtddrivers">6.3.7 Memory Technology Device Drivers</a><br> + <a href="#sdiodrivers">6.3.8 SDIO Device Drivers</a><br> + <a href="#usbhostdrivers">6.3.9 USB Host-Side Drivers</a><br> + <a href="#usbdevdrivers">6.3.10 USB Device-Side Drivers</a><br> </ul> </ul> <a href="#apndxconfigs">Appendix A: NuttX Configuration Settings</a><br> @@ -1128,7 +1129,7 @@ The system can be re-made subsequently by just typing <code>make</code>. is defined. </p> -<p><b>Inputs</b>:</p? +<p><b>Inputs</b>:</p> <ul> <li> <code>tcb</code>: The TCB of new task. @@ -1719,10 +1720,13 @@ extern void up_ledoff(int led); </p> <ul> <li> + <p> <b><code>include/nuttx/fs.h</code></b>. All structures and APIs needed to work with character drivers are provided in this header file. + </p> </li> <li> + <p> <b><code>struct file_operations</code></b>. Each character device driver must implement an instance of <code>struct file_operations</code>. That structure defines a call table with the following methods: @@ -1735,23 +1739,30 @@ extern void up_ledoff(int led); <code>int ioctl(FAR struct file *filp, int cmd, unsigned long arg);</code><br> <code>int poll(FAR struct file *filp, struct pollfd *fds, bool setup);</code></p> </ul> + </p> </li> <li> + <p> <b><code>int register_driver(const char *path, const struct file_operations *fops, mode_t mode, void *priv);</code></b>. Each character driver registers itself by calling <code>register_driver()</code>, passing it the <code>path</code> where it will appear in the <a href="#NxFileSystem">pseudo-file-system</a> and it's initialized instance of <code>struct file_operations</code>. + </p> </li> <li> + <p> <b>User Access</b>. After it has been registered, the character driver can be accessed by user code using the standard <a href="NuttxUserGuide.html#driveroperations">driver operations</a> including <code>open()</code>, <code>close()</code>, <code>read()</code>, <code>write()</code>, etc. + </p> </li> <li> + <p> <b>Examples</b>: <code>drivers/dev_null.c</code>, <code>drivers/fifo.c</code>, <code>drivers/serial.c</code>, etc. - </li> + </p> + </li> </ul> <h2><a name="blockdrivers">6.2 Block Device Drivers</a></h2> @@ -1761,10 +1772,13 @@ extern void up_ledoff(int led); </p> <ul> <li> + <p> <b><code>include/nuttx/fs.h</code></b>. All structures and APIs needed to work with block drivers are provided in this header file. + </p> </li> <li> + <p> <b><code>struct block_operations</code></b>. Each block device driver must implement an instance of <code>struct block_operations</code>. That structure defines a call table with the following methods: @@ -1776,34 +1790,45 @@ extern void up_ledoff(int led); <code>int geometry(FAR struct inode *inode, FAR struct geometry *geometry);</code><br> <code>int ioctl(FAR struct inode *inode, int cmd, unsigned long arg);</code></p> </ul> + </p> </li> <li> + <p> <b><code>int register_blockdriver(const char *path, const struct block_operations *bops, mode_t mode, void *priv);</code></b>. Each block driver registers itself by calling <code>register_blockdriver()</code>, passing it the <code>path</code> where it will appear in the <a href="#NxFileSystem">pseudo-file-system</a> and it's initialized instance of <code>struct block_operations</code>. + </p> </li> <li> + <p> <b>User Access</b>. Users do not normally access block drivers directly, rather, they access block drivers indirectly through the <code>mount()</code> API. The <code>mount()</code> API binds a block driver instance with a file system and with a mountpoint. Then the user may use the block driver to access the file system on the underlying media. <i>Example</i>: See the <code>cmd_mount()</code> implementation in <code>examples/nsh/nsh_fscmds.c</code>. + </p> </li> <li> + <p> <b>Accessing a Character Driver as a Block Device</b>. See the loop device at <code>drivers/loop.c</code>. <i>Example</i>: See the <code>cmd_losetup()</code> implementation in <code>examples/nsh/nsh_fscmds.c</code>. + </p> </li> <li> + <p> <b>Accessing a Block Driver as Character Device</b>. See the Block-to-Character (BCH) conversion logic in <code>drivers/bch/</code>. <i>Example</i>: See the <code>cmd_dd()</code> implementation in <code>examples/nsh/nsh_ddcmd.c</code>. + </p> </li> <li> + <p> <b>Examples</b>. <code>drivers/loop.c</code>, <code>drivers/mmcsd/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc. + </p> </li> </ul> @@ -1813,18 +1838,24 @@ extern void up_ledoff(int led); <ul> <li> + <p> <b><code>include/net/uip/uip-arch.h</code></b>. All structures and APIs needed to work with Ethernet drivers are provided in this header file. The structure <code>struct uip_driver_s</code> defines the interface and is passed to uIP via <code>netdev_register()</code>. + </p> </li> <li> + <p> <b><code>int netdev_register(FAR struct uip_driver_s *dev);</code></b>. Each Ethernet driver registers itself by calling <code>netdev_register()</code>. + </p> </li> <li> + <p> <b>Examples</b>: <code>drivers/net/dm90x0.c</code>, <code>arch/drivers/arm/src/c5471/c5471_ethernet.c</code>, <code>arch/z80/src/ez80/ez80_emac.c</code>, etc. + </p> </li> </ul> @@ -1832,10 +1863,13 @@ extern void up_ledoff(int led); <ul> <li> + <p> <b><code>include/nuttx/spi.h</code></b>. All structures and APIs needed to work with SPI drivers are provided in this header file. + </p> </li> <li> + <p> <b><code>struct spi_ops_s</code></b>. Each SPI device driver must implement an instance of <code>struct spi_ops_s</code>. That structure defines a call table with the following methods: @@ -1849,21 +1883,28 @@ extern void up_ledoff(int led); <code>uint16_t send(FAR struct spi_dev_s *dev, uint16_t wd);</code><br> <code>void exchange(FAR struct spi_dev_s *dev, FAR const void *txbuffer, FAR void *rxbuffer, size_t nwords);</code><br> <p><code>int registercallback(FAR struct spi_dev_s *dev, mediachange_t callback, void *arg);</code></p> - </ul> - <li> - <b>Binding SPI Drivers</b>. - SPI drivers are not normally directly accessed by user code, but are usually bound to another, - higher level device driver. - See for example, <code>int mmcsd_spislotinitialize(int minor, int slotno, FAR struct spi_dev_s *spi)</code> in <code>drivers/mmcsd/mmcsd_spi.c</code>. - In general, the binding sequence is: - <ul> - <li>Get an instance of <code>struct spi_dev_s</code> from the hardware-specific SPI device driver, and </li> - <li>Provide that instance to the initialization method of the higher level device driver.</li> </ul> + </p> + <li> + <p> + <b>Binding SPI Drivers</b>. + SPI drivers are not normally directly accessed by user code, but are usually bound to another, + higher level device driver. + See for example, <code>int mmcsd_spislotinitialize(int minor, int slotno, FAR struct spi_dev_s *spi)</code> in <code>drivers/mmcsd/mmcsd_spi.c</code>. + In general, the binding sequence is: + </p> + <p> + <ol> + <li>Get an instance of <code>struct spi_dev_s</code> from the hardware-specific SPI device driver, and </li> + <li>Provide that instance to the initialization method of the higher level device driver.</li> + </ol> + </p> </li> <li> - <b>Examples</b>: - <code>drivers/loop.c</code>, <code>drivers/mmcsd/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc. + <p> + <b>Examples</b>: + <code>drivers/loop.c</code>, <code>drivers/mmcsd/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc. + </p> </li> </ul> @@ -1871,10 +1912,13 @@ extern void up_ledoff(int led); <ul> <li> + <p> <b><code>include/nuttx/i2c.h</code></b>. All structures and APIs needed to work with I2C drivers are provided in this header file. + </p> </li> <li> + <p> <b><code>struct i2c_ops_s</code></b>. Each I2C device driver must implement an instance of <code>struct i2c_ops_s</code>. That structure defines a call table with the following methods: @@ -1883,20 +1927,27 @@ extern void up_ledoff(int led); <code>int setaddress(FAR struct i2c_dev_s *dev, int addr, int nbits);</code><br> <code>int write(FAR struct i2c_dev_s *dev, const uint8_t *buffer, int buflen);</code><br> <code>int read(FAR struct i2c_dev_s *dev, uint8_t *buffer, int buflen);</code></p> + </p> </ul> <li> - <b>Binding I2C Drivers</b>. - I2C drivers are not normally directly accessed by user code, but are usually bound to another, - higher level device driver. - In general, the binding sequence is: - <ul> - <li>Get an instance of <code>struct i2c_dev_s</code> from the hardware-specific I2C device driver, and </li> - <li>Provide that instance to the initialization method of the higher level device driver.</li> - </ul> + <p> + <b>Binding I2C Drivers</b>. + I2C drivers are not normally directly accessed by user code, but are usually bound to another, + higher level device driver. + In general, the binding sequence is: + </p> + <p> + <ol> + <li>Get an instance of <code>struct i2c_dev_s</code> from the hardware-specific I2C device driver, and </li> + <li>Provide that instance to the initialization method of the higher level device driver.</li> + </ol> + </p> </li> <li> - <b>Examples</b>: - <code>arch/z80/src/ez80/ez80_i2c.c</code>, <code>arch/z80/src/z8/z8_i2c.c</code>, etc. + <p> + <b>Examples</b>: + <code>arch/z80/src/ez80/ez80_i2c.c</code>, <code>arch/z80/src/z8/z8_i2c.c</code>, etc. + </p> </li> </ul> @@ -1904,10 +1955,13 @@ extern void up_ledoff(int led); <ul> <li> + <p> <b><code>include/nuttx/serial.h</code></b>. All structures and APIs needed to work with serial drivers are provided in this header file. + </p> </li> <li> + <p> <b><code>struct uart_ops_s</code></b>. Each serial device driver must implement an instance of <code>struct uart_ops_s</code>. That structure defines a call table with the following methods: @@ -1925,22 +1979,29 @@ extern void up_ledoff(int led); <code>bool txready(FAR struct uart_dev_s *dev);</code><br> <code>bool txempty(FAR struct uart_dev_s *dev);</code></p> </ul> + </p> </li> <li> + <p> <b><code>int uart_register(FAR const char *path, FAR uart_dev_t *dev);</code></b>. A serial driver may register itself by calling <code>uart_register()</code>, passing it the <code>path</code> where it will appear in the <a href="#NxFileSystem">pseudo-file-system</a> and it's initialized instance of <code>struct uart_ops_s</code>. By convention, serial device drivers are registered at paths like <code>/dev/ttyS0</code>, <code>/dev/ttyS1</code>, etc. See the <code>uart_register()</code> implementation in <code>drivers/serial.c</code>. + </p> </li> <li> + <p> <b>User Access</b>. Serial drivers are, ultimately, normal <a href="#chardrivers">character drivers</a> and are accessed as other character drivers. + </p> </li> <li> + <p> <b>Examples</b>: <code>arch/arm/src/chip/lm3s_serial.c</code>, <code>arch/arm/src/lpc214x/lpc214x_serial.c</code>, <code>arch/z16/src/z16f/z16f_serial.c</code>, etc. + </p> </li> </ul> @@ -1948,13 +2009,17 @@ extern void up_ledoff(int led); <ul> <li> - <b><code>include/nuttx/fb.h</code></b>. - All structures and APIs needed to work with frame buffer drivers are provided in this header file. + <p> + <b><code>include/nuttx/fb.h</code></b>. + All structures and APIs needed to work with frame buffer drivers are provided in this header file. + </p> </li> <li> - <b><code>struct fb_vtable_s</code></b>. - Each frame buffer device driver must implement an instance of <code>struct fb_vtable_s</code>. - That structure defines a call table with the following methods: + <p> + <b><code>struct fb_vtable_s</code></b>. + Each frame buffer device driver must implement an instance of <code>struct fb_vtable_s</code>. + That structure defines a call table with the following methods: + </p> <p> Get information about the video controller configuration and the configuration of each color plane. </p> @@ -1964,7 +2029,7 @@ extern void up_ledoff(int led); </ul> <p> The following are provided only if the video hardware supports RGB color mapping: - </p? + </p> <ul> <p><code>int (*getcmap)(FAR struct fb_vtable_s *vtable, FAR struct fb_cmap_s *cmap);</code><br> <code>int (*putcmap)(FAR struct fb_vtable_s *vtable, FAR const struct fb_cmap_s *cmap);</code></p> @@ -1978,33 +2043,144 @@ extern void up_ledoff(int led); </ul> </li> <li> - <b>Binding Frame Buffer Drivers</b>. - Frame buffer drivers are not normally directly accessed by user code, but are usually bound to another, - higher level device driver. - In general, the binding sequence is: + <p> + <b>Binding Frame Buffer Drivers</b>. + Frame buffer drivers are not normally directly accessed by user code, but are usually bound to another, + higher level device driver. + In general, the binding sequence is: + </p> + <p> + <ol> + <li>Get an instance of <code>struct fb_vtable_s</code> from the hardware-specific frame buffer device driver, and </li> + <li>Provide that instance to the initialization method of the higher level device driver.</li> + </ol> + </p> + </li> + <li> + <p> + <b>Examples</b>: + <code>arch/sim/src/up_framebuffer.c</code>. + See also the usage of the frame buffer driver in the <code>graphics/</code> directory. + </p> + </li> +</ul> + +<h3><a name="lcddrivers">6.3.6 LCD Drivers</a></h3> + +<ul> + <li> + <p> + <b><code>include/nuttx/lcd/lcd.h</code></b>. + Structures and APIs needed to work with LCD drivers are provided in this header file. + This header file also depends on some of the same definitions used for the frame buffer driver as privided in <code>include/nuttx/fb.h</code>. + </p> + </li> + <li> + <p> + <b><code>struct lcd_dev_s</code></b>. + Each LCD device driver must implement an instance of <code>struct lcd_dev_s</code>. + That structure defines a call table with the following methods: + </p> + <p> + Get information about the LCD video controller configuration and the configuration of each LCD color plane. + </p> + <ul> + <p> + <code>int (*getvideoinfo)(FAR struct lcd_dev_s *dev, FAR struct fb_videoinfo_s *vinfo);</code><br> + <code>int (*getplaneinfo)(FAR struct lcd_dev_s *dev, unsigned int planeno, FAR struct lcd_planeinfo_s *pinfo);</code> + </p> + </ul> + <p> + The following are provided only if the video hardware supports RGB color mapping: + </p> + <ul> + <p> + <code>int (*getcmap)(FAR struct lcd_dev_s *dev, FAR struct fb_cmap_s *cmap);</code><br> + <code>int (*putcmap)(FAR struct lcd_dev_s *dev, FAR const struct fb_cmap_s *cmap);</code> + </p> + </ul> + <p> + The following are provided only if the video hardware supports a hardware cursor: + </p> <ul> - <li>Get an instance of <code>struct fb_vtable_s</code> from the hardware-specific frame buffer device driver, and </li> - <li>Provide that instance to the initialization method of the higher level device driver.</li> + <p> + <code>int (*getcursor)(FAR struct lcd_dev_s *dev, FAR struct fb_cursorattrib_s *attrib);</code><br> + <code>int (*setcursor)(FAR struct lcd_dev_s *dev, FAR struct fb_setcursor_s *settings)</code> + </p> </ul> + <p> + Get the LCD panel power status (0: full off - <code>CONFIG_LCD_MAXPOWER</code>: full on). + On backlit LCDs, this setting may correspond to the backlight setting. + </p> + <ul> + <p> + <code>int (*getpower)(struct lcd_dev_s *dev);</code> + </p> + </ul> + <p> + Enable/disable LCD panel power (0: full off - <code>CONFIG_LCD_MAXPOWER</code>: full on). + On backlit LCDs, this setting may correspond to the backlight setting. + </p> + <ul> + <p> + <code>int (*setpower)(struct lcd_dev_s *dev, int power);</code> + </p> + </ul> + <p> + Get the current contrast setting (0-CONFIG_LCD_MAXCONTRAST) */ + </p> + <ul> + <p> + <code>int (*getcontrast)(struct lcd_dev_s *dev);</code> + </p> + </ul> + <p> + Set LCD panel contrast (0-CONFIG_LCD_MAXCONTRAST) + </p> + <ul> + <p> + <code>int (*setcontrast)(struct lcd_dev_s *dev, unsigned int contrast);</code> + </p> + </ul> + </p> + <li> + <p> + <b>Binding LCD Drivers</b>. + LCD drivers are not normally directly accessed by user code, but are usually bound to another, + higher level device driver. + In general, the binding sequence is: + </p> + <p> + <ol> + <li>Get an instance of <code>struct lcd_dev_s</code> from the hardware-specific LCD device driver, and </li> + <li>Provide that instance to the initialization method of the higher level device driver.</li> + </ol> + </p> </li> <li> - <b>Examples</b>: - <code>arch/sim/src/up_framebuffer.c</code>. - See also the usage of the frame buffer driver in the <code>graphics/</code> directory. + <p> + <b>Examples</b>: + <code>drivers/lcd/nokia6100.c</code>, <code>drivers/lcd/p14201.c</code>, <code>configs/sam3u-ek/src/up_lcd.c.</code> + See also the usage of the LCD driver in the <code>graphics/</code> directory. + </p> </li> </ul> -<h3><a name="mtddrivers">6.3.6 Memory Technology Device Drivers</a></h3> +<h3><a name="mtddrivers">6.3.7 Memory Technology Device Drivers</a></h3> <ul> <li> - <b><code>include/nuttx/mtd.h</code></b>. - All structures and APIs needed to work with MTD drivers are provided in this header file. + <p> + <b><code>include/nuttx/mtd.h</code></b>. + All structures and APIs needed to work with MTD drivers are provided in this header file. + </p> </li> <li> - <b><code>struct mtd_dev_s</code></b>. - Each MTD device driver must implement an instance of <code>struct mtd_dev_s</code>. - That structure defines a call table with the following methods: + <p> + <b><code>struct mtd_dev_s</code></b>. + Each MTD device driver must implement an instance of <code>struct mtd_dev_s</code>. + That structure defines a call table with the following methods: + </p> <p> Erase the specified erase blocks (units are erase blocks): </p> @@ -2013,7 +2189,7 @@ extern void up_ledoff(int led); </ul> <p> Read/write from the specified read/write blocks: - </p? + </p> <ul> <p><code>ssize_t (*bread)(FAR struct mtd_dev_s *dev, off_t startblock, size_t nblocks, FAR uint8_t *buffer);</code><br> <code>ssize_t (*bwrite)(FAR struct mtd_dev_s *dev, off_t startblock, size_t nblocks, FAR const uint8_t *buffer);</code></p> @@ -2042,32 +2218,42 @@ extern void up_ledoff(int led); </ul> </li> <li> - <b>Binding MTD Drivers</b>. - MTD drivers are not normally directly accessed by user code, but are usually bound to another, - higher level device driver. - In general, the binding sequence is: - <ul> - <li>Get an instance of <code>struct mtd_dev_s</code> from the hardware-specific MTD device driver, and </li> - <li>Provide that instance to the initialization method of the higher level device driver.</li> - </ul> + <p> + <b>Binding MTD Drivers</b>. + MTD drivers are not normally directly accessed by user code, but are usually bound to another, + higher level device driver. + In general, the binding sequence is: + </p> + <p> + <ol> + <li>Get an instance of <code>struct mtd_dev_s</code> from the hardware-specific MTD device driver, and </li> + <li>Provide that instance to the initialization method of the higher level device driver.</li> + </ol> + </p> </li> <li> - <b>Examples</b>: - <code>drivers/mtd/m25px.c</code> and <code>drivers/mtd/ftl.c</code> + <p> + <b>Examples</b>: + <code>drivers/mtd/m25px.c</code> and <code>drivers/mtd/ftl.c</code> + </p> </li> </ul> -<h3><a name="sdiodrivers">6.3.7 SDIO Device Drivers</a></h3> +<h3><a name="sdiodrivers">6.3.8 SDIO Device Drivers</a></h3> <ul> <li> - <b><code>include/nuttx/sdio.h</code></b>. - All structures and APIs needed to work with SDIO drivers are provided in this header file. + <p> + <b><code>include/nuttx/sdio.h</code></b>. + All structures and APIs needed to work with SDIO drivers are provided in this header file. + </p> </li> <li> - <b><code>struct sdio_dev_s</code></b>. - Each SDIOI device driver must implement an instance of <code>struct sdio_dev_s</code>. - That structure defines a call table with the following methods: + <p> + <b><code>struct sdio_dev_s</code></b>. + Each SDIOI device driver must implement an instance of <code>struct sdio_dev_s</code>. + That structure defines a call table with the following methods: + </p> <p> Initialization/setup: </p> @@ -2114,27 +2300,35 @@ extern void up_ledoff(int led); </ul> </li> <li> - <b>Binding SDIO Drivers</b>. - SDIO drivers are not normally directly accessed by user code, but are usually bound to another, - higher level device driver. - In general, the binding sequence is: - <ul> - <li>Get an instance of <code>struct sdio_dev_s</code> from the hardware-specific SDIO device driver, and </li> - <li>Provide that instance to the initialization method of the higher level device driver.</li> - </ul> + <p> + <b>Binding SDIO Drivers</b>. + SDIO drivers are not normally directly accessed by user code, but are usually bound to another, + higher level device driver. + In general, the binding sequence is: + </p> + <p> + <ol> + <li>Get an instance of <code>struct sdio_dev_s</code> from the hardware-specific SDIO device driver, and </li> + <li>Provide that instance to the initialization method of the higher level device driver.</li> + </ol> + </p> </li> <li> - <b>Examples</b>: - <code>arch/arm/src/stm32/stm32_sdio.c</code> and <code>drivers/mmcsd/mmcsd_sdio.c</code> + <p> + <b>Examples</b>: + <code>arch/arm/src/stm32/stm32_sdio.c</code> and <code>drivers/mmcsd/mmcsd_sdio.c</code> + </p> </li> </ul> -<h3><a name="usbhostdrivers">6.3.8 USB Host-Side Drivers</a></h3> +<h3><a name="usbhostdrivers">6.3.9 USB Host-Side Drivers</a></h3> <ul> <li> - <b><code>include/nuttx/usb/usbhost.h</code></b>. - All structures and APIs needed to work with USB host-side drivers are provided in this header file. + <p> + <b><code>include/nuttx/usb/usbhost.h</code></b>. + All structures and APIs needed to work with USB host-side drivers are provided in this header file. + </p> </li> <li> <p> @@ -2215,7 +2409,7 @@ extern void up_ledoff(int led); In general, the binding sequence is: </p> <p> - <ul> + <ol> <li> <p> Each USB host class driver includes an intialization entry point that is called from the @@ -2249,17 +2443,19 @@ extern void up_ledoff(int led); See the call to <code>register_blockdriver()</code> in the function <code>usbhost_initvolume()</code> in the file <code>drivers/usbhost/usbhost_storage.c</code>. </p> </li> - </ul> + </ol> </p> </li> </ul> -<h3><a name="usbdevdrivers">6.3.9 USB Device-Side Drivers</a></h3> +<h3><a name="usbdevdrivers">6.3.10 USB Device-Side Drivers</a></h3> <ul> <li> - <b><code>include/nuttx/usb/usbdev.h</code></b>. - All structures and APIs needed to work with USB device-side drivers are provided in this header file. + <p> + <b><code>include/nuttx/usb/usbdev.h</code></b>. + All structures and APIs needed to work with USB device-side drivers are provided in this header file. + </p> </li> <li> <p> @@ -2294,7 +2490,7 @@ extern void up_ledoff(int led); In general, the binding sequence is: </p> <p> - <ul> + <ol> <li> <p> Each USB device class driver includes an intialization entry point that is called from the @@ -2313,7 +2509,7 @@ extern void up_ledoff(int led); completing the initialization. </p> </li> - </ul> + </ol> </p> </li> </ul> |