Cerberus/4.2 SerialPort Parity.Even issue

Archive
1

Hi all!

I’ve an issue with Cerb40 or .NETMF 4.2 and not-None Parity of SerialPort. With FEZ Mini (4.1) Parity.Even works fine. But I’m trying to port my imBMW.net project to Cerberus and found that only Parity.None works. Parity.Even and Parity.Odd corrupt data on sending (receiving works fine). Others throw exception in SerialPort constructor.

Here is original data:

Here is corrupted data using Parity.Even (on both SerialPorts):

Parity.Odd:

Solution for 8 data bits:

General solution from stm32 c++ wrapper sources:

2

By the way, I lost “mark as question” checkbox. Where is it?

3

looks like the data length has been changed from 8 to 7 bits?

4

No, the only change was made is Parity:

base(new SerialPortConfiguration(port, BaudRate.Baudrate9600, Parity.None, 8, StopBits.One)
//base(new SerialPortConfiguration(port, BaudRate.Baudrate9600, Parity.Even, 8, StopBits.One)
5

I meant on the receiving end…

6

It was a loopback test. RX and TX of two identically inited ports were connected.

7

There is a bug with serial parity on the STM Cerb port.
Try changing the data bits to 9.

1 Like
8

I’ll try, thanks!

9

@ Bill Gates - [quote]Try changing the data bits to 9[/quote]

i tihnk 9 databits make no sense and prefer 2 stopbits

Daniel

10

9 data bits works on the test device, will test it in the car. Where should I fix it to remove dirty hack with 9 bits? In the GHI’s TinyCLR firmware for Cerb/STM32F4? Are there any issue tracker?

11

@ toxsedyshev -
Hi,
I think there is nothing wrong and there is no corruption of data. I think using the parity bit only makes sense with a data length of 7 bit. That ist the length of one character in the original ASCII-Code. When you use the parity.even, the leading bit is set so that the sum of the 1 in the Byte is even. I looked on your example for parity.even and the leading bit was set correct in all cases (Edit: for data length = 7).
With data bits = 8 the parity bit makes no sense as there had to be a ninth bit and you would have to read a hole Byte to get the parity bit.
So I’m quite sure: if really parity is used, you have to set datalength to 7.
Cheers
Roland

12

8 bytes and even parity works with FEZ Mini, but doesn’t work with Cerb40. I connected them to each other and only 8 bytes on Mini and 9 on Cerb works together. I’ll try other proposed configuration options today in the car on real iBus devices.

13

@ toxsedyshev -
Hi,
just found this link.
So apparently 8 bits in conjunction with parity can be used an it seems really be true as Bill Gates posted, that on ST microcontrollers the datalength has to be set to 9 if 8 data bits with parity are wanted. But I think it’s not a bug, it’s only unconventional.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FUSART%20with%20data%20parity&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=1393

this unconventional notation seems to be passed through to NETMF

According to the NETMF library the SerialPort.DataBits Property is from 5 through 8.

Cheers
Roland

14

Finally confirmed in the car on real iBus devices that 9 data bits fixes SerialPort Parity on Cerberus family.

The first link is broken. I see that the second link from MSDN says that max count of data bits is 8, but it’s strange because wiki says that there are some usages of 9 data bits: Serial port - Wikipedia

Anyway, it’s definitely a bug. Where it should be fixed without dirty hack with 9 data bits? I can’t find implementation of Cerberus’ SerialPort in its OpenSource CodePlex project.

15

@ toxsedyshev -
yes, the links seems to be to long. You can get it with a Google search with the following keywords:
STMicroelectronics USART with data parity

16

As I understand, this piece of code is missed in Cerberus firmware:

case 0x08:
    if (USART_InitStructure.USART_Parity == USART_Parity_No) {
      USART_InitStructure.USART_WordLength = USART_WordLength_8b;
    } else {
      USART_InitStructure.USART_WordLength = USART_WordLength_9b;
    }

That’s a reason to set 9 bits manually.

17

And I have same problem too…

https://www.ghielectronics.com/community/forum/topic?id=10242

18

Just try 9 data bits instead of 8

19

I have the same problem with the following configuration:
Cerbuino Bee with the latest firmware (4.2).
The required serial port settings are:
Baud rate: 9600
Data bits: 7
Parity: Odd
Stop bits: 1

I notice that using binary read of the serial port, the parity bit (value 128) is part of the received byte!
Reading lines of text by using function serialport.Readline() does not work properly because the parity bit is interpretated as character outside the range of the standard ASCII-set. As a last resort I could use binary read of single characters…but that solution creates quite a lot of overhead…

I used all kinds of settings of the serialport, but no succes…
Could anyone come up with a suggestion to solve this problem?

Freeck

BTW:
The following initialisation of the com-port led to the following events:
Setting port parameters to 7 bits ,Space,1 stopbit, resulted in an exception error from “Microsoft.SPOT.Hardware.SerialPort.dll”.
Setting port parameters to 7 bits,Mark,1 stop bit, resulted in an exception error from “Microsoft.SPOT.Hardware.SerialPort.dll”.

20

@ freeck - What happens if you use this…