On Apr 4, 12:01*pm, jodleren <sonn...@hot.ee> wrote:
> Hi
>
> My code is below. My problem is that I am trying to receive data from
> some hardware, and it works when I am debugging it. But when I run it
> in released mode, I get junk data - my strings get mixed up.
> And now when writing this, I just checked something - and found, that
> a break point in runtime, and I see that my received data is ok, but
> my readout (the 2 subsrings) causes the problems. Like they cannot
> handle the amount of data. Any ideas?
>
> My problem:
> * * * * * * * * line = ReceivedLine.Substring(0, i).Trim();
> * * * * * * * * string tmp = ReceivedLine.Substring(i +1);
> * * * * * * * * ReceivedLine = tmp;
>
> Entire code:
>
> * * * * * * Conn.NewLine = '\r'.ToString(); //set packet terminator
> * * * * * * Conn.DataBits = 8;
> * * * * * * Conn.BaudRate = 115200;
> * * * * * * Conn.Parity = System.IO.Ports.Parity.None;
> * * * * * * Conn.StopBits = System.IO.Ports.StopBits.One;
> * * * * * * Conn.DataBits = 8;
> * * * * * * Conn.DtrEnable = true;
> * * * * * * Conn.RtsEnable = true;
> * * * * * * Conn.ReadTimeout = Conn.WriteTimeout = 500;//ms
> * * * * * * Conn.DataReceived += Conn_DataReceived;
>
> * * * * // handle data received
> * * * * string ReceivedLine;
> * * * * private void Conn_DataReceived(object sender,
> System.IO.Ports.SerialDataReceivedEventArgs e)
> * * * * {
> * * * * * * string line;
>
> * * * * * * ReceivedLine = Conn.ReadExisting();// reader.ReadLine();
>
> * * * * * * while((i = ReceivedLine.IndexOf('\r')) != -1)
> * * * * * * {
> * * * * * * * * line = ReceivedLine.Substring(0, i).Trim();
> * * * * * * * * string tmp = ReceivedLine.Substring(i +1);
> * * * * * * * * ReceivedLine = tmp;
>
> * * * * * * * * __Log2(line);
> * * * * * * * * if (line != "")
> * * * * * * * * {
> * * * * * * * * * * if (line.Substring(0, 1) == "!")
> * * * * * * * * * * * * __Log2("dataline");
> * * * * * * * * }
> * * * * * * }
This is a shot in the dark. The fact that the debug and release
versions do different things suggests a possible timing problem.
I.e., a breakpoint might give an operation time to complete that
wouldn't normally have time to complete. Microsoft sometimes tries to
improve the performance of certain operations by letting them run
asynchronously and naively assume that they will be done before you
try to access the returned value. I know that it doesn't seem logical
for the code not to wait until the entire value is returned, but that
is exactly what happens with some DAO operations in Access databases.
Perhaps getting data from a COM port is enough like getting data from
a database for the same philosophy to be in play. To test out that
hypothesis, put in a delay after the line:
ReceivedLine = Conn.ReadExisting();// reader.ReadLine();
to ensure that the entire value has been read before trying to create
your substrings. If an adequate delay doesn't fix the substrings,
then the problem lies elsewhere. If you determine that your code is
actually timing sensitive, then you can't even be sure that the
correct value you get during debugging means that the code for that
result is correct! Curiosity might have killed the cat, but
Schrödinger might have brought it back :-). You just need to use some
logic to come up with tests that rule out potential timing issues.
James A. Fortune
(E-Mail Removed)
Similar Threads
