forked from Imagelibrary/rtems
cpukit: Convert files to README.md MarkDown
This commit is contained in:
Amar Takhar
committed by
Joel Sherrill
Joel Sherrill
parent
9b4ac0aa64
commit
55a0356d7c
@@ -1,3 +1,5 @@
|
||||
TODO
|
||||
====
|
||||
- Tree traversal functions
|
||||
- Graft function
|
||||
- Complete libfdt.h documenting comments
|
||||
@@ -1,13 +1,11 @@
|
||||
=====================
|
||||
Copyright and License
|
||||
=====================
|
||||
---------------------
|
||||
|
||||
For Copyright and License of the source code, see the header in
|
||||
libi2c.c.
|
||||
|
||||
=========
|
||||
Overview
|
||||
========
|
||||
--------
|
||||
|
||||
This directory contains a general I2C/SPI API library. It offers a
|
||||
standard API to I2C or SPI based device drivers, abstracting the low
|
||||
@@ -19,23 +17,21 @@ In most cases throughout this document, i2c and spi devices are
|
||||
handled in a similar way. Therefore spi will not be explicitly named
|
||||
in every location.
|
||||
|
||||
=========
|
||||
|
||||
Features
|
||||
=========
|
||||
---------
|
||||
|
||||
+ supports multiple i2c and/or spi busses
|
||||
|
||||
+ supports multiple devices connected to each i2c/spi bus
|
||||
|
||||
+ handles bus and device registration to the I/O manager
|
||||
|
||||
=========
|
||||
Structure
|
||||
=========
|
||||
---------
|
||||
|
||||
This library defines a layered API to i2c and spi devices. The
|
||||
layering is:
|
||||
|
||||
```
|
||||
+----------------------------------------+
|
||||
6| Application |
|
||||
+----------------------------------------+
|
||||
@@ -52,6 +48,7 @@ layering is:
|
||||
1| i2c controller driver |
|
||||
| (in BSP) |
|
||||
+----------------------------------------+
|
||||
```
|
||||
|
||||
This document will describe the following interfaces in separate
|
||||
sections:
|
||||
@@ -68,9 +65,9 @@ sections:
|
||||
+ the interface between the libi2c low level abstraction layer and
|
||||
the i2c controller driver (2<->1)
|
||||
|
||||
===================================
|
||||
|
||||
Differences between i2c and spi bus
|
||||
===================================
|
||||
-----------------------------------
|
||||
SPI and I2C has many similarities, but also some differences:
|
||||
|
||||
- I2C uses inband addressing (the first bits sent select, which slave
|
||||
@@ -90,9 +87,8 @@ of serial data transmission, but care should be taken not to use
|
||||
features dedicated to the wrong type of serial bus.
|
||||
|
||||
|
||||
======================
|
||||
Library Initialization
|
||||
======================
|
||||
----------------------
|
||||
Before any libi2c API is used, the library must be initialized. This
|
||||
is achived with a call to function
|
||||
|
||||
@@ -127,9 +123,9 @@ For the time being, we must rely on the BSP (predriver_hook)
|
||||
to initialize the i2c system if it is used by other drivers
|
||||
(e.g., the RTC driver may have to use a i2c device).
|
||||
|
||||
===================
|
||||
|
||||
Bus Registration
|
||||
===================
|
||||
----------------
|
||||
Each i2c and/or spi bus available must be registerd with a call to
|
||||
|
||||
int rtems_libi2c_register_bus (char *name,
|
||||
@@ -150,9 +146,9 @@ subsequent calls to register devices attached to this bus (see below).
|
||||
Typically the BSP startup code will perform this registration for each
|
||||
bus available on the board.
|
||||
|
||||
==========================
|
||||
|
||||
Device/Driver Registration
|
||||
==========================
|
||||
--------------------------
|
||||
Each device attached to an i2c or spi bus must be registered with a
|
||||
call to
|
||||
|
||||
@@ -181,9 +177,9 @@ Note: If you have multiple devices of the same type, you must register
|
||||
each of them through a separate call (with the same "drvtbl", but
|
||||
different name/bus/i2caddr).
|
||||
|
||||
====================================================================
|
||||
|
||||
(5<->4) RTEMS I/O Manager and the libi2c OS adaption layer IF
|
||||
====================================================================
|
||||
-------------------------------------------------------------
|
||||
|
||||
The RTEMS I/O Manager regards the libi2c OS adaption layer as a normal
|
||||
RTEMS Device Driver with one unique major number and a set of minor
|
||||
@@ -192,6 +188,7 @@ the busses.
|
||||
|
||||
Therefore the libi2c OS adaption layer provides the standard calls:
|
||||
|
||||
```c
|
||||
static rtems_driver_address_table libi2c_io_ops = {
|
||||
initialization_entry: i2c_init,
|
||||
open_entry: i2c_open,
|
||||
@@ -200,6 +197,7 @@ static rtems_driver_address_table libi2c_io_ops = {
|
||||
write_entry: i2c_write,
|
||||
control_entry: i2c_ioctl
|
||||
};
|
||||
```
|
||||
|
||||
These calls perform some parameter checking and then call the
|
||||
appropriate high level i2c device driver function, if available,
|
||||
@@ -215,9 +213,8 @@ The main reason for the libi2c OS adaption layer is, that it
|
||||
dispatches the RTEMS I/O Manager calls to the proper device driver
|
||||
according to the minor number used.
|
||||
|
||||
====================================================================
|
||||
libi2c OS adaption layer and the high level i2c device driver IF
|
||||
====================================================================
|
||||
----------------------------------------------------------------
|
||||
|
||||
Each high level i2c device driver provides a set of functions in the
|
||||
rtems_libi2c_drv_t data structure passed the libi2c when the device is
|
||||
@@ -227,12 +224,12 @@ the RTEMS I/O Mangers calls "open", "close", "read", "write",
|
||||
needed may be omited (and replaced by a NULL pointer in
|
||||
rtems_libi2c_drv_t).
|
||||
|
||||
======================================================================
|
||||
high level i2c device driver and libi2c low level abstraction layer IF
|
||||
======================================================================
|
||||
----------------------------------------------------------------------
|
||||
libi2c provides a set of functions for the high level drivers. These
|
||||
functions are:
|
||||
|
||||
```c
|
||||
rtems_libi2c_send_start();
|
||||
rtems_libi2c_send_stop();
|
||||
rtems_libi2c_send_addr();
|
||||
@@ -241,6 +238,7 @@ rtems_libi2c_write_bytes();
|
||||
rtems_libi2c_start_read_bytes();
|
||||
rtems_libi2c_start_write_bytes();
|
||||
rtems_libi2c_ioctl();
|
||||
```
|
||||
|
||||
Please look into libi2c.h for the proper parameters and return codes.
|
||||
|
||||
@@ -248,23 +246,28 @@ These functions perform the proper i2c operations when called.
|
||||
|
||||
A typical access sequence for the I2C bus would be:
|
||||
|
||||
```c
|
||||
rtems_libi2c_send_start();
|
||||
rtems_libi2c_send_addr();
|
||||
rtems_libi2c_write_bytes();
|
||||
rtems_libi2c_send_stop();
|
||||
```
|
||||
|
||||
Alternatively, the rtems_libi2c_write_bytes() call could be relpaced
|
||||
with a
|
||||
rtems_libi2c_read_bytes()
|
||||
|
||||
```c
|
||||
rtems_libi2c_read_bytes()
|
||||
```
|
||||
call or a sequence of multiple calls.
|
||||
|
||||
Note: rtems_libi2c_send_start() locks the i2c/spi bus used, so no other
|
||||
device can use this i2c/spi bus, until rtems_libi2c_send_stop() function
|
||||
is called for the same device.
|
||||
|
||||
|
||||
Special provisions for SPI devices:
|
||||
===================================
|
||||
-----------------------------------
|
||||
For SPI devices and their drivers, the libi2c interface is used
|
||||
slightly differently:
|
||||
|
||||
@@ -284,25 +287,32 @@ the bus.
|
||||
|
||||
A typical access sequence for the SPI bus would be:
|
||||
|
||||
```c
|
||||
rtems_libi2c_send_start();
|
||||
rtems_libi2c_ioctl(...,RTEMS_LIBI2C_IOCTL_SET_TFRMODE,...);
|
||||
rtems_libi2c_send_addr();
|
||||
rtems_libi2c_write_bytes();
|
||||
rtems_libi2c_send_stop();
|
||||
```
|
||||
|
||||
Alternatively, the rtems_libi2c_write_bytes() call could be relpaced
|
||||
with a
|
||||
```c
|
||||
rtems_libi2c_read_bytes()
|
||||
```
|
||||
or a
|
||||
```c
|
||||
rtems_libi2c_ioctl(...,RTEMS_LIBI2C_IOCTL_READ_WRITE,...)
|
||||
```
|
||||
call or a sequence of multiple calls.
|
||||
|
||||
====================================================================
|
||||
|
||||
libi2c low level abstraction layer and i2c controller driver IF
|
||||
====================================================================
|
||||
---------------------------------------------------------------
|
||||
Each low level i2c/spi driver must provide a set of bus_ops functions
|
||||
as defined in the rtems_libi2c_bus_ops_t structure.
|
||||
|
||||
```c
|
||||
typedef struct rtems_libi2c_bus_ops_
|
||||
{
|
||||
/* Initialize the bus; might be called again to reset the bus driver */
|
||||
@@ -326,14 +336,17 @@ typedef struct rtems_libi2c_bus_ops_
|
||||
void *buffer;
|
||||
);
|
||||
} rtems_libi2c_bus_ops_t;
|
||||
```
|
||||
|
||||
Each of these functions performs the corresponding function to the i2c
|
||||
bus.
|
||||
|
||||
|
||||
Special provisions for SPI devices:
|
||||
===================================
|
||||
-----------------------------------
|
||||
For SPI busses, special behaviour is required:
|
||||
|
||||
```c
|
||||
(*send_start) (rtems_libi2c_bus_t * bushdl)
|
||||
normally is an empty function.
|
||||
|
||||
@@ -350,9 +363,9 @@ For SPI busses, special behaviour is required:
|
||||
|
||||
(*ioctl(...,RTEMS_LIBI2C_IOCTL_READ_WRITE,...)
|
||||
will send and receive data at the same time.
|
||||
```
|
||||
|
||||
Note:
|
||||
|
||||
- low-level I2C drivers normally are specific to the master
|
||||
device, but independent from the board hardware. So in many cases they
|
||||
can totally reside in libcpu or libchip.
|
||||
@@ -1,6 +1,9 @@
|
||||
mqueue
|
||||
======
|
||||
This program should print out the default attribute settings for a
|
||||
POSIX message queue.
|
||||
|
||||
```c
|
||||
#include <mqueue.h>
|
||||
#include <stdio.h>
|
||||
|
||||
@@ -31,4 +34,4 @@ main()
|
||||
(void) mq_close( mqfd );
|
||||
exit( 0 );
|
||||
}
|
||||
|
||||
```
|
||||
@@ -1,10 +1,11 @@
|
||||
Unlimited Local Node Objects
|
||||
============================
|
||||
|
||||
This document explains how the unlimited objects support works. This was
|
||||
written by Chris Johns <ccj@acm.org> of Objective Design Systems as a
|
||||
design document. This was submitted as part of the patch which added
|
||||
this capability.
|
||||
|
||||
Unlimited Local Node Objects
|
||||
============================
|
||||
|
||||
1. Why ?
|
||||
|
||||
@@ -356,5 +357,3 @@ o The Test
|
||||
|
||||
A new sample test, unlimited is provided. It attempts to test this
|
||||
change.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user