Hello to the group. I'll introduce myself as a hobbyist at this point
(although we _are_ using one Armite on a quasi-regular basis at work).
Leon Heller mentioned this group in a post in the sparkfun forum, and I
see some posts here by rtstofer (thanks again for your help in the
gnuarm forum Richard).
Has anyone here used the philips VCOM driver for the lpc2148 on XP
lately? It is included in the files for AN10420 on the philips site.
There is what appears to be an identical copy in the files section here.
The crucial files appear to be PLP2KUS.inf and PLP2KUS.sys.
I'm having serious problems trying to install it (reboot in middle of
install). Trying to figure out if I'm doing something terribly wrong, or
if an XP update has torpedoed the driver, or...
-Hugh
new member - philips VCOM driver question
Started by ●July 18, 2009
Reply by ●July 19, 20092009-07-19
I tired it on my WinXP SP3 box, the VCP driver, PLP2KUS, was installed without
any problem.
On the installation, the new hardware dialog asks the location of PLP2KUS.sys, because this file isn't placed in the folder with the INF file. Just locating it on the file dialog, the install process successfully finishes. The installation occurs twice, for each VCP interface.
On your side, is there any clue left on the setupapi.log ( C:\Windows\setupapi.log )?
- Delete (uninstall) the COM port(s) and composite device for "Philips LPC2148 VCOM", if any, using USBDeview
- Just before plugging in the USB device, rename setupapi.log, for example, to setupapi0.log
- Plug in the USB device, and install the driver, as usual.
- A new setupapi.log is there, even after reboot.
The installation log of the USB device is placed at the first blocks of this new setupapi.log
USBDeview
http://www.nirsoft.net/utils/usb_devices_view.html
Tsuneo
--- In l..., "hsutherland2@..." wrote:
>
> Hello to the group. I'll introduce myself as a hobbyist at this point
> (although we _are_ using one Armite on a quasi-regular basis at work).
> Leon Heller mentioned this group in a post in the sparkfun forum, and I
> see some posts here by rtstofer (thanks again for your help in the
> gnuarm forum Richard).
> Has anyone here used the philips VCOM driver for the lpc2148 on XP
> lately? It is included in the files for AN10420 on the philips site.
> There is what appears to be an identical copy in the files section here.
> The crucial files appear to be PLP2KUS.inf and PLP2KUS.sys.
> I'm having serious problems trying to install it (reboot in middle of
> install). Trying to figure out if I'm doing something terribly wrong, or
> if an XP update has torpedoed the driver, or...
>
> -Hugh
>
On the installation, the new hardware dialog asks the location of PLP2KUS.sys, because this file isn't placed in the folder with the INF file. Just locating it on the file dialog, the install process successfully finishes. The installation occurs twice, for each VCP interface.
On your side, is there any clue left on the setupapi.log ( C:\Windows\setupapi.log )?
- Delete (uninstall) the COM port(s) and composite device for "Philips LPC2148 VCOM", if any, using USBDeview
- Just before plugging in the USB device, rename setupapi.log, for example, to setupapi0.log
- Plug in the USB device, and install the driver, as usual.
- A new setupapi.log is there, even after reboot.
The installation log of the USB device is placed at the first blocks of this new setupapi.log
USBDeview
http://www.nirsoft.net/utils/usb_devices_view.html
Tsuneo
--- In l..., "hsutherland2@..." wrote:
>
> Hello to the group. I'll introduce myself as a hobbyist at this point
> (although we _are_ using one Armite on a quasi-regular basis at work).
> Leon Heller mentioned this group in a post in the sparkfun forum, and I
> see some posts here by rtstofer (thanks again for your help in the
> gnuarm forum Richard).
> Has anyone here used the philips VCOM driver for the lpc2148 on XP
> lately? It is included in the files for AN10420 on the philips site.
> There is what appears to be an identical copy in the files section here.
> The crucial files appear to be PLP2KUS.inf and PLP2KUS.sys.
> I'm having serious problems trying to install it (reboot in middle of
> install). Trying to figure out if I'm doing something terribly wrong, or
> if an XP update has torpedoed the driver, or...
>
> -Hugh
>
Reply by ●July 19, 20092009-07-19
Thank you for taking the time to check this out Tsuneo. Your DriverView
utililty looks professional and behaves professionally also! I didn't
see plp2kus.sys in the list, so I guess my uninstall was successful. I
didn't attempt to reinstall yet. Let me elaborate.
Confession #1: Not knowing if I'd get any response, I supplied a very
abbreviated version of the story . One thing I didn't mention was that
the project didn't appear to build properly, and that I didn't get any
"new hardware found" dialog when I connected the development board to
the PC. At that point I decided to attempt installation of the driver
anyway...
Since everything worked for you, perhaps I should concentrate on my
problems building the project first. (It might make more sense to
inquire about that on the keil site, but since I've already started this
thread...).
When I simply loaded the project from the (demo version of) UV3 GUI, and
then chose "build", I got the following:
Build target 'MCB2140'
assembling Startup.s...
--- Error: failed to execute 'C:\Keil\ARM\BIN\AA'
Target not created
At this point, yet another thing that puzzles me. Some lines from the
help/about.. dialog:
uVision3 V3.80
Toolchain path: C:\Keil\ARM\BIN\
C Compiler: CA.exe
Assembler: AA.exe
Linker/Locator: LA.exe
Yet the contents of C:\Keil\AR\BIN are all .dll files. C:\Keil\ARM\BIN40
contains:
armcc.exe
armasm.exe
armlnk.exe
and these appear to be the ones that are covered in the documentation.
Anyways,
Confession #2: At that point, I, well, I essentially tried things at
random until I was able to produce a .hex file. (One of those things was
to make an entirely new project and replace Startup.s with the default.)
What is the best way to get that example project to build?
My original cry for help
on the Sparkfun
forum has a few more details.
The failed installs do show up at the end of my setupapi.log
(I posted
the entire thing).
I don't remember the exact sequence I went through, but it was something
like
1) Full install / crash
2) Disable
3) Re-enable / crash
4) Uninstall
5) Partial install / crash
6) Uninstall
7) More or less repeated the same steps on my laptop.
Any suggestions greatly appreciated.
-Hugh
--- In l..., "t_chinzei" wrote:
>
> I tired it on my WinXP SP3 box, the VCP driver, PLP2KUS, was installed
without any problem.
> On the installation, the new hardware dialog asks the location of
PLP2KUS.sys, because this file isn't placed in the folder with the INF
file. Just locating it on the file dialog, the install process
successfully finishes. The installation occurs twice, for each VCP
interface.
>
> On your side, is there any clue left on the setupapi.log (
C:\Windows\setupapi.log )?
>
> - Delete (uninstall) the COM port(s) and composite device for "Philips
LPC2148 VCOM", if any, using USBDeview
> - Just before plugging in the USB device, rename setupapi.log, for
example, to setupapi0.log
> - Plug in the USB device, and install the driver, as usual.
> - A new setupapi.log is there, even after reboot.
> The installation log of the USB device is placed at the first blocks
of this new setupapi.log
>
> USBDeview
> http://www.nirsoft.net/utils/usb_devices_view.html
>
> Tsuneo
>
> --- In l..., "hsutherland2@" hsutherland2@ wrote:
> >
> > Hello to the group. I'll introduce myself as a hobbyist at this
point
> > (although we _are_ using one Armite on a quasi-regular basis at
work).
> > Leon Heller mentioned this group in a post in the sparkfun forum,
and I
> > see some posts here by rtstofer (thanks again for your help in the
> > gnuarm forum Richard).
> >
> >
> > Has anyone here used the philips VCOM driver for the lpc2148 on XP
> > lately? It is included in the files for AN10420 on the philips site.
> > There is what appears to be an identical copy in the files section
here.
> > The crucial files appear to be PLP2KUS.inf and PLP2KUS.sys.
> >
> >
> > I'm having serious problems trying to install it (reboot in middle
of
> > install). Trying to figure out if I'm doing something terribly
wrong, or
> > if an XP update has torpedoed the driver, or...
> >
> > -Hugh
>
utililty looks professional and behaves professionally also! I didn't
see plp2kus.sys in the list, so I guess my uninstall was successful. I
didn't attempt to reinstall yet. Let me elaborate.
Confession #1: Not knowing if I'd get any response, I supplied a very
abbreviated version of the story . One thing I didn't mention was that
the project didn't appear to build properly, and that I didn't get any
"new hardware found" dialog when I connected the development board to
the PC. At that point I decided to attempt installation of the driver
anyway...
Since everything worked for you, perhaps I should concentrate on my
problems building the project first. (It might make more sense to
inquire about that on the keil site, but since I've already started this
thread...).
When I simply loaded the project from the (demo version of) UV3 GUI, and
then chose "build", I got the following:
Build target 'MCB2140'
assembling Startup.s...
--- Error: failed to execute 'C:\Keil\ARM\BIN\AA'
Target not created
At this point, yet another thing that puzzles me. Some lines from the
help/about.. dialog:
uVision3 V3.80
Toolchain path: C:\Keil\ARM\BIN\
C Compiler: CA.exe
Assembler: AA.exe
Linker/Locator: LA.exe
Yet the contents of C:\Keil\AR\BIN are all .dll files. C:\Keil\ARM\BIN40
contains:
armcc.exe
armasm.exe
armlnk.exe
and these appear to be the ones that are covered in the documentation.
Anyways,
Confession #2: At that point, I, well, I essentially tried things at
random until I was able to produce a .hex file. (One of those things was
to make an entirely new project and replace Startup.s with the default.)
What is the best way to get that example project to build?
My original cry for help
on the Sparkfun
forum has a few more details.
The failed installs do show up at the end of my setupapi.log
(I posted
the entire thing).
I don't remember the exact sequence I went through, but it was something
like
1) Full install / crash
2) Disable
3) Re-enable / crash
4) Uninstall
5) Partial install / crash
6) Uninstall
7) More or less repeated the same steps on my laptop.
Any suggestions greatly appreciated.
-Hugh
--- In l..., "t_chinzei" wrote:
>
> I tired it on my WinXP SP3 box, the VCP driver, PLP2KUS, was installed
without any problem.
> On the installation, the new hardware dialog asks the location of
PLP2KUS.sys, because this file isn't placed in the folder with the INF
file. Just locating it on the file dialog, the install process
successfully finishes. The installation occurs twice, for each VCP
interface.
>
> On your side, is there any clue left on the setupapi.log (
C:\Windows\setupapi.log )?
>
> - Delete (uninstall) the COM port(s) and composite device for "Philips
LPC2148 VCOM", if any, using USBDeview
> - Just before plugging in the USB device, rename setupapi.log, for
example, to setupapi0.log
> - Plug in the USB device, and install the driver, as usual.
> - A new setupapi.log is there, even after reboot.
> The installation log of the USB device is placed at the first blocks
of this new setupapi.log
>
> USBDeview
> http://www.nirsoft.net/utils/usb_devices_view.html
>
> Tsuneo
>
> --- In l..., "hsutherland2@" hsutherland2@ wrote:
> >
> > Hello to the group. I'll introduce myself as a hobbyist at this
point
> > (although we _are_ using one Armite on a quasi-regular basis at
work).
> > Leon Heller mentioned this group in a post in the sparkfun forum,
and I
> > see some posts here by rtstofer (thanks again for your help in the
> > gnuarm forum Richard).
> >
> >
> > Has anyone here used the philips VCOM driver for the lpc2148 on XP
> > lately? It is included in the files for AN10420 on the philips site.
> > There is what appears to be an identical copy in the files section
here.
> > The crucial files appear to be PLP2KUS.inf and PLP2KUS.sys.
> >
> >
> > I'm having serious problems trying to install it (reboot in middle
of
> > install). Trying to figure out if I'm doing something terribly
wrong, or
> > if an XP update has torpedoed the driver, or...
> >
> > -Hugh
>
Reply by ●July 19, 20092009-07-19
> One thing I didn't mention was that the project
didn't appear to build
properly,
Ah, I see.
When the device returns an unexpected response, the PC device driver
crashes, if it doesn't handle the error properly. When the device
returns corrupted descriptor for GetDescriptor request, for example, the
device driver causes access violation to unreserved memory. It results
BSOD. Usually, device drivers check such an error strictly. But this
PLP2KUS is too naive for unexpected behavior of devices.
> --- Error: failed to execute 'C:\Keil\ARM\BIN\AA'
You are compiling CARM project in RealView.
"C:\Keil\ARM\BIN\AA" is the Assembler of CARM. The NXP example was built
on the KEIL's old compiler, CARM, which was discontinued when ARM have
captured KEIL. To compile it in RealView, you have to make up a new
project file, .Uv2, from scratch. Fortunately, as CARM source code has
so much differences from RealView, the C source files are just dragged
in to the new RealView project, though you'll see many warnings on
compile.
Follow the procedure on the uVision manual to create a new RealView
project.
Create Project
http://www.keil.com/support/man/docs/uv3/uv3_ca_createproject.htm
In the course of project setting, you'll be asked if the start-up file
is placed on your project folder or not. Answer YES to the question, to
replace Startup.s from CARM's to RealView's.
I was aware that my WinXP box doesn't shutdown properly, when the
example device is attached. Even if the device is unplugged on shutdown,
Windows' shutdown process doesn't finish. Then, I have to shut down it
by pressing the power switch longer. Though I don't look in the source
code closely yet, the device driver seem to have a problem in the
clean-up procedures.
I recommend you to use Windows in-box device driver for VCOM,
usbser.sys, instead. Surely, usbser.sys has some problems, but it's
better than PLP2KUS.
Tsuneo
--- In l..., "hsutherland2@..."
wrote:
>
> Thank you for taking the time to check this out Tsuneo. Your
DriverView
> utililty looks professional and behaves professionally also! I didn't
> see plp2kus.sys in the list, so I guess my uninstall was successful. I
> didn't attempt to reinstall yet. Let me elaborate.
>
> Confession #1: Not knowing if I'd get any response, I supplied a very
> abbreviated version of the story . One thing I didn't mention was that
> the project didn't appear to build properly, and that I didn't get any
> "new hardware found" dialog when I connected the development board to
> the PC. At that point I decided to attempt installation of the driver
> anyway...
>
> Since everything worked for you, perhaps I should concentrate on my
> problems building the project first. (It might make more sense to
> inquire about that on the keil site, but since I've already started
this
> thread...).
>
> When I simply loaded the project from the (demo version of) UV3 GUI,
and
> then chose "build", I got the following:
>
> Build target 'MCB2140'
> assembling Startup.s...
> --- Error: failed to execute 'C:\Keil\ARM\BIN\AA'
> Target not created
>
> At this point, yet another thing that puzzles me. Some lines from the
> help/about.. dialog:
> uVision3 V3.80
> Toolchain path: C:\Keil\ARM\BIN\
> C Compiler: CA.exe
> Assembler: AA.exe
> Linker/Locator: LA.exe
> Yet the contents of C:\Keil\AR\BIN are all .dll files.
C:\Keil\ARM\BIN40
> contains:
> armcc.exe
> armasm.exe
> armlnk.exe
> and these appear to be the ones that are covered in the documentation.
> Anyways,
>
> Confession #2: At that point, I, well, I essentially tried things at
> random until I was able to produce a .hex file. (One of those things
was
> to make an entirely new project and replace Startup.s with the
default.)
> What is the best way to get that example project to build?
>
> My original cry for help
> on the Sparkfun
> forum has a few more details.
>
> The failed installs do show up at the end of my setupapi.log
> (I
posted
> the entire thing).
> I don't remember the exact sequence I went through, but it was
something
> like
> 1) Full install / crash
> 2) Disable
> 3) Re-enable / crash
> 4) Uninstall
> 5) Partial install / crash
> 6) Uninstall
> 7) More or less repeated the same steps on my laptop.
>
> Any suggestions greatly appreciated.
> -Hugh
> --- In l..., "t_chinzei" t_chinzei@ wrote:
> >
> > I tired it on my WinXP SP3 box, the VCP driver, PLP2KUS, was
installed
> without any problem.
> > On the installation, the new hardware dialog asks the location of
> PLP2KUS.sys, because this file isn't placed in the folder with the INF
> file. Just locating it on the file dialog, the install process
> successfully finishes. The installation occurs twice, for each VCP
> interface.
> >
> > On your side, is there any clue left on the setupapi.log (
> C:\Windows\setupapi.log )?
> >
> > - Delete (uninstall) the COM port(s) and composite device for
"Philips
> LPC2148 VCOM", if any, using USBDeview
> > - Just before plugging in the USB device, rename setupapi.log, for
> example, to setupapi0.log
> > - Plug in the USB device, and install the driver, as usual.
> > - A new setupapi.log is there, even after reboot.
> > The installation log of the USB device is placed at the first blocks
> of this new setupapi.log
> >
> > USBDeview
> > http://www.nirsoft.net/utils/usb_devices_view.html
> >
> > Tsuneo
> >
> > --- In l..., "hsutherland2@" hsutherland2@ wrote:
> > >
> > > Hello to the group. I'll introduce myself as a hobbyist at this
> point
> > > (although we _are_ using one Armite on a quasi-regular basis at
> work).
> > > Leon Heller mentioned this group in a post in the sparkfun forum,
> and I
> > > see some posts here by rtstofer (thanks again for your help in the
> > > gnuarm forum Richard).
> > >
> > >
> > > Has anyone here used the philips VCOM driver for the lpc2148 on
XP
> > > lately? It is included in the files for AN10420 on the philips
site.
> > > There is what appears to be an identical copy in the files section
> here.
> > > The crucial files appear to be PLP2KUS.inf and PLP2KUS.sys.
> > >
> > >
> > > I'm having serious problems trying to install it (reboot in
middle
> of
> > > install). Trying to figure out if I'm doing something terribly
> wrong, or
> > > if an XP update has torpedoed the driver, or...
> > >
> > > -Hugh
> > >
> >
>
properly,
Ah, I see.
When the device returns an unexpected response, the PC device driver
crashes, if it doesn't handle the error properly. When the device
returns corrupted descriptor for GetDescriptor request, for example, the
device driver causes access violation to unreserved memory. It results
BSOD. Usually, device drivers check such an error strictly. But this
PLP2KUS is too naive for unexpected behavior of devices.
> --- Error: failed to execute 'C:\Keil\ARM\BIN\AA'
You are compiling CARM project in RealView.
"C:\Keil\ARM\BIN\AA" is the Assembler of CARM. The NXP example was built
on the KEIL's old compiler, CARM, which was discontinued when ARM have
captured KEIL. To compile it in RealView, you have to make up a new
project file, .Uv2, from scratch. Fortunately, as CARM source code has
so much differences from RealView, the C source files are just dragged
in to the new RealView project, though you'll see many warnings on
compile.
Follow the procedure on the uVision manual to create a new RealView
project.
Create Project
http://www.keil.com/support/man/docs/uv3/uv3_ca_createproject.htm
In the course of project setting, you'll be asked if the start-up file
is placed on your project folder or not. Answer YES to the question, to
replace Startup.s from CARM's to RealView's.
I was aware that my WinXP box doesn't shutdown properly, when the
example device is attached. Even if the device is unplugged on shutdown,
Windows' shutdown process doesn't finish. Then, I have to shut down it
by pressing the power switch longer. Though I don't look in the source
code closely yet, the device driver seem to have a problem in the
clean-up procedures.
I recommend you to use Windows in-box device driver for VCOM,
usbser.sys, instead. Surely, usbser.sys has some problems, but it's
better than PLP2KUS.
Tsuneo
--- In l..., "hsutherland2@..."
wrote:
>
> Thank you for taking the time to check this out Tsuneo. Your
DriverView
> utililty looks professional and behaves professionally also! I didn't
> see plp2kus.sys in the list, so I guess my uninstall was successful. I
> didn't attempt to reinstall yet. Let me elaborate.
>
> Confession #1: Not knowing if I'd get any response, I supplied a very
> abbreviated version of the story . One thing I didn't mention was that
> the project didn't appear to build properly, and that I didn't get any
> "new hardware found" dialog when I connected the development board to
> the PC. At that point I decided to attempt installation of the driver
> anyway...
>
> Since everything worked for you, perhaps I should concentrate on my
> problems building the project first. (It might make more sense to
> inquire about that on the keil site, but since I've already started
this
> thread...).
>
> When I simply loaded the project from the (demo version of) UV3 GUI,
and
> then chose "build", I got the following:
>
> Build target 'MCB2140'
> assembling Startup.s...
> --- Error: failed to execute 'C:\Keil\ARM\BIN\AA'
> Target not created
>
> At this point, yet another thing that puzzles me. Some lines from the
> help/about.. dialog:
> uVision3 V3.80
> Toolchain path: C:\Keil\ARM\BIN\
> C Compiler: CA.exe
> Assembler: AA.exe
> Linker/Locator: LA.exe
> Yet the contents of C:\Keil\AR\BIN are all .dll files.
C:\Keil\ARM\BIN40
> contains:
> armcc.exe
> armasm.exe
> armlnk.exe
> and these appear to be the ones that are covered in the documentation.
> Anyways,
>
> Confession #2: At that point, I, well, I essentially tried things at
> random until I was able to produce a .hex file. (One of those things
was
> to make an entirely new project and replace Startup.s with the
default.)
> What is the best way to get that example project to build?
>
> My original cry for help
> on the Sparkfun
> forum has a few more details.
>
> The failed installs do show up at the end of my setupapi.log
> (I
posted
> the entire thing).
> I don't remember the exact sequence I went through, but it was
something
> like
> 1) Full install / crash
> 2) Disable
> 3) Re-enable / crash
> 4) Uninstall
> 5) Partial install / crash
> 6) Uninstall
> 7) More or less repeated the same steps on my laptop.
>
> Any suggestions greatly appreciated.
> -Hugh
> --- In l..., "t_chinzei" t_chinzei@ wrote:
> >
> > I tired it on my WinXP SP3 box, the VCP driver, PLP2KUS, was
installed
> without any problem.
> > On the installation, the new hardware dialog asks the location of
> PLP2KUS.sys, because this file isn't placed in the folder with the INF
> file. Just locating it on the file dialog, the install process
> successfully finishes. The installation occurs twice, for each VCP
> interface.
> >
> > On your side, is there any clue left on the setupapi.log (
> C:\Windows\setupapi.log )?
> >
> > - Delete (uninstall) the COM port(s) and composite device for
"Philips
> LPC2148 VCOM", if any, using USBDeview
> > - Just before plugging in the USB device, rename setupapi.log, for
> example, to setupapi0.log
> > - Plug in the USB device, and install the driver, as usual.
> > - A new setupapi.log is there, even after reboot.
> > The installation log of the USB device is placed at the first blocks
> of this new setupapi.log
> >
> > USBDeview
> > http://www.nirsoft.net/utils/usb_devices_view.html
> >
> > Tsuneo
> >
> > --- In l..., "hsutherland2@" hsutherland2@ wrote:
> > >
> > > Hello to the group. I'll introduce myself as a hobbyist at this
> point
> > > (although we _are_ using one Armite on a quasi-regular basis at
> work).
> > > Leon Heller mentioned this group in a post in the sparkfun forum,
> and I
> > > see some posts here by rtstofer (thanks again for your help in the
> > > gnuarm forum Richard).
> > >
> > >
> > > Has anyone here used the philips VCOM driver for the lpc2148 on
XP
> > > lately? It is included in the files for AN10420 on the philips
site.
> > > There is what appears to be an identical copy in the files section
> here.
> > > The crucial files appear to be PLP2KUS.inf and PLP2KUS.sys.
> > >
> > >
> > > I'm having serious problems trying to install it (reboot in
middle
> of
> > > install). Trying to figure out if I'm doing something terribly
> wrong, or
> > > if an XP update has torpedoed the driver, or...
> > >
> > > -Hugh
> > >
> >
>
Reply by ●July 20, 20092009-07-20
Tsuneo said:
> I recommend you to use Windows in-box device driver for
> VCOM, usbser.sys, instead. Surely, usbser.sys has some
> problems, but it's better than PLP2KUS.
Tsuneo knows of what he speaks! If you use usb.sersys and match
the requirements of the USB CDC class, you can make your product
work without any host drivers on Windows, Linux and OSX.
If this is what you need, I strongly suggest that you invest in
a USB analyser such as a Beagle 12. You will also need to be
very careful with the descriptors and .INF file for Windows.
Stephen
--
Stephen Pelc, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
> I recommend you to use Windows in-box device driver for
> VCOM, usbser.sys, instead. Surely, usbser.sys has some
> problems, but it's better than PLP2KUS.
Tsuneo knows of what he speaks! If you use usb.sersys and match
the requirements of the USB CDC class, you can make your product
work without any host drivers on Windows, Linux and OSX.
If this is what you need, I strongly suggest that you invest in
a USB analyser such as a Beagle 12. You will also need to be
very careful with the descriptors and .INF file for Windows.
Stephen
--
Stephen Pelc, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●July 20, 20092009-07-20
Stephen Pelc wrote:
>
>
> Tsuneo said:
>
> > I recommend you to use Windows in-box device driver for
> > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> > problems, but it's better than PLP2KUS.
>
> Tsuneo knows of what he speaks! If you use usb.sersys and match
> the requirements of the USB CDC class, you can make your product
> work without any host drivers on Windows, Linux and OSX.
I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
NXT pbLua firmware and it works great on all those platforms.
Ralph
>
>
> Tsuneo said:
>
> > I recommend you to use Windows in-box device driver for
> > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> > problems, but it's better than PLP2KUS.
>
> Tsuneo knows of what he speaks! If you use usb.sersys and match
> the requirements of the USB CDC class, you can make your product
> work without any host drivers on Windows, Linux and OSX.
I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
NXT pbLua firmware and it works great on all those platforms.
Ralph
Reply by ●July 20, 20092009-07-20
Have you managed to fix the problems of: ?
1) You connect to the device VCOM
2) Disconnect device
3) Connect it again...
4) Even if you close the VCOM you're unable to connect again...
I think it's an usbser.sys bug or limit because of it's architecture.
2009/7/20 Ralph Hempel :
> Stephen Pelc wrote:
>
>> Tsuneo said:
>>
>> > I recommend you to use Windows in-box device driver for
>> > VCOM, usbser.sys, instead. Surely, usbser.sys has some
>> > problems, but it's better than PLP2KUS.
>>
>> Tsuneo knows of what he speaks! If you use usb.sersys and match
>> the requirements of the USB CDC class, you can make your product
>> work without any host drivers on Windows, Linux and OSX.
>
> I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> NXT pbLua firmware and it works great on all those platforms.
>
> Ralph
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
1) You connect to the device VCOM
2) Disconnect device
3) Connect it again...
4) Even if you close the VCOM you're unable to connect again...
I think it's an usbser.sys bug or limit because of it's architecture.
2009/7/20 Ralph Hempel :
> Stephen Pelc wrote:
>
>> Tsuneo said:
>>
>> > I recommend you to use Windows in-box device driver for
>> > VCOM, usbser.sys, instead. Surely, usbser.sys has some
>> > problems, but it's better than PLP2KUS.
>>
>> Tsuneo knows of what he speaks! If you use usb.sersys and match
>> the requirements of the USB CDC class, you can make your product
>> work without any host drivers on Windows, Linux and OSX.
>
> I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> NXT pbLua firmware and it works great on all those platforms.
>
> Ralph
>
--
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
Reply by ●July 20, 20092009-07-20
Thank you for the guidance, Tsuneo, Stephen, and Ralph. Seems pointless
to waste time trying to figure out exactly where I went wrong building
the Philips app.
I see at least two more possibilities here in the lpc2000 group; one in
the files section and one in links.
* USBVCOM.c
clXuQC6JL51uOY4FxoY8nEHWWBX_q2F-Qfqap7R5nU16QhF-tp18K6RvRPyqL0C-opxSyLYg\
AlaN0/USBVCOM.c> by Mike Anton
* LPCUSB by Bertrik
Sikken
Can anyone comment on either of these as a starting point? For now, I
will be unlikely to want anything other than a virtual COM port.
-Hugh
(I hate to admit it but for the project I'm working on, FTDI is
beginning to look pretty good. Even though it would rankle to have those
USB ports on the 4148 sitting idle.)
--- In l..., Ralph Hempel wrote:
>
> Stephen Pelc wrote:
> >
> >
> > Tsuneo said:
> >
> > > I recommend you to use Windows in-box device driver for
> > > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> > > problems, but it's better than PLP2KUS.
> >
> > Tsuneo knows of what he speaks! If you use usb.sersys and match
> > the requirements of the USB CDC class, you can make your product
> > work without any host drivers on Windows, Linux and OSX.
>
> I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> NXT pbLua firmware and it works great on all those platforms.
>
> Ralph
>
to waste time trying to figure out exactly where I went wrong building
the Philips app.
I see at least two more possibilities here in the lpc2000 group; one in
the files section and one in links.
* USBVCOM.c
clXuQC6JL51uOY4FxoY8nEHWWBX_q2F-Qfqap7R5nU16QhF-tp18K6RvRPyqL0C-opxSyLYg\
AlaN0/USBVCOM.c> by Mike Anton
* LPCUSB by Bertrik
Sikken
Can anyone comment on either of these as a starting point? For now, I
will be unlikely to want anything other than a virtual COM port.
-Hugh
(I hate to admit it but for the project I'm working on, FTDI is
beginning to look pretty good. Even though it would rankle to have those
USB ports on the 4148 sitting idle.)
--- In l..., Ralph Hempel wrote:
>
> Stephen Pelc wrote:
> >
> >
> > Tsuneo said:
> >
> > > I recommend you to use Windows in-box device driver for
> > > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> > > problems, but it's better than PLP2KUS.
> >
> > Tsuneo knows of what he speaks! If you use usb.sersys and match
> > the requirements of the USB CDC class, you can make your product
> > work without any host drivers on Windows, Linux and OSX.
>
> I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> NXT pbLua firmware and it works great on all those platforms.
>
> Ralph
>
Reply by ●July 20, 20092009-07-20
> For now, I will be unlikely to want anything other
than a virtual COM
port.
Then, a USB-serial chip like FTDI FT232R, is an easy way.
FTDI distributes their reliable device driver on their web page.
http://www.ftdichip.com/Drivers/VCP.htm
On the device side, the chip communicates with your MCU over a UART.
Then, you can select any MCU, as long as it has an on-chip UART - most
of MCU has. Also, the programming of UART is much easier than USB :-)
For quick test, breakout boards are sold for this chip in many shops.
For example,
http://www.sparkfun.com/commerce/product_info.php?products_idq8
http://www.sparkfun.com/commerce/product_info.php?products_id72
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&namev8-101\
7-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&namev8-101\
8-ND
You may find one of breakout boards in your favorite local reseller,
because this chip is popular.
If you want to start your study on USB, or to extend the device
functions over USB, or to reduce the production cost (not the
development cost :-)) with single chip, CDC class implementation like
LPCUSB by Bertrik is the way. LPCUSB will give you good starting point
for your USB study.
Tsuneo
--- In l..., "hsutherland2@..."
wrote:
>
> Thank you for the guidance, Tsuneo, Stephen, and Ralph. Seems
pointless
> to waste time trying to figure out exactly where I went wrong building
> the Philips app.
>
> I see at least two more possibilities here in the lpc2000 group; one
in
> the files section and one in links.
>
> * USBVCOM.c
>
\
>
clXuQC6JL51uOY4FxoY8nEHWWBX_q2F-Qfqap7R5nU16QhF-tp18K6RvRPyqL0C-opxSyLYg\
\
> AlaN0/USBVCOM.c> by Mike Anton
> * LPCUSB by
Bertrik
> Sikken
> Can anyone comment on either of these as a starting point? For now, I
> will be unlikely to want anything other than a virtual COM port.
>
> -Hugh
> (I hate to admit it but for the project I'm working on, FTDI is
> beginning to look pretty good. Even though it would rankle to have
those
> USB ports on the 4148 sitting idle.)
>
> --- In l..., Ralph Hempel rhempel@ wrote:
> >
> > Stephen Pelc wrote:
> > >
> > >
> > > Tsuneo said:
> > >
> > > > I recommend you to use Windows in-box device driver for
> > > > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> > > > problems, but it's better than PLP2KUS.
> > >
> > > Tsuneo knows of what he speaks! If you use usb.sersys and match
> > > the requirements of the USB CDC class, you can make your product
> > > work without any host drivers on Windows, Linux and OSX.
> >
> > I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> > NXT pbLua firmware and it works great on all those platforms.
> >
> > Ralph
> >
>
port.
Then, a USB-serial chip like FTDI FT232R, is an easy way.
FTDI distributes their reliable device driver on their web page.
http://www.ftdichip.com/Drivers/VCP.htm
On the device side, the chip communicates with your MCU over a UART.
Then, you can select any MCU, as long as it has an on-chip UART - most
of MCU has. Also, the programming of UART is much easier than USB :-)
For quick test, breakout boards are sold for this chip in many shops.
For example,
http://www.sparkfun.com/commerce/product_info.php?products_idq8
http://www.sparkfun.com/commerce/product_info.php?products_id72
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&namev8-101\
7-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&namev8-101\
8-ND
You may find one of breakout boards in your favorite local reseller,
because this chip is popular.
If you want to start your study on USB, or to extend the device
functions over USB, or to reduce the production cost (not the
development cost :-)) with single chip, CDC class implementation like
LPCUSB by Bertrik is the way. LPCUSB will give you good starting point
for your USB study.
Tsuneo
--- In l..., "hsutherland2@..."
wrote:
>
> Thank you for the guidance, Tsuneo, Stephen, and Ralph. Seems
pointless
> to waste time trying to figure out exactly where I went wrong building
> the Philips app.
>
> I see at least two more possibilities here in the lpc2000 group; one
in
> the files section and one in links.
>
> * USBVCOM.c
>
\
>
clXuQC6JL51uOY4FxoY8nEHWWBX_q2F-Qfqap7R5nU16QhF-tp18K6RvRPyqL0C-opxSyLYg\
\
> AlaN0/USBVCOM.c> by Mike Anton
> * LPCUSB by
Bertrik
> Sikken
> Can anyone comment on either of these as a starting point? For now, I
> will be unlikely to want anything other than a virtual COM port.
>
> -Hugh
> (I hate to admit it but for the project I'm working on, FTDI is
> beginning to look pretty good. Even though it would rankle to have
those
> USB ports on the 4148 sitting idle.)
>
> --- In l..., Ralph Hempel rhempel@ wrote:
> >
> > Stephen Pelc wrote:
> > >
> > >
> > > Tsuneo said:
> > >
> > > > I recommend you to use Windows in-box device driver for
> > > > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> > > > problems, but it's better than PLP2KUS.
> > >
> > > Tsuneo knows of what he speaks! If you use usb.sersys and match
> > > the requirements of the USB CDC class, you can make your product
> > > work without any host drivers on Windows, Linux and OSX.
> >
> > I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> > NXT pbLua firmware and it works great on all those platforms.
> >
> > Ralph
> >
>
Reply by ●July 21, 20092009-07-21
> Have you managed to fix the problems of: ?
> 1) You connect to the device VCOM
> 2) Disconnect device
> 3) Connect it again...
> 4) Even if you close the VCOM you're unable to connect again...
On your PC application, detect connection / disconnection of the CDC
device.
- When a device is connected, open the port and start communication over
the port
- When a device is disconnected, close the port and stop communication
over the port
To detect connection / disconnection, there are two options,
a) Register device notification and get device message (WM_DEVICECHANGE)
b) Using SetupDi-API, poll the device connection periodically
a) Using WM_DEVICECHANGE notification
To register USB device for device notification, the interface GUID of
the device driver is required. Unfortunately, usbser.sys doesn't expose
any device interface (including GUID_DEVINTERFACE_COMPORT). Using
serenum.sys as the upper filter of usbser.sys,
GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR is available to specify
usbser.sys for notification.
You'll see many example INF files on the web, to attach serenum.sys upon
usbser.sys.
For example,
Make Controller USB CDC ACM Setup File
http://www.makingthings.com/files/temp/make_controller_kit.inf
GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR
http://msdn.microsoft.com/en-us/library/bb663066.aspx
Once the interface GUID is available, register it, and handle
WM_DEVICECHANGE message (DBT_DEVICEARRIVAL / DBT_DEVICEREMOVECOMPLETE)
as usual USB devices.
Jan Axelson shows a good example of WM_DEVICECHANGE handling for HID.
The outline for COM port is almost same as the code flow of this
example.
http://www.lvr.com/files/usbhidio_V2.3.cs.zip
- DeviceManagement.cs,
- DeviceManagementDeclarations.cs,
- frmMain.cs - OnDeviceChange()
b) Using SetupDi-API polling
In this post to Microchip forum, I posted an example to detect CDC
devices currently attached to the PC.
CDC_COM_port_lister.cpp
http://www.microchip.com/forums/tm.aspx?m64903
Run this procedure periodically, to detect attach / detach of CDC
devices.
In the source code of Mike Obrien's HID library, you'll find the idea -
how to run it periodically.
http://labs.mike-obrien.net/Document.aspx?id=hidlibrary
https://hidlibrary.svn.codeplex.com/svn/Library/HIDLibrary/HidDeviceEven\
tMonitor.vb
https://hidlibrary.svn.codeplex.com/svn/Library/HIDLibrary/HidDevices.vb
If you unplug a USB device and re-plug it quickly, Windows sometimes
fail to detect the re-connection. At least 2-3 seconds interval is
recommended before re-plug.
Tsuneo
--- In l..., Miguel Angel wrote:
>
> Have you managed to fix the problems of: ?
>
> 1) You connect to the device VCOM
> 2) Disconnect device
> 3) Connect it again...
> 4) Even if you close the VCOM you're unable to connect again...
> I think it's an usbser.sys bug or limit because of it's architecture.
>
> 2009/7/20 Ralph Hempel rhempel@...:
> >
> >
> > Stephen Pelc wrote:
> >
> >>
> >>
> >> Tsuneo said:
> >>
> >> > I recommend you to use Windows in-box device driver for
> >> > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> >> > problems, but it's better than PLP2KUS.
> >>
> >> Tsuneo knows of what he speaks! If you use usb.sersys and match
> >> the requirements of the USB CDC class, you can make your product
> >> work without any host drivers on Windows, Linux and OSX.
> >
> > I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> > NXT pbLua firmware and it works great on all those platforms.
> >
> > Ralph
> > --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
> 1) You connect to the device VCOM
> 2) Disconnect device
> 3) Connect it again...
> 4) Even if you close the VCOM you're unable to connect again...
On your PC application, detect connection / disconnection of the CDC
device.
- When a device is connected, open the port and start communication over
the port
- When a device is disconnected, close the port and stop communication
over the port
To detect connection / disconnection, there are two options,
a) Register device notification and get device message (WM_DEVICECHANGE)
b) Using SetupDi-API, poll the device connection periodically
a) Using WM_DEVICECHANGE notification
To register USB device for device notification, the interface GUID of
the device driver is required. Unfortunately, usbser.sys doesn't expose
any device interface (including GUID_DEVINTERFACE_COMPORT). Using
serenum.sys as the upper filter of usbser.sys,
GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR is available to specify
usbser.sys for notification.
You'll see many example INF files on the web, to attach serenum.sys upon
usbser.sys.
For example,
Make Controller USB CDC ACM Setup File
http://www.makingthings.com/files/temp/make_controller_kit.inf
GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR
http://msdn.microsoft.com/en-us/library/bb663066.aspx
Once the interface GUID is available, register it, and handle
WM_DEVICECHANGE message (DBT_DEVICEARRIVAL / DBT_DEVICEREMOVECOMPLETE)
as usual USB devices.
Jan Axelson shows a good example of WM_DEVICECHANGE handling for HID.
The outline for COM port is almost same as the code flow of this
example.
http://www.lvr.com/files/usbhidio_V2.3.cs.zip
- DeviceManagement.cs,
- DeviceManagementDeclarations.cs,
- frmMain.cs - OnDeviceChange()
b) Using SetupDi-API polling
In this post to Microchip forum, I posted an example to detect CDC
devices currently attached to the PC.
CDC_COM_port_lister.cpp
http://www.microchip.com/forums/tm.aspx?m64903
Run this procedure periodically, to detect attach / detach of CDC
devices.
In the source code of Mike Obrien's HID library, you'll find the idea -
how to run it periodically.
http://labs.mike-obrien.net/Document.aspx?id=hidlibrary
https://hidlibrary.svn.codeplex.com/svn/Library/HIDLibrary/HidDeviceEven\
tMonitor.vb
https://hidlibrary.svn.codeplex.com/svn/Library/HIDLibrary/HidDevices.vb
If you unplug a USB device and re-plug it quickly, Windows sometimes
fail to detect the re-connection. At least 2-3 seconds interval is
recommended before re-plug.
Tsuneo
--- In l..., Miguel Angel wrote:
>
> Have you managed to fix the problems of: ?
>
> 1) You connect to the device VCOM
> 2) Disconnect device
> 3) Connect it again...
> 4) Even if you close the VCOM you're unable to connect again...
> I think it's an usbser.sys bug or limit because of it's architecture.
>
> 2009/7/20 Ralph Hempel rhempel@...:
> >
> >
> > Stephen Pelc wrote:
> >
> >>
> >>
> >> Tsuneo said:
> >>
> >> > I recommend you to use Windows in-box device driver for
> >> > VCOM, usbser.sys, instead. Surely, usbser.sys has some
> >> > problems, but it's better than PLP2KUS.
> >>
> >> Tsuneo knows of what he speaks! If you use usb.sersys and match
> >> the requirements of the USB CDC class, you can make your product
> >> work without any host drivers on Windows, Linux and OSX.
> >
> > I'll second that. I use the default CDC driver in my LEGO MINDSTORMS
> > NXT pbLua firmware and it works great on all those platforms.
> >
> > Ralph
> > --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
