[SOLVED] Help needed with Arduino Serial Monitor output

[Brumby]

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 output should look like.

[mauroh]

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
 

[hamster_nz]

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?

[Brumby]

I believe I have found it - but to respond to the posts...

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
 

The 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.

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?

Thank 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.

[sleemanj]

> 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 of

  Serial.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 do
 
  Serial.print("HELLO");
  Serial.print("WORLD");

that's going to consume 12 bytes of ram, while

  Serial.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.

[Brumby]

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.

[NivagSwerdna]

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.

<< 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!)

[Brumby]

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.

[NivagSwerdna]

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.cpp

I 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.

[Brumby]

Yes.  It was a fun afternoon.

I have implemented the tip from sleemanj and I've clawed back another 650 bytes.  For just a couple of minutes work, that's a brilliant result.