Unify metadata definition with firmware

[t-sasatani]

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.

[sneakers-the-rat]

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: https://github.com/Aharoni-Lab/miniscope-io/pull/49#issuecomment-2458657648

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]

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]

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]

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]

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"