Skip to content
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

Increase the size of the R_SERIAL_NUMBER to match 128bit UUID #31

Open
1 of 4 tasks
bruno-f-cruz opened this issue Dec 21, 2023 · 4 comments · May be fixed by #39
Open
1 of 4 tasks

Increase the size of the R_SERIAL_NUMBER to match 128bit UUID #31

bruno-f-cruz opened this issue Dec 21, 2023 · 4 comments · May be fixed by #39
Assignees
Labels
proposal Request for a new feature under review An issue that is undergoing pr review

Comments

@bruno-f-cruz
Copy link
Member

  • Proposed
  • Prototype: Not Started
  • Implementation: Not Started
  • Specification: Not Started

Summary

The current R_SERIAL_NUMBER only supports a U16 value. My proposal is to increase the size of this register (U16*8 values) as to accommodate the (UUID 128bit standard)[https://en.wikipedia.org/wiki/Universally_unique_identifier]. This makes this register usable for future hardware implementations of the core since one can use the Serial number of the embedded systems in this register.

Motivation

The pico, for instance, uses a 32bit serial number. Adopting an industry standard of 128 should make it future proof.

Detailed Design

Change the core register to an array of 8 U16 numbers.

Drawbacks

Backwards compatibility?

Alternatives

N/A

Unresolved Questions

Does this break backwards compatibility?

Design Meetings

TBD

@bruno-f-cruz bruno-f-cruz added the proposal Request for a new feature label Dec 21, 2023
@glopesdev
Copy link
Collaborator

glopesdev commented Jan 11, 2024

Feedback from SRM:

  • @artursilva0 and @filcarv proposed adding a new register R_SERIAL_NUMBER_EXTENDED with 16 bytes.
  • For backward compatibility, the first 2 bytes should be shared with R_SERIAL_NUMBER
  • The new register would be optional, and older devices would not be required to implement it

Missing:

  • Address?
  • Name? ("UUID")

@filcarv
Copy link
Contributor

filcarv commented Feb 5, 2024

Unfortunately, there are no free bytes in the EEPROM of the atxmega implementation. What we can do is:

  • Reduce the bytes available for the DeviceName register (reduce by 8 bytes instead of 16 to still have room for the DeviceName). I'm not sure, but this may represent a major release of the core. Or,
  • Move the application register's EEPROM base address from 32 to 64. This would represent a major change, i.e., a major release of the core.

@bruno-f-cruz
Copy link
Member Author

I would favor your second solution as it would make the interface backwards compatible. The first one actually break it if I understand correctly.

@bruno-f-cruz
Copy link
Member Author

bruno-f-cruz commented Feb 29, 2024

Notes from 29022024:

Register name: UUID
Register Number: 16
Register Size: uint8[16]
Register Access: Read-only as per protocol specification

Importantly, the current R_SERIAL_NUMBER register will remain as is for backward compatibility with the following assumptions:

  1. The first 2 bytes of the new register UUID will be duplicated to the two bytes of register R_SERIAL_NUMBER
  2. This register will be deprecated with the next major release in favor of the UUID one

I will make a PR with this proposal

@bruno-f-cruz bruno-f-cruz added the under review An issue that is undergoing pr review label Feb 29, 2024
@bruno-f-cruz bruno-f-cruz self-assigned this Feb 29, 2024
@bruno-f-cruz bruno-f-cruz linked a pull request Feb 29, 2024 that will close this issue
@bruno-f-cruz bruno-f-cruz linked a pull request Feb 29, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Request for a new feature under review An issue that is undergoing pr review
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants