Hmm, I don't really like this PR. Wrapping an RTT to fill the RTC interface kind of blows the concept of the periph drivers: they are meant to abstract the MCU hardware. If the hardware does not provide some peripheral, it should just not implement the periph driver for the peripheral. I should be then up to the higher level modules, do work with what is there. E.g. the xtimer should take care to select the RTC or RTT, depending on what the CPU provides.

@haukepetersen Almost all MCUs support RTT (counting) mode. And the RTT interface just sucks (see sizeof(struct tm) and the codesize + deps of the corresponding conversion functions).

That's why I proposed to just move it to sys/, so that if people want, they can use "struct tm", but our general recommendation is to use xtimer (+ maybe some wall clock API based on that / RTT).

@haukepetersen @kaspar030 I won't join that discussion, I just needed an RTC driver :-)

Related: #4758

Just realized that I still had this PR open.

I've concluded that this fix isn't common enough. For instance, it assumes times are 32 bits, which wasn't the case for the EFM32 I am doing (only 24 bits). This means that I have to keep track of the overflows to support times and alarms that exceed the 'current' interval (apart from that, I implemented both RTT and RTC but not via this wrapper)

Because the discussion of whether this should be fixed in the driver is not concluded, I abandon this PR.