• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 541 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Serial Port Break Clarification

460822
Genius 4055 points

Many years ago, when the serial port protocol was started, a break was defined as the time between bursts of bytes.  Bursts of bytes (one or more) are transmitted ... then there is a pause before the next burst of bytes is transmitted.  That pause is a break.

To help keep things simple, a byte of data begins with a start bit and ends with a stop bit.  This is followed by a second byte with a start bit and stop bit.  The start bit can occur immediately after the last stop bit ... or it can occur later. 

The stop bit is the opposite polarity of the start bit.  If the start bit is a zero, then the stop bit is a one.  In this case, when the signal goes to zero after the stop bit, it is interpreted as another start bit. 

TI design folks have decided that the signal must be zero to be a break.  This is an error in logic.  Multiple start bits (more than 10) is a framing error.  A break is when there are multiple stop bits ... which is standard RS232 communication. 

It is unfortunate that some TI person decided to changed this protocol.  The current TI micros require us to use a timer to determine when there is a break in the communication.  This consumes time and power.  If TI micros used multiple stop bits as a break, it would reduce time and power consumption.

It would be good if TI modified their micros to handle this correctly.  I doubt it would impact anyone ... unlikely anyone uses the TI break system as it is unusable in its current form.

  • 0
    TI__Expert 6380 points

    Being an old mdoem jockey, that used breaks in the past to synchronize an async UART backplane, I figured I would ask.

    Which flavor of MSP430 are you using?

    For example, MSP430x2xx (assuming idle is high and start is high to low 1st bit)

    When UCMODEx = 00, 01, or 10 the receiver detects a break when all data, parity, and stop bits are low,

    regardless of the parity, address mode, or other character settings. When a break is detected, the UCBRK

    bit is set. If the break interrupt enable bit, UCBRKIE, is set, the receive interrupt flag UCAxRXIFG will also

    be set. In this case, the value in UCAxRXBUF is 0h since all data bits were zero.

     

    Now the trick often comes in what to do if the line is stuck low, I have no knowledge of MSP430 (I am on the analog support side) but some processors when resetting from break see a stuck low as another start bit transition and then things get very confusing - at least they did when I design "pocket modems" running on 9volt batteries 20 years ago...

     

  • 0
    Guru 35565 points

    Clyde Eisenbeis said:
    there is a pause before the next burst of bytes is transmitted.  That pause is a break

    No, it isn't - a Break is not the same as just a pause in transmission:

    • A pause in transmission just leaves the line in the idle ("Mark") state;
    • A Break puts it in to the Active ("Space") state

    Wikipedia said:
    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.

    http://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter#Break_condition

    Clyde Eisenbeis said:
    A break is when there are multiple stop bits

    No - that is just an idle line state!

    Cross-post: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/152249.aspx

     

     

  • 0 in reply to Andy Neil
    Genius 4055 points

    All MSP430 and TMS micros.

    Apparently there was a misinterpretation of a "break" more 30 years ago.  Back then we viewed a pause as a break.  I know of no equipment that operates using a break as described ... other than using something like Hyper Terminal.

    Typically I have an interrupt capturing all of the bytes ... with no notification that this is happening.  Only after all of the bytes have been received do I want to retrieve the bytes and interpret them.  I do this with a timer.  It would be simpler if this were done automatically by enabling a "detect pause" ... which would adjust automatically to handle the different baud rates.