Fixed three issues with the SPI driver for the LPC1549 platform:

* The TXDATCTL register was used even if only the control signals were
  modified which caused extra data to be transmitted.

* The RXDAT register does not only contain the received data, but also
  control information in bits 16 to 20. The old code did not mask out
  the control information and in rare cases that would cause the returned
  data to include too much information (i.e. received 0xaa as data but the
  function returned 0x300aa).

* The LPC1549 uses a Switch Matric (SWM) to allow any pin to have any
  function. This is not used in the old code which simply assigned
  the first instance of the SPI class to SPI0 and the second instance to
  SPI1. The third instance would result in a call to error().

  This behaviour is not at all working with real world examples where the
  SPI bus contains more than two peripherals. The third peripheral would
  cause the platform to end up in error().

  The solution is to modify the get_available_spi() function to first see
  if the MISO/MOSI/SCLK and SSEL pins are already configured for use as
  either SPI0 or SPI1. If the exact same pins are already used then the
  SPIx will be reused. If one or more pins are different then another
  SPIx will be used (or if both are alredy in use then error()). With this
  change it is now possible to do this:

  MyFlash      f(D11,D12,D13);      // Will use SPI0
  MyTemp       t(D11,D12,D13);      // Will use SPI0
  SDFileSystem s(D11,D12,D13,"sd"); // Will use SPI0
  MyDisplay    d(D11,D12,D13);      // Will use SPI0

  The old/existing code would have resulted in this

  MyFlash      f(D11,D12,D13);      // Will use SPI0
  MyTemp       t(D11,D12,D13);      // Will use SPI1
  SDFileSystem s(D11,D12,D13,"sd"); // error()
  MyDisplay    d(D11,D12,D13);      // Will never be called
Merge branch 'master' of https://github.com/mbedmicro/mbed
moved PeripheralNames.h to target folder (set new target values to 0)
Moved peripheral PinMap declarations to PeripheralPins.c
Deleted duplicate mbed_overrides.c
Merge pull request #412 from sg-/master

[MTS_GAMBIT] Add new target support
Merge pull request #413 from lindvalla/fix_spi_on_lpc1549

Fixed three issues with the SPI driver for the LPC1549 platform:
Bugfix: Replaced magic value of UNDEF test result with proper const name
Added pseudo random seed source from compiler -D option
Changed copyright date to 2014
Fix KL25Z connect problem with some USB 3.0 hosts

This change fixes a problem I've encountered using the Freescale KL25Z as a USB client device when attaching to a USB 3.0 port on a host PC.  I've personally observed the problem on two PCs, one a Dell running Windows 8.1 and the other a custom-built Windows 7 machine with a Gigabyte mobo.  Several other people on the Web have reported what appears to be the same problem.  It even appears to happen with some Macs - so it's apparently not Windows-specific or Windows-version-specific.  But it does seem to be USB 3.0 specific, and one report speculated that the common element is the Intel Haswell chip set on the host side.

The problem can be worked around by using USB 2.1 ports (many PCs have a mix of 2.1 and 3.0 port hardware) or by connecting a USB 2.1 hub between the device and host.  I have USB 2.1 ports on both of my testing machines, and this solution does work for me.  But I wanted to fix it at the software level if possible, so that my project would work for people who might only have USB 3.0 ports available.

I tracked down the problem to a timing issue that seems to cause the device and host to get out of sync with respect to flow direction on the USB connection during the initial handshake. It seems that the host can issue a CONTROL OUT token at a point where the client is trying to send the response for a previous CONTROL IN token. I found a note in some USB 3.0 reference material that this situation can occur, and that the client can resolve it by sending a zero-length ACK, which tells the host that the client isn't ready and that the host request should be repeated. 

My fix sends a zero-length reply in USBDevice::controlOut() when the control flow error is detected, and also explicitly sends the pending CONTROL_IN packet.  This appears to fix it reliably on my machine.  I'm not entirely confident about the fix, though, since I don't feel I understand the USB protocol or the mbed code in enough depth.  I'm submitting the change here in the hope that someone with a deeper knowledge of the mbed code can determine if this is a good fix, and if not can hopefully use it as the starting point for a better solution.  

Note that I submitted the same pull request via the mbed source control system, but I was advised by another mbed user that I should also submit it directly on github.  Apologies for any confusion caused by the redundant submissions.
Added STM32F411RE to list
Added simple random seed provider.
Small refactoring for SD card tests for TARGET_K64F platform
FAT library will be now built to .a / .ar separate folder. New switch -f / --fat is introduced for build.py script
Had duplicate set of api drivers in the directory - deleted
added define guards to xxxxx_api.c files for device.h peripheral gating
Sleep fix + some device.h settings

LPC1114 has no semihosting and also no localfilesystem. I took the
liberty of guessing the LPC11Cxx also don't have those.

Sleep code did nothing outside of locking up the microcontroller
(because semihosting was enabled). Code seems to be copied from
LPC11u24, but the LPC1114 is fundamentally different. (For example
deep-sleep bit is now the deep-powerdown bit, which you dont want).

Aditionally it keeps current peripheral state during deepsleep and when
waking up. Datasheet rates LPC1114 at 6uA in deepsleep, I measured it at
3.7uA. That makes me a happy panda.
Bugfix: Make redirected stdio write initialize UART

Calling a scanf before the first printf would end up calling serial_getc without initializing the UART.
Change F411 to Cortex-M4F instead of Cortex-M4
Added "M4F"

Several listed as Cortex M4 cores are actually M4F cores (having a floating point unit), I did some homework to figure out which ones have FPU's. It appears that the K20D50M is the only board with a Cortex-M4 MCU that is does not have a floating point unit.
Merge pull request #416 from sg-/master

Had duplicate set of api drivers in the directory - deleted
Merge pull request #419 from 23chrischen/master

Change F411 to Cortex-M4F instead of Cortex-M4