Hi Nathan,

As far as I know Breaks are Asynchronous (not buffer)

By definition: a BREAK is a Start bit that lasts for more bit times then the
configured word size, parity and stop bit times. This is how the receiver
detects it.

AFAIN NuttX can not propagate the reception of the break to an App as a
BREAK and may deliver 0s, (as it delivers bad 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 <hartman.nat...@gmail.com>
Sent: Tuesday, January 31, 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(TIOCSBRK);
write(...);

then the Break will not necessarily be transmitted between the two writes.
It will very likely be transmitted during the first write, masking part of
that write.

Is my understanding correct, and is that the intended behavior?

Thanks for that link. I didn't know about TIOCSBRK.

Nathan

On Tue, Jan 31, 2023 at 2:27 AM David Sidrane <david.sidr...@nscdg.com>
wrote:

> 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 <hartman.nat...@gmail.com>
> Sent: Monday, January 30, 2023 7:16 PM
> To: dev@nuttx.apache.org
> Subject: Serial driver: No BREAK support?
>
> Serial communications sometimes use a condition called BREAK [1]. I
> need to interface to 3rd party equipment that uses this feature.
>
> In Unix-like OSes a BREAK can be sent by calling termios function
> tcsendbreak() or ioctl TCSBRK.
>
> NuttX has an extern declaration for tcsendbreak() and a #define for
> TCSBRK.
> However, there is no implementation for these in the serial driver (no
> such function, no handling for this IOCTL).
>
> I am wondering how to implement this in the serial driver. I know that
> the basic change is:
>
> (1) In libs/libc/termios/, add new file lib_tcsendbreak.c which calls
> ioctl TCSBRK.
>
> (2) In drivers/serial/serial.c uart_ioctl(), add a case for TCSBRK
> which calls the upper half driver, e.g., new function uart_tcsendbreak().
>
> (3) In uart_tcsendbreak(), do some magic.
>
> That magic is the question:
>
> What if there is pending transmit data? Then BREAK should happen after
> transmit done but before any new transmit data.
>
> What if filep->f_oflags & O_NONBLOCK? Then how does the driver
> schedule BREAK to happen after transmit done but before new transmit data?
>
> Any ideas would be appreciated.
>
> References:
> [1]
> https://stackoverflow.com/questions/1279478/rs-232-break-signal#127967
> 1
>
> Cheers,
> Nathan
>

Reply via email to