I have the Essentials kit, which includes seven modules and a USB to DUELink adapter.
Since I’m working in an unsupported language, I’ve been developing my own support library and framework.
I’ve reached a point where I want to identify which modules are connected to the chain and their respective positions.
I had hoped that the info(3) command, which retrieves a module’s downlink mode, would reveal the last module in the chain. However, it appears that all the modules, including the last one, have the same mode: daiseylink.
Of course, I can use a timeout to locate the last module, but I was wondering if anyone has experimented with module discovery and found a more sophisticated method for finding the end of the chain.
The last module does not know it is the last module. That is just how enumeration works today. However, there is a benefit in knowing a module is the last in chain.
Things get tricky because the bus allows the user to switch and of the modules to a host and you could have non DUELink i2c models as well. There are many other edge cases.
We should open an issue and look into this any way.
Kathy Giori also wants to enumerate modules so glad you’re looking into options. A module count would be good.
Meanwhile, what’s a reasonable timeout? When you are stepping down the module chain you’ll know you you’ve gone past the end of the chain when the selected module does not respond in some number of milliseconds. I’m guessing a timeout of 50 to 100 msecs would be sufficient?
The documentation is a bit vague. What device should be selected(target of command)? I assume device 1. If the command is sent to a later device in the chain does it return the same count as the first? Is the command independent of the selected device, and the module with the answer always responses? What are the numbers for the next lottery drawing?
Of course, I could load the firmware and answer all the above questions, except for the lottery numbers.
