This explanation was really useful. I used the WM_DEVICECHANGE mechanism
for other usb devices, but I didn't know that it was possible to use
it with CDC this way.
Thank you Tsuneo!,
Really! :)
2009/7/21 t_chinzei : >> 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
>>
--
Miguel Angel Ajo Pelayo http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of h...@sbcglobal.net
> Sent: Monday, July 20, 2009 5:20 PM
> To: l...
> Subject: [lpc2000] Re: new member - philips VCOM driver question
> 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
>
> 38CkN6IcsO\
> clXuQC6JL51uOY4FxoY8nEHWWBX_q2F-Qfqap7R5nU16QhF-tp18K6RvRPyqL0
> C-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.
>
I submitted the USBVCOM.c file to the group. It is based on the
VCOM files from LPCUSB. I modified it to improve performance, and
so that it behaves more like a standard USART. You will need to use
it along with the other LPCUSB files to make it work.
LPCUSB is a general purpose USB stack, and as such can be used as
the driver for many USB devices. VCOM is just one of the device
types that it supports. I've used it for MSC as well, and it works
very well for both devices.
Mike Anton
Reply by Stephen Pelc●July 21, 20092009-07-21
> 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.
I can't comment on the first, but Bertrik's code is good, easy
to read, and well factored.
> (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.)
The other reason to use an FTDI device is to reduce the CPU load
and to reduce interrupt overhead. Unless you use DMA (strongly
recommended), the interrupt overhead can be much more than you
expect. Using DMA adds its own wrinkles, but makes later
expansion to a Mass Storage Class device (FlashDrive) much
easier.
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 t_chinzei●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
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 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
>
Reply by t_chinzei●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 :-)
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 "hsu...@sbcglobal.net"●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
>
Reply by Miguel Angel●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
Reply by Ralph Hempel●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
Reply by Stephen Pelc●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
Reply by t_chinzei●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.
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
> > >
> >
>
