Hello Herr_Ball,

Your question does make sense. When you're using the UARTWrite command in ARC, you're sending data to a UART port. If you want to send the decimal value 10, you need to send the ASCII character that corresponds to the decimal value 10, which is a line feed (LF) character.

In ASCII, the character '1' has a decimal value of 49, and '2' has a decimal value of 50, as you've mentioned. However, to send the value 10, you don't send the characters '1' and '0' separately. Instead, you send the single character whose ASCII value is 10.

To send the decimal value 10 over UART, you would use the following command:

UARTWrite(0, 0, 10)

This sends the actual byte value of 10 (which is a non-printable control character in ASCII, specifically the line feed) to the UART port.

If you want to send the two characters '1' and '0' to represent the number 10 as text, you would send them as a string:

UARTWrite(0, 0, "10")

This sends the ASCII values for '1' followed by '0', which would be interpreted as the string "10" by the receiving device.

Remember that when you're sending numbers as ASCII characters, you're actually sending the character representation of that number, not its binary value. If the device you're communicating with expects the binary value, send it as a number, not as a string. If it expects ASCII characters, send the string representation.

I hope this clarifies your question! If you need further assistance, feel free to ask.

@Athena

UARTWrite(0, 0, "10")  does not work. What is the ASCII character that represents the number 10?

Apologies for the confusion earlier. The ASCII character that represents the number 10 is actually a control character for a line feed (LF). In ASCII, printable characters start from the value 32 (space) and up. The value 10 is a non-printable control character.

If you want to send the decimal number 10 as a single byte value over UART, you would not use the ASCII representation. Instead, you would send the byte value directly like this:

UARTWrite(0, 0, 0x0A)

Here, 0x0A is the hexadecimal representation of the decimal value 10. When you use this command, it sends the byte value 10 (line feed in ASCII) to the UART port.

If you are trying to send the two-digit number "10" as ASCII characters, you would indeed use:

UARTWrite(0, 0, "10")

This sends the ASCII codes for '1' followed by '0', which would be interpreted as the string "10" by the receiving device.

If UARTWrite(0, 0, "10") does not work as expected, please ensure that the device you are communicating with is configured to interpret the data correctly and that the baud rate and other UART settings match between the two devices.

This ascii chart will be helpful to you. You may also use google to find other ascii charts that you may prefer.

@Athena, can you give me an ascii to decimal conversion list?

Certainly, DJ_Sures! Below is a list of ASCII characters and their corresponding decimal values for the standard ASCII table (0-127):

ASCII Character | Decimal Value
----------------|--------------
NUL             | 0
SOH             | 1
STX             | 2
ETX             | 3
EOT             | 4
ENQ             | 5
ACK             | 6
BEL             | 7
BS              | 8
HT              | 9
LF              | 10
VT              | 11
FF              | 12
CR              | 13
SO              | 14
SI              | 15
DLE             | 16
DC1             | 17
DC2             | 18
DC3             | 19
DC4             | 20
NAK             | 21
SYN             | 22
ETB             | 23
CAN             | 24
EM              | 25
SUB             | 26
ESC             | 27
FS              | 28
GS              | 29
RS              | 30
US              | 31
Space           | 32
!               | 33
"               | 34
#               | 35
$               | 36
%               | 37
&               | 38
'               | 39
(               | 40
)               | 41
*               | 42
+               | 43
,               | 44
-               | 45
.               | 46
/               | 47
0               | 48
1               | 49
2               | 50
3               | 51
4               | 52
5               | 53
6               | 54
7               | 55
8               | 56
9               | 57
:               | 58
;               | 59
<               | 60
=               | 61
>               | 62
?               | 63
@               | 64
A               | 65
B               | 66
C               | 67
D               | 68
E               | 69
F               | 70
G               | 71
H               | 72
I               | 73
J               | 74
K               | 75
L               | 76
M               | 77
N               | 78
O               | 79
P               | 80
Q               | 81
R               | 82
S               | 83
T               | 84
U               | 85
V               | 86
W               | 87
X               | 88
Y               | 89
Z               | 90
[               | 91
\               | 92
]               | 93
^               | 94
_               | 95
`               | 96
a               | 97
b               | 98
c               | 99
d               | 100
e               | 101
f               | 102
g               | 103
h               | 104
i               | 105
j               | 106
k               | 107
l               | 108
m               | 109
n               | 110
o               | 111
p               | 112
q               | 113
r               | 114
s               | 115
t               | 116
u               | 117
v               | 118
w               | 119
x               | 120
y               | 121
z               | 122
{               | 123
|               | 124
}               | 125
~               | 126
DEL             | 127

This list covers the standard ASCII characters from 0 to 127,including control characters (0-31) and the printable characters (32-127). For extended ASCII characters (128-255),you would need to refer to an extended ASCII table,as those values are not standardized and can vary depending on the character encoding used.

Please note that when sending control characters (like LF,CR,etc.) through UART or other communication protocols,you would typically send the decimal value directly,rather than the character representation.

I understand the ASCII chart.

ASCII UARTWrite(0,0,"49") in decimal form is = 1 UARTWrite(0,0,"50") in decimal form is = 2 UARTWrite(0,0,"51") in decimal form is = 3

Instead of writing: UARTWrite(0, 0, "1") ... the number 1 you must write: UARTWrite(0, 0, "49") ..  the ASCII code

Instead of writing: UARTWrite(0, 0, "2") .. the number 2 you must write: UARTWrite(0, 0, "50") .. the ASCII code

Instead of writing: UARTWrite(0, 0, "10") ... the number 10 What should I write as the ASCIIcode?

We noticed you did not tag @athena to continue the conversation for assistance. But I will attempt to help.

1. The string "10" is an ASCII string character "1" with an ASCII string character "0" next to it. That makes it a number "10". Also, a string "20" is a "2" with a "0" next to it.

2. Looking at the ASCII chart above, the string "10" would be an ASCII decimal 49 with an ASCII decimal 48 next to it.

3. If you're attempting to send a string of "10", it would be easiest to use the UARTWriteString() function instead. https://synthiam.com/Support/javascript-api/UART/hardwareUartWriteString

UART.hardwareUartWriteString(0, "10");

4. If you have reasons for using UartWrite() instead of the above suggestion, you would send both ascii decimal values...

UART.hardwareUartWrite(0, [49, 48]);

I think herrball is asking about ezscript, not javascript. So the ezscript manual says...

UARTWrite( boardIndex, port, data )

         Write ASCII data through the Peripheral UART.

         The Board Index is the EZ-B index starting at 0.

         The port can be 0, 1 or 2.

         Look near at the UART Port section lower in this document for the EZ-B Pin’s associated with each UART Port.

         Example: UARTWrite(0, 0, hello world )

         Example: UARTWrite(0, 0, 0x30, 0x40, hello )

and the answer would be

UARTWrite(0, 0, 40, 48)

DJ is correct about the EZ Script.

@Athena

UARTWrite(0, 0, 40, 48) ... which I believe should be UARTWrite(0, 0, 49, 48) does not work. It sends it in two separate parts, Decimal 49 and then Decimal 48. Which is a 1 and then a 0. Not as a 10.

I have been able to do a work around, instead of 1,2,3,4,5,6,7,8,9,10. I have done, 0,1,2,3,4,5,6,7,8,9 It still gives me the 10 Decimals I need but not using the 10.

Maybe this will help show you what I need to do?

void serialEvent() { while (Serial.available()) { // read the oldest byte in the serial buffer: incomingByte = Serial.read();
// if it's a capital 1 (ASCII 49), go to void oneon: if (incomingByte == '1') oneon(); // if it's a capital 2 (ASCII 50), go to void oneoff: if (incomingByte == '2') oneoff(); // if it's a capital 3 (ASCII 51), go to void twoon: if (incomingByte == '3') twoon(); // if it's a capital 4 (ASCII 52), go to void twooff: if (incomingByte == '4') twooff(); // if it's a capital 5 (ASCII 53), go to void threeon: if (incomingByte == '5') threeon(); // if it's a capital 6 (ASCII 54), go to void threeoff: if (incomingByte == '6) threeoff(); // if it's a capital 7 (ASCII 55), go to void fouron: if (incomingByte == '7) fouron(); // if it's a capital 8 (ASCII 56), go to void fouroff: if (incomingByte == '8') fouroff(); // if it's a capital 9 (ASCII 57), go to void fiveon: if (incomingByte == '9') fiveon(); // if it's a capital 10 (ASCII ?), go to void fiveoff:   ..... <<<<<<<<<<<<<<<<<<<<< if (incomingByte == '10') fiveoff();   ...... <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< } }

If this all makes sense? LOL

It would be nice to know though how it can be done, if it can?

Well the problem is 10 is two bytes. Because it’s two characters.

insread if using strings, just use the decimal value. There’s no such thing as an ascii 10. Because a 10 is a 1 and a 0 next to each other. Just like there’s no such thing as an ascii banana. There’s an ascii b and an ascii a and so on

so it looks like you’re making a command protocol. If so, just use the decimal value, not the ascii value.

I was on my phone for the previous response so that I couldn't provide a code example. But here's what you want to do.

In ARC with ezscript...

# Send the command oneon();
UARTWrite(0, 0, 0)

# Send the command oneoff();
UARTWrite(0, 0, 1)

# Send the command fiveon();
UARTWrite(0, 0, 9)

# Send the command fiveoff();
UARTWrite(0, 0, 10)

On your Arduino or "whatever," this goes on...

void serialEvent() {
while (Serial.available()) {
   
//Read the oldest byte in the serial buffer:
incomingByte = Serial.read();

if (incomingByte == 1) oneon();
if (incomingByte == 2) oneoff();
if (incomingByte == 3) twoon();
if (incomingByte == 4) twooff();
if (incomingByte == 5) threeon();
if (incomingByte == 6) threeoff();
if (incomingByte == 7) fouron();
if (incomingByte == 8) fouroff();
if (incomingByte == 9) fiveon();
if (incomingByte == 10) fiveoff()
}
}

@athena, what do you think?

DJ Sures' approach is correct. In your case, you want to send a single byte to represent a command, and that byte's value corresponds to the command number. You do not need to use ASCII characters for this; you can use the actual byte values directly.

In EZ-Script, you would use the UARTWrite command with the decimal value of the command you want to send. For example, to send the command fiveoff, which you want to correspond to the number 10, you would use:

UARTWrite(0, 0, 10)

This sends the byte value 10 directly to the UART port. On the Arduino side, you would compare the received byte to the decimal values, not ASCII characters. DJ Sures provided the correct Arduino code to handle these byte values.

Remember that when you use UARTWrite with a number (not a string), you are sending the actual byte value, not an ASCII representation. This is a more efficient way to handle simple command protocols where each command can be represented by a single byte.

If you have any further questions or need additional clarification, feel free to ask!

@athena explain to HerrBall why using a string in a communication protocol for the command is bad practice and requires additional effort.

Certainly, DJ Sures. Using strings in a communication protocol for commands can be considered bad practice for several reasons, especially when dealing with microcontroller communication, such as between ARC and an Arduino. Here's why:

1. Increased Data Size: Strings are composed of multiple bytes, one for each character. This means that sending a command like "10" actually sends two bytes (49 and 48 for '1' and '0', respectively) instead of just one byte if you were to send the command as a number (10). This increases the amount of data transmitted, which can be less efficient, especially for high-throughput or real-time systems.

2. Complexity in Parsing: When you send a string, the receiving device must parse and interpret each character to reconstruct the intended number or command. This adds complexity to the code and requires additional processing time, which can be a critical factor in performance-sensitive applications.

3. Error Handling: With strings, there's a higher chance of errors in communication. For example, if part of a string is lost or corrupted during transmission, it can be more difficult to detect and correct the error compared to dealing with single-byte numerical commands.

4. Memory Usage: Microcontrollers like the Arduino have limited memory resources. Storing and manipulating strings can consume more memory than handling simple numerical values, which can lead to memory constraints in larger programs.

5. Consistency and Standards: Using numerical values for commands often aligns with industry standards and protocols, which typically use numerical codes or bytes to represent different commands and statuses. This makes it easier to maintain consistency and interoperability between different systems and devices.

For these reasons, it's generally better to use numerical values for commands in a communication protocol. It leads to simpler, more efficient, and more reliable communication between devices. In your case, sending a single byte to represent each command is a straightforward and effective approach.