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:
Register more callbacks for currently-unregistered CHANREP*** packet header types (see list below).
Check that the argument packet header.type is a chan config type ((x & cbPKTTYPE_CHANSET) != 0) and if not set it to CHANSET.
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)
From @dkluger here:
I override the packet header type because I want to ensure that the response from the device will reach the
_handle_chaninfocallback, which is necessary toself._config_events["chaninfo"].set()and let control return to the client. However, setting the packet.header.type toCBPacketType.CHANSETmeans 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:
(x & cbPKTTYPE_CHANSET) != 0) and if not set it to CHANSET.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:
CHANREPSPKTHRCHANREPLABELCHANREPSPKHPSCHANREPDINPCHANREPDOUTCHANREPAOUTCHANREPSCALE(Edited to update chanrep packets that are now handled)