Remove CRLF conversion in ramlog

[尹声凯]

Hello everyone:

I submitted a PR(https://github.com/apache/nuttx/pull/8755) to remove CRLF 
conversion in ramlog, which is unnecessary in ramlog and causes extra overhead.
After removing the CRLF check, I will use memcpy instead of byte-by-byte copy, 
which will bring a large performance improvement.

Carriage returns are already discarded in 
libs/libc/stream/lib_syslogstream.c:152, and double checks will bring 
additional overhead.

Here's how long it took me to test syslog 100 times:
Original time: 1924us
Remove CRLF time: 1918us
Using memcpy time: 1094us

Let me know if you find any other issues, thanks!


Best regards,

Yin Shengkai

#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!**/#

Re: Default behavior of cu

[Tomek CEDRO]

On Mon, Mar 13, 2023 at 8:18 AM Huang Qi wrote:
> I see some implementation of cu (like BSD) will disable the echo and CR/LF 
> convertion and let remote machine to handle them.
>
> I prefer to follow the BSD way, is there any side effect for you? Or do you 
> have any suggetions?

I prefer this approach too, thanks Qi :-)

Driver should be as simple as possible, provide raw data, and perform
no "silent" transformation of data. The rest is up to the application
and/or explicit driver configuration :-)

On FreeBSD there is a `stty` utility [1] to display and change
terminal driver setup (i.e. parity, bits, speed, rtscts and rtsdtr
flow, etc), so you can setup your local terminal to a client needs
(i.e. setup usb-uart port to use / do not use rtscts flow used by some
esp32 boards to select bootloader mode), and/or setup the terminal to
a known state that client needs to adhere (most terminal clients can
do this easily).

Also I see stty man page relates to termios man page [2]. Cu [3] is
the most common utility for serial console, but I also use Minicom
with curses interface and lots of useful functions on a client machine
:-)

[1] https://man.freebsd.org/cgi/man.cgi?query=stty=1=html
[2] 
https://man.freebsd.org/cgi/man.cgi?query=termios=4=0=FreeBSD+13.1-RELEASE
[3] 
https://man.freebsd.org/cgi/man.cgi?query=cu=0=0=FreeBSD+13.1-RELEASE=default=html

Best regads :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Configuration of external RTC results in build error

[Michal Lenc]

Hello,




there seems to be a possible build error hidden in configuration of external
RTC. If configure CONFIG_RTC and CONFIG_RTC_EXTERNAL to use external RTC the
build ends

with following error:





undefined reference to `up_rtc_initialize'




This is caused by lines




https://github.com/apache/nuttx/blob/master/sched/clock/clock_initialize.c#L
218

and

https://github.com/apache/nuttx/blob/master/include/nuttx/arch.h#L2272




that declare and call function up_rtc_initialize which however I suppose is
not used since external RTC is to be configured. This happens since pull 
request #5232 (https://github.com/apache/nuttx/pull/5232) which removed && !
defined(CONFIG_RTC_EXTERNAL) from files mentioned above. The quick fix so 
far is to add the constrain of disabled CONFIG_RTC_EXTERNAL back as
suggested here (https://github.com/michallenc/incubator-nuttx/commit/bc04eb9
d891c44a6b41bb0badf34636e24e63b61).




Some ideas or objections? I am not sure if there was not some other change
that would require different configuration of external RTC.



Best regards,

Michal Lenc

Default behavior of cu

[Huang Qi]

Hi all,

There excatly are some issues after echo input in driver 
(https://github.com/apache/nuttx/pull/8691), the default behavior of cu is one 
of them should be discussed.
[https://opengraph.githubassets.com/d9287525ac4414548917840a0f06e871d6208b7ef78597353c79478a6ee0199f/apache/nuttx/pull/8691]
drivers/serial: Echo input in driver layer by no1wudi · Pull Request #8691 · 
apache/nuttx
Summary Works with apache/nuttx-apps#1608 Impact nsh Testing nsh and telnet
github.com

In current master, cu will let local machine handle the echo and CR/LF 
convertion by default, a major usage of cu (for me) is to connect to a AMP core 
(running another NuttX ) over uart_rpmsg, now the uart_rpmsg driver disabled 
its echo to avoid double the input (from the local core and AMP core).

I see some implementation of cu (like BSD) will disable the echo and CR/LF 
convertion and let remote machine to handle them.

I prefer to follow the BSD way, is there any side effect for you? Or do you 
have any suggetions?

BR,
Qi