serial RS232 detect signal Break condiction

Hi,
I’d like to know if it would be possible to detect with BBB RS232 the signal Break condiction [which is caused by sending continuous Spacing values (no Start or Stop bits)].
I would need to syncronize my communication on a break received from external device on serial port…
I would need, in alternative, a way to detect a framing error…

any help would be appreciate…
thank you
Maui

Break condition
A “break condition” occurs when the receiver input is at the “space” level for longer than some duration of time, typically, for more than a character time. This is not necessarily an error, but appears to the receiver as a character of all zero bits with a framing error.

Not only is it possible, it already works. When enabled in the kernel (CONFIG_MAGIC_SYSRQ=y), sending a break to the serial console activates the Magic SYSREQ-key. if you type a break followed by a space (within 5 seconds) you wiil see SYSREQ HELP displayed Don’t hit other keys unless you know what you are doing.
How you handle the break in your application is off course up to you.

LP

Hi LP,

I’m not sure if we are talking about the same thing.
Here is how i understood what you are suggesting, I can catch a ctrl-c(break) with enabling the CONFIG_MAGIC_SYSRQ, am I Right? If so, it is not what I’m looking for.
I’m trying to implement in c code, the reading of a break event on the uart (framing error), but in the library termios, I can’t find any flag bit to catch the event.

Best Regards,

Maui

We are talking about the same thing, I merely used the magic sysreq as an example where it is being used.
that is what you asked, after all (is it possible to …)

If you want to catch an error (break, parity, framing) I suggest you study the MPU technical reference manual, chapter 19 I believe

LP

would you please paste in or attach a basic example?
thank you for support :slight_smile:

在 2013年6月26日星期三 UTC+8上午1:11:19,maui写道:

Hi , I have recently encountered the same problem, another pc is sensbreak,
I have set the BRKINT flag, and set ttyUSB0 to controlling tty successfully, but ttyUSB0’s program still didnt receive the SIGINT signal

On Mon, 9 Oct 2017 20:20:07 -0700 (PDT),
fang1457737815@gmail.com declaimed the
following:

Hi , I have recently encountered the same problem, another pc is sensbreak,
I have set the BRKINT flag, and set ttyUSB0 to controlling tty
successfully, but ttyUSB0's program still didnt receive the SIGINT signal

  I'm surprised that any /USB/ serial adapter passes a break signal.
Break, even if handled by a hardware UART (by holding the line down for
some long period), represents a disconnected (broken) serial line
(equivalent to a telephone "flash"/hook switch).

  USB itself does not support a physical break. USB<>serial adapters
would have to turn a break into some special command that can be sent over
a USB packet to the adapter, and turned into a hardware break at the
adapter itself -- at which point it may be considered rather futile: the
USB link obviously is not "broken" if packets are being received by the
adapter, so emulating a break would only be on the short span from the
adapter to the board. Similarly, a break from the board to the adapter
would have to be turned into some USB packet and sent to the host driver
which would have to emulate whatever a hardware UART break would cause.

https://electronics.stackexchange.com/questions/51750/does-transmitting-break-over-ftdi-chipset-yield-a-binary-0-received-on-the-recei
seems to say the user was seeing a null byte, and did not see any "framing
error" indication. Again, it could be that the driver on the sending
computer sent a null, but can not send a framing error over USB (remember,
while it looks like a UART to applications, it is just a data byte(s) to
USB packet on the line).

http://www.ftdichip.com/Products/ICs/FT232R.htm
does claim that chip has support for line-break... However, the spec sheet
only uses the word "break" once.
"""
The UART interface also supports the RS232 BREAK setting and detection
conditions.
"""
Doesn't say what it does with them, or how the USB side processes them.

FWIW, quite a few do, but sometimes the drivers don’t implement this since it’s relatively seldom used. Sometimes it’s easier to look in drivers/usb/serial/ for the driver, and check whether it implements .break_ctl (e.g. https://github.com/torvalds/linux/blob/master/drivers/usb/serial/ch341.c#L628 ) rather than try and find a datasheet…

Tim.