BrettThePark at 04:22, 26 October 2011

2011-10-26T04:22:21Z

BrettThePark at 04:21, 26 October 2011

2011-10-26T04:21:07Z

BrettThePark: Created page with "During testing an issue appeared while using version 11b of NewSoftSerial. In order to make sure everything was going correctly, the arduino was set up to echo back any bytes t..."

2011-10-26T04:07:15Z

Created page with "During testing an issue appeared while using version 11b of NewSoftSerial. In order to make sure everything was going correctly, the arduino was set up to echo back any bytes t..."

New page

During testing an issue appeared while using version 11b of NewSoftSerial.

In order to make sure everything was going correctly, the arduino was set up to echo back any bytes that it received via the software serial connection. This presented an error. In total, 16 bytes were send in one burst and 15 bytes were received back.
<syntaxhighlight lang="cpp">
f0:7f:7f:03:00:00:7f:01:7f:00:00:02:00:7f:00:f7 // Data Sent
f0:7f:7f:03:80:80:bf:80:bf:80:80:81:80:01:dd //Data received
</syntaxhighlight>

As you can see by the data received the first few bytes work fine, but as time goes on the bytes are not correct but still seem to be in some sort of order.

Lets look closer at the binary version of the data

{| border="1" cellspacing="0" cellpadding="2" style="font-family: monospace;"
|-
!scope="col"| Byte
!scope="col"| Sent Hex
!scope="col"| Received Hex
!scope="col"| Sent Binary
!scope="col"| Received Binary
|-
!scope="row"| 1
| 0xF0
| 0XF0
| 11110000
| 11110000
|-
!scope="row"| 2
| 0x7F
| 0X7F
| 01111111
| 01111111
|-
!scope="row"| 3
| 0x7F
| 0X7F
| 01111111
| 01111111
|-
!scope="row"| 4
| 0x03
| 0X03
| 00000011
| 00000011
|-
!scope="row"| 5
| 0x00
| 0X80
| 00000000
| 10000000
|-
!scope="row"| 6
| 0x00
| 0X80
| 00000000
| 10000000
|-
!scope="row"| 7
| 0x7F
| 0XBF
| 01111111
| 10111111
|-
!scope="row"| 8
| 0x01
| 0X80
| 00000001
| 10000000
|-
!scope="row"| 9
| 0x7F
| 0XBF
| 01111111
| 10111111
|-
!scope="row"| 10
| 0x00
| 0X80
| 00000000
| 10000000
|-
!scope="row"| 11
| 0x00
| 0X80
| 00000000
| 10000000
|-
!scope="row"| 12
| 0x02
| 0X81
| 00000010
| 10000001
|-
!scope="row"| 13
| 0x00
| 0X80
| 00000000
| 10000000
|-
!scope="row"| 14
| 0x7F
| 0X01
| 01111111
| 00000001
|-
!scope="row"| 15
| 0x00
| 0XDD
| 00000000
| 11011101
|-
!scope="row"| 16
| 0xF7
|
| 11110111
|
|-
|}

Everything up to bytes 5 is identical. Lets layout the binary in a stream.

<syntaxhighlight lang="cpp">
| byte5| byte 6| byte 7| byte 8| byte 9| byte10| byte11| byte12| byte13| byte14| byte15| byte16|
000000000000000001111111000000010111111100000000000000000000001000000000011111110000000011110111 //sent
1000000010000000101111111000000010111111100000001000000010000001100000000000000111011101 //recv
</syntaxhighlight>

For byte 5 and bytes 6 the only problem is that the first bit of each packet has been changed to a 1 from a 0. Byte 7 received then begins with a 1 when it should also start with a 0. However, if we were to erase the first bit of byte 7, things start lining up again:
<syntaxhighlight lang="cpp">
| byte5| byte 6| byte 7| byte 8| byte 9| byte10| byte11| byte12| byte13| byte14| byte15| byte16|
000000000000000001111111000000010111111100000000000000000000001000000000011111110000000011110111 //sent
100000001000000001111111000000010111111100000001000000010000001100000000000000111011101 //recv
1 was erased
</syntaxhighlight>

Now bytes 7, 8, and 9 are correct but start going bad at byte 10 again. At this point we can assume that maybe the timing of reading data is slightly off (as we are using software not hardware). During [http://en.wikipedia.org/wiki/Asynchronous_serial_communication Serial Communication] there are actually 10 bits sent per byte. The first or "start" bit signals the start of a transmitting byte and occurs when the line goes from 1 to 0 and the last bit (stop bit) is a 1. If the process of grabbing the data off the line was slightly slow, it would be possible to accidentally read the stop bit as if it were actually part of the data. At first you might think that if this was the case the bad 1 value would occur at the end of the byte. However, the serial line is transferring the bits with the least significant bit (lsb) first.

For example:
<syntaxhighlight lang="cpp">
Sending 0x00 // hex
Byte: 00000000 //binary
With Start and stop Bits:0000000001 //

First we change the serial line from 1 to 0 this causes the receiver to know a byte is coming:

0000000001
|

Then we start sending data from right to left (not including the stop byte)
0000000001
|
0000000001
|
0000000001
|
0000000001
|
0000000001
|
0000000001
|
0000000001
|
0000000001
|
0000000001
|

Another example:
If we number all the bits: 12345678

We send the data like so: Start Bit 8 7 6 5 4 3 2 1 Stop Bit
</syntaxhighlight>

So the end result that if the timing is off and the stop bit is accidentally read, it will cause the most significant bit (msb) of the byte to be a 1.

== Solution ==

The solution is to alter the timing of the NewSoftSerial parameters to work slightly faster than they are.

In our particular example we are operating at 57600 baud on a 16Mhz processor. If we look in the cpp file for NewSoftSerial library we can find this table.
<syntaxhighlight lang="cpp">
static const DELAY_TABLE PROGMEM table[] =
{
// baud rxcenter rxintra rxstop tx
{ 115200, 1, 17, 17, 12, },
{ 57600, 10, 37, 37, 33, },
{ 38400, 25, 57, 57, 54, },
{ 31250, 31, 70, 70, 68, },
{ 28800, 34, 77, 77, 74, },
{ 19200, 54, 117, 117, 114, },
{ 14400, 74, 156, 156, 153, },
{ 9600, 114, 236, 236, 233, },
{ 4800, 233, 474, 474, 471, },
{ 2400, 471, 950, 950, 947, },
{ 1200, 947, 1902, 1902, 1899, },
{ 300, 3804, 7617, 7617, 7614, },
};
</syntaxhighlight>

There are three timings we are interested in.

rxcenter: This is the time it takes to go from the edge of the start bit to about half way through the bit (in order to center reading).

rxintra: This is the time to wait between sampling bits of the data

rxstop: This is the time to wait for the stop bit to finish being sent.

In order to speed things up slightly the rxcenter has been modified to be 8 so the bits are caught slightly closer to the start and the rxstop has been altered so we don't take quite as long waiting for the stop bit. This solves the problem by kicking out of the interrupt slightly quicker which allows it to be called again faster in situations where a lot of data is being sent all at once.

<syntaxhighlight lang="cpp">
static const DELAY_TABLE PROGMEM table[] =
{
// baud rxcenter rxintra rxstop tx
{ 115200, 1, 17, 17, 12, },
{ 57600, 8, 37, 30, 33, }, //Changed rxCenter to 8 and rxstop to 30
{ 38400, 25, 57, 57, 54, },
{ 31250, 31, 70, 70, 68, },
{ 28800, 34, 77, 77, 74, },
{ 19200, 54, 117, 117, 114, },
{ 14400, 74, 156, 156, 153, },
{ 9600, 114, 236, 236, 233, },
{ 4800, 233, 474, 474, 471, },
{ 2400, 471, 950, 950, 947, },
{ 1200, 947, 1902, 1902, 1899, },
{ 300, 3804, 7617, 7617, 7614, },
};
</syntaxhighlight>

The new values were just found by trial and error. Perhaps with some more time and greater insight more accurate values could be used.

← Older revision		Revision as of 04:22, 26 October 2011
Line 229:		Line 229:

	The new values were just found by trial and error. Perhaps with some more time and greater insight more accurate values could be used.		The new values were just found by trial and error. Perhaps with some more time and greater insight more accurate values could be used.
		+
		+	== External Links ==
		+	<references/>
		+	{{Comments}}

@@ Line 133: / Line 133: @@
 </syntaxhighlight>
-Now bytes 7, 8, and 9 are correct but start going bad at byte 10 again. At this point we can assume that maybe the timing of reading data is slightly off (as we are using software not hardware). During [http://en.wikipedia.org/wiki/Asynchronous_serial_communication Serial Communication] there are actually 10 bits sent per byte. The first or "start" bit signals the start of a transmitting byte and occurs when the line goes from 1 to 0 and the last bit (stop bit) is a 1. If the process of grabbing the data off the line was slightly slow, it would be possible to accidentally read the stop bit as if it were actually part of the data. At first you might think that if this was the case the bad 1 value would occur at the end of the byte. However, the serial line is transferring the bits with the least significant bit (lsb) first.
+Now bytes 7, 8, and 9 are correct but start going bad at byte 10 again. At this point we can assume that maybe the timing of reading data is slightly off (as we are using software not hardware). During Serial Communication <ref>http://en.wikipedia.org/wiki/Asynchronous_serial_communication</ref> there are actually 10 bits sent per byte. The first or "start" bit signals the start of a transmitting byte and occurs when the line goes from 1 to 0 and the last bit (stop bit) is a 1. If the process of grabbing the data off the line was slightly slow, it would be possible to accidentally read the stop bit as if it were actually part of the data. At first you might think that if this was the case the bad 1 value would occur at the end of the byte. However, the serial line is transferring the bits with the least significant bit (lsb) first.
 For example:

Rainboard NewSoftSerial - Revision history

BrettThePark at 04:22, 26 October 2011

BrettThePark at 04:21, 26 October 2011

BrettThePark: Created page with "During testing an issue appeared while using version 11b of NewSoftSerial. In order to make sure everything was going correctly, the arduino was set up to echo back any bytes t..."