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 sequence of 0 bits that triggers a Framing Error at the receiving UART. Most UARTs have the capability to detect the difference between a Break and a Framing Error caused by an actual error. If you are using 8N1 (8 data bits, no parity, 1 stop bit) then transmitting 10 consecutive 0 bits is considered a Break. Depending on the Baud Rate, that may be a millisecond or even much less. In fact, in one project I did a few years ago (not the project I'm working on now) two microcontrollers communicated via UARTs at 2 MHz with interrupt-driven DMA with multibyte messages transferred both ways every 1 millisecond. The problem with DMA is the possibility to lose synchronization so this project used a sequence of Breaks of ~5uS each to synchronize the two microcontrollers. The whole synchronization and handshake took a time span of microseconds -- not milliseconds but microseconds!! It was very cool and works robustly to this day. That's not what I'm working on now. Right now I just need the POSIX-like tcsendbreak() to work and send a Unix-like 0.25-0.5 second Break and that will work fine. Right now, NuttX is missing the tcsendbreak() function. I can add it but I need to figure out if in terms of APIs and standards, tcsendbreak() is supposed to be synchronous with the rest of the data (i.e. write() followed by tcsendbreak() followed by write() is expected to transmit those things in that order) or if tcsendbreak() is supposed to be immediate, masking any transmit in progress. The standards docs and man pages don't say. Once I know the answer to that, I can proceed with some kind of implementation. Cheers Nathan On Tue, Jan 31, 2023 at 7:05 AM Alan C. Assis <acas...@gmail.com> wrote: > 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 > >> > > >
