But if the number is negative it jumps to the next line.
The LCD used is a 20x4 character display and the maximum number to be displayed is 180.00 and the negative number looks like -9.00.
and here is my code which works just fine when I comment the test code out:
lcd.clear();
lcd.print("Running....");
lcd.setCursor(0,2);
lcd.print(freq1); // initial entry frequency
break;
I would suspect the formating in display Axis, also if you suing same LCD library keep in mind it MAY not initialize properly.
The one I am using has a note that it initilaizes properly only on factory default - on power. up.
I cannot make my to behave any differently after power -up.
Good luck.
Vaclav
setCurstor(0,1) and output more that 16 characters to the first line - works fine on first try
output less than 16 characters next time and it goes to the second line
Remove the setCursor (0,1)
output less than 16 characters and it goes to first line OK
The gotcha is - the LCD line has MORE than visible # of characters in a line and they do not get cleared by the LCD clear function.
So they are there (probably some kinda of character count) and the next write gets rolled over to the second line.
Another reason to ditch the LiquidCrystal,h library IMHO.
My workaround - limit # of characters per line - for now.
MarkT:
The tests for the magnitude of axis only work for positive axis, not negative - the absolute
value should be taken before comparing to 10.0 or 100.0
But then remains the question how to print the -n sign?
You should read the document. If your maximal is 100.00 and possibly -100.00 as minimal, then you need 7 total spaces and DON'T pad it with spaces, cause dtostrf does it already.
liudr:
You should read the document. If your maximal is 100.00 and possibly -100.00 as minimal, then you need 7 total spaces and DON'T pad it with spaces, cause dtostrf does it already.
I am surely missing something here as i dont see dtostrf padding spaces.
Now i have this code but stil no succes with the neg numbers.
I must bre dumber than dumb but i dont see it.
It's implied by the 2nd argument being the "minimum" field width. It probably pads on the wrong side of the number, though.
dtostrf handles the minus sign as well. But your original code will generate 7 characters for -9.0: (two spaces, because -9 is less than both 10 and 100, a minus sign, a 9, a decimal point, and two zeros.) This may overflow the buffer and cause unpredictable behavior.
(Hmm. In fact, dtostrf() seems to pad the way you'd want it to. So if the number is never larger than 999.99 (or smaller than -999.99) you can probably get what you want with:
OP should read dtostrf() document, period. I've used it for quite some time and it always behaves as expected with positive and negative, no need to manually pad.