Previously I posted a bug on the topic of the Gadgeteer.Interfaces.Serial. The issue was specific to the LineReceived event not firing when the program was compiled/download as “release” code rather than “debug” code.
In debug mode, it works fine. In release mode something either hangs or the LineReceived event doesnt fire. It’s driving me nuts and this particular issue will determine success or failure on the project. I am reading a GPS unit that was configured to send only 3 sentences at 57kbps.
When i use a timer and poll the serial port buffer fast enough, it works both in debug and in release mode. Unfortunately this strategy wont work for me.
In the event that this will not or cannot be addressed in the near term, do this feature work on any of the GHI products? Does anyone know if it works on Netduino?
Any input would be greatly appreciated.
Imports GT = Gadgeteer
Imports GTM = Gadgeteer.Modules
Imports Gadgeteer.Interfaces.Serial
Imports Gadgeteer.Modules.GHIElectronics
Partial Public Class Program
Dim gps As GT.Interfaces.Serial
Public Sub ProgramStarted()
Try
Dim objSocket As Gadgeteer.Socket
objSocket = Gadgeteer.Socket.GetSocket(1, True, extender, "")
gps = New Gadgeteer.Interfaces.Serial(objSocket, 57600, SerialParity.None, SerialStopBits.One, 8, HardwareFlowControl.NotRequired, extender)
gps.LineReceivedEventDelimiter = Microsoft.VisualBasic.Constants.vbCrLf
gps.AutoReadLineEnabled = True
AddHandler gps.LineReceived, AddressOf GPS_handler 'moved here based on forum feedback
gps.Open()
'AddHandler gps.LineReceived, AddressOf GPS_handler 'tried it here too, same result
Catch ex As Exception
Debug.Print("Err in ProgramStarted: " & ex.Message)
End Try
End Sub
Private Sub GPS_handler(ByVal sender As Gadgeteer.Interfaces.Serial, ByVal line As String)
Try
Debug.Print(line)
Catch ex As Exception
Debug.Print("Err in Handler: " & ex.Message)
End Try
End Sub
End Class
This is odd. [Unfortunately,] I’ve yet to encounter a situation where changing from Debug to Release made any difference in the NETMF world. Have you tried monitoring your app with MFDeploy to see if you can see any additional information? I’m also wondering if MS finally fixed Debug.Print in 4.2 so that it doesn’t actually compile while in release mode to be consistent with the full .NET Framework. I haven’t tested that yet. You might try blinking the onboard LED in GPS_Handler instead of a Debug.Print and see if you get different results.
Since the LineReceived function is a Gadgeteer specific function, I would expect it to work the same on all Gadgeteer platforms.
Why do you focus on LineRecieved and why don’t you consider the strandard DataReceived event? Why do you say that the polling strategy won’t work - I guess for us to help you most you might need to explain a little more.
What 3 sentences are you getting from the GPS; ie what sentence size (character counts) are you expecting to get each time, and how often are these sentences being sent - every second? 10 times a sec? All that will greatly change the potential bottlenecks in an app and how successful you’ll be; remembering that the NetMF isn’t real-time.
I wanted to use the LineRecieved event in order to simplify the code and to eliminate polling the serial buffer when I don’t need to. Once per second and the sentences vary in length depending on the quality of the reception (no reception, less data). Typically, the 3 sentences together are in the range of 500 bytes - which means only two reads if timing works out. Polling does work, but the solution is less elegant and required addition loops to ensure proper data capture.
I also know its not a realtime system, but it’s good enough. I am building a controller system for a quadcopter. In order to ensure that timing works out, the sensor fusion calculations and PWM in (from the radio when in directed flight) are being handled by a different processor. The Cerbuino will handle stability, control and autonomous flight.
Although I love the Cerbuino, and I fully understand that this is not a RTM product, but it’s frustrating to stumble into some things work and some things don’t.
I will try your suggestion to remove the debug.print code. I’m a noob and have not fully learned to use MFDeploy yet. I will explore that too. I will also experiment with DataReceived to see if that works better.
For the GHI team, this is very easy to reproduce, maybe when time permits, someone could provide feedback as to the cause.
Go back to the good old Serial port in NetMF not Gadgeteer and don’t use LineRecieved but just use DataRecieved. Handle the CR or LF yourself and bubble that up in an event.
It seems to me it’s unlikely to be the serial port handler on Cerberus family since you say polling works; so it’s unlikely to be something that GHI are any more able to diagnose for you.
The code for Gadgeteer is open so you could look yourself at what seems to be the problem; http://gadgeteer.codeplex.com/SourceControl/changeset/view/21495#200062 seems to be the link to the Gadgeteer serial port module. When I compare it to the previous versions, I see the readline thread (yes, it just runs its own thread!) has undergone some changes from the current changeset to the 16545 changeset. I wonder what build version we have…
Since VB support is new, have you thought about taking a step back with a simple app and trying this in a C# program and seeing if the same issue still applies?
I very much appreciate the advice…I think I will try the DataReceived event and concatenate the data (I prefer this approach to a polling with a timer) and see if it deploys. If it doesnt work, then the problem would probably lie in the serial event handler and I have to go back to the timer. If it does work, then the problem would probably lie in the LineReceived code. Either way it will be solved.
I think it might be related to threading; I noticed this problem when I was trying to catch the event from a thread the Program thread created. I still have no idea why debug vs release would change the behavior, but I was able to copy and paste the Gadgeer LineReceived function into my code and it worked flawlessly.
I assume you’ve looked at the Gadgeer source code, but for others who haven’t, the DataReceived handler is fired from native code (which is exposed through the NETMF Serial class). You’ll notice this event fires fine. The LineReceived event is a different beast – The Gadgeteer class starts a thread that polls the serial port for new data continuously, and raises the event when it sees the line ending character.
Anyway, you can copy and paste this function into your code and it works flawlessly.
I solved my problem by sending all received data with the DataReceived event from the RS232 line to xbee direct. The parser is running on the Windows host machine then…
I’m still wondering about the bugs in .netmf.
The auto linereceived event ist working with serial usb modul, but only in dubinng mode! For this I tried to use the RS232 modul…
