Parity bit in UART

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a product with XMega sending and receiving 8 bit even parity with one stop bit through a RS-422 trasmitter/receiver. On the other end I have either a USB/serial (FTDI) or Ethernet/serial (MOXA) converter connected to a Windows PC. The serial port is seen as a virtual port by a terminal software Tera Term.

 

If I use any parity (even, odd, mark or space) in Tera Term everything works fine in both directions. Why wrong parity settings work as well? I have checked with an oscilloscope that XMega is sending even parity + one stop bit. Why aren't all characters dropped with odd parity setting and half of the characters with mark or space parity setting? Also setting two stop bits seems to nothing, although I can see from the oscilloscope that XMega is transmtting the next byte right away after the only one stop bit.

 

With the Ethernet/serial I can even use 7 bits setting, no parity etc. and it just keeps working. Only changing the baudrate seems to stop it.

 

The USB/serial can be stopped with 7 bits setting or no parity stetting.

 

Is this something special with these converters? Or with Tera Term? Or is this normal?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also checked with the scope, that the parity settings of the Tera Term do change the parity bit send to XMega. So is the default in Tera Term/Windows to ignore the value of the parity bit received?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jmaja1 wrote:
 is the default in Tera Term/Windows to ignore the value of the parity bit received?

More likely, I suspect the default is to ignore any Parity errors.

 

For specific questions about TeraTerm, go to the TeraTerm forums: http://logmett.com/support-forums

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did some searches on the TeraTerm forums. I found several questions about parity error handling, but no answers. Are terminal programs typically just ignoring the parity (and overrun) errors?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

jmaja1 wrote:

Are terminal programs typically just ignoring the parity (and overrun) errors?

 

What should they do in such a case?

 

They have no higher-level functionality to deal with any errors so I suspect that ignoring them is the right thing to do.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

What should they do in such a case?

 

They have no higher-level functionality to deal with any errors so I suspect that ignoring them is the right thing to do.

 

I don't know what they should do, but they could drop or mark the bytes with errors. Or give a warning that there are errors. Or at least tell that when you select e.g. even parity, that will change the format trasmitted and received, but no error detection is done while receiving. Or is that so obvious that it is always missing?

 

I'm just asking what are they doing, since it is quite hard to find any information about that. I did find some instruction how to make your own code to drop or mark parity errors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jmaja1 wrote:
I did find some instruction how to make your own code to drop or mark parity errors.
fyi, this changed in Windows 10 (updated driver, additional API).

There's sample source code for the Universal Windows Platform (UWP) for the added API.

Microsoft logo

Microsoft Windows USB Core Team Blog

What is new with Serial in Windows 10

by George Roussos [MSFT]

July 29, 2015

https://blogs.msdn.microsoft.com/usbcoreblog/2015/07/29/what-is-new-with-serial-in-windows-10/

...

2.   A Windows Runtime API for communication with Serial devices

...

Windows 10 SDK includes two Universal SDK samples illustrating this API:

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jmaja1 wrote:
 they could ... mark the bytes with errors.

But how would they do that?

 

Or give a warning that there are errors.

Again - how, exactly, would they do that?

 

The truth is probably that, nowadays, parity errors are so rare as to be not really worth considering.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

But how would they do that?

 

You can easily detect the errors in the code. So the only problem is how to let the user know. These are nowadays graphical softwares, so the characters with parity erros could be shown e.g. with red color. And you could show statistics telling XX parity errors in second or per 1000 bytes etc.

 

It is quite easy to get parity errors with microcontrollers using an internal resonator as a clock source. XMega 2M and 32M clocks may not be accurate enough unless you use DFLL.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But TerraTerm is a legacy product. Doubt much development has been done on it in years. If I were its developer, I would spend very little time and energy on it.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
But TerraTerm is a legacy product. Doubt much development has been done on it in years.
Jim,

 

I think you may be a bit confused about TT development. It's true the original stalled but another team took that up and have continued to develop the 4.x releases. As you can see here:

 

https://osdn.net/projects/ttssh2...

 

There have been recent releases as follows:

 

4.92 - 31st August 2016

4.91 - 31st May 2016

4.90 - 5th March 2016

etc.

 

AFAIK it is very much a "current development".

 

(oh and for those who care about such things if you want to know what it's doing with parity on the "inside" then the source is completely open and available to anyone with a copy of SVN. I had a quick look at the .sln files look like they are for Visual Studio version 12. That is the VS2013 release - so again quite up to date).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try using RealTerm, it has a status bit that turns red when an error occurs.  

 

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jmaja1 wrote:
 the only problem is how to let the user know

Yes - that was exactly my point!

 

If you don't like the way TeraTerm does it, you can easily get a refund of the full price you paid for it ...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was just looking at some of the TeraTerm source code. I see it doing things like this:

 

https://osdn.net/projects/ttssh2...

 

Presumably it would not be bothering to set Parity setting in the DCB if it did not intend to use it?

 

Apparently the way you get Rx data in Win32 is to handle WM_NOTIFY and the lParam points to an NMSERIAL structure in which the notification may be SPN_DATARECEIVED or SPN_ERRORRECEIVED. If the latter it may be further identified as CE_RXPARITY. So if anyone can be bothered to pull the entire TeraTerm source via SVN you could then grep the tree for those symbol names and see how they are handled (if!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

jmaja1 wrote:
 the only problem is how to let the user know

Yes - that was exactly my point!

 

If you don't like the way TeraTerm does it, you can easily get a refund of the full price you paid for it ...

 

I use TeraTerm and I'm mostly very happy with it. Not my intention to criticize it. It appears that almost all devices and softwares have the same problem. They allow you to change parity, but do not tell you anything about the effect of that change for reveiving.

 

I was stupid enough to think that most actually do parity error checking. Why is any device using parity bit in the first place, if it is not used while receiving?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

Try using RealTerm, it has a status bit that turns red when an error occurs. 

 

Thanks! Seems to work even with an Ethernet RS-422 converter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

legacy!

like most people only use 3 wires, (no handshake) 

 

I have to ask, do you check for frame error in the AVR code?   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jmaja1 wrote:
So is the default in Tera Term/Windows to ignore the value of the parity bit received?
It's not the application program, but the method of reading the UART/USART.  

If the device driver uses PIO, then the UART's status register could also be read to check for framing or parity errors for each byte received. 

But if DMA is employed to transfer the received bytes to the memory buffer, then a framing or parity error can no longer be associated with a particular byte.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

I have to ask, do you check for frame error in the AVR code?   

 

No I'm not. The device is not receiving anything in normal operation. The receiving is only needed for possible configuration that can be activated only by a special string.

 

The parity bit was specified by my customer. I found out now they are not using it for parity error checking.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found out now they are not using it for parity error checking.

???

what else can it be used for ? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

I found out now they are not using it for parity error checking.

???

what else can it be used for ? 

 

Backward compatibility. The earlier device thay used had a parity bit. It was not done to their specifications. So when changing the device they don't have to change any settings.