Avoiding the Chameleon, Again

Question

Okay,here's the post in question

We wrote some more debugging stuff in my shop yesterday and this morning.

With the aid of those new debugging routines, I have now learned that...

• The UART is working 10 times in a row at full speed, then craps out. (i.e., sees no more bytes from the input side)
• Repeatedly sending the same byte produces a predictably quasi-consistent error.
• Sending incrementing bytes (00, 01, 02, 03...) produces a weird error, but one which I think I can repeat.
• The tenth byte silence thing persists even if I give both systems (the sending and receiving) a long rest (e.g., 30 seconds).
• It appears that I never really truly receive the byte that was actually sent to the device.

With these 5 newly discovered evidence data, do I ask 5 questions ? Do I ask this as one question with all five things ?

If I add this to the original question, it's chameleon time.

If I leave out these 5 details, the expert somewhere on earth who has seen this before doesn't get the full context of the question.

If I include the five details, have I disguised 5 questions as one ? Is that chameleon bait ?

I am confident that somebody somewhere has seen and solved this before me, and Stack Overflow is exactly the place for him and me to connect for 3 minutes.

First, What's the right thing to do ? After that, What's the smart thing to do ?

Answer 1

With these 5 newly discovered evidence data, do I ask 5 questions ?

Why? It's 5 bits of information relevant to your single specific question.

Do I ask this as one question with all five things ?

Yes. See above. That you have 5 new bits of new data doesn't mean you have 5 new questions - your question still remains.

---

Now, if these are related to an existing, unanswered question, what you should do is edit that question and add those details to it. This also applies if there are answers that have not helped you and where such additional information has been requested.

In essence - if the question has not changed and this is just additional information - edit the original.

Answer 2

Personally, I'd try debugging it a bit more before posting. This kind of stuff is hard, and there's no guarantee you'll get a quick-fix especially since your descriptions at this stage are still not very concrete. Given that you made good progress by doing some debugging, I'd simply proceed along the path of elimination -- write the simplest possible program that fails, and work out what's wrong from there.

Once you've debugged and found a better way to explain the problem, it will make for a better question. At that time, you may have enough to ask a separate, detailed question.