Please help with writing to a serial port - C# Discussion Boards

1-Nov-11 20:12

Can anyone tell me why I cannot get this code to write to my serial port (microchip) ?

If I send "pin1=2" via the simpleserial object, it is received and the microchip code reacts. When I try and send it through the below method, the data is not received by the microchip and it does not react.

Thanks for reading.

using System;
using System.Collections.Generic;
using System.Text;
using System.IO.Ports;
using System.Windows.Forms;

namespace SimpleSerial
{
    class test
    {
        private void serialPortWrite()//(string lineToWrite)
        {
            SerialPort serialPort1 = new SerialPort();
            string lineToWrite = "pin1=2";
            serialPort1.PortName = "COM8";
            serialPort1.BaudRate = 115200;
            serialPort1.DataBits = 8;
            serialPort1.Parity = Parity.None;
            serialPort1.StopBits = StopBits.One;
            serialPort1.Open();
            MessageBox.Show(lineToWrite);
            //serialPort1.WriteLine("pin1" + "=" + "1");
            foreach (char chr in lineToWrite)
            {
                char[] buff = new char[1];
                buff[0] = chr;
                serialPort1.Write(buff, 0, 1);
            }

            serialPort1.Close();
        }
    }
}

BobJanova1-Nov-11 23:51

BobJanova

1-Nov-11 23:51

Looks like it must be in the options you're using; the write code is the same. (Though I don't understand why you send one byte at a time.)

turbosupramk32-Nov-11 2:10

2-Nov-11 2:10

Hi Bob,

Thanks for the reply. As you can see, I tried the "writeline" method as well.

In the simpleserial code example, they wrote one byte at a time as a keypress event and so I was trying to mimic that when troubleshooting after "writeline" didn't work.

What do you mean by "options"?

private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
  {
      // If the port is closed, don't try to send a character.
      if (!serialPort1.IsOpen) return;

      // If the port is Open, declare a char[] array with one element.
      char[] buff = new char[1];

      // Load element 0 with the key character.
      buff[0] = e.KeyChar;

      // Send the one character buffer.
      serialPort1.Write(buff, 0, 1);

      // Set the KeyPress event as handled so the character won't
      // display locally. If you want it to display, omit the next line.
      e.Handled = true;
  }

Luc Pattyn2-Nov-11 3:25

2-Nov-11 3:25

In .NET strings and char contain 16-bit Unicode characters. So your serialPort1.Write(buff, 0, 1) is writing one character, i.e. two bytes; for ASCII characters that effectively means there is a NULL character preceeding every character you really want.

And yes, the MSDN documentation states that ASCII encoding is the default for SerialPort, but something isn't quite right about that. Either set the Encoding property explicitly, or (what I normally do) construct a byte array yourself and send that using the other Write overload.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

turbosupramk32-Nov-11 3:55

2-Nov-11 3:55

Hi Luc!

Thanks for the reply. I set the encoding explicitly and it is not working yet. Can you expand on what you mean by saying that each character that is written is 2 bytes? This is confusing since it should only take 1 byte for each character.

As for the construction of a byte array, should that be something like (even though the compiler doesn't like the equals sign in this case below)

byte[] bytArr = new byte[] { p, i, n, 2, =, 2 };

And then say serialPort1.WriteLine(bytArr)?

or

foreach (byte byt in bytArr)
{
    serialPort1.WriteLine(byt)
}

Is that what you are meaning?

Luc Pattyn2-Nov-11 4:22

2-Nov-11 4:22

There are many mistakes in your message now, you really should brush up on C# IMO.

The other overload of Write() obviously is called Write() too, it differs by its parameter list (it takes a byte array instead of a char array).

There are basically two ways of operating a serial port:
- either you claim it all is text and let the system handle the details;
- or you take charge of each and every byte, i.e. you let the system treat it as bytes-not-to-be-touched.

WriteLine() is a text-oriented method, it deals with characters (which are 16-bit normally) AND appends a NewLine (which on Windows by default contains CR LF). That is NOT what you want.

I've had some trouble with SerialPort and ASCII (or any other single-byte) text. In my experience the default Encoding is Unicode, and NOT ASCII, no matter what the doc says; Unicode would send the low and high bytes of the 16-bit character value. Sometimes setting once Encoding=Encoding.ASCII explicitly before sending/receiving anything seems to suffice, however I generally prefer to take full control, hence use byte arrays.

In byte[] bytArr = new byte[] { p, i, n, 2, =, 2 }; the assignment is OK, it is the initialization that is faulty; you can't type letters like that, they need single quotes; and then the compiler would tell you a character doesn't fit in a byte.

One way would be:

byte[] bytes=new byte[6];
bytes[0]=(byte)'p';
...

Luc Pattyn [My Articles] Nil Volentibus Arduum

turbosupramk32-Nov-11 5:48

2-Nov-11 5:48

Hi Luc,

You'll have to forgive my ignorance, serial data and byte arrays are something I have not ever done until now.

The byte array with the overload is not working, so it looks like I will just have to figure it out through attrition. For some reason the simpleserial object works, but I can't mimic that in my own test program, the only difference that I can see is that the keypress event is occurring and capturing each character and sending it that way. I don't know how this event changes things, but it appears that it does. When I port this over to the simpleserial object for testing, and use the byte array or char array, the simpleserial object breaks, when it put it back to the code below with writing a single char from a char array, it works fine.

private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
        {
            if (!serialPort1.IsOpen) return;
            char[] buff = new char[1];

            buff[0] = e.KeyChar;

            serialPort1.Write(buff, 0, 1);
        }

Luc Pattyn2-Nov-11 6:52

2-Nov-11 6:52

You're still sending text, and so you are probably back now at sending two bytes, the one you intend and a NULL, as e.g. 'A' in ASCII is 0x41 but in Unicode it is 0x0041.

try this:

byte[] buff=new byte[1];
buff[0]=(byte)e.KeyChar;
serialPort1.Write(buff, 0, 1);

Once that works, fill an entire byte array as I told you before. That should work too, except there is a tiny chance your target isn't coping with a byte array at top speed, I noticed you are using a high baud rate, no parity, and a single stop bit, which is about the fastest you can hope for, however it might flood the target; remember for serial port, the source must use at least as many stop bits as the target is expecting, more is fine, less is not.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

turbosupramk32-Nov-11 9:00

2-Nov-11 9:00

Yes your example did work correctly. I understand what you are saying with the preceding null character and sending a word instead of a byte.

The uC is set to 115200, 8N1 and it has been ok at this speed using prebuilt terminals.

I have been trying to fill a byte array as instructed, but it is not working as the previous example. I believe text is still being sent, but I am not sure as to why at this point.

byte[] buff = new byte[1];
buff[0] = (byte)'a';
serialPort1.Write(buff, 0, 1);

No luck with this either

byte[] buff = new byte[3];
buff[0] = (byte)'a';
buff[1] = (byte)'b';
buff[2] = (byte)'c';
serialPort1.Write(buff, 0, buff.Length);

Luc Pattyn2-Nov-11 9:11

2-Nov-11 9:11

Those two snippets look OK, they send bytes, not text. There may be text in the bytes, but technically it is binary data as far as the PC can tell. Two suggestions:

1.
doesn't the target expect some "end-of-command" indication, maybe a CR or a LF or both? If so, add it to the byte array in the exact same way you do other ASCII characters.

2.
Timing issues:
2a. you did not understand well I'm afraid; if the target accepts 8N1, the source is allowed to use 8N2 which slows down the communication by 10% but may be enough for the target to keep up.
2b. if you open the port, adjust it settings, and send something all in a row, without any delays, most targets I have encountered will just not hear the message, they are still getting ready to listen (opening the port is likely to set one of the control lines, which in turn interrupts the target, signalling something might be going to happen, etc). Hence, open the port in advance, wait 10 msec (NOT inside a button_click handler!), then communicate.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

turbosupramk32-Nov-11 9:54

2-Nov-11 9:54

Luc,

You're the man. Thanks for sticking with me, I really appreciate it ... the CR was what was missing at the end of the byte array.

When I send that, I'm able to send data and have it recognize it. Thanks again for the lesson! I guess the keypress event sends that behind the scenes? I did not know that the chip looked for that before now.

byte[] buff = new byte[7];
buff[0] = (byte)'p';
buff[1] = (byte)'i';
buff[2] = (byte)'n';
buff[3] = (byte)'2';
buff[4] = (byte)'=';
buff[5] = (byte)'3';
buff[6] = (byte)13;
serialPort1.Write(buff, 0, buff.Length);

Luc Pattyn2-Nov-11 10:10

2-Nov-11 10:10

You're welcome. I'm glad you got it working.

turbosupramk3 wrote:
I guess the keypress event sends

Not at all. Something else must have been going on.

turbosupramk3 wrote:
I did not know that the chip looked for that

That should have been obvious: after receiving some digits, how would it know the number is complete? either there is a strict syntax (that many digits), or a time-out (not a nice idea), or there must be a terminator. Everything being ASCII, a CR terminator would be the obvious choice IMO.

turbosupramk3 wrote:
I really appreciate it

Then start upvoting whatever message(s) actually helped you.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

turbosupramk32-Nov-11 11:03

2-Nov-11 11:03

You were also right about having timing issues.

I have LED's that can turn on and off 10 times a second (resolution) inside of a program, and a clock speed on the uC of 80mhz, so I did not anticipate having any timing issues with this. It is sometimes skipping over commands to turn the LED's on and off. The uC can flash the LED's a 1000+ times a second, so the bottle neck has to be in the serial portion of it.

To expand on your 2., the uC only functions at 8N1. I have added the 10MS wait per your advice, do I need to have that in between serial command sends as well?

[EDIT]

It appears to be the code on the uC is what is slowing it down, this code below is not even processing correctly. I have terminal data coming back also, maybe that is effecting it?

serialPortWrite("pin16=1");
  Thread.Sleep(100);
  serialPortWrite("pin16=0");
  serialPortWrite("pin17=1");
  Thread.Sleep(100);
  serialPortWrite("pin17=0");
  serialPortWrite("pin18=1");
  Thread.Sleep(100);
  serialPortWrite("pin18=0");
  serialPortWrite("pin19=1");
  Thread.Sleep(100);
  serialPortWrite("pin19=0");
  serialPortWrite("pin20=1");
  Thread.Sleep(100);
  serialPortWrite("pin20=0");
  serialPortWrite("pin21=1");
  Thread.Sleep(100);
  serialPortWrite("pin21=0");
  serialPortWrite("pin22=1");
  Thread.Sleep(100);
  serialPortWrite("pin22=0");
  serialPortWrite("pin23=1");

  Thread.Sleep(100);
  serialPortWrite("pin23=0");
  serialPortWrite("pin22=1");
  Thread.Sleep(100);
  serialPortWrite("pin22=0");
  serialPortWrite("pin21=1");
  Thread.Sleep(100);
  serialPortWrite("pin21=0");
  serialPortWrite("pin20=1");
  Thread.Sleep(100);
  serialPortWrite("pin20=0");
  serialPortWrite("pin19=1");
  Thread.Sleep(100);
  serialPortWrite("pin19=0");
  serialPortWrite("pin18=1");
  Thread.Sleep(100);
  serialPortWrite("pin18=0");
  serialPortWrite("pin17=1");
  Thread.Sleep(100);
  serialPortWrite("pin17=0");
  serialPortWrite("pin16=1");


  Thread.Sleep(100);
  serialPortWrite("pin16=0");
  serialPortWrite("pin17=1");
  Thread.Sleep(100);
  serialPortWrite("pin17=0");
  serialPortWrite("pin18=1");
  Thread.Sleep(100);
  serialPortWrite("pin18=0");
  serialPortWrite("pin19=1");
  Thread.Sleep(100);
  serialPortWrite("pin19=0");
  serialPortWrite("pin20=1");
  Thread.Sleep(100);
  serialPortWrite("pin20=0");
  serialPortWrite("pin21=1");
  Thread.Sleep(100);
  serialPortWrite("pin21=0");
  serialPortWrite("pin22=1");
  Thread.Sleep(100);
  serialPortWrite("pin22=0");
  serialPortWrite("pin23=1");

  Thread.Sleep(100);
  serialPortWrite("pin23=0");
  serialPortWrite("pin22=1");
  Thread.Sleep(100);
  serialPortWrite("pin22=0");
  serialPortWrite("pin21=1");
  Thread.Sleep(100);
  serialPortWrite("pin21=0");
  serialPortWrite("pin20=1");
  Thread.Sleep(100);
  serialPortWrite("pin20=0");
  serialPortWrite("pin19=1");
  Thread.Sleep(100);
  serialPortWrite("pin19=0");
  serialPortWrite("pin18=1");
  Thread.Sleep(100);
  serialPortWrite("pin18=0");
  serialPortWrite("pin17=1");
  Thread.Sleep(100);
  serialPortWrite("pin17=0");
  serialPortWrite("pin16=1");

modified 2-Nov-11 17:22pm.

Luc Pattyn2-Nov-11 11:20

2-Nov-11 11:20

turbosupramk3 wrote:
so the bottle neck has to be in the serial portion of it.

Nope. A lot of things could cause less than real-time behavior. The Windows serial port is heavily buffered, your outgoing data is copied several times, and collected, regrouped, eventually sent out; so it could cause delays. But then a number of Windows timers have their limitations (I wrote an article on the subject). And overall Windows isn't a real-time operating system, it is intended to either serve a single human being typing and clicking away, or (as a server) a number of non-time-critical requests from a lot of loosely connected clients. In either case, reaction times in the order of 10 to 100 msec are considered "good enough".

If you want a LED to flash, have your microcontroller do that, and have your PC just send one command to start it.

turbosupramk3 wrote:
the uC only functions at 8N1

That means it uses 8 data bits, no parity, and will SEND using a single stop bit. It will receive and understand anything that has 1 or more stop bits.

turbosupramk3 wrote:
I have added the 10MS wait per your advice

That was suggested between opening the port and sending the first message; I trust you keep the port open, so there normally would be no need once the port has been open for such period. Unless the target is "serially deaf" while executing your previous command, then your PC would require a fixed period in between serial commands. Either the target's doc, or some experiments, should point that out. Obviously, opening and closing the port all the time could be detrimental to the comm performance.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

turbosupramk32-Nov-11 11:37

2-Nov-11 11:37

Ok, I stripped out the feedback data that I use to troubleshoot, and I put the 10mS wait when I first open the port and it is working with a resolution of 100ms, which I think will server my purposes.

Thank you very much Luc!

Rob Philpott2-Nov-11 7:34

Rob Philpott

2-Nov-11 7:34

Nice.

Regards,
Rob Philpott.

PIEBALDconsult2-Nov-11 9:00

PIEBALDconsult

2-Nov-11 9:00

Perhaps to add to what Luc is saying... perhaps you want to use System.Text.Encoding.ASCII.GetBytes ( string ) ?

turbosupramk32-Nov-11 9:10