Adding MAXWSNENV platform.

[jeremybrodt]

Adding support for the Maxim Integrated MAXWSNENV platform.

[0xc0170]

currently default can be ARM or uARM (for online IDE)

[jeremybrodt]

What is the difference between ARM and uARM? I'm not sure which we should use.

[0xc0170]

Here's the link for explanation : http://www.keil.com/support/man/docs/armlib/armlib_chr1358938938431.htm

[0xc0170]

@jeremybrodt Can you provide some details for deep-sleep function?

There's rtc used as time keeper. How many bits does the counter has for your platform ? How does this can be implemented for other platforms with rtc only 24 bit ? Or, Nordic rtc cant be set, the counter is read only for instance. What options did u consider for deepsleep function? Firing all scheduled events before going to deepsleep?
How this deepsleep implement would change if we add another ticker based on low power timer like rtc?

[jeremybrodt]

On our platform, the timer used for the us_ticker is not clocked in deepsleep. We must use the RTC to generate a time based wakeup. Our RTC is 32-bits.

Why would this need to be implemented on other platforms? From what I have seen, it appears the us_ticker continues to operate on other platforms. I simply added this functionality so the us_ticker wouldn't break when going into deepsleep.

If you added another, low-power ticker, then we would change this implementation appropriately. The us_ticker time would still need to be updated after wakeup based on the elapsed RTC time, since it is not clocked in deepsleep.

[Sissors]

For other platforms us_ticker stops operating in deepsleep. Well on the NRF one it should continue, but every other one has no active ticker in deepsleep. I like your solution, but it is different behavior than others, so probably something which needs to be considered :).

Especially added with what that new mythical low-power API is going to bring.

[jeremybrodt]

So do I need to remove the RTC code from deepsleep and just let the us_ticker die? This will make our BLE applications more complicated since we will have to manage this at a higher level.

[0xc0170]

@jeremybrodt Can keep it for now, but we should look at this more closer to unify it.

I will review the other changes.

[0xc0170]

This can be merged. There are some conflicts, can you resolve them ?

I got one more comment, to xxxAliases which are defines, if they can be defined as enums. This can be done via a new PR.

[jeremybrodt]

Ok. I will rebase to the latest head.

Are you refering to PinAliases.h and PeripheralAliases.h? If so, the underlying symbols are already enums defined in PinNames.h and PeripheralNames.h.

[0xc0170]

I can't locate any other LED1 or LED_GREEN, only these

+// mbed original LED naming
+#define LED1 LED_RED
+#define LED2 LED_GREEN
+#define LED3 LED_BLUE
+#define LED4 LED_BLUE

[jeremybrodt]

They are just above in the same file.
LED1 --> LED_RED --> P1_7 (enum)
LED2 --> LED_GREEN --> P1_6 (enum)

[0xc0170]

Why do you prefer defines over enums? Can you make all those part of PinNames?

[jeremybrodt]

We are planning to make multiple boards using the same microcontroller. I am trying to abstract micro-specific definitions from board-specific definitions. The enums in PinNames.h define the actual pins of the micro. The macros in PinAliases.h define what board features the pins are connected to. Depending on the board, they may be connected to different things. On this board (MAXWSNENV), the green LED is connected to P1.7. On a different board, it may be a different pin.

We are using macros because we do not want to create a new type. These symbols will be passed as parameters to the various API functions. They need to be of type "PinName."

[jeremybrodt]

What is the advantage of making the aliases enums of type PinName as opposed to macros?

[0xc0170]

Thanks for rebasing.

To have them as symbols, for example available when debugging. And users look at PinNames to find what valid PinNames an application can use. A comment would be helpful there in the above PinNames, that additional pins are in those aliases header files, just my 5 cents.

I don't know if all aliases are valid for all platforms which will come, if this could be valid. Add all common symbols as LED, SW, USBTX in PinNames, redefine the values using preprocessor. An example -

Somewhere in specific platform header file
#define LED1_MAX_TARGET P0_0
in PinNames:
LED1 = LED1_MAX_TARGET

I'll merge this as it is.