Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Serial datarecieved event


  • Please log in to reply
27 replies to this topic

#1 skywalker

skywalker

    New Member

  • Members
  • Pip
  • 4 posts

Posted 15 December 2010 - 07:17 PM

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); } } }

#2 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 17 December 2010 - 02:41 AM

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);
}
}
}

I am having the same problem with your code, but it triggers once for me. After the first trigger it wont do it again.

#3 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 17 December 2010 - 02:49 AM

I fixed my issue doing this:

 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 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 17 December 2010 - 02:50 AM

could you tell us what you are using to talk to the mini? I use the sparkfun 3.3V FTDI to usb. make sure you don't have the TX and RX switched around.

#5 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 December 2010 - 03:01 AM

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

#6 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 17 December 2010 - 02:43 PM

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

Hi 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 Fred

Fred

    Advanced Member

  • Members
  • PipPipPip
  • 302 posts
  • LocationUK

Posted 17 December 2010 - 03:31 PM

I'm successfully using DataReceived to receive and parse a continuous stream of GPS data. I'm using a standard netduino but will try to test it on a mini when I can.

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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 January 2011 - 12:51 AM

skywalker, Okay, we figured this out. The .NET MF implementation of the SerialPort.DataReceived event behaves differently than the standard implementation. .NET: DataReceived is fired when data is received. It is fired again every time additional data has been received. .NET MF: DataReceived is fired when first data is received. Additionally, it is fired again every time the user reads data via SerialPort.Read(...) but does not read all of it. But if the user does not read data in the DataReceived(...) event, they may never be notified of additional incoming data. We have modified the Netduino's .NET MF implementation to match the desktop's implementation in v4.1.1 alpha 5, which we'll be posting in the next week or two. We'll also propose and donate the change to Microsoft for .NET MF 4.2. [BTW, it is generally good practice to read data or empty out the read buffer in the DataReceived event. Otherwise, you may just fill up the receive buffer.] Chris

#9 Tecchie

Tecchie

    Member

  • Members
  • PipPip
  • 23 posts
  • LocationGermany

Posted 03 January 2011 - 10:29 AM

I have a related strange problem:

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 Tecchie

Tecchie

    Member

  • Members
  • PipPip
  • 23 posts
  • LocationGermany

Posted 03 January 2011 - 10:59 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.

Tecchie

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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 Tecchie

Tecchie

    Member

  • Members
  • PipPip
  • 23 posts
  • LocationGermany

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 Mats Karlsson

Mats Karlsson

    New Member

  • Members
  • Pip
  • 6 posts

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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 07 January 2011 - 08:38 PM

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

#16 phantomtypist

phantomtypist

    Advanced Member

  • Members
  • PipPipPip
  • 142 posts
  • LocationNew York, NY

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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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 phantomtypist

phantomtypist

    Advanced Member

  • Members
  • PipPipPip
  • 142 posts
  • LocationNew York, NY

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 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

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 phantomtypist

phantomtypist

    Advanced Member

  • Members
  • PipPipPip
  • 142 posts
  • LocationNew York, NY

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

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.