Your polling loop runs at full speed of your processor, and writes to the serial port in each round.
This way, you're writing way more often to the serial port than it can handle.
The port does what it was meant to do in this case - writewrites out data as fast as you configured it, and buffer data that is comming in from your program too fast, to write it out as soon as possible. It will keept the order of the values(!). It the buffer is full, it just drops new data.
What's important here is that it will keep the order of the values: It is a FIFO buffer, working in First In/First Out order.
What happens is:
The loop fills the port buffer, and keeps it 100% full.
If you turn the potentiometer, the changed value get's written to the end of the buffer, the port works as fast as it can to write out all elements in the buffer, that have still the old value.
And
And finally the value you are interested in. The most current value we wanted to see immediately was at the end of the FIFO, and first in/ first out also means last in/last out. The opposite of what we want.
The maximum frequency it makes sense to read your data, is the frequency you can write it out, so you should use at least a delay that is long enough to write out the bytes at the current port speed.
IndependentAs another, independent measure to prevent this kind of that:
To prevent this kind of delay in general, you could set the write buffer of the port to a minimum.
delay in general, you could additionally set the write buffer of the port to a minimum.That would cause data to be dropped much earlier, instead of buffering a lot first.
Of course, in many applications that is not what you need; With bad luck, it could work anyway in the beginning, and get unstable in some situations when the timing changes based on things like processor load, and there are only some random data samples that get dropped. A large buffer generally behaves much more deterministic, so do use a large buffer by default.