boards/cpu: add support form EFM32 and starter kits

[basilfx]

This PR adds initial support for the EFM32 and EZR32 MCUs by Silicon Labs. It refers to issue #1123.

The first commit adds the targets, the second commit adds the boards. It uses the existing flash scripts and Cortex architecture. It does not modify any other files.

Overview

The EFM32 and EZR32 MCUs are supported, including the new EFM32 Gemstone MCUs. All peripherals, except random number generator, are supported.

An overview^1,2:

• EFM32 Gecko
• EFM32 Giant Gecko
• EFM32 Happy Gecko
• EFM32 Jade Gecko
• EFM32 Leopard Gecko
• EFM32 Pearl Gecko
• EFM32 Tiny Gecko
• EFM32 Wonder Gecko
• EFM32 Zero Gecko
• EZR32 Leopard Gecko

It targets the following boards²:

• STK3200 — EFM32 Zero Gecko
• SLSTK3401A — EFM32 Pearl Gecko
• STK3600 — EFM32 Leopard Gecko
• STK3700 — EFM32 Giant Gecko
• STK3800 — EFM32 Wonder Gecko

Features

• Low-power UART support (can be disabled via LOW_POWER_ENABLED=0, disables USB UART on STK3200, because it is connected to LEUART0).
• Code Correlation for Advanced Energy Monitor (Cortex M3/M4 only, can be disabled via AEM_ENABLED=0)
• RTT or RTC. As I don't know how core: API: RTC interface should not use struct tm #2538 will end, I implemented both. The new EFM32 Gemstone MCUs have proper RTC support, the older ones use time conversions. It can be configured as RTC via RTT_AS_RTC=1.

Documentation

I have prepared wiki pages for the boards here.

Testing

I have a STK3200, SLSTK3401A and STK3600. The STK3700 and STK3800 are identical to the STK3600.

The applicable peripheral tests compile and work, with a few exceptions:

• periph_rtc fails on STK3200 (problems with timer).
• periph_uart exceeds RAM on STK3200.
• periph_spi compiles and works, but I haven't found a way to actually verify what is send on the pins.

I noticed two odds:

• periph_spi hardcodes PULLUP for output pins. This is not supported by the GPIO peripheral of EFM32.
• perip_rtc behaviour depends on implementation (time_t wrapper vs dedicated peripheral).

TODO

• Optimizing code (I'm not a C expert).
• Fixing SPI.
• More testing.
• Benchmarking energy consumption.

Long term (probably not in this PR):

• Adding DMA support
• Adding support for LETIMER. I used the EZR32WG timer implementation, but I don't like using two 16-bit timers to create a 32-bit timer. I don't know the timer requirements, but reducing it to 16-bit shortens the period.

Conclusion

I know this PR is using vendor libraries. As mentioned in #1123, it is not a board support package. I also know that RIOT-OS targets as efficient code as possible. That said, emlib (the vendor library) does increase the code size, but adds flexibility. I have reported this before, but I expected a constant increase. To verify/research this, I conducted several benchmarks with different compile options and a few boards. The results of approximately 2200 compilations can be found here (large file!)^3,4. I see an increase of 3-4 kb compared to other boards⁵.

I fully understand that the above may influence the decision not to include this PR in RIOT-OS. But #1123 is open for quite some time, and this could serve as a starting point for optimization. The targeted MCUs have variants with enough flash and ram. Furthermore, It did not stop me from learning about RIOT-OS, EFM32, embedded and coding in general, so no hard feelings. I will probably still use it for my personal projects.

Footnotes

¹ EZR32 Wonder Gecko is missing, but is already included in RIOT-OS. There is no compatibility or overlap.

² SLWSTK6220A is missing, but is already included in RIOT-OS. There is no compatibility or overlap.

³ Parallel builds using make -jN for N > 1 failed in many cases with 'malformed archives'. Therefore a larger number of build failed. Manually cleaning and recompiling the same code for N = 1 succeeded, however.

⁴ Click the numbers in the TEXT, DATA or BSS column for more information.

⁵ My code is verbose: I explicitly reset peripherals, and initialize all parameters. Furthermore, clock setup and frequency calculation is also responsible for a big part of code (but used by multiple peripherals).

[kaspar030]

freie universität berlin?

[haukepetersen]

Would it be possible to split up this PR? This PR adds >1200 files, which is not manageable for decent reviewing... I would propose you add each board (and their corresponding CPU) as separate PR, this should reduce the number of files at least to some extend...

[basilfx]

Yeah sure, I will do that. I think I will do that tomorrow.

[haukepetersen]

Thanks!

[basilfx]

I wasn't able to fix this last weekend, sorry. I found a few bugs while working on a Si7021 driver, which I want to fix first.

[haukepetersen]

sure, take your time!

[basilfx]

I will close this one in favor of #4824. Let's start with one CPU/Board and see where that goes :-)