xtimer: Set XTIMER_SHIFT to 0 if underlying timer is 32768 Hz

[jnohlgard]

The error message "XTIMER_SHIFT cannot be derived for given XTIMER_HZ, verify settings!" is triggered if XTIMER_HZ is not a power of two multiple of 1 MHz. If XTIMER_SHIFT is defined to 0, then the other error message "XTIMER_SHIFT is set relative to XTIMER_HZ, no manual define required!" is triggered instead. This change was introduced by #6702

[smlng]

Looks good, another (side) case which was missed during testing.

Hence, we should add a test for all those xtimer frequencies ...

[jnohlgard]

The frdm-kw41z board in #6995 will use 32768 as the frequency, I don't think we need to spend any more effort on adding test cases for it.

[kYc0o]

I think that was because #6507 was not merged before... just sayin' 🙄

[smlng]

I think that was because #6507 was not merged before

nope, I just missed the already present special case of 32768HZ external crystals. Or more to the point, before #6702 it wasn't necessary to specifically care about that frequency. Btw. 32768 is no multiple of 576 as required for #6507, so that wouldn't have solved the issue!

[kYc0o]

What I mean is that I took into account 32768 when the calculations are done, which was not taken into account in #6702 and that's why at some point that PR was waiting for #6507, but nevermind, it doesn't matter now.

[smlng]

I'm (still) not convinced that #6507 solves the issue addressed here or would have prevented the regression, if merged first. Because, the bug was introduced by the missing check/case using pre-processor #if (XTIMER_HZ == 32768) in xtimer.h, a file PR #6507 doesn't touch at all. The conversions in div.h and tick_conversion.h specific to a frequency of 32768 were already there.

Hence, even if #6507 would have been merged before #6702 the issue would (IMHO) have come up, too.