OK, bit of a story behind this one. Been debugging board initialization problems, and what I've found is that there are frequently "noise" packets coming in over the serial line when we enter clear_serial. I'm sure they mean something, but they're not relevant to the task of trying to prepare the serial line.
The prior implementation sent two requests and expected two responses, in order. The loop is probably there specifically for the purpose of reading and discarding those "noise" packets, in order to sync up.
But here's the problem: if there are an odd number of noise packets (the number seems to vary basically randomly on every initialization), the two-request sequence is off-by-one. It never syncs and eventually times out.
If you unroll the loop, it looks like this:
send request 1
read odd-numbered noise packet
send request 2
read response to request 1
send request 1
read response to request 2
and so on...
One way to fix it is to loop on the request/response pairs separately. Send request 1 in a loop until you get the expected response, then do the same for request 2. That works.
But on further investigation, the first request is actually the _read_fields command. It is not needed for the task of clearing the serial line. We can just drop it and loop only on the second request. That gets the job done, avoids the off-by-one bug, and is actually a lot faster.
Along the way, I made the incidental discovery that the preamble to reading the board address doesn't actually seem to do anything. Board address reads just fine without it.
This commit just comments-out the unnecessary bits, to make it easy to switch to one of the other solutions if you prefer that to what I eventually settled on.
OK, bit of a story behind this one. Been debugging board initialization problems, and what I've found is that there are frequently "noise" packets coming in over the serial line when we enter
clear_serial
. I'm sure they mean something, but they're not relevant to the task of trying to prepare the serial line.The prior implementation sent two requests and expected two responses, in order. The loop is probably there specifically for the purpose of reading and discarding those "noise" packets, in order to sync up.
But here's the problem: if there are an odd number of noise packets (the number seems to vary basically randomly on every initialization), the two-request sequence is off-by-one. It never syncs and eventually times out.
If you unroll the loop, it looks like this:
One way to fix it is to loop on the request/response pairs separately. Send request 1 in a loop until you get the expected response, then do the same for request 2. That works.
But on further investigation, the first request is actually the
_read_fields
command. It is not needed for the task of clearing the serial line. We can just drop it and loop only on the second request. That gets the job done, avoids the off-by-one bug, and is actually a lot faster.Along the way, I made the incidental discovery that the preamble to reading the board address doesn't actually seem to do anything. Board address reads just fine without it.
This commit just comments-out the unnecessary bits, to make it easy to switch to one of the other solutions if you prefer that to what I eventually settled on.