If CONFIG_SERIAL_TERMIOS is not selected then non-consoles will do
nothing. In order to restore legacy behavior you would have to do this:
+#ifdef CONFIG_SERIAL_TERMIOS
if (
-#ifdef CONFIG_SERIAL_TERMIOS
dev->tc_iflag & ECHO
-#else - dev->isconsole -
On Thu, Mar 9, 2023 at 2:14 AM Nathan Hartman wrote:
> I guess you have to assess the intended lifecycle of your product and
> over-provision your MCU accordingly to the expected rate of growth of the
> firmware.
I would stick to the smallest-possible-core-kernel-and-base-by-design
and put everyth
On Wed, Mar 8, 2023 at 5:31 PM Gregory Nutt wrote:
>
> >> At some point NuttX will grow too large for deep embedded platforms.
> >>
> >>
> >> My concern exactly. Yes, POSIX compliance is super important because it
> >> provides portability: I regularly write a program and run it on PC and
> >> em
On Wed, Mar 8, 2023 at 11:31 PM Gregory Nutt wrote:
> Related: This would be an issue for people who have to support a product
> for an extended life. In the early 2010's, for example, there were
> products using NuttX based on MCUs with 32Kb of FLASH memory. I suspect
> those would already be in
On Wed, Mar 8, 2023 at 11:14 PM Nathan Hartman wrote:
> On Wed, Mar 8, 2023 at 4:02 PM Sebastien Lorquet
> wrote:
> > You are right about posix compliance, this is a valuable goal, but at
> > the same time it raises the hard remark:
> > At some point NuttX will grow too large for deep embedded pla
At some point NuttX will grow too large for deep embedded platforms.
My concern exactly. Yes, POSIX compliance is super important because it
provides portability: I regularly write a program and run it on PC and
embedded with almost no changes. This is one of the big selling points of
NuttX f
On Wed, Mar 8, 2023 at 4:02 PM Sebastien Lorquet
wrote:
> You are right about posix compliance, this is a valuable goal, but at
> the same time it raises the hard remark:
>
> At some point NuttX will grow too large for deep embedded platforms.
My concern exactly. Yes, POSIX compliance is super
You are right about posix compliance, this is a valuable goal, but at
the same time it raises the hard remark:
At some point NuttX will grow too large for deep embedded platforms.
That may or may not be true. Certainly NuttX has outgrown most old
architectures with 16-bit address space lim
You are right about posix compliance, this is a valuable goal, but at
the same time it raises the hard remark:
At some point NuttX will grow too large for deep embedded platforms.
Sebastien
On 3/8/23 21:41, Gregory Nutt wrote:
Historically, whenever we find a POSIX issue we have always fixed i
Historically, whenever we find a POSIX issue we have always fixed it in
order to as compliant as possible. In the hierarchy of values, POSIX is
probably at the top of the list and well above personal preferences and
novel solutions. In the name of POSIX compliance, we have eliminated
architec
On Wed, Mar 8, 2023 at 3:20 PM Gregory Nutt wrote:
> POSIX defines the TERMIOS options and, I suspect that those TERMIOS
> options are required, not optional (need to check that). If that is
> true, then there should be no CONFIG_SERIAL_TERMIOS option; it should
> always be enabled.
Unless the
POSIX defines the TERMIOS options and, I suspect that those TERMIOS
options are required, not optional (need to check that). If that is
true, then there should be no CONFIG_SERIAL_TERMIOS option; it should
always be enabled.
On 3/8/2023 2:15 PM, Nathan Hartman wrote:
On Wed, Mar 8, 2023 at 2:
Hi,
This is a good idea to better follow posix.
This is typically the kind of stuff that would have deserved a message
on the dev list to say:
Hey friends we are improving terminals, expect bugs because it's hard to
get right, oh btw apps need to be updated too, otherwise strange things
m
On Wed, Mar 8, 2023 at 2:26 PM Xiang Xiao wrote:
>
> Since the code to handle the special process is very small, is it better to
> always allow application change ECHO and OPOST through TCSETS? So, the
> special function or program can disable ECHO/OPOST programmatically.
Only if termios suppo
On Thu, Mar 9, 2023 at 3:07 AM Gregory Nutt wrote:
>
> I imagine that this is occurring because readline also echos the
> input:
>
>
>
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
> The low-level serial driver should not e
I imagine that this is occurring because readline also echos the input:
https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
The low-level serial driver should not echo just because /isconsole /is
true. Console echo is always handled by the application.
On Thu, Mar 9, 2023 at 2:17 AM Gregory Nutt wrote:
>
> >> I imagine that this is occurring because readline also echos the input:
> >>
> >>
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
> >>
> >> The low-level serial driver should not echo just bec
I imagine that this is occurring because readline also echos the input:
https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
The low-level serial driver should not echo just because /isconsole /is
true. Console echo is always handled by the application. I
On Wed, Mar 8, 2023 at 12:09 AM Gregory Nutt wrote:
> I imagine that this is occurring because readline also echos the input:
>
>
> https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
>
> The low-level serial driver should not echo just because /isconsole /is
>
Many people are affected by this double echo
https://github.com/apache/nuttx/issues/8731
Sebastien
Le 07/03/2023 à 17:09, Gregory Nutt a écrit :
I imagine that this is occurring because readline also echos the input:
https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_c
I imagine that this is occurring because readline also echos the input:
https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
The low-level serial driver should not echo just because /isconsole /is
true. Console echo is always handled by the application. I wo
Hi,
I am connecting to my board using
python3 -m serial --raw --eol cr /dev/ttyUSB0 115200
This has ALWAYS worked.
Today it does not work anymore.
Every character I send to NSH is echoed TWICE, see below just typing help:
--
seb@lap:~$ python3 -m serial --raw
22 matches
Mail list logo