Go Down

Topic: Printf in Arduino Due (Read 4738 times) previous topic - next topic

Paul Stoffregen

Dec 01, 2013, 02:33 am Last Edit: Dec 01, 2013, 02:38 am by Paul Stoffregen Reason: 1
I was just curious why the translation was thought to be important enough to put in that code
but now it is not in the new printf() for the Print class.

I'm pretty sure that was just a copy and paste from some other project.

That serial code is intended to process data 1 character at a time.  The original version (while developing the USB code) didn't use interrupts at all.  It doesn't matter if extra time is spent processing each character, since it's just going to busy loop on the UART, and it's never meant to be part of any real program anyway.

The print class code is meant to be in real applications.  Performance matters.  Processing data as a block is extremely beneficial when the output device is USB or Ethernet.  Taking a block of data and processing 1-byte-at-a-time involves a pretty big performance hit if individual bytes are sent to the USB Serial write() function.

There are lots of ways to deal with this, of course, involving more complexity.

So to directly answer your question Bill, my motivation is based on performance and simplicity, and also somewhat laziness (far too many other higher priority software priorities), and also somewhat laziness in that the _write(fd, buf, len) API maps neatly onto the print class write(buf, len).  :)

Then again, if not translating LF to CR+LF turns out to be a problem for a substantial number of users, I'll certainly respond by elevating the priority from "not likely to ever get around to it" to something likely to happen.  Much like supporting printf() at all in the Print class, which has been on my low priority list for many months, I did get around to it, mainly because it's been requested more frequently.  With only a limited number of hours in each day and a TODO list longer than I'll ever complete, I have to prioritize somehow.  I mostly go with what the most people want, and adding yet another layer for LF translation (without a big performance penalty on USB) is no exception.


Dec 01, 2013, 02:38 am Last Edit: Dec 01, 2013, 02:40 am by ghlawrence2000 Reason: 1
;) ]:) All the time it has taken to write all these forum messages, I am thinking CR/LF could have been implemented in less time ;)




I understand. I didn't mean to upset you. I was more interested out of curiousity
how you ended up with the different implementations
than any sort of prodding one direction or the other.
I'm a unix guy so I do agree with you.
I believe that unix got line endings correct long before the others
went off in their own different directions,
--- bill


Dec 01, 2013, 02:58 am Last Edit: Dec 01, 2013, 03:24 am by ghlawrence2000 Reason: 1
This seems to be a long running issue in a variety of different areas, not just Arduino printf.

[Ctrl] J 10 0A  LF Line Feed FE A format effector which advances the active position to the same character position of the next line.
[Ctrl] M 13 0D  CR Carriage Return FE A format effector which moves the active position to the first character position on the same line.

Try playing with an old EPSON FX80 dot matrix printer, you will find it behaves in the manner as defined above as does Windows Hyperterminal, such that if you want to go down a line AND start at the beginning of that line, you NEED to issue both CR AND LF.

The serial monitor in the IDE doesn't care, but that does not mean that people should not be aware of what CR, CR/LF or LF is actually 'supposed' to do.



Paul Stoffregen

I'm not upset.  You did ask pointedly about my reasoning, and I took a moment to explain.

I should also add that I might be willing to accept a pull request that adds this translation layer.  But if it imposes a lot of overhead, like taking block transfers and turning them into byte-at-a-time writes, it'll need to be disabled by default.

Then again, I could be really swayed by a pull request accompanied by some significant work to benchmark performance over a variety of print(), println() and printf() scenarios.


Well I eluded to this in my previous post, but my 'tuppence worth, is that if you do need to issue "\r\n" then do so, but if the choice is taken away programatically such that "\n" will issue CR/LF regardless.............. what if a user actually requires independent control of "\n" , "\r", "\n\r" or am I missing the point here?



Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131