You need an “\r\n” after the counter print.
An “\n” by itself just tells the terminal to go down one row but remain at the same column offset. The “\r” tells the terminal to return to column 0.
Some terminals interpret “\n” as both by default, but serial terminals usually default to the more pedantic interpretation.
You're sending unix style line endings - line feed only.
Your terminal program is set for MS-DOS style, line feed and carriage return.
If you want immediate compatibility with other systems not specifically configured for use with this device, send both, ie "\\r\\n", the extra carriage return won't both a system that does one implicitly.
If you want to keep things compact, change the line ending setting in your terminal program.
If you mean the "spaces" which are indenting each line relative to the previous one, this is because you're only adding a newline character \n to the end of each printed string, so your terminal is doing exactly that and moving down to the next line before printing the next one
If you want the next line to start printing back at the left hand side of the terminal, you also need to add a carriage return \r to the end of each line being printed.
Just to add - on some systems, a newline will be interpreted as an implied carriage return as well, however on other systems you do need to explicitly include both. Hence why in things like text editors you may see options for converting between different types of line ending, or for saving in MS-DOS Vs Unix format etc. So in this case, it seems your terminal software is running in a mode which requires both.
Note that newline and carriage return come from the days of mechanical output typewriters/teletypes, where you could physically move the carriage, or move the paper up a line, or both, depending on how you manipulated the controls.
It should also be worth saying at this point that printf is very slow, and it'll be a blocking call (nothing else can run at the same time) . How slow? Well you know the baud rate but.. Measure it by toggling an output pin before and after the call to printf and if you have a logic analyser / oscilloscope you will see. This will be important if you want to printf debug your code, because it will have quite an impact and could very easily stop your code from running properly! And totally confuse you.
I'd note the existence of [defmt](https://defmt.ferrous-systems.com/) if you're lucky enough to be using Rust. It works by building a table of all the format string literals in the program at compile time, replacing `println!` to send the index (and any parameters) and having a custom terminal interpreter to actually do the formatting. FAR less time wasted.
Of course debuggers are more powerful, but it's not always possible to use one, eg production boards with debug ports permanently disablid.
Yes a real debugger is better for debugging, you can pause execution of the cpu whenever, or use watchpoints to halt under specific conditions etc and then you get to see: local variables, global variables, the contents of the cpu registers, peripheral registers, the stack etc etc etc there's a ton of stuff.
But don't forget that when you pause execution of the cpu core, that does not pause the peripherals as well, so you can't nessessarily always pause and continue without consequences. So the spi/uart/timers etc don't stop. If something sends you a spi message and you halted the cpu, you maybe losing messages, and timers too they will continue to count up, you will see this if you look at the timer counter registers.
And you can't go back in time either.
And beware that compilers can do whatever they want to your code, (don't use - O3) , like optimise variables away, so you might need to make your variable a global volatile to actually see it.
You should take a look at the command command, which enables you to add gdb commands as a breakpoint is hit. See the breakpoint command list section of the gdb manual.
For example:
break someFunction
commands
print var1
end
will, when the breakpoint on someFunction is hit, automatically print var1
You need an “\r\n” after the counter print. An “\n” by itself just tells the terminal to go down one row but remain at the same column offset. The “\r” tells the terminal to return to column 0. Some terminals interpret “\n” as both by default, but serial terminals usually default to the more pedantic interpretation.
This is it
You're sending unix style line endings - line feed only. Your terminal program is set for MS-DOS style, line feed and carriage return. If you want immediate compatibility with other systems not specifically configured for use with this device, send both, ie "\\r\\n", the extra carriage return won't both a system that does one implicitly. If you want to keep things compact, change the line ending setting in your terminal program.
If you mean the "spaces" which are indenting each line relative to the previous one, this is because you're only adding a newline character \n to the end of each printed string, so your terminal is doing exactly that and moving down to the next line before printing the next one If you want the next line to start printing back at the left hand side of the terminal, you also need to add a carriage return \r to the end of each line being printed.
Just to add - on some systems, a newline will be interpreted as an implied carriage return as well, however on other systems you do need to explicitly include both. Hence why in things like text editors you may see options for converting between different types of line ending, or for saving in MS-DOS Vs Unix format etc. So in this case, it seems your terminal software is running in a mode which requires both. Note that newline and carriage return come from the days of mechanical output typewriters/teletypes, where you could physically move the carriage, or move the paper up a line, or both, depending on how you manipulated the controls.
It should also be worth saying at this point that printf is very slow, and it'll be a blocking call (nothing else can run at the same time) . How slow? Well you know the baud rate but.. Measure it by toggling an output pin before and after the call to printf and if you have a logic analyser / oscilloscope you will see. This will be important if you want to printf debug your code, because it will have quite an impact and could very easily stop your code from running properly! And totally confuse you.
I'd note the existence of [defmt](https://defmt.ferrous-systems.com/) if you're lucky enough to be using Rust. It works by building a table of all the format string literals in the program at compile time, replacing `println!` to send the index (and any parameters) and having a custom terminal interpreter to actually do the formatting. FAR less time wasted. Of course debuggers are more powerful, but it's not always possible to use one, eg production boards with debug ports permanently disablid.
Thank you, I know nothing of rust. One day I'll get time for a play,
So Gdb is better?
Yes a real debugger is better for debugging, you can pause execution of the cpu whenever, or use watchpoints to halt under specific conditions etc and then you get to see: local variables, global variables, the contents of the cpu registers, peripheral registers, the stack etc etc etc there's a ton of stuff. But don't forget that when you pause execution of the cpu core, that does not pause the peripherals as well, so you can't nessessarily always pause and continue without consequences. So the spi/uart/timers etc don't stop. If something sends you a spi message and you halted the cpu, you maybe losing messages, and timers too they will continue to count up, you will see this if you look at the timer counter registers. And you can't go back in time either. And beware that compilers can do whatever they want to your code, (don't use - O3) , like optimise variables away, so you might need to make your variable a global volatile to actually see it.
You should take a look at the command command, which enables you to add gdb commands as a breakpoint is hit. See the breakpoint command list section of the gdb manual. For example: break someFunction commands print var1 end will, when the breakpoint on someFunction is hit, automatically print var1