Correct time initialization for the case where time is initialized from settings in the .config file.  The correct range for month (tm_mon) internally is 0-11, not 1-12 as it is in the .config file.

Correct clock initialization.  The correct range for the month is 0-11 but is entered as 1-12 in the .config file

Revert "Correct a problem in clock_gettime(CLOCK_REALTIME, &time); which is ahead by 1 month of the specified CONFIG_START_MONTH"

I don't believe this change is correct in general.  Nomralling clock_isleapyear() is called with tm_mon which is in the range of 0-11.  That change would be bad for that range.  It would make sense for a range of 1-12, but that is not how tm_mon is defined.

This reverts commit 1796a25e.

Correct a problem in clock_gettime(CLOCK_REALTIME, &time); which is ahead by 1 month of the specified CONFIG_START_MONTH

Merged in david_s5/nuttx-7/david_s5/stm32f76xx77xx_pinmaph-missed-one-1477516213180 (pull request #158)

stm32f76xx77xx_pinmap.h Missed one

stm32_i2c.c Dejavu

Within the OS, when a thread obtains a semaphore count it must call sem_addholder() if CONFIG_PRIORITY_INHERITANCE is enabled.  If a count is available, then sem_wait() calls sem_addholder(), otherwise it waited for the semaphore and called sem_addholder() when it eventually received the count.

This caused a problem when the thread calling sem_wait() was very low priority.  When it received the count, there may be higher priority threads "hogging" the CPU that prevent the lower priority task from running and, as a result, the sem_addholder() may be delayed indefinitely.

The fix was to have sem_post() call sem_addholder() just before restarting the thread waiting for the semaphore count.

This problem was noted by Benix Vincent who also suggested the solution.

CHxN channels are always outputs

Initial implemention of the STM32 F37xx SDADC module. There are also changes to ADC, DAC modules. SDADC has only been tested in DMA mode and does not support external TIMER triggers. This is a work in progress.

Enable and renames for 32l4 UARTs 4 and 5

Fix i2c devices rcc registers

STM32 F4 I2c: A new implementation of the STM32 F4 I2C bottom half.  The commin I2C as this did not handled correctly in the current implementation (see also https://github.com/PX4/NuttX/issues/54).  The changes almost exclusively affect the ISR.