[En-Nut-Discussion] Cooked text mode for socket streams

[Philipp Burch]

Hi Harald!

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.

Thanks,
Philipp