I like the idea as reporting contiguous sub-devices as virtual rootdevice, but then I see the problem of identifying this as "virtual" root device.
Going with Hamish' example, "Now we set the BLOCK_ADDRESS to 1.
Root DEVICE_INFO reports DMX Address 1, footprint of 10."
What will occur? When reading the device info, it will tell me:
- I have a root device with a start address and I have 10 slots used. Reading the subdevice count field, I see that I have (additional) Sub-Devices present. So I read all the Sub-Devices and find, there are ten more slots (so now I have a total of 20 slots used), and I find, the subdevice addresses conflict with what I have already read for the "virtual" root (overlap).
Wrong or right?
Thus I would assume, reporting a start address and footprint for a "virtual" root device is not possible at all without creating additional confusion... We should separate rootdevice info and subdevice info as much as possible.
I would like to offer two solutions for the problem "to enable the many controllers that don't really do sub-devices":
- add additional functionality to the controllers under review, or
- make using subdevices optional.
We have chosen the latter option. Units are shipped as root devices having a start address and a number of slots used. User can activate subdevice functionality calling a manufacturer function called "ENABLE SUBDEVICES". When done, the unit identifies itself as rootdevice using no slots and so start address, but features a number of subdevices instead. BLOCK ADDRESS will only affect subdevice addressing, and never report to rootdevice data.
Comments welcome.
|