OpenNETCF.IO.Serial doesn't fire received event!!!!!

  • Thread starter Thread starter Matteo Cima
  • Start date Start date
M

Matteo Cima

hi,
i am really smashing my head on the screen...
i am using the latest opennetcf serial.dll
trying to deal with the example "serialcsharp"...
well, the event Port.CommEvent is not fired correctly,
if i use hyperterminal, echo > com1, and everything else, no matter what the
settings are,
i CAN'T display ALL the sent data to the device... it fires the event almost
randomly...

let's say, from xp command prompt
echo abcde > com1

device shows "ab"

then,
echo fghi > com1

device shows "abcde"

i tried everything, i changed all the code on the received event in any
manner... but can't make it work!

please help me,
with any idea
Matteo Cima.
 
I got the Serial sample to work by hooking up two PPC together. My problem
arrived when I tried to create a Widows full framework version to talk to a
PPC version. It appears that the test for fullframework fails in the full
environment. So I reversed the logic, rebuilt and that helped a little. I
know uses the kernel32.dll instead of the coredd.dll while in fullframework
mode. However, the program immediately crashes because it cannot find
EventModify in the kernel32.dll.

Any help would be greatly appreciated.

Chris Pair
 
One other thing: I had to place a sleep(100); directly after sending data
through the port. Without this the receiving application would only receive
2 characters no matter what.
 
yes, it fails.
it doesn't receive the event if there's data in the buffer after the 2nd
char printed... seems like the event can only be fired something like twice
in a given amount of time...
in serialcsharp example i tried also to change the code of the event to be
sure:

private void port_DataReceived()
{
// since RThreshold = 1, we get an event for every character
byte inputData;
int t;

try
{
t=0;
while (true)
{
inputData = port.Input[t];
txtRx.Text += Convert.ToChar(inputData);
t++;
}
}
catch {}
finally
{
txtRx.Refresh();
}
}

and sending the text "abcdefg" just prints "a", the 2nd time it displays
"ab"...
Seems that there's an issue between an "internal buffer" and the
port.input[], and the port.input isn't filled with all the buffer's data...
Any solution/workaround?

As usual, any help highly appreciated.
Regards,
Matteo Cima.
 
Chris,

Thank you very much for looking at this. It is very important for us to have
the same code on the desktop vs. the CF. We have a program that controls
devices and plan to run that program of CE .net as well a tablet PC.

Notice that I also had to force a sleep(100) after each send in the sample
code when talking between two PPC (206mhz). Is this normal?

Chris Pair
 
Remember that, if you are not using flow control (handshaking), then it's
quite possible that, on a fast machine, you'll be dumping stuff out the
serial port faster than the other end of the connection is able to receive
it...

Paul T.
 
Chris,

I agree with Paul. I frequently have to insert Sleeps when I'm sending
output to printers, from both the desktop and CE devices.
 
I still think something is wrong with the library. I cannot receive binary
data from the port consistently. I should receive about 80 bytes but the
data_received is only called 2 times. I have tried to play around with
sleeps but to no avail. The weird thing is that if I send data to the port
multiple times then the data_received is eventually called enough times to
get all the data out of the input buffer.

I really want to use this library because of its characteristic of desktop
and cf. Any help would be greatly appreciated.

Chris
 
the same happens to me!
i tried any configuration, with same results.
And activesync works on the same connection, (it is disconnected when i try
to use the com by my own) so it's not a problem in the cable...

I hope to Tacke this :-)

Regards,
Matteo Cima
 
Let's just make sure that it's not a disconnect in how the library is
supposed to work and how you're using it. Whenever you receive a
data_received event, you are reading *all* of the data that the port has,
right? In C, when your code returns from something like WaitCommEvent(),
you keep calling ReadFile() until you get back no data. Then, you go back
to WaitCommEvent() again. Does your code do something similar to this?
Maybe you should post a very small program which does nothing but serial I/O
and shows the problem. That would give us a testbed to try various things
against, maybe giving Chris some help with more information about the
failure mode.

Paul T.
 
I've rolled some quick fixes into the Serial library and released v1.1.

This version has *only* some bug fixes, all of which pertain to using the
library on the desktop. The fixes do not, however, address all of the
issues that exist. I simply wanted to provide something to further anyone's
effort to get the library working fully.

We don't currently have the bandwidth to investigate and fix either the
desktop or reported device issues. If anyone has a solid understanding of
C# and serial communications and would like to volunteer some time, we would
appreciate it.
 
Back
Top