coredll CreateFile on serial port

G

GraemeR

Hi, when I execute the following call (on an iPAQ Pocket PC) nothing happens
to the RS232 cable I'm using.

<System.Runtime.InteropServices.DllImport("coredll.dll")> _
Private Shared Function CreateFile( _
ByVal lpFileName As String, _
ByVal dwDesiredAccess As Integer, _
ByVal dwShareMode As Integer, _
ByVal lpSecurityAttributes As Integer, _
ByVal dwCreationDisposition As Integer, _
ByVal dwFlagsAndAttributes As Integer, _
ByVal hTemplateFile As Integer) As Integer
End Function

Public Sub openPort()
mhRS = CreateFile("COM1:", GENERIC_READ Or GENERIC_WRITE, 0, 0,
OPEN_EXISTING, 0, 0)
End Sub

Mappling the DllImport to "kernal32.dll" and compiling+executing as a
Windows application causes RS232 cable to light up.
Is there some massaging I need to do to get the Pocket PC serial port to
behave as the desktop port does?

Note: I can verify that the port and cable work by using the CEWedge
application http://www.taltech.com/products/cewedge.html

Thanks for advice you can offer, Graeme.
 
D

Daniel Moth

What is the value of the handle (mhRS) you get back? What does
Marshal.GetLastWin32Error return? If you get a valid handle and no error try
communicating down the cable anyway (don't just look at the lights)...

Also have you tried with any of the rs232 implementations we have in
opennetcf? The more recent addition is under IO.Ports...

Cheers
Daniel
 
C

Chris Tacke, eMVP

What exactly causes the light to illuminate? The issue here may be that the
light is attached to a control line (RTS, CTS, etc) and it's quite possible
that your device isn't a full-featured serial port. It may also be that you
need to enable some sort of hardware handshaking. I'm totally guessing here
and may well be wrong, but that could explain the difference. Can the OEM
provide info about what lines are required? If you have access to a serial
analyzer you can quickly check the difference in line states between what's
working (desktop) and what's not (PPC).

--
Chris Tacke
Co-founder
OpenNETCF.org
Has OpenNETCF helped you? Consider donating to support us!
http://www.opennetcf.org/donate
 
G

GraemeR

Hi Daniel,
Port Handle on Pocket PC: (e.g.) 258517566
GetLastWind32Error: 0
I read this as everything working OK. I need to work out how to read/accept
a value from the attached calipers next.

I tried using the OpenNetCF library but lack the skill to configure it for
the RS232.
An example would be welcomed.

Thanks, Graeme.
 
G

GraemeR

Hi Sergey, this is the code I tried to open the port using the OpenNetCF
library

Private WithEvents mprtCOM As OpenNETCF.IO.Serial.Port

mbps = New OpenNETCF.IO.Serial.DetailedPortSettings
mbps.BasicSettings.BaudRate = OpenNETCF.IO.Serial.BaudRates.CBR_4800
mbps.BasicSettings.Parity = OpenNETCF.IO.Serial.Parity.even
mbps.BasicSettings.ByteSize = 7 'DataBits?
mbps.BasicSettings.StopBits = OpenNETCF.IO.Serial.StopBits.two

mprtCOM = New OpenNETCF.IO.Serial.Port("COM1:", mbps)
mprtCOM.Open()

The BasicSettings construct doesn't have a property for DataBits. I've used
the ByteSize property but am sure that this is wrong.

I trapped every event fro mprtCOM and got nothing.
I'm trying to go back to first principals in order to understand what's
happening or what should happen.
Thanks, Graeme.
 
G

GraemeR

Hi Chris, using CEWedge application I can see that the cable lights up from
the COM1 port on the iPAQ H3870 Pocket PC running MS Pocket PC Version
3.0.11171.

What do you mean by control line (RTS, CTS, etc)...?

I don't have a serial analyser.
Thanks, Graeme.
 
C

Chris Tacke, eMVP

Alright, so if another CE app works, then you know it's not a hardware
incompatability (you really should read up on serial cooms though, knowing
what RTS, CTS, etc are is useful).

Are you using any flow control with CEWedge? My guess is that this is where
the difference lies. The device is probably waiting from a control line
state change that you're not providing (through flow control).

--
Chris Tacke
Co-founder
OpenNETCF.org
Has OpenNETCF helped you? Consider donating to support us!
http://www.opennetcf.org/donate
 
G

GraemeR

Hi Daniel,
GetLastWind32Error is 183, not 0 as stated in my last post.

Any idea what this means?

Thanks, Graeme.
 
G

GraemeR

Hi Chris,
The flow control property is set to None in the CE Wedge application.

You're right on my lack of understanding re RTS, CTS, etc. and on serial
communication in general.

Cheers, Graeme.
 
D

Daniel Moth

"Cannot create a file when that file already exists."

Do you always get that though or is it because you did not Close the
handle/port last time?

Cheers
Daniel
 
G

GraemeR

Thanks Daniel, yes I'm always getting error 183. How do I clear the error
before calling the the dll?

Private Const GENERIC_READ As System.Int32 = &H80000000
Private Const GENERIC_WRITE As System.Int32 = &H40000000
Private Const OPEN_EXISTING As System.Int32 = 3 ' I trust these are
correct.

<System.Runtime.InteropServices.DllImport("coredll.dll",
SetLastError:=True)> _
Private Shared Function CreateFile( _
ByVal lpFileName As String, _
ByVal dwDesiredAccess As Integer, _
ByVal dwShareMode As Integer, _
ByVal lpSecurityAttributes As Integer, _
ByVal dwCreationDisposition As Integer, _
ByVal dwFlagsAndAttributes As Integer, _
ByVal hTemplateFile As Integer) As Integer
End Function

Private mhRS As Integer = -1

' I want to clear the error here!
mhRS = CreateFile("COM1:", GENERIC_READ Or GENERIC_WRITE, 0, 0,
OPEN_EXISTING, 0, 0)
MessageBox.Show("Port handle: " & mhRS & "; Last Error: " & _
System.Runtime.InteropServices.Marshal.GetLastWin32Error.ToString)

Thanks, Graeme.
 
D

Daniel Moth

It sounds like some other application is keeping the port open (probably
your CEWedge). The port can only be used by one process at a time.

If you ever get a valid handle you should call CloseHandle when you are
done.
<DllImport("coredll.dll")> Private Shared Function CloseHandle(ByVal hObject
As Integer) As Integer
End Function

Call it passing the handle to the port.

Let me advise you again to use one of the opennetcf classes or at least look
at the code to see how to call the native APIs.

Cheers
Daniel
 
G

GraemeR

Thanks Daniel.
It sounds like some other application is keeping the port open (probably
your CEWedge). The port can only be used by one process at a time.
I thought of this. I manually reset the iPAQ (reset button on bottom) before
running my test code. Painful and slow, but must be done.
If you ever get a valid handle you should call CloseHandle when you are
done.
I close the port when I'm finished with it; or attempt to reopen it. I'm
using a flag value of -1 to indicate the port is closed (i.e. handle not
initialised)
Let me advise you again to use one of the opennetcf classes or at least
look at the code to see how to call the native APIs.
Have been trying but am a little weak with C# (and VB .NET) code.

Before leaving the thread can yopu advise the reference you used to fin
error code 183?
Cheers, Graeme.
 
D

Daniel Moth

Before leaving the thread can yopu advise the reference you used to fin
error code 183?

Launch eVC (if you don't have it, it is a free download)
Tools->Error Lookup

Cheers
Daniel
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top