Some issues while communicating with C# appclication

hi everybody

I'm aware of this topic Recieve and send data from arduino to c# and vice versa - Interfacing w/ Software on the Computer - Arduino Forum.
I'm using an Arduino Uno Board.
I got some problems when my c# application allready opend a serial port and sending some 5 Byte command messages.
The first and the last byte is just for checking the message. The significant command lies between these two bytes.

  1. The sketch gets the message and activates some leds on the board via serialEvent function. this is working good.
    Now, I want a answer. This answer ist corrupted. Just one out of five bytes looks good. If I m debugging my C# code and breaking right before I get the answers everything is looking nice again. Is my communication to slow?

  2. Same issue, when sending some commands in a very short time.

  3. The application is using 9600 baud on the serial port. If I change this settings in the app and my sketch the messages are messed up and nothing happens to my leds. whats the problem in this case? baudrates up to 9600 are working, nothing faster is giving me a reponse., but the app opens the port without an exception.

in the attechment you ll find neary the same code as posted in the german forums for another topic. of cource a als can provide my poor c# app.

SMTDriver.zip (3.39 KB)

This demo shows how to send and receive data using Python. The approach will be the same for any language.

If you are attaching code to your posts please just add it as .ino files. Better still keep it short and just include it in your post.

...R

I'll check your example. Don't worry. The approach looks different to mine.
Sadly the python code looks ugly and like a ancienct language to me. Need some time with this code.
What do you think about the third problem I mentioned?

devpap7:
Sadly the python code looks ugly and like a ancienct language to me.

Don't dismiss Python on the basis of my poor use of it :slight_smile:

Personally I prefer Ruby but I have sadly come to the conclusion that Python is a great deal easier to work with. It is also more practical for people who use this Forum.

As far as I know the Python demo works fine up to 1,000,000 baud.

...R

I won't dismiss it. Just not familiar with python code.

But I really don't understand why my application isn't communication above 9600 Baud. Are there some constraints using C# and and a ino-Sketch with 19200 Baud for example? Are there some basic I need to understand first?

in the attechment you ll find neary the same code as posted in the german forums for another topic. of cource a als can provide my poor c# app.

You must have zipped something else. C# files do not use the cpp extension.

Yes, thats right. I zipped my Arduino Sketch with some librarys. Basically these are my lines:
In C#:

port = new SerialPort(m_portName, 9600);

In the ino/cpp file:

void setup()
{
	Serial.begin(9600);
       /* other stuff*/
}

Everthing up to 9600 is working nice. But everthing above is just giving me a little flash on the RX-LED on my board.

I'm sending message to the board like this from my C# app:

port.Write(m_messageBuffer, 0, m_messageBuffer.Length);

The messageBuffer is a 5 byte array. First and last byte to check the message.

Is there something I need to consider while using higher baudrates?

Why not write a short Arduino sketch and a short C# program that do nothing but exchange data with each other?

If you have Python installed on your PC you should be able to run the code I linked to. You will need to amend it to use the correct COM port - but I think the rest should work on Windows. If it works then you can experiment with different baud rates.

If it works you could write a short C# program to take the place of the Python program knowing that the Arduino code works properly.

And if (as I expect) the Python code works at high baud rates then you will know to explore the innards of your C# program for an explanation as to why it won't. I'm not aware of the need for any special treatment to deal with different baud rates.

...R

Okay. Let's do it this way. Maybe right now. Thanks for now.