data on parity in some
> drivers.)
>
> When sending a Break, the app can use other IOCTL to ensure the data is
> sent. Then Issue the break (stop issuing) and then resume.
>
> David
>
> -Original Message-
> From: Nathan Hartman
> Sent: Tuesday, January 31, 2023
, 2023 8:12 AM
To: dev@nuttx.apache.org
Subject: Re: Serial driver: No BREAK support?
Hi David,
If I understand correctly, if there is ongoing transmit of data that was
previously buffered, this will mask it?
In other words, if O_NONBLOCK and the application does something like:
write(...);
ioctl
Hi Alan,
Thanks for those links. FreeBSD does have excellent docs.
The 0.25 second to 0.5 second Breaks and >1.6 second Breaks discussed for
Unix-like systems are an artifact of the old school teletype systems and
that will work fine for my project right now.
But technically a Break is any
Hi David,
If I understand correctly, if there is ongoing transmit of data that was
previously buffered, this will mask it?
In other words, if O_NONBLOCK and the application does something like:
write(...);
ioctl(TIOCSBRK);
write(...);
then the Break will not necessarily be transmitted between
There are at least two types of breaks, from previous link:
"In modern systems there are two types of Break signals. If the Break
is longer than 1.6 seconds, it is considered a "Modem Break", and some
modems can be programmed to terminate the conversation and go on-hook
or enter the modems'
Hi Nathan,
Have you seen
https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32f7/stm32_serial.c#L2657
?
David
-Original Message-
From: Nathan Hartman
Sent: Monday, January 30, 2023 7:16 PM
To: dev@nuttx.apache.org
Subject: Serial driver: No BREAK support?
Serial
Hi Nathan,
Some UART drivers implement TIOCSBRK instead.
I was thinking we had a discussion about serial break here in the
mailing list, but I couldn't find it.
As I recall from that discussion (I think it was in the company, not
here in the list), there are different types and meanings of
