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

Unify metadata definition with firmware #37

Open
3 tasks
t-sasatani opened this issue Aug 13, 2024 · 5 comments
Open
3 tasks

Unify metadata definition with firmware #37

t-sasatani opened this issue Aug 13, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@t-sasatani
Copy link
Collaborator

Some data length-related parameters are defined based on 32-bit in firmware and 8-bit in miniscope-io, which is confusing.

  • Unify all the length definitions.
  • Update code that relies on this length definition.
  • Make all metadata configured by device config in Miniscope-io accessible from the MS_config.h file in firmware.
@t-sasatani t-sasatani added the enhancement New feature or request label Aug 13, 2024
@t-sasatani t-sasatani self-assigned this Aug 13, 2024
@sneakers-the-rat
Copy link
Collaborator

Going to use this issue to also say that we need to have some system for versioning and checking compatibility between firmware versions and software versions re: discussion here: #49 (comment)

e.g. it should be possible for firmware to update the output format of its data, but it should also be possible for miniscope-io to tell that rather than having a hard to diagnose error when trying to interpret the data. Something as simple as versioning the firmware, making a command so that we can query a device for its firmware version, and then declaring the version range of firmware that an interface class supports would do it, same as standard version constraints.

@t-sasatani
Copy link
Collaborator Author

We can start thinking about this now that some downlinks have started working, and that's why I put the DEVICE key in the commands. But also, the downlink is pretty lossy, fewer interrupts are better, and there isn't much config info, so I also thought we could just stream serialized diagnosis/metadata using the first 10 bytes or something instead of reserving a spot in the buffer for returning requested values. I'm working on this, but I will let you know.

@sneakers-the-rat
Copy link
Collaborator

yes yes i definitely think we should not have header schema info in the header itself, i was thinking exactly something like that DEVICE key where we can maybe get a CBOR dump of the device metadata when first connecting

@t-sasatani
Copy link
Collaborator Author

Well, I think it could be in the header because we don't want to necessitate "pairing" and that way, there's no apparent start of streaming. Also, there's no side-channel. I'm thinking of defining OSI-ish layers because it feels like having all layers equal and mixed up as header is the problem now but am pushing later.

@sneakers-the-rat
Copy link
Collaborator

Also, there's no side-channel.

am too tired and uh well lets say "cognitively distressed" from the day to address this now, but want to flag this as an important thing that i might be misunderstanding about the design of the r/w channel between software and hardware so future me knows to come back to it, but in the meantime say "ohhhh this might be one source of difference in how we have been thinking about design here"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants