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

set_channel_config_by_packet should allow scoped CHANSET packet types. #6

Open
cboulay opened this issue Mar 10, 2024 · 0 comments
Open

Comments

@cboulay
Copy link
Contributor

cboulay commented Mar 10, 2024

From @dkluger here:

better default argument definition for cbsdk.configure_channel_by_packet and cbhw.device.nsp.set_channel_config_by_packet Right now, cbhw.device.nsp.set_channel_config_by_packet mandates packet.header.type to be a 'chan_info' packet, but the header can be a different packet type per class CBPacketType, which tracks with cbproto. I've made changes to cbsdk.py to allow optional declaration of the packet type, but default to CBPacketType['CHANSET'], and then modified cbhw\device\nsp.py similarly.

I override the packet header type because I want to ensure that the response from the device will reach the _handle_chaninfo callback, which is necessary to self._config_events["chaninfo"].set() and let control return to the client. However, setting the packet.header.type to CBPacketType.CHANSET means that every field is being set on the device and this only works if every field is correct. This works fine as long as the client creates their chan config packet from a copy of the known config.

Contrast this with Central where the config packet is initialized with random data and only a subset of fields are set to their correct values, but the pkt.header.type is set to a scoped type so the device only looks at the subset of fields.

If we wanted to enable clients to initialize CHANSETXXX config packets with incomplete data and only have to set the fields for the scoped packet type, then we would have to make the following changes:

  1. Register more callbacks for currently-unregistered CHANREP*** packet header types (see list below).
  2. Check that the argument packet header.type is a chan config type ((x & cbPKTTYPE_CHANSET) != 0) and if not set it to CHANSET.
  3. Assert that the argument packet header.type is not in the set of known unhandled CHANSET packets.

Step 1 is worthwhile anyway because we want to handle packets that are responses to other clients modifying the config.

Here is the list of CHANREP packet.header.types that do not currently have a registered callback:

  • CHANREPNTRODEGROUP
  • CHANREPSPKTHR
  • CHANREPDISP
  • CHANREPLABEL
  • CHANREPUNITOVERRIDES
  • CHANREPSPKHPS
  • CHANREPDINP
  • CHANREPDOUT
  • CHANREPAOUT
  • CHANREPSCALE

(Edited to update chanrep packets that are now handled)

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

No branches or pull requests

1 participant