Serial issues - again.

[david]

Hi All,
A few weeks back I raised what I thought were some issues with high speed serial data but was eventually pacified however I have run in to more curious happenings that I would like to try to understand.

Issue 1.
It seems to me that when sending serial data in Decimal format that space is reserved to cope with the full potential data payload.  When sending a Word size value with a preceding identifier it sends "#" and then a total of 5 spaces or digits, even if the number is zero.   So zero is #----0 and 32000 is #32000 - almost identical in duration
Compare that to sending the same Word size value in Hex where a value of zero is $0 and 32000 (7D00) is $7D00.  So the use of Hex does not pad out the data to the size of the variable - it only sends the bare value.  Is there a reason Decimal format can not do the same?

Issue 2.
Sending two fields of data  - a signed Word value (decimal) with preceding identifier and a Word value (decimal) with preceding identifier.  I have two examples attached with both containing 4 digits in each field.   One example is taken at 115200 and takes 1.0mS.  (you can also see the gaps for unfilled numbers).  The second example is taken at 230400 and takes 0.92mS even though the bit period is half that of 115200.  So I double the baud rate, confirm the bit period is around 4.3uS and yet it is only marginally faster.  Where do all those extra gaps come from when all I changed was the baud rate?   Just to make sure the measurement system was not dropping out I used a terminal utility to generate a very similar payload and that looked ok (but I see I added two spaces at the start).

So Hex behaves as hoped/expected but Decimal is proving rather strange.

Cheers,
David

[trastikata]

Hello David,

I ran some tests, and regarding Issue 1:

There's an odd behavior when the the desired number of digits after the modifier is larger than the variable's maximum size, but other than that the modifiers and desired number of digits work as expected.Further down you can see the results from the test - each modifier Dec, Dec4, SDec ... is followed by the representation of the six variables and their values.

But I am not sure I fully understand the issue you described, can you include some code?

About Issue 2 - are you directly using the modifiers with conjunction with HSerout or you first build the string and then send it? Because if it is the former, then probably the time it takes for conversion to a string contributes significantly more to the total time than the transmission itself.

Code Select Expand

Unsigned (Dec, Dec4, Hex ...): bTest = 0 : wTest = 0 : dTest = 0 : bTest = 125 : wTest = 32000 : dTest = 320000
Signed (SDec, SDec4, SHex ...): sbTest = 0 : swTest = 0 : sdTest = 0 : sbTest = 125 : swTest = 32000 : sdTest = 320000

Dec
0
0
0
125
32000
320000
Dec4
0000
0000
0000
0125
2000
0000
Dec7
00000
00000
0000000
00125
32000
0320000
IDec
#0
#0
#0
#125
#32000
#320000
IDec4
#0000
#0000
#0000
#0125
#2000
#0000
IDec7
#00000
#00000
#0000000
#00125
#32000
#0320000
Sdec
0
0
0
125
32000
320000
Sdec4
0000
0000
0000
0125
2000
0000
Sdec7
00000
00000
0000000
00125
32000
0320000
ISdec
#0
#0
#0
#125
#32000
#320000
ISdec4
#0000
#0000
#0000
#0125
#2000
#0000
ISdec7
#00000
#00000
#0000000
#00125
#32000
#0320000
Hex
0
0
0
7D
7D00
4E200
Hex4
0000
0000
0000
007D
7D00
E200
Hex7
0000
0000
0000000
007D
7D00
004E200
SHex
0
0
0
7D
7D00
4E200
SHex4
0000
0000
0000
007D
7D00
E200
SHex7
0000
0000
0000000
007D
7D00
004E200
ISHex
$0
$0
$0
$7D
$7D00
$4E200
ISHex4
$0000
$0000
$0000
$007D
$7D00
$E200
ISHex7
$0000
$0000
$0000000
$007D
$7D00
$004E200


[tumbleweed]

Because if it is the former, then probably the time it takes for conversion to a string contributes significantly more to the total time than the transmission itself.

Bingo.

I think we've been through this before. If you use HSerout to format the string it calculates a digit, sends it, calculates the next digit, sends it, etc. The faster you make the baud rate, the more you'll see the time it takes to calculate each digit in between each char.

Contrast that to formatting the data into a string first and then sending the string. There will be minimal gaps between each transmitted char (since it's already formatted), but if you were to time the entire code it would end up being pretty much the same. All you can do is move around where the time is spent... it still takes about the same in the end.

[david]

Thank you trastikata.
Yes - I can see where I'm going wrong on the first issue now.

"The numbers after the Bin, Dec, and Hex modifiers are optional. If they are omitted, then the
default is all the digits that make up the value will be displayed. "

So I omitted the value after the IDec hence it will use the full compliment of spaces.  But I don't have a number after the IHex either and it doesn't do that.  Hex sends just the bare number.  Examples attached.
So the code I'm using is-
HRSOut ISDec turns  where turns is a signed Word variable
HRSOut IDec batt    where batt is a Word variable

I'm comparing to the same but in Hex format
HRSOut ISHex turns  where turns is a signed Word variable
HRSOut IHex batt    where batt is a Word variable

As for issue 2 - I'm sending directly from HRSOut without forming a string first.  The last example shows Hex being sent at 230400 with no numerical limits on the Hex yet it sends only the data required with no spaces.  Perhaps you're right and the formatting to Decimal is the bottleneck but it really puts a limit on the maximum UART speed you can use with Decimal.  The Hex works very nicely, even at 230400.

Cheers,
David

[david]

Many thanks tumbleweed.
I think we're converging on the Decimal formatting as the main issue here.  I have a very limited time budget for sending as I'm blurting out a little bit of data between stepper motor pulses down to about 800uS intervals.   The receiving end is much more relaxed so it would seem the best action would be to continue with using Hex and convert at the receiving end.

Cheers,
David

[trastikata]

Hello David,

I ran a second test and here are the results, I am confused because I don't see anything wrong with it, can you point me to the issue?

The receiving end is much more relaxed so it would seem the best action would be to continue with using Hex and convert at the receiving end

If there's a receiver that you have control over, then why not sending the data without conversion to a string and convert it at the receivers end? It will be much faster to send 2 Words (4 Bytes in total) instead of 12 bytes as string and you spare the conversion at the TX side.

[david]

I'm sure I've probably confused you by now.
Neither the Decimal nor the Hex results are wrong but I was curious as to why the Decimal format padded out the data sent with spaces.
So for IDec turns  if turns is a Word variable with a value of 0 then it sends #- - - - 0  (total 6 char spaces)
For IHex turns    if turns is a Word variable with a value of 0 then it sends  $0   (total 2 char spaces)
The manual does indicate that if the Dec or Hex is not defined by a numeral follow then it sends the extent of the variable used.  This is true for Dec but not for Hex.  A Hex Word could be FFFF but if the value is 0 it doesn't send $- - -0.
I'm sure the Hex is much easier to work with and I've underestimated the time needed to format to Decimal.

So my typical requirement is sending a signed 4 character Hex (or Dec) number followed by a 3 character Hex number (or 4 digit Dec).  As the last plot shows, I can send this as Hex with identifiers in around 425uS if using 230400. Is there a faster way?

Cheers,
David  (off to bed at 3:13am....)

[trastikata]

So my typical requirement is sending a signed 4 character Hex (or Dec) number followed by a 3 character Hex number (or 4 digit Dec).  As the last plot shows, I can send this as Hex with identifiers in around 425uS if using 230400. Is there a faster way?

Cheers,
David  (off to bed at 3:13am....)

  now the confusion has been cleared. As for the quoted part - refer to my second paragraph - you can send only 4 bytes (two words) with no conversion and deal with it at the RX side:

If there's a receiver that you have control over, then why not sending the data without conversion to a string and convert it at the receivers end? It will be much faster to send 2 Words (4 Bytes in total) instead of 12 bytes as string and you spare the conversion at the TX side.