drivers/802154: improve setting of default short address

[PeterKietzmann]

In #5457 we concluded to spend some more entropy for the default short address generation of 802.15.4 transceivers. As there is no standard for such generation, I propose two possibilities here, demonstrated at the current kw2xrf driver. The first commit takes all CPUID_LEN bytes of the CPUID into account whereas the second commit only uses CPUID_LEN - IEEE802154_LONG_ADDRESS_LEN bytes of the CPUID.

[PeterKietzmann]

It took my some minutes to find out you changed your nickname :-)

[miri64]

Just for understanding of that line: you are taking every odd byte of the CPU ID and XOR it with the most-significant byte of the short address and every even byte with the least-significant byte. Is that correct? (maybe add a comment?)

[miri64]

It took my some minutes to find out you changed your nickname :-)

;-)

Other then the readability of the code I'm fine with this change.

[PeterKietzmann]

That is correct. I can give it a comment then. Generally, do you prefer the version in the first commit which takes the full CPUID_LEN into account but introduces an additional loop or do you think the second version (both commits together) which just uses CPUID_LEN - IEEE802154_LONG_ADDRESS_LEN bytes of the CPUID? I personally prefer version 1.

Will adapt this PR once #5461 is clarified.

[miri64]

I think I prefer version 1, too, though it should be CPUID_LEN > 0 (for LONG it should also be <= and some alternative path must be found when the CPUID_LEN is shorter). Rational: if its shorter then or equal to 2 (the current condition for excluding this code; and I know that a vendor will most likely never set such a CPUID, but let's say we emulate the driver for native (where the CPUID is the PID)) the CPUID can still be used as a scalar value (which the loop ensures regardless).

[PeterKietzmann]

@miri64, I moved the short address generation some lines upwards so it will be set once CPUID is not zero. I didn't change the condition for setting the long address because it should be ok for all Kinetis CPUs.

Let's see this PR as a quick fix. I don't want to elaborate on this single driver any more because (i) after discussing in #5457 I think we need some "major " restructuring in terms of address generation and (ii) @jfischer-phytec-iot already proposed a (WIP) driver for netdev2.

What do you say, can we merge as is (after squashing)?

[miri64]

Yes, ACK. Please squash.

[PeterKietzmann]

Did