next topic »

[Reply #15 on:]

I do recall a lot of RYRYRYRY test tapes as well as a lot of the "THE QUICK BROWN FOX JUMPED OVER THE LAZY DOGS BACK" tapes back in my Air Force days in the late 60s.

I was taught that the RYRYRY sequence was sent because it used and tested alternate bit combinations in the old 5-bit code used at the time.

Around Christmas time every year the data centers would be streaming and passing along wonderful graphic art work, kind of the predecessor of today's ASCII art and drawings. If the Russkies ever managed to break the crypto codes in the day and decoded one of these long 'art' messages (some were 10ft long when hung on a wall) I wonder what they would have thought of that.  

Lefty

[Reply #16 on:]

After a few tests on my arduino, it seems to me that the proposed code solves only one half of the problem. It indeed changes the parity on the arduino, but I am afraid the Serial library does not check for parity errors.

For example, using a PC and an Arduino2009 with Even parity, I sent a message from the PC and expected and answer from the arduino (using modbus RTU):
PC (8N1) <-> Ard (8E1): communication erros (expected behaviour)
PC (8E1) <-> Ard (8E1): communication correct (just as expected)
PC (8O1) <-> Ard (8E1): the arduino interprets the message as correct (it should not) and replies accordingly, however the PC reports the arduino message is wrong (parity error).
If I change the arduino to 8O1, I will get similar results (does not work with PC-8N1, works with PC-8O1, half works with PC-8E1).

It looks like the parity errors are never checked on the Arduino serial library (for example, by reading the UPEn flag on register UCSRnA).
Am I missing something?
If the serial library is indeed not checking for parity erros, any ideas how to solve it (preferably, without messing with the library)?

[Reply #17 on:]

If the serial library is indeed not checking for parity erros, any ideas how to solve it (preferably, without messing with the library)?

I think that would pretty much require a complete redo of the serial library as it is a very low level function and would have to have a standard interface to the user to let know when such errors occur (parity errors, framing errors, etc).

When reliable and rugged communications is required it's more common to do it at a higher level protocol instead of at a character at a time basis. Adding and checking for error free message can be done using CRC generation/error detection and message ack/nak handshaking between the two nodes.

It can be a complex subject and a lot depends on if one can dictate what standards will be used on both sides of the comm link. If not, one just has to adapt as best as they can.

Lefty

[Reply #18 on:]

I think that would pretty much require a complete redo of the serial library as it is a very low level function and would have to have a standard interface to the user to let know when such errors occur (parity errors, framing errors, etc).

At the low level: I was thinking to just "ignore" a character when a parity error occurs. According to the ATmega's manual, the parity is checked by the hardware, and it raises a flag everytime such an error occurs. I am rather new to the arduino, therefore I was not sure if there was something missing on the library side.

At a higher level: I am using Modbus RTU, so the CRC is there already.

Thanks for your response.

[Reply #19 on:]

If you are sending/receiving seven data bits, even or odd parity, you can always generate and check parity in your program.  Let the serial library default to eight data bits, no parity, set the parity bit in bytes you send, and check the parity bit in bytes you receive.

The parity bit is the high order bit in the byte.  For even parity, the high order bit is set to 0 or 1 as appropriate to make the total number of 1 bits in the byte (including the parity bit) an even number of bits.  For odd parity, the goal is an odd number of total bits in the byte.

You can shift and mask bits to count them, but a faster way is to use a lookup table.  If you use just one bit per table entry, your table will only be 16 bytes long.

Regards,

-Mike

[Reply #20 on:]

Hi

I am using the ArduinoMega with a Serial Servo controller. unfortunately the the servo controller requires 8N2 at 2400 baud. any idea how I can get this ??

I will appreciate any help i can get

Thanx
Maysam

[Reply #21 on:]

Framing bits are set using the USRnC register (where n is the hardware serial port)
I think the following code will set serial port 0 to 2400 baud 8N2

Code:

Serial.begin(2400);
 UCSR0C=0x0E; // 8n2

I don't have that board so I have not tried this, good luck