[En-Nut-Discussion] Cooked text mode for socket streams
phip at hb9etc.ch
Fri Sep 27 11:06:01 CEST 2013
On 09/27/2013 10:45 AM, Harald Kipp wrote:
> Hi Philipp,
> On 27.09.2013 09:44, Philipp Burch wrote:
>> I've here an application where a board running Ethernut may be accessed
>> via a Telnet connection. This works well with a Linux client, but if I
>> connect from Windows, using e.g. Putty, the sent lines are displayed
>> shifted like so:
>> : abc
>> : def
>> : ghi
> Known problem, at least to me. I have a few apps, where a configuration
> menu is presented either at the RS-232 port or a telnet connection.
> The problem with cooked output is, that the carriage return has to be
> inserted, which introduces a lot of extra work for tiny CPUs. For the
> UART driver, the best place is when the output string is copied to the
> interrupt buffer. Handshake and buffer overflow processing requires
> single character processing anyway.
> Other interfaces like Ethernet are optimized for speed and always
> transfer blocks, never checking single characters. Thus, there is no
> good place available to insert single characters without significantly
> reducing the transfer rate.
Ok, this sounds like a reasonable explanation :) Looks like it's best to
update the strings. Some regex searches should make it relatively easy
to find about 99% of the locations which need to be changed. The last 1%
can then be treated as a bug for later solving...
> So far I solved this by a hack, using a flag. All linefeeds are
> transmitted by a specific function, which decides by the flag, if an
> additional carriage return is required. For a menu system this is no big
> problem, because it is mainly based on a data structure containing the
> dialogs and a few specific routines handling the user interface. In most
> other cases this is a bad solution.
Uhm, all of my outputs are based on either fputs() or one of the
printf() variants. Don't these call some underlying fputc() function
anyway for every single character? If yes, then this could be a place to
implement such functionality. Or could that break something else?
> Another solution may be based on the Telnet protocol. In fact, Nut/OS
> doesn't provide a real Telnet protocol. It's just a raw TCP connection.
> A full Telnet implementation allows to transfer optional settings when
> the session is started.
Correct, my Telnet also is just raw TCP. This always causes an unknown
command right after connecting, because the client sends some DOs and
DONTs. But that's not so much of an issue.
> For a quick solution, you may check your client capabilities. Not sure
> about Putty, but the command line Telnet typically allows to set a
> specific option for EOL-translation.
Yep, just checked this. Putty has a setting named "Implicit CR in every
LF", which does exactly this. It's not particularly nice, but should be
ok for a maintenance-only interface.
More information about the En-Nut-Discussion