diff options
Diffstat (limited to 'nuttx/Documentation/NuttxPortingGuide.html')
-rw-r--r-- | nuttx/Documentation/NuttxPortingGuide.html | 254 |
1 files changed, 252 insertions, 2 deletions
diff --git a/nuttx/Documentation/NuttxPortingGuide.html b/nuttx/Documentation/NuttxPortingGuide.html index 1934e9bb6..eea76434f 100644 --- a/nuttx/Documentation/NuttxPortingGuide.html +++ b/nuttx/Documentation/NuttxPortingGuide.html @@ -12,7 +12,7 @@ <h1><big><font color="#3c34ec"> <i>NuttX RTOS Porting Guide</i> </font></big></h1> - <p>Last Updated: May 9, 2009</p> + <p>Last Updated: May 21, 2009</p> </td> </tr> </table> @@ -104,6 +104,18 @@ </ul> </ul> <a href="#NxFileSystem">5.0 NuttX File System</a><br> + <a href="#DeviceDrivers">6.0 NuttX Device Drivers</a><br> + <ul> + <a href="#chardrivers">6.1 Character Device Drivers</a><br> + <a href="#blockdrivers">6.2 Block Device Drivers</a><br> + <a href="#blockdrivers">6.3 Specialized Device Drivers</a> + <ul> + <a href="#ethdrivers">6.3.1 Ethernet Device Drivers</a><br> + <a href="#spidrivers">6.3.2 SPI Device Drivers</a><br> + <a href="#i2cdrivers">6.3.3 I2C Device Drivers</a><br> + <a href="#serialdrivers">6.3.4 Serial Device Drivers</a> + </ul> + </ul> <a href="#apndxconfigs">Appendix A: NuttX Configuration Settings</a><br> <a href="#apndxtrademarks">Appendix B: Trademarks</a> </ul> @@ -1624,6 +1636,243 @@ extern void up_ledoff(int led); <table width ="100%"> <tr bgcolor="#e4e4e4"> <td> + <h1><a name="DeviceDrivers">6.0 NuttX Device Drivers</a></h1> + </td> + </tr> +</table> + +<p> + NuttX supports a variety of device drivers including: + <ul> + <li><i>Character</i> Device Drivers,</li> + <li><i>Block</i> Device Drivers, and</li> + <li>Other <i>Specialized</i> Drivers.</li> + </ul> + As discussed in the following paragraphs. +</p> + +<h2><a name="chardrivers">6.1 Character Device Drivers</a></h2> + +<p> + Character device drivers have these properties: +</p> +<ul> + <li> + <b><code>include/nuttx/fs.h</code></b>. + All structures and APIs needed to work with character drivers are provided in this header file. + </li> + <li> + <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: + <ul> + <p><code>int open(FAR struct file *filp);</code></p> + <p><code>int close(FAR struct file *filp);</code></p> + <p><code>ssize_t read(FAR struct file *filp, FAR char *buffer, size_t buflen);</code></p> + <p><code>ssize_t write(FAR struct file *filp, FAR const char *buffer, size_t buflen);</code></p> + <p><code>off_t seek(FAR struct file *filp, off_t offset, int whence);</code></p> + <p><code>int ioctl(FAR struct file *filp, int cmd, unsigned long arg);</code></p> + <p><code>int poll(FAR struct file *filp, struct pollfd *fds, boolean setup);</code></p> + </ul> + </li> + <li> + <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>. + </li> + <li> + <b>User Access</b>. + After it has been registered, the character driver can be accessed by user code using the standard functions <code>open()</code>, <code>close()</code>, <code>read()</code>, <code>write()</code>, etc. + </li> + <li> + <b>Examples</b>. + <code>drivers/dev_null.c</code>, <code>drivers/fifo.c</code>, <code>drivers/serial.c</code>, etc. + </li> +</ul> + +<h2><a name="blockdrivers">6.2 Block Device Drivers</a></h2> + +<p> + Block device drivers have these properties: +</p> +<ul> + <li> + <b><code>include/nuttx/fs.h</code></b>. + All structures and APIs needed to work with block drivers are provided in this header file. + </li> + <li> + <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: + <ul> + <p><code>int open(FAR struct inode *inode);</code></p> + <p><code>int close(FAR struct inode *inode);</code></p> + <p><code>ssize_t read(FAR struct inode *inode, FAR unsigned char *buffer, size_t start_sector, unsigned int nsectors);</code></p> + <p><code>ssize_t write(FAR struct inode *inode, FAR const unsigned char *buffer, size_t start_sector, unsigned int nsectors);</code></p> + <p><code>int geometry(FAR struct inode *inode, FAR struct geometry *geometry);</code></p> + <p><code>int ioctl(FAR struct inode *inode, int cmd, unsigned long arg);</code></p> + </ul> + </li> + <li> + <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>. + </li> + <li> + <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. + <b>Example:</b> See the <code>cmd_mount()</code> implementation in <code>examples/nsh/nsh_fscmds.c</code>. + </li> + <li> + <b>Accessing a Character Driver as a Block Device</b>. + See the loop device at <code>drivers/loop.c</code>. + <b>Example:</b> See the <code>cmd_losetup()</code> implementation in <code>examples/nsh/nsh_fscmds.c</code>. + </li> + <li> + <b>Accessing a Block Driver as Character Device</b>. + See the Block-to-Character (BCH) conversion logic in <code>drivers/bch/</code>. + <b>Example:</b> See the <code>cmd_dd()</code> implementation in <code>examples/nsh/nsh_ddcmd.c</code>. + </li> + <li> + <b>Examples</b>. + <code>drivers/loop.c</code>, <code>drivers/mmcds/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc. + </li> +</ul> + +<h2><a name="blockdrivers">6.3 Specialized Device Drivers</a></h2> + +<h3><a name="ethdrivers">6.3.1 Ethernet Device Drivers</a></h3> + +<ul> + <li> + <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>. + </li> + <li> + <b><code>int netdev_register(FAR struct uip_driver_s *dev);</code></b>. + Each Eterhenet driver registers itself by calling <code>netdev_register()</code>. + </li> + <li> + <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. + </li> +</ul> + +<h3><a name="spidrivers">6.3.2 SPI Device Drivers</a></h3> + +<ul> + <li> + <b><code>include/nuttx/spi.h</code></b>. + All structures and APIs needed to work with SPI drivers are provided in this header file. + </li> + <li> + <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: + <ul> + <p><code>void select(FAR struct spi_dev_s *dev, enum spi_dev_e devid, boolean selected);</code></p> + <p><code>uint32 setfrequency(FAR struct spi_dev_s *dev, uint32 frequency);</code></p> + <p><code>void setmode(FAR struct spi_dev_s *dev, enum spi_mode_e mode);</code></p> + <p><code>void setbits(FAR struct spi_dev_s *dev, int nbits);</code></p> + <p><code>ubyte status(FAR struct spi_dev_s *dev, enum spi_dev_e devid);</code></p> + <p><code>uint16 send(FAR struct spi_dev_s *dev, uint16 wd);</code></p> + <p><code>void exchange(FAR struct spi_dev_s *dev, FAR const void *txbuffer, FAR void *rxbuffer, size_t nwords);</code></p> + <p><codei>nt 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>. + </li> + <li> + <b>Examples</b>. + <code>drivers/loop.c</code>, <code>drivers/mmcds/mmcsd_spi.c</code>, <code>drivers/ramdisk.c</code>, etc. + </li> +</ul> + +<h3><a name="i2cdrivers">6.3.3 I2C Device Drivers</a></h3> + +<ul> + <li> + <b><code>include/nuttx/i2c.h</code></b>. + All structures and APIs needed to work with I2C drivers are provided in this header file. + </li> + <li> + <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: + <ul> + <p><code>uint32 setfrequency(FAR struct i2c_dev_s *dev, uint32 frequency);</code></p> + <p><code>int setaddress(FAR struct i2c_dev_s *dev, int addr, int nbits);</code></p> + <p><code>int write(FAR struct i2c_dev_s *dev, const ubyte *buffer, int buflen);</code></p> + <p><code>int read(FAR struct i2c_dev_s *dev, ubyte *buffer, int buflen);</code></p> + </ul> + <li> + <b>Binding I2C Drivers</b>. + SPI drivers are not normally directly accessed by user code, but are usually bound to another, + higher level device driver. + </li> + <li> + <b>Examples</b>. + <code>arch/z80/src/ez80/ez80_i2c.c</code>, <code>arch/z80/src/z8/z8_i2c.c</code>, etc. + </li> +</ul> + +<h3><a name="serialdrivers">6.3.4 Serial Device Drivers</a></h3> + +<ul> + <li> + <b><code>include/nuttx/serial.h</code></b>. + All structures and APIs needed to work with serial drivers are provided in this header file. + </li> + <li> + <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: + <ul> + <p><code>int setup(FAR struct uart_dev_s *dev);</code></p> + <p><code>void shutdown(FAR struct uart_dev_s *dev);</code></p> + <p><code>int attach(FAR struct uart_dev_s *dev);</code></p> + <p><code>void detach(FAR struct uart_dev_s *dev);</code></p> + <p><code>int ioctl(FAR struct file *filep, int cmd, unsigned long arg);</code></p> + <p><code>int receive(FAR struct uart_dev_s *dev, unsigned int *status);</code></p> + <p><code>void rxint(FAR struct uart_dev_s *dev, boolean enable);</code></p> + <p><code>boolean rxavailable(FAR struct uart_dev_s *dev);</code></p> + <p><code>void send(FAR struct uart_dev_s *dev, int ch);</code></p> + <p><code>void txint(FAR struct uart_dev_s *dev, boolean enable);</code></p> + <p><code>boolean txready(FAR struct uart_dev_s *dev);</code></p> + <p><code>boolean txempty(FAR struct uart_dev_s *dev);</code></p> + </ul> + </li> + <li> + <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 pathes like <code>/dev/ttyS0</code>, <code>/dev/ttyS1</code>, etc. + See the <code>uart_register()</code> implementation in <code>drivers/serial.c</code>. + </li> + <li> + <b>User Access</b>. + Serial drivers are, ultimately, normal <a href="#chardrivers">character drivers</a> and are accessed as other character drivers. + </li> + <li> + <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. + </li> +</ul> + +<table width ="100%"> + <tr bgcolor="#e4e4e4"> + <td> <h1><a name="apndxconfigs">Appendix A: NuttX Configuration Settings</a></h1> </td> </tr> @@ -2255,9 +2504,10 @@ extern void up_ledoff(int led); </tr> </table> - <li>ARM, ARM7 ARM7TDMI, ARM9, ARM926EJS are trademarks of Advanced RISC Machines, Limited.</li> + <li>ARM, ARM7 ARM7TDMI, ARM9, ARM920T, ARM926EJS, Cortex-M3 are trademarks of Advanced RISC Machines, Limited.</li> <li>Cygwin is a trademark of Red Hat, Incorporated.</li> <li>Linux is a registered trademark of Linus Torvalds.</li> + <li>Eagle-100 is a trademark of <a href=" http://www.micromint.com/">Micromint USA, LLC</a>. <li>LPC2148 is a trademark of NXP Semiconductors.</li> <li>TI is a tradename of Texas Instruments Incorporated.</li> <li>UNIX is a registered trademark of The Open Group.</li> |