Sending an int from C# to arduino that surpasses a bytes range.

[Artifactx]

Hello. I want to send an int value from C# and use that value as a delay on my arduino.

This is my C# Code:

Code: [Select]

            if (!sp.IsOpen)
            {   
                sp.Open();
            }
            int MyInt = 500;
            byte[] b = BitConverter.GetBytes(MyInt);
            sp.Write(b, 0, b.Length);
            Console.ReadLine();   

This is my Arduino Code:

Code: [Select]

byte ch;
int inputData;
int myDelay = 0;
boolean flag= true;
void setup()
{
  Serial.begin(9600);
  for(int i = 13; i > 10; i--)
  {
    pinMode(i, OUTPUT);
  }
}

void loop()
{ 
    digitalWrite(12,HIGH);
    delay(myDelay);
    digitalWrite(12,LOW);
    delay(myDelay);   
}

void serialEvent()
{
  while(Serial.available() && flag)
  {
    myDelay = Serial.read();
   flag = false;
  }
}

This works as long as  I don't send a value that is higher than the max val of a byte. But how do I handle values that are higher than 255?

[Grumpy_Mike]

If you want bigger numbers than a byte you must send and recieve two or more bytes.
The simplest way is to use something like a CR character to signify the end of the number.
So on the send side don't convert to a byte but send the int followed by a CR.
On the recieve side gather bytes until you get a CR. each byte toy gather or together with an eight times shifted to the left copy of the previous byte.

[PeterH]

You need to send a sequence of bytes containing your value. This means you need to decide on a message format. Your message format needs to make it possible to determine the start and end of each message. The simplest encoding scheme for this sort of data is to transfer it textually and use a text delimiter such as a linefeed to denote the end of the message. This means you need to format the number as a string on the sending side, and parse the string to obtain the number on the receiving side.

If bandwidth is an issue then sending the data in a binary format would result in smaller messages but then you need to deal with an encoding scheme that can contain arbitrary numbers - obviously, these could include any value you used to mark the start/end of the message so you the encoding scheme needs to be more complex.

[billroy]

Some of these little problems are fun to work in Bitlash.  You could upload Bitlash and paste in the two functions below…  note the sending end would need to send "d=25\n", not just "25".

Code: [Select]


// Blink pin 13 with programmable delay
// To change the delay, send "d=25" for 25 ms and so on
//
function t13 {d13=!d13; snooze(d);}
function startup {pinmode(13,1); d=100; run t13;}


Good luck with your project.

-br
http://bitlash.net

[PaulS]

I think some of you missed the point. OPs code IS sending multiple bytes. The receiving code is wrong.

OP, you need to consider whether you really want to send an integer from the PC to the Arduino as a series of bytes. The biggest difficulty with doing so is knowing how many bytes the int on the PC is, and what order they are.

Typically, the int is a 4 byte value. Sending those 4 bytes, vs. sending a string that represents the valid data that is in those 4 bytes may not represent any significant savings in number of characters sent. If the value, as in the example is 500, sending it as a string is 3 bytes ('5', '0', and '0'). Sending it as a series of bytes requires 4 bytes. So, in this case, the string wins.

Now, to be fair, you need to send some kind of delimiter at the end of the string, so that the Arduino can tell where in a string of characters like "1255045800" the values are, so a string involves a variable number of characters, instead of a fixed number of characters.

On the other hand, serial data delivery is not guaranteed, so, you'd need to send a sequence of bytes between each value sent, as stop/start bytes. Since any byte could contain a value that represents a byte in an int, you can't send a single byte as the start/stop byte. You'd typically send 4 bytes as the stop/start marker, each containing 0xFF. Then, you simply need to assure that 0xFFFFFFFF is not valid as a value to be sent. Of course, delaying for 0xFFFFFFFF milliseconds is not a useful thing to do, so that's not a problem. 4,294,967 seconds is 1,183 hours or 49+ days.