atomic: add atomic ops

Based on the nice set of atomic ops for the Linux kernel, a standard
atomic operations API is provided, along with an implementation for
ARMv7-M.

There is a general atomic.h file to include, which will automatically
include the appropriate arch-dependent implementation of the API.

Change-Id: I50578a6ea695b5fe174c38bf08d20d7307454069
obj: initial obj implementation

Again taking a page from the Linux kernel, I have added an "obj"
and an API to interact with it. Similar to a kobj, an obj serves
as an easy and standard way to make something reference counted
and named. Each obj also has a "type", which describes how to
unpack the container from the obj and what to do with the obj
when its reference count reaches zero. It also has a parent, for
when it and its containing struct are associated with something else.

Differing from kobj though, an obj also has a void* to "ops".
These "ops" will make more sense later, but they are essentially
used when a group of objs all have the same purpose and/or support the
same set of operations, but all have their own implementations.

It's kind of like the specific "methods" on a bunch of things that
all implement a common "interface"

Change-Id: I214716d2486e7d0d6853824ef13f77c5b4d21b69
obj: classes and collections

This commit adds 2 important features: classes and collections.

Collections are nothing more than a group of objs, but they handle
iteration and locking internally, so you don't have to. Abstracting
away the synchronization and enumeration of collections will allow
enhancements to accessing these groups without affecting the API and
anywhere it's used.

Classes are a bit stranger. The purpose of a class is to be able to
easily interact with a certain "type" of obj. A class has an obj type
and destructor associated with it, and a collection it maintains.
One can "instantiate" a class with a specific set of ops, and that
obj goes onto the classes collection. Classes are named as well.
Why would this be useful? Think about a certain type of sensor, like
an accelerometer. An "accelerometer" class would define a set of ops
that each accelerometer must support, and could maintain a named
collection of every accelerometer in the system, making it easy
to use any accelerometer. The person writing the driver for a specific
accelerometer would only need to implement the standard set of ops
for their particular chip, and instantiate a new accelerometer with
those ops from the standard class, and it would be visible to the
entire system.

Comments in header files have more info.

Change-Id: Ic59b00731ce65877f2ac7b8ccecb89831c89e27b
obj: initial systems implementation

A system is the basis of raw access to devices and other system structures.

A system is simply a collection of classes (and by definition their
instances) meant for some common purpose.

Change-Id: Iae038c8d5de7fe1a7b8cdfdbd0d9e63b5b584162
obj: make it build!

cleaner offset_of and makefile additions to build all this cool new stuff

Change-Id: Iafdbe95bb76b8a0e95aaaa10f95f378659853914
systems: add system_ctl program

A very basic initial implementation, which allows access to view the
contents of systems.

Change-Id: I2a109cfc8d4c08e48907ee9c47086bfe3a0a170d
dev: add device construct

A device describes a physical device connected to some physical parent.
By including a struct device in a device's data structure, a standard
mechanism for finding the parent is provided.

Change-Id: I9efb9e9d019a2ff8b770deab848cfd5e046c49c4
dev: spi class

Provide a generic SPI class using the obj device framework.

Instead of providing a SPI API, use the obj framework to define a
SPI class, of which physical SPI implementations will be a member of.
Devices on a SPI bus will have a SPI object as their parent, and will
use that object's ops for all communications.

Remove the SPI API; all drivers should switch to the obj device framework.

Change-Id: Ic660b7fafdf40fee74aeef936f793b7545b4bc3a
stm32f4: obj SPI driver

Convert the existing STM32F4 SPI driver to the new obj-based SPI class.
Instead of using the SPI api, drivers should now keep a reference to the
SPI object of the bus they are on, and use its ops for interactions.

For now, all of the supported SPI ports are listed in an array, and
initialized at boot.

Change-Id: I2f9f9e2e66e3f4b65966880933b4f3448a82018d
dev: accelerometer class

Implement a generic accelerometer class using the obj device framework.

This class provides a common interface to any accelerometer, abstracting
away the implementation details of specific accelerometers.

Change-Id: Ibee46110558b122cc6961e6dc31727e6ea2e4d05
periph: LIS302DL accelerometer

Convert the STM32F4 Discovery accelerometer driver to a generic LIS302DL
accelerometer driver using the obj driver framework.

Change-Id: I65cb0243a408775bd4457c96755cd7d05a8cc0a4
DO NOT SUBMIT: temp: disable px4 MPU6000

It has not converted to the new SPI implementation, so does not
currently build.

Change-Id: I0b4606cb965d2a686db2eded8c2fb766971d0ee7
shell: generic accelerometer shell program

Convert the Discovery accelerometer shell program to a generic
accelerometer reading program, capable of reading from any
accelerometer.

For now, it is hard coded to the LIS302DL

XXX: For now, don't build the lowpass shell program

Change-Id: I40a637f517b1d130f1dab05497e92c0a01068200
atomic: provide load_link and store_conditional

Provide load_link and store_conditional macros to allow programs to make
generic use of load link/store conditional semantics in whatever manner
they need.

Change-Id: Icdcac1716f2706e9207bc6d6b2ef872683722587
stm32f4: use load_link/store_conditional for GPIOs

Make GPIO register accesses thread-safe by using
load_link/store_conditional semantics to ensure that the registers have
not been modified.

Change-Id: I5c3f8339b1707cc569e11be9916d66affd82741a
dev: gpio class

Provide a generic GPIO class to build a common interface to GPIOs.

Several methods support implementation-dependent extensions for
supporting extra features available in some drivers.

Change-Id: I58ed36f7123be6ac79c9d0dc89a2d0908daa7e9d
stm32f4: gpio driver

Provide a standard GPIO driver for the stm32f4 using the obj driver
framework.

Change-Id: I357c2d68b1b3b6dff2030157c58391120ee67778
dev: generic LED driver

The LED driver is a simple wrapper around the GPIO driver.  A few
board-specific files provide an array of the GPIOs used as LEDs, then
the led_ wrapper functions can be used to get one of the LEDs by index,
and enable, disable, and toggle it.

Since the LED GPIOs are now objs, the power LED cannot be enabled until
after the heap in initialized.

Change-Id: I1374488acb2d5f5084762cfdc4eb23871d2dc9f9
shell: update blink LED API

Update blink to use the new LED API.  This means explicitly getting the
LEDs be toggling them.  Since the periodic tasks never end, the LEDs are
never led_put back.

Change-Id: I594dc796d41e391d91f595aa9d7aaec02f3c2953
spi: update to use GPIO objs for chip select

struct spi_dev has been updated to contain a struct GPIO for chip
select.  This GPIO should be configured by the child driver, such that
the SPI driver need only set the GPIO to 0 to active the CS line, and 1
to deactivate it.

Change-Id: I696eeb2a7e025bababd0a5a85d6dd53c2b2ab575