Do you ever use Serial.begin() in your code, and you see a string of static (ex: ¿¿¿$##««@) on the screen when you open the monitor?
Have you used a delay() command to try and stop the static? There's a better way with a function that I rarely see used: Serial.flush();
A call to Serial.flush() will stop everything until the last transmission on the serial line has finished transmitting, and then it releases the com line back to you.
It's simple and painless.
Serial.begin(9600);
Serial.flush();
Serial.print("Works for me!");
I hope this helps your code as it did mine.
Take care!
Do you ever use Serial.begin() in your code, and you see a string of static (ex: ¿¿¿$##««@) on the screen when you open the monitor?
Have you used a delay() command to try and stop the static? There's a better way with a function that I rarely see used: Serial.flush();
A call to Serial.flush() will stop everything until the last transmission on the serial line has finished transmitting, and then it releases the com line back to you.
It's simple and painless.
Serial.begin(9600);
Serial.flush();
Serial.print("Works for me!");
I hope this helps your code as it did mine.
Take care!
Hi Casey,
There are other things the flush will do and it will fix your issue in this case, but "fix" is not the word to use here 🙂
It's probably hiding an underlying cable or hardware issue or possibly even environmental. Does it generate the same chars every time or random ones? Will the same happen with a different microcontroller board and or cable? Is there a fan or other high EMF source nearby? If so, if you move the board to another location, is it still doing it? Do you have a shield on the board, if so what kind? The noise could also be on your PC side.
As you stated, you can fix it and in devl you can ignore it, but there may be something contributing to the noise that can be fixed. Noise is a big issue in electronics and uC electronics especially. I hate the noise.
Thanks,
Scott
That's a good point, Scott, and I'm onboard with what you're saying. I have a prototype development platform for testing my projects, and all I have to do is plug the little, semi-hand-held oscilloscope into the 9vDC power supply (with the test leads disconnected), and I can watch the static bounce off the feed line as I move the scope around. I understand of the endless variables in a test environment that can influence outcomes in observations.
Alright, if you prefer the word "fix" not be used, let's say that it's a great step towards fixing when used as a diagnostic tool, because if you do, in fact, call the Serial.flush() command immediately after the Serial.begin() call, and you STILL experience static on your monitor prior to you code executing, you can most likely exclude your code as the cause of the static, because the code cannot execute until the previous serial transmission has ended due to the flush() command. You can then move on to environmental issues as the cause with more confidence.
I stand corrected, my good Sir.
Peace always. 🧐
Sorry, I was not meaning the "fix" is bad as I "fix" things all the time 😉 Sorry, my literalness causes me to quote things a lot. Autism... To your point with flush, I am a big flush fan. It has saved my butt many times and is in my code a lot at home and work. I love to do flushes before reading data on synchronous conversations.
Thanks,
Scott
Glad to hear it. I've so rarely seen it used in anyone's code. I ran across it in the stdio.h(?) file definitions or some header file like that.
Peace always 🧐
Do you ever use Serial.begin() in your code, and you see a string of static (ex: ¿¿¿$##««@) on the screen when you open the monitor?
Have you used a delay() command to try and stop the static? There's a better way with a function that I rarely see used: Serial.flush();
A call to Serial.flush() will stop everything until the last transmission on the serial line has finished transmitting, and then it releases the com line back to you.
It's simple and painless.
Serial.begin(9600);
Serial.flush();
Serial.print("Works for me!");
I hope this helps your code as it did mine.
Take care!
I've never really experienced this before, but I don't really see a need for it in your setup function anyway.
Theoretically, there should be nothing in the stream at this point in time of the setup, right?
Normally the advice is to use:
while(!Serial)... to ensure the serial port is ready?
I've still often seen static coming from the serial communications just prior to some sketch uploading into the microprocessor.
If you open the serial monitor on the IDE prior to the upload, and you've got gray screen on the monitor, it's a craps shoot as to what the serial com is doing - even after the while( !Serial ) loop ends; at least that's what I've experienced.
I use the while( !Serial ) command, always. It's kind of a must, always.
I'm just saying flush() works for me. It's pretty much what flush() was designed for. It's a viable substitute for using a delay() function call because you don't have to figure out how long to wait on the delay(). The flush() function call releases control after the previous serial communications end. Simple. If you don't like it, don't use it. No sweat off my back, as they say. 🧐
I appreciate your response because it always leaves food for thought.
Thanks, my friend.
Indeed, that's what flush does these days (though that's not what it originally did prior to version 1.0).
I don't have anything against it, I've just never experienced your issue, so never had the need to use it for that reason.
Nice to meet you too! 🙂