SerialPort and SerialDataReceivedEventHandler
Seb
I am a beginner in C# programming and I would like, for my first
application, to make a communication between a microcontroller (MCU)
and my computer. I'm more specialized in electronic devices than in
computer programming.
I have checked the communication between the MCU and the hyperterminal
and it works. The sending with a C# program works too but the C#
program doesn't received any byte from the MCU.
I created two functions, one for the reception of the bytes and
another for the errors of communication but the program doesn't go
there. The MCU send 2 times per seconde, continuously, the caracter
0x30.
I have seen that the variable port.BytesToRead stays at 0 all the
time, without knowing why. The value of this variable has to change
when a byte is received, no ?
The communication between the MCU and the computer is done by an USB/
serial converter.
The code I tried is :
using System;
using System.IO.Ports;
using System.Text;
namespace SerialPortExample
{
class SerialPortProgram
{
// Create the serial port with basic settings
private SerialPort port = new SerialPort("COM4", 9600,
Parity.None, 8, StopBits.One);
[STAThread]
static void Main(string[] args)
{
new SerialPortProgram();
}
private SerialPortProgram()
{
port.ReceivedBytesThreshold = 1;
port.Handshake = Handshake.None;
port.DtrEnable = false;
port.RtsEnable = false;
// Instatiate this class
Console.WriteLine ("Incoming Data:");
// Begin communications
port.Open();
port.DataReceived += new SerialDataReceivedEventHandler
(port_DataReceived);
port.ErrorReceived += new SerialErrorReceivedEventHandler
(port_ErrorReceived);
Console.WriteLine(port.ReadBufferSize);
System.Console.ReadKey();
port.Close();
}
private void port_DataReceived (object sender,
System.IO.Ports.SerialDataReceivedEventArgs e)
{
// Show all the incoming data in the port's buffer
Console.WriteLine("Character received");
Console.WriteLine(port.ReadExisting());
}
private void port_ErrorReceived(object sender,
SerialErrorReceivedEventArgs e)
{
Console.WriteLine("Error");
}
}
}
I hope anyone can give me some help to solve my problem.
Sebastien.
Cmplx80
Isn't the port closing inside the constructor with the "port.Close()"
statement? Shouldn't this be in a separate function?
Frank
Cmplx80
OOPS! Sorry, I just noticed the blocking ReadKey() preceding the
port.Close().
Frank
Ben Voigt [C++ MVP]
>> statement? Shouldn't this be in a separate function?
>>
>> Frank
>>
>
> OOPS! Sorry, I just noticed the blocking ReadKey() preceding the
> port.Close().
>
> Frank
That's still potentially a problem, since the message dispatch loop is
blocked waiting for ReadKey, one can't expect events to run.
Peter Duniho
It's a console application. There's no message dispatch loop.
Now, whether the lack of a message dispatch loop is in fact a problem for
the SerialPort class, I don't know. I suspect not, but don't have enough
experience with the class to know for sure. But in the given code
example, there's not a message dispatch loop to get blocked.
Pete
Seb
wrote:
Thanks for your comment,
I had already try different configuration. Replace the
System.Console.ReadKey(); by
for (; ; )
{
if (port.BytesToRead > 0)
{
Console.WriteLine(port.BytesToRead);
port.Write("1");
}
}
I tried also to change the size of the ReadBufferSize, the value of
the ReceivedBytesThreshold, but the results were the same.
I will try to test the same program with a true serial port RS232 to
see if I will have the same results.
Rick Lones
Seb,
I tried your program (almost) exactly as written using 2 serial ports on the
same machine connected together with a null modem serial cable. I ran
Hyperterminal at COM1 to supply bytes manually via keyboard and changed your app
to use COM2 instead of COM4 on the receive side. It worked without any changes
to the logic, so something else must be going on.
I have had problems in the past with USB/Serial converters back when USB was
newer, but if Hyperterminal sees your input as a normal serial port stream, then
it would seem that the conversion must be working okay. Are you sure that your
program's port settings are the same as you used for the Hyperterminal session
that successfully saw the spew from your device?
hth,
-rick-
Seb
Hello Rick,
For me, the parameters are the same as you can see it on the
screenshot here (my XP is in French) : http://www.imagup.com/pics/1248668135.html
Could you confirm please ?
Seb
Aucun = None :)
Rick Lones
I was sending using Hyperterminal on COM1 and receiving via your program on
COM2. Other than the port, your Hyperterminal settings are the same as mine. I
had also tried "hardware" as the COM1 flow control option and that also worked.
-rick-
Seb
Is it possible that the SerialPort class is waiting for one (or more)
condition which occurs with a true serial port and not with a virtual
port COM ? Is it possible that the HyperTerminal which is an "old"
software also doesn't need to meet this (these) condition too ?
I made some tests of the communication with a software used in my
company, developped in VB 6.0 few years ago, and the communication
works fine, it's why I'm thinking about differences between the
SerialPort class and the communication methods of older programs.
http://www.imagup.com/pics/1248669471.html
Rick Lones
I have used the SerialPort class under Framework 2.0 to talk to over a "true"
serial port. I tend to think your problem must be on the USB-to-serial
conversion end of things somehow. Could there be USB 1.0/2.0 compatibility
issues with your hardware, perhaps?
> I made some tests of the communication with a software used in my
> company, developped in VB 6.0 few years ago, and the communication
> works fine, it's why I'm thinking about differences between the
> SerialPort class and the communication methods of older programs.
> http://www.imagup.com/pics/1248669471.html
Do you mean that you successfully talked through your USB/Serial converter to
your MCU using the VB6 software? In that case, maybe you have uncovered a
SerialPort issue.
Seb
Hello Rick,
I have searched during a part of the night and I have found what's
going wrong.
Even if there is no physical DTR and RTS, you have to enable them to
communicate. The driver of the converter maybe handles these two
lines.
I tried in the beginning to change their values and nothing changed
but maybe because there were other problems in my code.
Thank you for your help and to have tested my code in real conditions.
Rick Lones
That makes total sense. Those signals are part of the RS-232 interface and the
converter would have to support them. Whether you need them in a given
situation would seem to depend on how the external hardware is wired and/or
configured.
This sounds as if your code as posted might be made to work and that you could
maybe attack the problem from the other side, meaning the UART register
initialization on your MCU. (I am guessing it looks like normal serial comm on
that side rather than some raw USB interface.) That might be advantageous going
forward if it keeps you compatible with your legacy software.
Anyhow, I'm glad you have an answer.
Regards,
-rick-
Seb
I agree with you that it makes total sense. I had tried these
parameters in the beginning but nothing had changed because there were
other errors in my program.
The MCU part is already done with about 70% of the application. I will
only replace printf functions, used for the HyperTerminal, by direct
writing to the register of the UART. But first, I need to improve my
knowledge of the C#.
You are correct, it's a normal serial communication.