Standard error handling demands that code must be adaptible. What if you get a transfer error resulting in your code getting only 24 characters, or getting just a single character? Even if a valid message must be 25 characters, you can't demand 25 bytes from the UART. Any communication code must be prepared for the situations that you get too little or too much and resynchronize someway. What happens if your PC waits for a TCP/IP message on the network cable before you are allowed to shut it down, and that specific message never comes? Should you never be allowed to turn off the PC then?


Yes.


It does. But since you reset DPTR to the initial value every turn of the loop, your increment will be overwritten. Single-stepping the loop on paper should have shown you this. If your goal is to increment DTPR inside a loop then DPTR must be given its initial value before you enter the loop. Having both initial value and increment inside the same loop will just have the two instructions fight each other.

When you get experienced, you can "test" code in your head because you get better and better at visualizing what happens - how many source lines and variable operations interacts. But it really is good to test something with pen andnd paper and to write down the values of the variables as you step through the instructions. But when you have a loop, you must step through that loop multiple times to see that the loop continues to progress towards the goal. Your 25 iteration steps should be ticked off one-by-one. And your destination address should also be ticking step-by-step. Pen and paper would tell you if two processor instructions fights each other.