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' command mode when the modem detects this signal. If the Break is smaller than 1.6 seconds, it signifies a Data Break and it is up to the remote computer to respond to this signal. Sometimes this form of Break is used as an Attention or Interrupt signal and sometimes is accepted as a substitute for the ASCII CONTROL-C character."
BR, Alan On 1/30/23, Alan C. Assis <acas...@gmail.com> wrote: > 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 break > signal. > > It started with this discussion here: > https://github.com/esphome/feature-requests/issues/1494 > > Also please take a look at this document: > > https://docs.freebsd.org/en/articles/serial-uart/ > > BR, > > Alan > > On 1/30/23, Nathan Hartman <hartman.nat...@gmail.com> wrote: >> 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#1279671 >> >> Cheers, >> Nathan >> >
