serial and networking problem

Hi, I have a problem when a try to use network and serial communication (RS232) in netduino plus. One thread has network, the other the rs232 stuff. The network just stops, it does not throw any exception, it just does not process information. If I take out the rs232 stuff from the other thread, then it works fine. Is it any kind of dead lock? Has anyone experienced somethink like this with netduino plus?

 

Thanks in advance.

Hi mbinelo, How are your threads set up? Are you responding to the SerialPort.DataReceived event? When you say that the network thread just stops...what line of code does it stop on? Chris

Hi Chris Walker

Yes, I'm responding to the SerialPort.DataReceived event. I can't say in what line of code it stops, it just does not run. The same problem hapens with i2c too. The trheads setup is the same used in the examples provided in the forum, nothing special. For now I "solved" the problem by putting all communications in the same thread, and its working fine. Unfortunatly I cannot came back to test it again with communications in different threads bacause I'm running out of time to finish my project.

If nobudy else has had this problem, it was probably some mistake I made. Anyway, if someone has used rs232 and TCP in different threads, just write in the thread "it works for me".

 

thanks.

I have a similar problem right now even as I write:  DataReceived stops firing after a while.  I can see data is coming in because I have the serial line tapped so I can monitor via putty.  I already did major surgery to that module today since my debug logging (to file on SD) caused stoppage of delivery of events, then my taking too long in the event handler cause stoppage, and then I had regex woes.

 

Incidentally, if I litter the code with:

Debug.GC(true);

then it keeps working.  Hmmm!  By 'litter' I mean that in my case I'm operating a GPRS modem, and there is a long fixed sequence of AT commands I must send to get the modem configured, on the network, tcp started, and connected to the server, and I can stick the GC directive easily in-between them.

 

Not exactly stable but it might get me through today; then I will have to do another surgery to change the design to not use the DataReceived event.  The code was super-stable on desktop -- I ran it with the gsm module (connected to the PC with one of those USB serial boards) connected and communicating for a couple days with zero communication probs, but you know the netmf is (quite) a different beast....

 

Lastly, in my project the communications is swappable, so I can also run the rest of the project code using the ethernet transport.  I mention this becuase in that case, it runs with zero incidents for days on end. Sockets doesn't depend on events, however.

 

So my guess at this point is seems like there is some fundamental reliabillty problem with event delivery in complex applications, or maybe those under memory pressure, or a bunch of threads.  But I don't know what it is, alas....

 

Edit:  the GC forcing was not a reliable workaround (thankfully in my view).  What worked better for me was to turn off logging to a file.  This logger tees data to Debug.Print, and also a file.  When I stop logging to a file, then the serial port becomes (more) stable.  The file logger uses a FileStream and does a seek, write, flush within a lock section.  Seems benign, but maybe there's some interrupt stuff going on causing the hosage.  Or maybe it's something altogether different!