In my project I need to make readable 96bit UID, in reference manual is described how the number is encoded:

struct Uid {
    uint16_t X;  // x-coordinate
    uint16_t Y;  // y-coordinate
    uint8_t WAF;  // Wafer number
    char LOT[7];  // Lot number

My question is how x and y coordinates are encoded. if 0x0000 is in middle of wafer or on side.

here are some examples which I see in X-coordinate: 0x0000, 0x0001, 0x0006, 0x8001, 0x8004, 0x801f, .... some numbers has set MSB bit.

In Y-coordinate I always see numbers where MSB is NOT set, like: 0x0001, 0x0003, 0x0005, 0x001f, 0x0030, 0x003f, ...

I don't have so many samples to read many numbers and get better statistics of numbering so my question is what mean if number has set MSB bit in coordinate? I think that this is sign, but I'm not sure.

Reason why I interesting of this, is that I need decrease size of this number and remove some bits from this UID, my idea is to remove bits 11-14 from each coordinate to keep position and (probably) sign and make this number smaller and still unique. I need to decrease it by 8 bits only.

MCU is STM32F0xx

UPDATE: I have small statistic from 75 pcs of STM32F031 and here are uniqeue values for:

X: 0003, 0008, 0009, 000a, 000b, 000e, 0010, 0013, 0014, 0015, 0016, 0018, 001c, 0021, 0024, 002a, 8001, 8002, 801b, 801c, 801d, 8020
Y: 0003, 0005, 0006, 0007, 000c, 000f, 0010, 0011, 0013, 0014, 0016, 0017, 0018, 0019, 001a, 001b, 001e, 001f, 0020, 0022, 0024, 0028, 0029, 002a, 002c, 002d, 002e, 0030, 0032, 0033, 0034, 0035, 0037, 0038, 0039, 003a, 003c, 003f, 0042, 0044, 0045, 0046, 0047, 0048, 0049, 004b, 004e
WAF: 0b, 0c, 0d, 0e, 18

Seems that X and Y and WAFER is not BCD but HEX and MSB bit in X coordinate will be probably sign

  • 1
    \$\begingroup\$ How are we supposed to know? This structure is specific to some unknown code only you are seeing, not something standard. Also you mention some "reference manual". Of what? \$\endgroup\$ – Eugene Sh. Nov 7 '17 at 14:45
  • 1
    \$\begingroup\$ It says that X and Y are expressed in BCD format. So the mentioned 0x801f can't be right. Also I don't think you can reduce this number and maintain it unique. There is a reason 96 bits were selected. You might be able to compress it though... \$\endgroup\$ – Eugene Sh. Nov 7 '17 at 14:52
  • 1
    \$\begingroup\$ @Eugene Sh. RM is a standard STM document. Anyone using the STM micros knows what it is. \$\endgroup\$ – P__J__ Nov 8 '17 at 13:22
  • 1
    \$\begingroup\$ @Eugene Sh. And no, not everyone using STM32 is even aware of this structure existence. Yeah - HAL generation, reading is boring, knowing the hardware is boring \$\endgroup\$ – P__J__ Nov 8 '17 at 14:27
  • 1
    \$\begingroup\$ @vlk I won't write an answer because it is not authoritative, but it seems it may be a mistake in the manual: community.st.com/s/question/0D50X00009XkeO9SAJ/… \$\endgroup\$ – dim Sep 24 '18 at 13:31

If all you need to reduce number of bits, but don't know which ones are significant, you can always "xor" them together. for example, xor upper and lower bytes: 0x801f -> 0x80 ^ 0x1f = 0x9f

This requires that your high and low bytes are independent (for example if numbers have a step of 0x101, then the algorithm would not work well). But from your data, it looks like you will be fine.

  • 3
    \$\begingroup\$ It won't guarantee that the resulting number will still be unique per chip, unless you can guarantee, for example, that the first byte will always be 0x80 or 0x00 and that the second will be <= 0x7f. But the spec does not give strong guarantee on that, and seems even inconsistent with the actual values. As I understand the question, this is the problem OP is having: in which range the values are (to ensure strong guarantees on unicity), it is not in how to combine them (this is the easy part). \$\endgroup\$ – dim Sep 24 '18 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.