Hi David, Thank you for this input. That is extremely helpful! Knowing it is asynchronous, I can go ahead and add the support. I'll get started on the PR right away.
By the way, as I understand it, Unix-like OSes do not support delivering BREAK to the application either. It's not just a limitation in NuttX. For example: BRKINT exists but sends a SIGINT only for one controlling port and is out-of-sync with the received data stream. It is possible to configure termios to report a BREAK as the sequence 0xff, 0x00, 0x00 in the data stream, but if this collides with any valid data sequence (i.e., if your messaging format is binary and that sequence could conceivably appear in a normal message) then it will not be acceptable. On Linux it is possible to poll TIOCGICOUNT ioctl. This gives counters for the number of BREAKs, Frame Errors, and Parity Errors on that port, which can be compared to previous values. And like the first option above (BRKINT), detection of the BREAK is out-of-sync with the received data stream... and you have to poll this and guess what happened. In other words, receiving BREAKs on Unix-like OSes is clumsy. Sending BREAKs is easy with tcsendbreak() and you get "something" in the range of 0.25 to 0.5 seconds, and that's exactly what I'm working on. PR coming soon... Thanks again, Nathan On Tue, Jan 31, 2023 at 2:30 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > 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 > >
