Windows CE 5.0

[Guest]

Hello,

I've upgraded from 4.2 and having quite a bit of trouble getting things to
work in 5.0. I am writing an app in C# which uses the Serial class from
opennetcf.org. This app will run on an x86 device and basically displays in a
text box any characters it receives from a PC. When i have CE 4.2 running on
the device, the characters are displayed fine.

However when i have CE 5.0 running on the device, the app displays in hex
the characters f5, f4, and f6. I never had this problem in 4.2. Has anyone
encountered similar problems? Would anyone know what is causing this? How
much different is the Serial driver in 5.0 compared to that in 4.2? Thanks.

Kind Regards,

Michael--J.

 

[Paul G. Tobey [eMVP]]

That doesn't sound like a serial driver thing; more likely a change in the
text mapping or code page. Debug your program and see what you are getting
back. If it's the same in both systems, you can obviously eliminate the
serial I/O...

Paul T.

 

[Guest]

Hello Paul,

What did you mean by "Debug your program"? Which program are you talking
about? Are you talking about my C# application which i deploy on my device?
Or are you talking about debugging the OS image? If you meant my C# app, i
have already tested it on both systems. In 4.2 it works fine, but in 5.0 the
behaviour i mentioned in my previous post happens. I probably didn't
undestand you... can you please elaborate...

Also, would having a side-by-side installation of 4.2 and 5.0 have anything
to do with it?

Kind Regards,

Michael--J.

 

[Paul G. Tobey [eMVP]]

Right. The behavior happens, but, "displays the characters it receives",
has two parts: receives and displays, right? Is the data wrong from
receive? No, I bet it isn't, but I can't tell, from a display of the data,
whether it's a receive problem or a display problem; with the debugger, *you
can*. When you've done so, tell us...

Paul T.

 

[Guest]

Yes, i just did what you told me and the data is wrong from the receive. I
did this check by examining what byte was read after calling the API method
ReadFile().

What could this mean?

 

[Paul G. Tobey [eMVP]]

If there is a parity error, perhaps the driver has changed slightly to
return something different. This would probably not be an intentional
thing, but a change in error handling causing a change in the undefined
behavior as a side-effect.

If it were me, I'd return to C/C++ and write a simple program (you already
have the basic code for configuration and read/write; you just have to port
it to C). Verify that the C program has the same problem, then start
looking for error returns. Is ReadFile returning false, for example? If
not, are you sure that you aren't going past the end of the read data (in C,
make sure that the number of bytes returned matches what you are using to
read the data).

Paul T.

 

[Guest]

Also Paul, since i need to use all 4 com ports on my device, i had to disable
the serial debugging of Platform Builder of COM1 by modifying the code in
debug.c at C:\WINCE500\PUBLIC\COMMON\OAK\CSP\X86\OAL. I did the same thing in
the 4.2 system (which worked fine).

In 5.0 however, i can open all com ports and then close them. But when i try
to open them again, a "CreateFile failed: 55" error occurs for COM2, 3, and
4, but not COM1 and i have to perform a hard reset on the device in order to
open those ports properly again. COM1 can actually be opened and closed as
many times as possible, it is ports COM2, 3, and 4 that cause me grief.

Kind Regards,

Michael--J.

 

[Paul G. Tobey [eMVP]]

It sounds to me like you are getting the handles to the ports mixed up
somehow. I don't have 5.0 running on any devices, but that is *extremely*
strange behavior in 4.2 and I have never seen it. What serial driver is
this? How is the registry set?

Paul T.

 

[Guest]

The serial driver i am using is just the built-in driver that Microsoft
supplies (i.e. comes with Platform Builder), which is com16550. When you said
"but that is *extremely* strange behavior in 4.2 and I have never seen it", i
must reinforce that everything works fine in 4.2... these strange behaviours
only occur in 5.0.

Yes, i also had to modify the registry in platform.reg because COM1 and COM3
were sharing the same address space, as was COM2 and COM4. These are the
settings which include the changes made (they are the same as the registry
settings used in the 4.2 version):

; COM1
IF BSP_SERIAL1
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1]
"SysIntr"=dword:14
"IoBase"=dword:03F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:0
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL1
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL1

; COM2
IF BSP_SERIAL2
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2]
"SysIntr"=dword:13
"IoBase"=dword:02F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:1
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL2
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL2

; COM3
IF BSP_SERIAL3
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3]
"SysIntr"=dword:1B
"IoBase"=dword:03E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:2
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL3
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL3

; COM4
IF BSP_SERIAL4
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4]
"SysIntr"=dword:1A
"IoBase"=dword:02E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:3
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL4
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL4
ENDIF BSP_NOSERIAL !

I also had to add two environment variables in the OS image, BSP_SERIAL1=1
and BSP_SERIAL4=1, because i noticed that they weren't present after typing
"set" in DOS.

 

[Steve Maillet \(eMVP\)]

Can you re-port this in raw C/C++ as Paul suggested. This smells to me like
an OpennetCF + V5.0 issue and not a serial driver one.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com

Do have an opinion on the effectiveness of Microsoft Windows Mobile and
Embedded newsgroups? Let us know!
https://www.windowsembeddedeval.com/community/newsgroups

 

[Paul G. Tobey [eMVP]]

The strange behavior I was referring to was the open/close stuff that you
see on multiple ports in 4.2, but not in 5.0...

I'm a little worried about the order in which ports are going to be opened
there. That is, I'm not sure that serial2 will always end up being COM2,
the way you have things set up. Once the device has booted, you might use
the Remote Registry Editor to verify that the entry
HKLM/Drivers/Active/<whatever> which corresponds to COM1 points back to the
Serial1 entry in BuiltIn, and that COM2 points to Serial2, etc. If not, you
want to add the Order and Index keys to make the drivers load in the right
order to have 1 = COM1, 2 = COM2, etc.

I'm also a little worried about the DeviceArrayIndex entries and whether
that is the right way to set things for the generic 16550 driver. You might
check and see whether setting them all to 0 isn't the right thing to do.

Paul T.

The serial driver i am using is just the built-in driver that Microsoft
supplies (i.e. comes with Platform Builder), which is com16550. When you
said
"but that is *extremely* strange behavior in 4.2 and I have never seen
it", i
must reinforce that everything works fine in 4.2... these strange
behaviours
only occur in 5.0.

Yes, i also had to modify the registry in platform.reg because COM1 and
COM3
were sharing the same address space, as was COM2 and COM4. These are the
settings which include the changes made (they are the same as the registry
settings used in the 4.2 version):

; COM1
IF BSP_SERIAL1
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1]
"SysIntr"=dword:14
"IoBase"=dword:03F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:0
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL1
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL1

; COM2
IF BSP_SERIAL2
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2]
"SysIntr"=dword:13
"IoBase"=dword:02F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:1
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL2
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL2

; COM3
IF BSP_SERIAL3
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3]
"SysIntr"=dword:1B
"IoBase"=dword:03E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:2
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL3
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL3

; COM4
IF BSP_SERIAL4
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4]
"SysIntr"=dword:1A
"IoBase"=dword:02E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:3
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL4
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL4
ENDIF BSP_NOSERIAL !

I also had to add two environment variables in the OS image, BSP_SERIAL1=1
and BSP_SERIAL4=1, because i noticed that they weren't present after
typing
"set" in DOS.

It sounds to me like you are getting the handles to the ports mixed up
somehow. I don't have 5.0 running on any devices, but that is
*extremely*
strange behavior in 4.2 and I have never seen it. What serial driver is
this? How is the registry set?

Paul T.

 

[Guest]

Steve,

To test with C/C++, do i use Embedded Visual C++ 4.0? I haven't used that
before, would know any existing component that i could just employ to do that
test?

Paul,

I did what you said and checked the Remote Registry Editor and all COMx
correspond to the correct Serialx ports. Just to let you know also, the only
changes i made to platform.reg was modify the "SysIntr" of COM3 and COM4...
that's it. The rest is Microsoft's default so i didn't want to touch any of
it. Should i carry out your suggestions anyway?

Kind Regards,

Michael--J.

The strange behavior I was referring to was the open/close stuff that you
see on multiple ports in 4.2, but not in 5.0...

I'm a little worried about the order in which ports are going to be opened
there. That is, I'm not sure that serial2 will always end up being COM2,
the way you have things set up. Once the device has booted, you might use
the Remote Registry Editor to verify that the entry
HKLM/Drivers/Active/<whatever> which corresponds to COM1 points back to the
Serial1 entry in BuiltIn, and that COM2 points to Serial2, etc. If not, you
want to add the Order and Index keys to make the drivers load in the right
order to have 1 = COM1, 2 = COM2, etc.

I'm also a little worried about the DeviceArrayIndex entries and whether
that is the right way to set things for the generic 16550 driver. You might
check and see whether setting them all to 0 isn't the right thing to do.

Paul T.

The serial driver i am using is just the built-in driver that Microsoft
supplies (i.e. comes with Platform Builder), which is com16550. When you
said
"but that is *extremely* strange behavior in 4.2 and I have never seen
it", i
must reinforce that everything works fine in 4.2... these strange
behaviours
only occur in 5.0.

Yes, i also had to modify the registry in platform.reg because COM1 and
COM3
were sharing the same address space, as was COM2 and COM4. These are the
settings which include the changes made (they are the same as the registry
settings used in the 4.2 version):

; COM1
IF BSP_SERIAL1
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1]
"SysIntr"=dword:14
"IoBase"=dword:03F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:0
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL1
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL1

; COM2
IF BSP_SERIAL2
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2]
"SysIntr"=dword:13
"IoBase"=dword:02F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:1
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL2
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL2

; COM3
IF BSP_SERIAL3
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3]
"SysIntr"=dword:1B
"IoBase"=dword:03E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:2
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL3
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL3

; COM4
IF BSP_SERIAL4
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4]
"SysIntr"=dword:1A
"IoBase"=dword:02E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:3
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL4
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL4
ENDIF BSP_NOSERIAL !

I also had to add two environment variables in the OS image, BSP_SERIAL1=1
and BSP_SERIAL4=1, because i noticed that they weren't present after
typing
"set" in DOS.

It sounds to me like you are getting the handles to the ports mixed up
somehow. I don't have 5.0 running on any devices, but that is
*extremely*
strange behavior in 4.2 and I have never seen it. What serial driver is
this? How is the registry set?

Paul T.

Also Paul, since i need to use all 4 com ports on my device, i had to
disable
the serial debugging of Platform Builder of COM1 by modifying the code
in
debug.c at C:\WINCE500\PUBLIC\COMMON\OAK\CSP\X86\OAL. I did the same
thing
in
the 4.2 system (which worked fine).

In 5.0 however, i can open all com ports and then close them. But when
i
try
to open them again, a "CreateFile failed: 55" error occurs for COM2, 3,
and
4, but not COM1 and i have to perform a hard reset on the device in
order
to
open those ports properly again. COM1 can actually be opened and closed
as
many times as possible, it is ports COM2, 3, and 4 that cause me grief.

Kind Regards,

Michael--J.

:

Yes, i just did what you told me and the data is wrong from the
receive.
I
did this check by examining what byte was read after calling the API
method
ReadFile().

What could this mean?

:

Right. The behavior happens, but, "displays the characters it
receives",
has two parts: receives and displays, right? Is the data wrong from
receive? No, I bet it isn't, but I can't tell, from a display of
the
data,
whether it's a receive problem or a display problem; with the
debugger,
*you
can*. When you've done so, tell us...

Paul T.

Hello Paul,

What did you mean by "Debug your program"? Which program are you
talking
about? Are you talking about my C# application which i deploy on
my
device?
Or are you talking about debugging the OS image? If you meant my
C#
app, i
have already tested it on both systems. In 4.2 it works fine, but
in
5.0
the
behaviour i mentioned in my previous post happens. I probably
didn't
undestand you... can you please elaborate...

Also, would having a side-by-side installation of 4.2 and 5.0 have
anything
to do with it?

Kind Regards,

Michael--J.

:

That doesn't sound like a serial driver thing; more likely a
change
in
the
text mapping or code page. Debug your program and see what you
are
getting
back. If it's the same in both systems, you can obviously
eliminate
the
serial I/O...

Paul T.

message
Hello,

I've upgraded from 4.2 and having quite a bit of trouble
getting
things
to
work in 5.0. I am writing an app in C# which uses the Serial
class
from
opennetcf.org. This app will run on an x86 device and basically
displays
in a
text box any characters it receives from a PC. When i have CE
4.2
running
on
the device, the characters are displayed fine.

However when i have CE 5.0 running on the device, the app
displays
in
hex
the characters f5, f4, and f6. I never had this problem in 4.2.
Has
anyone
encountered similar problems? Would anyone know what is causing
this?
How
much different is the Serial driver in 5.0 compared to that in
4.2?
Thanks.

Kind Regards,

Michael--J.

 

[Paul G. Tobey [eMVP]]

Yes, that's what you would use. You don't want to use any opaque
components; you want to do the same steps you are doing in your .NET CF
application, but with C++.

Paul T.

Steve,

To test with C/C++, do i use Embedded Visual C++ 4.0? I haven't used that
before, would know any existing component that i could just employ to do
that
test?

Paul,

I did what you said and checked the Remote Registry Editor and all COMx
correspond to the correct Serialx ports. Just to let you know also, the
only
changes i made to platform.reg was modify the "SysIntr" of COM3 and
COM4...
that's it. The rest is Microsoft's default so i didn't want to touch any
of
it. Should i carry out your suggestions anyway?

Kind Regards,

Michael--J.

The strange behavior I was referring to was the open/close stuff that you
see on multiple ports in 4.2, but not in 5.0...

I'm a little worried about the order in which ports are going to be
opened
there. That is, I'm not sure that serial2 will always end up being COM2,
the way you have things set up. Once the device has booted, you might
use
the Remote Registry Editor to verify that the entry
HKLM/Drivers/Active/<whatever> which corresponds to COM1 points back to
the
Serial1 entry in BuiltIn, and that COM2 points to Serial2, etc. If not,
you
want to add the Order and Index keys to make the drivers load in the
right
order to have 1 = COM1, 2 = COM2, etc.

I'm also a little worried about the DeviceArrayIndex entries and whether
that is the right way to set things for the generic 16550 driver. You
might
check and see whether setting them all to 0 isn't the right thing to do.

Paul T.

The serial driver i am using is just the built-in driver that Microsoft
supplies (i.e. comes with Platform Builder), which is com16550. When
you
said
"but that is *extremely* strange behavior in 4.2 and I have never seen
it", i
must reinforce that everything works fine in 4.2... these strange
behaviours
only occur in 5.0.

Yes, i also had to modify the registry in platform.reg because COM1 and
COM3
were sharing the same address space, as was COM2 and COM4. These are
the
settings which include the changes made (they are the same as the
registry
settings used in the 4.2 version):

; COM1
IF BSP_SERIAL1
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1]
"SysIntr"=dword:14
"IoBase"=dword:03F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:0
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE
FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial1\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL1
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL1

; COM2
IF BSP_SERIAL2
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2]
"SysIntr"=dword:13
"IoBase"=dword:02F8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:1
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
"Priority"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE
FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL2
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL2

; COM3
IF BSP_SERIAL3
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3]
"SysIntr"=dword:1B
"IoBase"=dword:03E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:2
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE
FIFO)
; "Irq"=dword:4
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial3\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL3
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL3

; COM4
IF BSP_SERIAL4
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4]
"SysIntr"=dword:1A
"IoBase"=dword:02E8
"IoLen"=dword:8
"DeviceArrayIndex"=dword:3
"Prefix"="COM"
"IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
"Dll"="Com16550.Dll"
"Order"=dword:0
; Turn on follows for Installable ISR (isr16550 supporting SOFTWARE
FIFO)
; "Irq"=dword:3
; "IsrDll"="isr16550.dll"
; "IsrHandler"="ISRHandler"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial4\Unimodem]
"Tsp"="Unimodem.dll"
"DeviceType"=dword:0
"FriendlyName"=LOC_FRIENDLYNAME_SERIAL4
"DevConfig"=hex: 10,00, 00,00, 05,00,00,00, 10,01,00,00, 00,4B,00,00,
00,00, 08, 00, 00, 00,00,00,00
ENDIF BSP_SERIAL4
ENDIF BSP_NOSERIAL !

I also had to add two environment variables in the OS image,
BSP_SERIAL1=1
and BSP_SERIAL4=1, because i noticed that they weren't present after
typing
"set" in DOS.

:

It sounds to me like you are getting the handles to the ports mixed up
somehow. I don't have 5.0 running on any devices, but that is
*extremely*
strange behavior in 4.2 and I have never seen it. What serial driver
is
this? How is the registry set?

Paul T.

Also Paul, since i need to use all 4 com ports on my device, i had
to
disable
the serial debugging of Platform Builder of COM1 by modifying the
code
in
debug.c at C:\WINCE500\PUBLIC\COMMON\OAK\CSP\X86\OAL. I did the same
thing
in
the 4.2 system (which worked fine).

In 5.0 however, i can open all com ports and then close them. But
when
i
try
to open them again, a "CreateFile failed: 55" error occurs for COM2,
3,
and
4, but not COM1 and i have to perform a hard reset on the device in
order
to
open those ports properly again. COM1 can actually be opened and
closed
as
many times as possible, it is ports COM2, 3, and 4 that cause me
grief.

Kind Regards,

Michael--J.

:

Yes, i just did what you told me and the data is wrong from the
receive.
I
did this check by examining what byte was read after calling the
API
method
ReadFile().

What could this mean?

:

Right. The behavior happens, but, "displays the characters it
receives",
has two parts: receives and displays, right? Is the data wrong
from
receive? No, I bet it isn't, but I can't tell, from a display of
the
data,
whether it's a receive problem or a display problem; with the
debugger,
*you
can*. When you've done so, tell us...

Paul T.

message
Hello Paul,

What did you mean by "Debug your program"? Which program are
you
talking
about? Are you talking about my C# application which i deploy
on
my
device?
Or are you talking about debugging the OS image? If you meant
my
C#
app, i
have already tested it on both systems. In 4.2 it works fine,
but
in
5.0
the
behaviour i mentioned in my previous post happens. I probably
didn't
undestand you... can you please elaborate...

Also, would having a side-by-side installation of 4.2 and 5.0
have
anything
to do with it?

Kind Regards,

Michael--J.

:

That doesn't sound like a serial driver thing; more likely a
change
in
the
text mapping or code page. Debug your program and see what
you
are
getting
back. If it's the same in both systems, you can obviously
eliminate
the
serial I/O...

Paul T.

message
Hello,

I've upgraded from 4.2 and having quite a bit of trouble
getting
things
to
work in 5.0. I am writing an app in C# which uses the Serial
class
from
opennetcf.org. This app will run on an x86 device and
basically
displays
in a
text box any characters it receives from a PC. When i have
CE
4.2
running
on
the device, the characters are displayed fine.

However when i have CE 5.0 running on the device, the app
displays
in
hex
the characters f5, f4, and f6. I never had this problem in
4.2.
Has
anyone
encountered similar problems? Would anyone know what is
causing
this?
How
much different is the Serial driver in 5.0 compared to that
in
4.2?
Thanks.

Kind Regards,

Michael--J.