Add LCD driver documentation
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@3239 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo
parent
3c7c2266e6
commit
bb77d00e75
@ -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,22 +1739,29 @@ 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.
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
@ -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:
|
||||
@ -1850,20 +1884,27 @@ extern void up_ledoff(int led);
|
||||
<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>
|
||||
</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:
|
||||
<ul>
|
||||
</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>
|
||||
</ul>
|
||||
</ol>
|
||||
</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>
|
||||
|
||||
@ -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>
|
||||
<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:
|
||||
<ul>
|
||||
</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>
|
||||
</ul>
|
||||
</ol>
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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:
|
||||
<ul>
|
||||
</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>
|
||||
</ul>
|
||||
</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="mtddrivers">6.3.6 Memory Technology Device Drivers</a></h3>
|
||||
<h3><a name="lcddrivers">6.3.6 LCD 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/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>
|
||||
<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>
|
||||
<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.7 Memory Technology Device Drivers</a></h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<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>
|
||||
<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>
|
||||
<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:
|
||||
<ul>
|
||||
</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>
|
||||
</ul>
|
||||
</ol>
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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:
|
||||
<ul>
|
||||
</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>
|
||||
</ul>
|
||||
</ol>
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user