[SOLVED] Help needed with Arduino Serial Monitor output - Page 1
Forum section: electronics / general

author: Brumby
author_rank: Unknown
timestamp: August 02, 2017, 06:12:18 am
content: I've been working on a project and have suddenly had an unpleasant surprise in the Serial Monitor output.The change was to move a timestamp from the right of the output line to the left - and now I'm getting random crap getting dropped into the output. I can't see it being a problem with data types, as the data is pretty consistent in this screenshot and the problem is landing on top of string output - but it looks like something is crapping on the output buffer.Yes, I tried moving it back to the right, but the problem has stuck, as you can see.I'm using a mix of the Serial << "XYZ" << myValue; and Serial.println (" "); - but I have been doing this for ages without this sort of problem.I tried loading an older version of the program and it worked fine. While it doesn't have the timestamp, the timestamp has been used for several iterations quite successfully.Any pointers on how to solve this?Note: The yellow highlighted lines are what the outputshouldlook like.

author: mauroh
author_rank: Frequent Contributor
timestamp: August 02, 2017, 07:55:08 am
content: Post the code...Are you sending to the serial output part of the string as long as you are putting it toghether or you are sending a big buffer all at once?Mauro

author: hamster_nz
author_rank: Super Contributor
timestamp: August 02, 2017, 08:15:50 am
content: The error that is 'star space box space box' repeats every four and a bit lines. How odd.Accidental recursion (calling a function from within itself) perhaps?

author: Brumby
author_rank: Unknown
timestamp: August 02, 2017, 08:54:45 am
content: I believe I have found it - but to respond to the posts...Quote from: mauroh on August 02, 2017, 07:55:08 amThe code isn't going to help you unless I post the whole lot (and even then, I have my doubts) - and I'm not doing that ... especially now.Quote from: hamster_nz on August 02, 2017, 08:15:50 amThank you for looking at the pattern - that's what I was hoping someone might recognise. You are forgiven for not having an answer, but you effort is appreciated.My suspicion was that there may have been an issue with the serial output buffer getting corrupted.The problem seems to have been alleviated by going through the sketch and commenting out a lot of the debugging code and variables. This was prompted by reviewing the compiler messages warning of low memory availability causing stability problems.I had seen this message frequently and there had been no problems (until now) so I had not paid close attention to the details - but this time I check the figures and it reported that there was only 180 bytes free for local variables ... and that might not be enough.I tend to run with Global variables - so I might need to look at a more intelligent use of Local variables if things get tight.To test this theory out, I re-enabled a truckload of Serial and Serial.print statements - and it all ran smooth as silk.

author: sleemanj
author_rank: Super Contributor
timestamp: August 02, 2017, 09:20:16 am
content: > I might need to look at a more intelligent use of Local variables if things get tight.Remember to "F" your constant strings :-)Serial.print(F("Blah"))instead ofSerial.print("Blah")the second form takes space both in program memory and in ram.The first form takes space in program memory but is copied into ram only temporarily when whatever is going to use it, uses it (provided that thing knows what to do with an __FlashStringHelper, like Serial).So if you doSerial.print("HELLO");Serial.print("WORLD");that's going to consume 12 bytes of ram, whileSerial.print(F("HELLO"));Serial.print(F("WORLD"));will need only 6 bytes of ram to contain the strings temporarily during the Serial.print() operation, after Serial.print() is done that 6 bytes will be free to use again.

author: Brumby
author_rank: Unknown
timestamp: August 02, 2017, 09:55:25 am
content: Thanks for the tip. That will be quite useful.I was just thinking over dinner that I need to look at making things into constants that don't need to be variables. This is a very easy change to implement, which is always nice.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: August 02, 2017, 09:57:27 am
content: Quote from: Brumby on August 02, 2017, 06:12:18 am<< is just syntactic sugar if you have template<class T> inline Print &operator <<(Print &obj, T arg) { obj.print(arg); return obj; } defined but you should usefully try simple .Print for now just to eliminate that variable. (If the template isn't in context you will probably end up with a bit shift!)

author: Brumby
author_rank: Unknown
timestamp: August 02, 2017, 10:15:54 am
content: I went through and changed all the Serial << statements to Serial.print to check - and it made no difference.Once I cleaned up the variables, everything has behaved (so far) even after I re-enabled a swag of debugging displays that used Serial << and Serial.print.This is the first time I've done a significant programming exercise on an Arduino Nano (clone). I haven't been as disciplined as I should - but now I have a heightened appreciation.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: August 02, 2017, 10:23:51 am
content: If you are interested you will find the source for HardwareSerial here...https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/HardwareSerial.cppI think .Print is blocking with a circular tx_buffer.... so corruption of tx_buffer (and/or tx_buffer_index) will cause trouble... but it looks like you solved your problem so... happy days.

author: Brumby
author_rank: Unknown
timestamp: August 02, 2017, 10:52:03 am
content: Yes. It was a fun afternoon.I have implemented the tip fromsleemanjand I've clawed back another 650 bytes. For just a couple of minutes work, that's a brilliant result.