Serial datarecieved event
#1
Posted 15 December 2010 - 07:17 PM
#2
Posted 17 December 2010 - 02:41 AM
I am having the same problem with your code, but it triggers once for me. After the first trigger it wont do it again.Having trouble fireing the serial datareceived event. I use com2 for programming. Then I stop debugging, Use putty
on the same port to send characters. The receive event should blink an led.
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoMini;
using System.Text;
using System.IO.Ports;
namespace blink
{
public class Program
{
public static SerialPort port2 = new SerialPort("COM2", 115200, Parity.None, 8, StopBits.One);
public static OutputPort outpt=new OutputPort(Pins.GPIO_PIN_5,false);
public static void Main()
{
port2.Open();
port2.DataReceived += new SerialDataReceivedEventHandler(ReceiveData);
Thread.Sleep(Timeout.Infinite);
}
public static void ReceiveData(object sender, SerialDataReceivedEventArgs e)
{
outpt.Write(true);
Thread.Sleep(500);
outpt.Write(false);
Thread.Sleep(500);
}
}
}
#3
Posted 17 December 2010 - 02:49 AM
public static void Main() { com = new SerialPort(SerialPorts.COM1, 9600, Parity.None, 8, StopBits.One); com.Open(); com.DataReceived += new SerialDataReceivedEventHandler(com_DataReceived); while (true) { led.Write(!led.Read()); Thread.Sleep(1000); if (send) { com.Open(); // do stuff send = false; } } } static void com_DataReceived(object sender, SerialDataReceivedEventArgs e) { send = true; com.Close(); }
#4
Posted 17 December 2010 - 02:50 AM
#5
Posted 17 December 2010 - 03:01 AM
#6
Posted 17 December 2010 - 02:43 PM
Hi Chris,Interesting. We're aware of a glitch in .NET MF relating to when the DataReceived event is wired up...but I haven't seen this before.
Just to clarify...does this work properly when you're debugging? But not when you stop debugging?
Does it work if you reset your Netduino Mini (or when you first power it up)?
Chris
For me it works when debugging and when not debugging. I am using the regular netduino and not the mini.
Sorry if you were asking skywalker, I hope that info helped though.
#7
Posted 17 December 2010 - 03:31 PM
The differences I can see between my code and that above are:
* I assign the delegate function without the "new SerialDataReceivedEventHandler" bit
* I assign the delagate before opening the port
* My wait code doesn't use Timeout.Infinite. (I just feel the code below gives less chance of locking the device and being unable to connect.)
com.DataReceived += com_DataReceived; com.Open(); while (true) Thread.Sleep(1000);
It might be worth trying some of these to see if it makes any difference.
#8
Posted 03 January 2011 - 12:51 AM
#9
Posted 03 January 2011 - 10:29 AM
Short story: the DataReceived event does not fire for the COM-Port i'm using but for the other one!?
Long story:
static byte[] tmp = new byte[128]; public static void Main() { Debug.Print("starting ..."); SerialPort serial = new SerialPort(SecretLabs.NETMF.Hardware.NetduinoMini.SerialPorts.COM1, 115200, Parity.None, 8); serial.Open(); serial.DataReceived += new SerialDataReceivedEventHandler(delegate(object sender, SerialDataReceivedEventArgs eArgs) { Debug.Print("serial rcvd"); int read = serial.Read(tmp, 0, serial.BytesToRead); Debug.Print("read bytes " + read); }); byte[] s = Encoding.UTF8.GetBytes("foo"); while (true) { serial.Write(s, 0, s.Length); Thread.Sleep(1000); } }
As you can see, i open COM1 (i.e. the serial port on Pin 11 + 12). I have a Xbee connected to that port. The 'foo' strings are perfectly transported by the XBee to the receiver. But data sent from the computer to that XBee never fires the DataReceived event. I'm sure that the data is actually transmitted, because the same setup is happily working on my Netduino Plus and i can see the correct number of bytes in the receive buffer, when i read the BytesToRead Property in the while loop.
And now the odd part: the DataReceived is fired, when there's data coming into COM2! So when i start MFDeploy, open the connection and then e.g. press ping, i get several DataReceived-Events.
So the event is somehow wired to the wrong COM-Port!
I've already tried whether flashing the current firmware resolves that problem but it's still there.
Is there anybody who can reproduce that behaviour or is that a special problem of my Netduino Mini?
Tecchie
#10
Posted 03 January 2011 - 10:59 AM
The behaviour slightly changed:
the event is now fired exactly once when data is received on the wrong COM port (i.e. when i generate date on the debug port, e.g. setting a breakpoint or pinging in MFDeploy) and then never again no matter on which COM port data is fed into the Mini.
Tecchie
#11
Posted 03 January 2011 - 11:05 AM
I've already tried whether flashing the current firmware resolves that problem but it's still there.
Is there anybody who can reproduce that behaviour or is that a special problem of my Netduino Mini?
Hi Tecchie,
Very interesting. When you say that you tried flashing the current firmware, did you try using v4.1.1 alpha 5 (the one we just posted a few hours ago)?
On the Netduino Mini, the two ports (COM1 and COM2) are reversed internally. We did this because the RS232 port is designed to be the main programming port (and from most testers' logical view, the TTL port on pins 11/12 should be COM1).
It's possible that something is wired up wrong and that we don't have a testing scenario for this in the Netduino Mini test suite.
If this is happening both with the production firmware as well as the new v4.1.1 alpha 5 firmware...please let me know. Actually, let me know either way... And I'll see what we can get fixed for the next alpha/beta release (in roughly the next two weeks). You can also download the source and muck around yourself...but we're happy to fix it here if we can put together a simple repro case.
Chris
#12
Posted 03 January 2011 - 11:08 AM
Flashed the new alpha firmware i just found in the General forum.
The behaviour slightly changed:
the event is now fired exactly once when data is received on the wrong COM port (i.e. when i generate date on the debug port, e.g. setting a breakpoint or pinging in MFDeploy) and then never again no matter on which COM port data is fed into the Mini.
Thanks for testing that (before I even finished asking)
Is the dozen or so lines of code posted above a good repro case? It sounds like we fixed most of the DataReceived-related issues, but there's at least one to go on the Mini...
BTW, am I correct in assuming that the Read(...) and Write(...) functions are working properly...and that it's just the event that's misbehaving?
Chris
#13
Posted 03 January 2011 - 01:54 PM
BTW, am I correct in assuming that the Read(...) and Write(...) functions are working properly...and that it's just the event that's misbehaving?
Yes, Write(), Read(), BytesToRead, ... is working properly. If i poll the bytes in my loop i get the strings i send to the Xbee. It's just the event that's not fireing for its intended port but for the other one.
Is the dozen or so lines of code posted above a good repro case?
Yes, they are sufficient. I added some commented lines, so that you see, that polling the bytes is working:
static byte[] tmp = new byte[64]; public static void Main() { // opening com1 (pin 11 + pin 12 on netduino mini) SerialPort serial = new SerialPort(SecretLabs.NETMF.Hardware.NetduinoMini.SerialPorts.COM1, 115200, Parity.None, 8); serial.Open(); serial.DataReceived += new SerialDataReceivedEventHandler(delegate(object sender, SerialDataReceivedEventArgs eArgs) { // event (fires for wrong com port!) Debug.Print("serial rcvd, bytes avail = " + serial.BytesToRead); int read = serial.Read(tmp, 0, serial.BytesToRead); Debug.Print("read bytes " + read); }); byte[] s = Encoding.UTF8.GetBytes("foo"); while (true) { // writing is working properly serial.Write(s, 0, s.Length); // polling the bytes is working too Debug.Print("polling bytes: " + serial.BytesToRead); if (serial.BytesToRead > 0) { byte[] bS = new byte[serial.BytesToRead]; serial.Read(bS, 0, serial.BytesToRead); char[] rcvS = Encoding.UTF8.GetChars(bS); Debug.Print("got string: " + (new string(rcvS))); } Thread.Sleep(2000); } }
Thanks for looking into it.
Tecchie
#14
Posted 07 January 2011 - 08:28 PM
It sounds like we fixed most of the DataReceived-related issues, but there's at least one to go on the Mini...
BTW, am I correct in assuming that the Read(...) and Write(...) functions are working properly...and that it's just the event that's misbehaving?
Chris
I'm having the same problem with the mini. I'm using a Parani Bluetooth module with serial interface, and no problems on the regular netduino.
The workaround for me now is to not subscribe for the datarecieved event, but to poll using a timer, and raising it manually.
Also using COM1, and it appears that the Read, Write-methods and BytesToRead-property appears to be working.
#15
Posted 07 January 2011 - 08:38 PM
#16
Posted 19 January 2011 - 04:55 AM
Thanks for the additional feedback. This should give us what we need to make sure the DataReceived event handler gets fixed for Netduino Mini in v4.1.0.6 beta 2 and v4.1.1 alpha 6. ETA: 5-10 days.
Chris
Any luck with resolving this issue?
#17
Posted 19 January 2011 - 05:00 AM
Any luck with resolving this issue?
Yes and no. It's a bit of a tricky issue. We internally swap COM1 and COM2 on the Netduino Mini...and we're working on changing the way we do that. Right now we're testing out a simple swap of the two values' assignments in the SerialPort constructor instead of at the microcontroller register level.
Chris
#18
Posted 26 January 2011 - 03:44 AM
Yes and no. It's a bit of a tricky issue. We internally swap COM1 and COM2 on the Netduino Mini...and we're working on changing the way we do that. Right now we're testing out a simple swap of the two values' assignments in the SerialPort constructor instead of at the microcontroller register level.
Chris
So until this is fixed in the firmware, I guess I can safely call "COM2" in code if I really want to be communicating with something on the serial TTL pins 11 and 12?
#19
Posted 26 January 2011 - 03:57 AM
So until this is fixed in the firmware, I guess I can safely call "COM2" in code if I really want to be communicating with something on the serial TTL pins 11 and 12?
Yes, absolutely. COM2 is pins 11/12. DataReceived has a glitch, but everything else should work.
Chris
#20
Posted 26 January 2011 - 05:36 AM
Yes, absolutely. COM2 is pins 11/12. DataReceived has a glitch, but everything else should work.
Chris
For some reason this only works once. I am debugging on RS232 and have an XBee connected to TTL. In the code I open up COM2 to read data from the XBee. If I stop debugging and then start again I can't. I cannot even connect via MFDeploy. At that point I have to reflash TinyBooter and the firmware to get the Netduino Mini working again.
Not sure if it's just me, but fyi.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users