PR created also to satisfy the clock configuration on #5301

ACK once comment is addressed.

NACK, It seems wrong that the ticks count should be passed through the usec to ticks macro. Why not modify the usec to ticks scaling instead of introducing another related definition?

I may have been a little too harsh and unreasonable in my previous comment. What I meant to say was that what this PR is doing is changing the definition of 1 second in the xtimer subsystem, which will make all timings wrong in the system. Instead of changing the number of microseconds in 1 second, what should be done is to change the number of hardware timer ticks in 1 second. The scaling from usec to ticks is done with the XTIMER_USEC_TO_TICKS macro, and that's what should be modified, not the argument to the macro.

Ok now it's very clear to me. Don't worry, it was me who didn't see the whole problem and trying something just too simple.

Even if the initialisation that I proposed for my specific case on the waspmote is near to 1000000 (921600), which is actually then shifted by 2, I think we should analyse a way to reduce the timing errors as much as possible.

Can we know what's the actual introduced error using values near to 1sec? I think that even initialising XTIMER at 1sec we are not 100% accurate, so maybe we can try to correct the inaccuracy by some other means.

Closed by #5608