I’ve been trawling through the DW code all day, trying to figure out what the **** it is doing, and how it is doing it. It took me a while to discover that there are two state machines that run in parallel. Of course the state names are similar, just to confuse things. There is a state machine that keeps track of the SOC states, and then there is another state machine that keeps track of the ranging app.
The state machine for the device initiating the ranging, is different from the SM for the node being ranged. Rather than making two distinct SMs they combined them into one, and parameterized the states with “tag”, “anchor”, and “listener”. Their ranging protocol exchanges 6 distinct packets which you would think would cause the SM to cycle through at least 6 extra states to keep track of the phases… but oh no. There is a “prepare to send packet state”, and a “prepare to receive packet state”, both of which are parameterized with the packet type. Bottom line is that the processing from some of these states has multiple combinations of option, and goes on for pages. To understand which thread the code takes, I have to keep track of all the parameters in my tiny head.
And of course it’s hard to trace through the code in the debugger, because it is a real-time system with lots of critical sections that time out.
I am actually finding bugs in the code, so I do wonder how other folks have got on. The basic timer code only handles a 5 second delay. Any other parameter causes random results because the person that wrote it didn’t understand that you can’t shift a floating point number right 12 places and expect the same thing to happen as if you did it to a fixed point number.
I’m of the opinion that the person who wrote this code wasn’t very experienced because it’s messy and poorly structured.
The DW status register has lots of status bits, that get set in what seems like a random order. Sometimes condition A is asserted first, and sometimes condition B. This means you have to write code to handle all possible sequences.
So I’m throwing away whole modules of code and building my own state machine, so I make sure I understand what’s going on. It probably won’t work, but at least I will discover (the hard way) why they have all these subtle fiddly bits in their code. And if it does work my code should be a lot cleaner because I don’t need to address all the demo options that complicate every touch and turn. No wonder the Pozyx people used the same processor – they probably don’t understand how all the code works either.
So no tangible progress, but at least I kind of understand the code more.