|
|
You're in the
dotnet compact framework
group:Windows CE 5.0
dotnet compact framework:
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,
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. [quoted text, click to view] "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message news:7C70703C-92DC-40DA-B309-3D387043B88C@microsoft.com... > 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.
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. [quoted text, click to view] "Paul G. Tobey [eMVP]" wrote:
> 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. > > "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > news:7C70703C-92DC-40DA-B309-3D387043B88C@microsoft.com... > > 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. > >
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. [quoted text, click to view] "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message news:3802031F-BF69-40EA-8CE5-598BC87A2C4F@microsoft.com... > 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]" wrote: > >> 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. >> >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> news:7C70703C-92DC-40DA-B309-3D387043B88C@microsoft.com... >> > 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. >> >> >>
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? [quoted text, click to view] "Paul G. Tobey [eMVP]" wrote:
> 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. > > "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > news:3802031F-BF69-40EA-8CE5-598BC87A2C4F@microsoft.com... > > 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]" wrote: > > > >> 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. > >> > >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > >> news:7C70703C-92DC-40DA-B309-3D387043B88C@microsoft.com... > >> > 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. > >> > >> > >> > >
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. [quoted text, click to view] "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message news:C2367647-C7CA-453E-8059-2237095126A0@microsoft.com... > 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]" wrote: > >> 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. >> >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> news:3802031F-BF69-40EA-8CE5-598BC87A2C4F@microsoft.com... >> > 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]" wrote: >> > >> >> 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. >> >> >> >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> >> news:7C70703C-92DC-40DA-B309-3D387043B88C@microsoft.com... >> >> > 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. >> >> >> >> >> >> >> >> >>
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. [quoted text, click to view] "Michael--J" wrote:
> 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]" wrote: > > > 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. > > > > "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > > news:3802031F-BF69-40EA-8CE5-598BC87A2C4F@microsoft.com... > > > 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]" wrote: > > > > > >> 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. > > >> > > >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > > >> news:7C70703C-92DC-40DA-B309-3D387043B88C@microsoft.com... > > >> > 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. > > >> > > >> > > >> > > > >
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. [quoted text, click to view] "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message news:8EF8A40B-9421-4054-8720-F4845C96E209@microsoft.com... > 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. > > "Michael--J" wrote: > >> 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]" wrote: >> >> > 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. >> > >> > "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> > news:3802031F-BF69-40EA-8CE5-598BC87A2C4F@microsoft.com... >> > > 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]" wrote: >> > > >> > >> 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. >> > >> >> > >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> > >> news:7C70703C-92DC-40DA-B309-3D387043B88C@microsoft.com... >> > >> > 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. >> > >> >> > >> >> > >> >> > >> > >> >
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. [quoted text, click to view] "Paul G. Tobey [eMVP]" wrote:
> 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. > > "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > news:8EF8A40B-9421-4054-8720-F4845C96E209@microsoft.com... > > 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. > > > > "Michael--J" wrote: > > > >> 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]" wrote: > >> > >> > 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. > >> > > >> > "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > >> > news:3802031F-BF69-40EA-8CE5-598BC87A2C4F@microsoft.com... > >> > > 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]" wrote: > >> > > > >> > >> 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... > >> > >>
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. [quoted text, click to view] "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message
news:4CCFA834-861A-4D09-9EAD-342FF82F0354@microsoft.com... > 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. > > "Paul G. Tobey [eMVP]" wrote: > >> 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. >> >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> news:8EF8A40B-9421-4054-8720-F4845C96E209@microsoft.com... >> > 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. >> > >> > "Michael--J" wrote: >> > >> >> 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]" wrote: >> >> >> >> > 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... >> >> >
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
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. [quoted text, click to view] "Paul G. Tobey [eMVP]" wrote:
> 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. > > "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > news:4CCFA834-861A-4D09-9EAD-342FF82F0354@microsoft.com... > > 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. > > > > "Paul G. Tobey [eMVP]" wrote: > > > >> 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. > >> > >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message > >> news:8EF8A40B-9421-4054-8720-F4845C96E209@microsoft.com... > >> > 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
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. [quoted text, click to view] "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message
news:3EC0B153-303E-46E2-A13D-0E03A8A9E0FA@microsoft.com... > 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. > > "Paul G. Tobey [eMVP]" wrote: > >> 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. >> >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> news:4CCFA834-861A-4D09-9EAD-342FF82F0354@microsoft.com... >> > 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. >> > >> > "Paul G. Tobey [eMVP]" wrote: >> > >> >> 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. >> >> >> >> "Michael--J" <MichaelJ@discussions.microsoft.com> wrote in message >> >> news:8EF8A40B-9421-4054-8720-F4845C96E209@microsoft.com... >> >> > Also Paul, since i need to use all 4 com ports on my device, i had >> >> > to
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |