Pages: 1 [2]   Go Down
Author Topic: Printf in Arduino Due  (Read 3784 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
God Member
*****
Karma: 26
Posts: 625
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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).  smiley

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.
« Last Edit: November 30, 2013, 08:38:34 pm by Paul Stoffregen » Logged

UK
Offline Offline
Full Member
***
Karma: 0
Posts: 101
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

 smiley-wink smiley-evil All the time it has taken to write all these forum messages, I am thinking CR/LF could have been implemented in less time smiley-wink

Regards,

Grham
« Last Edit: November 30, 2013, 08:40:33 pm by ghlawrence2000 » Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2745
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

UK
Offline Offline
Full Member
***
Karma: 0
Posts: 101
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

This seems to be a long running issue in a variety of different areas, not just Arduino printf.

Quote
http://ascii-table.com/control-chars.php
Quote
[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.
Quote
[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.

Regards,

Graham
« Last Edit: November 30, 2013, 09:24:58 pm by ghlawrence2000 » Logged

0
Offline Offline
God Member
*****
Karma: 26
Posts: 625
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

UK
Offline Offline
Full Member
***
Karma: 0
Posts: 101
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?

Regards,

Graham
Logged

Pages: 1 [2]   Go Up
Jump to: