Skip to content

Unique serial numbers for picoprobe #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 3, 2021

Conversation

newbrain
Copy link
Contributor

@newbrain newbrain commented Feb 2, 2021

This PR (hinted at in the comments for #5) makes the USB serial number for each Picoprobe unique.
It will come handy for multi probe support in pyocd.

Code is very simple, a direct conversion of the flash unique ID to a C string.

As far as I can see, there's no need to bracket the call to pico_get_unique_board_id(); with disable/enable interrupt, as they seem not to be enabled (yet) when usb_serial_init() is called.

uint8_t nibble = (uID.id[bi] >> 4) & 0x0F;
uID.id[bi] <<= 4;
/* Binary to hex digit */
usb_serial[i] = nibble < 10 ? nibble + '0' : nibble + 'A' - 10;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or you could just use sprintf ?

Copy link
Contributor Author

@newbrain newbrain Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With a cast to uint64_t?
Yes, type punning would in this case be 100% safe (and even guaranteed by the standard), and printf is already brought in so that won't make much of a difference.
But, it will display the flash ID in reverse with respect to the "wire order". Not that it makes that much of a difference, I just find it weird.

Otherwise, it would be sprintf in a loop on the id[] array (quite an expensive thing) or a monster call (ugly), and not really any simpler in both cases - as you can see it's four simple lines.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sprintf in a loop on the id[] array (quite an expensive thing)

With the Pico running at 133MHz, I guess I was just being lazy 😉

@lurch
Copy link
Contributor

lurch commented Feb 2, 2021

there's no need to bracket the call to pico_get_unique_board_id(); with disable/enable interrupt

I believe fetching the flash-chip UID is only done once at startup? So any calls to pico_get_unique_board_id() just return the already-read value.

@newbrain
Copy link
Contributor Author

newbrain commented Feb 2, 2021

I believe fetching the flash-chip UID is only done once at startup? So any calls to pico_get_unique_board_id() just return the already-read value.

Yes you are right! I was thinking of the underlying call.

@liamfraser liamfraser merged commit 0fe6a09 into raspberrypi:master Feb 3, 2021
@newbrain newbrain deleted the FlashID branch February 4, 2021 00:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants