ez80: Add *PTR definitions to inttypes.h

Add architecture-specific inttypes.h

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.