Discussion:
Bug with MPC55XX eSCI serial port byte size and parity?
Peter Dufault
2014-08-23 13:19:59 UTC
Permalink
I think the behavior of the esci.c serial port driver in libcpu/powerpc/mpc55xx/esci/esci.c is incorrect. I'm basing this partly on this page:

https://www.cmrr.umn.edu/~strupp/serial.html

The eSCI itself supports 8 and 9 bits of data with and without parity.

I think TERMIOS CS7 and CS8 selects the number of data bits, and when parity is enabled you get an additional parity bit. So CS7 with parity sends 8 bits, and CS8 with parity sends 9 bits.

The existing driver rejects all character sizes except CS8 and allows enabling parity, but when you enable parity it sends 7 data bits and 1 parity bit, which I think is incorrect behavior.

The following settings can be supported using the 8 bit data setting on the eSCI (leaving the "M" bit in the device control register clear), essentially what the driver is doing now except it is always forcing you to specify "CS8":

8 bits, no parity, 1 stop bit (8N1):
options.c_cflag &= ~(PARENB|CSTOPB|CSIZE);
options.c_cflag |= CS8;

7 bits, even parity, 1 stop bit (7E1):
options.c_cflag &= ~(PARODD|CSTOPB|CSIZE);
options.c_cflag |= CS7|PARENB;

7 bits, odd parity, 1 stop bit (7O1):
options.c_cflag &= ~(CSTOPB|CSIZE);
options.c_cflag |= CS7|PARENB|PARODD;

The following settings can't currently be set, but can be supported by using the 9 bit data setting on the eSCI (setting the "M" bit in the control register):

8 bits, even parity, 1 stop bit (8E1):
options.c_cflag &= ~(PARODD|CSTOPB|CSIZE);
options.c_cflag |= CS8|PARENB;

8 bits, odd parity, 1 stop bit (8O1):
options.c_cflag &= ~(CSTOPB|CSIZE);
options.c_cflag |= CS8|PARENB|PARODD;

All other settings would be illegal, since the eSCI supports no other sizes and only supports a single stop bit.

Does this sound correct? I'll prepare a patch.

I verified that by setting the M bit you get 8 data bits plus 1 parity bit. A client of mine bumped into this problem trying to send data to a device that required 8 data bits plus parity, and it couldn't be done with the existing interface.

Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
Joel Sherrill
2014-08-23 13:56:39 UTC
Permalink
That all sounds very reasonable and since you have the hardware, you can check that it works. The interactive termios test is good for manually cycling through all the various settings. Change them on the target, then your comma program, see if the output is still right and then check another setting.

--joel
Post by Peter Dufault
I think the behavior of the esci.c serial port driver in
libcpu/powerpc/mpc55xx/esci/esci.c is incorrect. I'm basing this
https://www.cmrr.umn.edu/~strupp/serial.html
The eSCI itself supports 8 and 9 bits of data with and without parity.
I think TERMIOS CS7 and CS8 selects the number of data bits, and when
parity is enabled you get an additional parity bit. So CS7 with parity
sends 8 bits, and CS8 with parity sends 9 bits.
The existing driver rejects all character sizes except CS8 and allows
enabling parity, but when you enable parity it sends 7 data bits and 1
parity bit, which I think is incorrect behavior.
The following settings can be supported using the 8 bit data setting on
the eSCI (leaving the "M" bit in the device control register clear),
essentially what the driver is doing now except it is always forcing
options.c_cflag &= ~(PARENB|CSTOPB|CSIZE);
options.c_cflag |= CS8;
options.c_cflag &= ~(PARODD|CSTOPB|CSIZE);
options.c_cflag |= CS7|PARENB;
options.c_cflag &= ~(CSTOPB|CSIZE);
options.c_cflag |= CS7|PARENB|PARODD;
The following settings can't currently be set, but can be supported by
using the 9 bit data setting on the eSCI (setting the "M" bit in the
options.c_cflag &= ~(PARODD|CSTOPB|CSIZE);
options.c_cflag |= CS8|PARENB;
options.c_cflag &= ~(CSTOPB|CSIZE);
options.c_cflag |= CS8|PARENB|PARODD;
All other settings would be illegal, since the eSCI supports no other
sizes and only supports a single stop bit.
Does this sound correct? I'll prepare a patch.
I verified that by setting the M bit you get 8 data bits plus 1 parity
bit. A client of mine bumped into this problem trying to send data to
a device that required 8 data bits plus parity, and it couldn't be done
with the existing interface.
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
_______________________________________________
users mailing list
http://lists.rtems.org/mailman/listinfo/users
Peter Dufault
2014-08-23 19:22:09 UTC
Permalink
Post by Joel Sherrill
That all sounds very reasonable and since you have the hardware, you can check that it works. The interactive termios test is good for manually cycling through all the various settings. Change them on the target, then your comma program, see if the output is still right and then check another setting.
My major question is how TERMIOS, data size, and parity should work. To me it's vague. If it's agreed that 7 bit data with parity is 8 bits of data and 8 bit data with parity is 9 bits of data then I'll make up a patch.

Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
Chris Johns
2014-08-24 02:24:56 UTC
Permalink
Post by Peter Dufault
Post by Joel Sherrill
That all sounds very reasonable and since you have the hardware, you can check that it works. The interactive termios test is good for manually cycling through all the various settings. Change them on the target, then your comma program, see if the output is still right and then check another setting.
My major question is how TERMIOS, data size, and parity should work. To me it's vague. If it's agreed that 7 bit data with parity is 8 bits of data and 8 bit data with parity is 9 bits of data then I'll make up a patch.
This is defined in the Open Group
(https://www2.opengroup.org/ogsys/catalog/t101). In "Section 11.2.4
Control Modes" it states:

The CSIZE bits shall specify the number of transmitted or received
bits per byte. If ISTRIP is not set, the value of all the other bits
is unspecified. If ISTRIP is set, the value of all but the 7 low-order
bits shall be zero, but the value of any other bits beyond CSIZE is
unspecified when read. CSIZE shall not include the parity bit, if any.
If CSTOPB is set, two stop bits shall be used; otherwise, one stop
bit. For example, at 110 baud, two stop bits are normally used.

I hope this helps.

Chris
Peter Dufault
2014-08-24 22:37:27 UTC
Permalink
Post by Chris Johns
Post by Peter Dufault
Post by Joel Sherrill
That all sounds very reasonable and since you have the hardware, you can check that it works. The interactive termios test is good for manually cycling through all the various settings. Change them on the target, then your comma program, see if the output is still right and then check another setting.
My major question is how TERMIOS, data size, and parity should work. To me it's vague. If it's agreed that 7 bit data with parity is 8 bits of data and 8 bit data with parity is 9 bits of data then I'll make up a patch.
This is defined in the Open Group
(https://www2.opengroup.org/ogsys/catalog/t101). In "Section 11.2.4
The CSIZE bits shall specify the number of transmitted or received
bits per byte. If ISTRIP is not set, the value of all the other bits
is unspecified. If ISTRIP is set, the value of all but the 7 low-order
bits shall be zero, but the value of any other bits beyond CSIZE is
unspecified when read. CSIZE shall not include the parity bit, if any.
If CSTOPB is set, two stop bits shall be used; otherwise, one stop
bit. For example, at 110 baud, two stop bits are normally used.
I hope this helps.
Chris
It helps, I think my analysis is correct.

Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
Sebastian Huber
2014-08-25 06:54:14 UTC
Permalink
Hello Peter,

we never used or tested something else than 8N1.
--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber-L1vi/***@public.gmane.org
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Loading...