Hi,
I'm working on a handheld equipment running on AT91SAM7XC512. Currently we
use USB CDC class to realize virtual COM communications with host, everything is
working fine after some modification to ATMEL USB Framework. But the data rate
of virtual COM is a little bit low, because we need to download chunk of data
from the device to host.
We plan to migrate to USB class with higher speed. We need the application on
the host to configure the handheld equipment, get configuration from it, issue
command to it to do something, and get data from SD card inserted in the device.
By the way we use proprietary protocol to talk with each other and the device
interprets and executes commands and returns result to host, so simply what we
need is transparent USB transportation, we can write bytes to buffer and send
via USB, and read bytes from buffer when packets received. The key point is we
wanna use generic drivers that Windows has already provided, namely, real
plug'n'play, and the application will take care of interpretation of
various commands.
Which class should we use?
Thanks.
Jeremy
USB class choice for AT91SAM7XC USB interface
Started by ●May 6, 2009
Reply by ●May 7, 20092009-05-07
On Thu, May 7, 2009 at 9:09 AM, jeremywang2008
wrote:
> The key point is we wanna use generic drivers that Windows has already
> provided, namely, real plug'n'play, and the application will take care of
> interpretation of various commands.
>
> Which class should we use?
>
Firstly CDC-ACM is not really plug and play and you still need to have
your own INF file provided. Maybe HID + MSD composite device?
The MSD interface can be configured to transfer data. The HID
interface can be configured to transfer the command and response
data.
--
Xiaofan http://mcuee.blogspot.com
wrote:
> The key point is we wanna use generic drivers that Windows has already
> provided, namely, real plug'n'play, and the application will take care of
> interpretation of various commands.
>
> Which class should we use?
>
Firstly CDC-ACM is not really plug and play and you still need to have
your own INF file provided. Maybe HID + MSD composite device?
The MSD interface can be configured to transfer data. The HID
interface can be configured to transfer the command and response
data.
--
Xiaofan http://mcuee.blogspot.com
Reply by ●May 7, 20092009-05-07
Hi,
what speeds do you get with CDC? When transferring data to the host it
can be quite quick. The opposite direction has problems because the
default CDC driver on the PC (windows XP) does not send short packets
to close the transfer when needed. Thus you can receive only one
packet with one transfer. But there is a windows (XP) update for this
(KB943198). You can also use timeouts on the embedded side to overcome
this. (If no data is received for a period close the transfer.) The
second solution is to implement some kind of protocol. First you send
a command telling the length of the data filed. The you send the data.
You can add extra bytes if the short packet is needed. These can be
ignored by the embedded side based on the length received in the
command phase.
I had good speed results when not using a terminal program for
testing. Try "copy some_text_file.txt COMn" in a command window. This
results in 100% USB band width usage if your device is fast enough.
If you want to get rid of CDC go for mass-storage. You can use vendor
specific SCSI commands to implement special functionality.
(http://msdn.microsoft.com/en-gb/library/ms810309.aspx) It seems you
can send these even from user space using DeviceIoControl
(DeviceIoControl
check
this too example code
).
You can go the UNIX way and add some special "virtual" files to the
mass-storage device. Data read/written to these can be feed to your
command processor. This needs no special drivers on windows side, but
needs additional code on the SAM7. More dirty but easier to implement
is to make some special sectors at the end of the mass-storage media.
Any read or write will fail on these except if you unlock them with a
special pattern written. After unlocked read/write to these sectors
feed/get data from your command processor. When the media is
formatted, windows will mark the special sector as a bad block and
will not use it for the file system. You can access the special
sectors from user space using sector read/write.
Foltos
jeremywang2008 wrote:
> Hi,
>
> I'm working on a handheld equipment running on AT91SAM7XC512.
> Currently we use USB CDC class to realize virtual COM communications
> with host, everything is working fine after some modification to
> ATMEL USB Framework. But the data rate of virtual COM is a little
> bit low, because we need to download chunk of data from the device
> to host.
>
> We plan to migrate to USB class with higher speed. We need the
> application on the host to configure the handheld equipment, get
> configuration from it, issue command to it to do something, and get
> data from SD card inserted in the device. By the way we use
> proprietary protocol to talk with each other and the device
> interprets and executes commands and returns result to host, so
> simply what we need is transparent USB transportation, we can write
> bytes to buffer and send via USB, and read bytes from buffer when
> packets received. The key point is we wanna use generic drivers that
> Windows has already provided, namely, real plug'n'play, and the
> application will take care of interpretation of various commands.
>
> Which class should we use?
>
> Thanks.
>
> Jeremy
>
what speeds do you get with CDC? When transferring data to the host it
can be quite quick. The opposite direction has problems because the
default CDC driver on the PC (windows XP) does not send short packets
to close the transfer when needed. Thus you can receive only one
packet with one transfer. But there is a windows (XP) update for this
(KB943198). You can also use timeouts on the embedded side to overcome
this. (If no data is received for a period close the transfer.) The
second solution is to implement some kind of protocol. First you send
a command telling the length of the data filed. The you send the data.
You can add extra bytes if the short packet is needed. These can be
ignored by the embedded side based on the length received in the
command phase.
I had good speed results when not using a terminal program for
testing. Try "copy some_text_file.txt COMn" in a command window. This
results in 100% USB band width usage if your device is fast enough.
If you want to get rid of CDC go for mass-storage. You can use vendor
specific SCSI commands to implement special functionality.
(http://msdn.microsoft.com/en-gb/library/ms810309.aspx) It seems you
can send these even from user space using DeviceIoControl
(DeviceIoControl
check
this too example code
).
You can go the UNIX way and add some special "virtual" files to the
mass-storage device. Data read/written to these can be feed to your
command processor. This needs no special drivers on windows side, but
needs additional code on the SAM7. More dirty but easier to implement
is to make some special sectors at the end of the mass-storage media.
Any read or write will fail on these except if you unlock them with a
special pattern written. After unlocked read/write to these sectors
feed/get data from your command processor. When the media is
formatted, windows will mark the special sector as a bad block and
will not use it for the file system. You can access the special
sectors from user space using sector read/write.
Foltos
jeremywang2008 wrote:
> Hi,
>
> I'm working on a handheld equipment running on AT91SAM7XC512.
> Currently we use USB CDC class to realize virtual COM communications
> with host, everything is working fine after some modification to
> ATMEL USB Framework. But the data rate of virtual COM is a little
> bit low, because we need to download chunk of data from the device
> to host.
>
> We plan to migrate to USB class with higher speed. We need the
> application on the host to configure the handheld equipment, get
> configuration from it, issue command to it to do something, and get
> data from SD card inserted in the device. By the way we use
> proprietary protocol to talk with each other and the device
> interprets and executes commands and returns result to host, so
> simply what we need is transparent USB transportation, we can write
> bytes to buffer and send via USB, and read bytes from buffer when
> packets received. The key point is we wanna use generic drivers that
> Windows has already provided, namely, real plug'n'play, and the
> application will take care of interpretation of various commands.
>
> Which class should we use?
>
> Thanks.
>
> Jeremy
>
Reply by ●May 7, 20092009-05-07
Thank you very much for your valuable information, Foltos.
Due to the constraints of our application, the current CDC speed is just 115K. Another reason why we wanna leave CDC is it still needs a customized 6119.inf, and in some cases the virtual COM port won't work properly, as I explained in the rely to Chen.
I've done some reserch on Mass Storage Class, my concern was it'll operate based on drive, so how I can feed commands to application. Now I like your solution of virtual files, and probably I'll try this.
By the way, how about HID? It's a pretty generic class, a lot of devices can go to this class, like point-of-sales, medical equipment, etc. Our device is a little similar to POS, and we also scan tags. But I'm wondering, except for keyboard and mouse which are plug'n'play, do we need to provide vendor-specific driver?
Regards
Jeremy
--- In A..., Foltos wrote:
>
> Hi,
>
> what speeds do you get with CDC? When transferring data to the host it
> can be quite quick. The opposite direction has problems because the
> default CDC driver on the PC (windows XP) does not send short packets
> to close the transfer when needed. Thus you can receive only one
> packet with one transfer. But there is a windows (XP) update for this
> (KB943198). You can also use timeouts on the embedded side to overcome
> this. (If no data is received for a period close the transfer.) The
> second solution is to implement some kind of protocol. First you send
> a command telling the length of the data filed. The you send the data.
> You can add extra bytes if the short packet is needed. These can be
> ignored by the embedded side based on the length received in the
> command phase.
> I had good speed results when not using a terminal program for
> testing. Try "copy some_text_file.txt COMn" in a command window. This
> results in 100% USB band width usage if your device is fast enough.
>
> If you want to get rid of CDC go for mass-storage. You can use vendor
> specific SCSI commands to implement special functionality.
> (http://msdn.microsoft.com/en-gb/library/ms810309.aspx) It seems you
> can send these even from user space using DeviceIoControl
> (DeviceIoControl
> check
> this too example code
> ).
>
> You can go the UNIX way and add some special "virtual" files to the
> mass-storage device. Data read/written to these can be feed to your
> command processor. This needs no special drivers on windows side, but
> needs additional code on the SAM7. More dirty but easier to implement
> is to make some special sectors at the end of the mass-storage media.
> Any read or write will fail on these except if you unlock them with a
> special pattern written. After unlocked read/write to these sectors
> feed/get data from your command processor. When the media is
> formatted, windows will mark the special sector as a bad block and
> will not use it for the file system. You can access the special
> sectors from user space using sector read/write.
>
> Foltos
>
> jeremywang2008 wrote:
> >
> >
> > Hi,
> >
> > I'm working on a handheld equipment running on AT91SAM7XC512.
> > Currently we use USB CDC class to realize virtual COM communications
> > with host, everything is working fine after some modification to
> > ATMEL USB Framework. But the data rate of virtual COM is a little
> > bit low, because we need to download chunk of data from the device
> > to host.
> >
> > We plan to migrate to USB class with higher speed. We need the
> > application on the host to configure the handheld equipment, get
> > configuration from it, issue command to it to do something, and get
> > data from SD card inserted in the device. By the way we use
> > proprietary protocol to talk with each other and the device
> > interprets and executes commands and returns result to host, so
> > simply what we need is transparent USB transportation, we can write
> > bytes to buffer and send via USB, and read bytes from buffer when
> > packets received. The key point is we wanna use generic drivers that
> > Windows has already provided, namely, real plug'n'play, and the
> > application will take care of interpretation of various commands.
> >
> > Which class should we use?
> >
> > Thanks.
> >
> > Jeremy
> >
> >
> >
Due to the constraints of our application, the current CDC speed is just 115K. Another reason why we wanna leave CDC is it still needs a customized 6119.inf, and in some cases the virtual COM port won't work properly, as I explained in the rely to Chen.
I've done some reserch on Mass Storage Class, my concern was it'll operate based on drive, so how I can feed commands to application. Now I like your solution of virtual files, and probably I'll try this.
By the way, how about HID? It's a pretty generic class, a lot of devices can go to this class, like point-of-sales, medical equipment, etc. Our device is a little similar to POS, and we also scan tags. But I'm wondering, except for keyboard and mouse which are plug'n'play, do we need to provide vendor-specific driver?
Regards
Jeremy
--- In A..., Foltos wrote:
>
> Hi,
>
> what speeds do you get with CDC? When transferring data to the host it
> can be quite quick. The opposite direction has problems because the
> default CDC driver on the PC (windows XP) does not send short packets
> to close the transfer when needed. Thus you can receive only one
> packet with one transfer. But there is a windows (XP) update for this
> (KB943198). You can also use timeouts on the embedded side to overcome
> this. (If no data is received for a period close the transfer.) The
> second solution is to implement some kind of protocol. First you send
> a command telling the length of the data filed. The you send the data.
> You can add extra bytes if the short packet is needed. These can be
> ignored by the embedded side based on the length received in the
> command phase.
> I had good speed results when not using a terminal program for
> testing. Try "copy some_text_file.txt COMn" in a command window. This
> results in 100% USB band width usage if your device is fast enough.
>
> If you want to get rid of CDC go for mass-storage. You can use vendor
> specific SCSI commands to implement special functionality.
> (http://msdn.microsoft.com/en-gb/library/ms810309.aspx) It seems you
> can send these even from user space using DeviceIoControl
> (DeviceIoControl
> check
> this too example code
> ).
>
> You can go the UNIX way and add some special "virtual" files to the
> mass-storage device. Data read/written to these can be feed to your
> command processor. This needs no special drivers on windows side, but
> needs additional code on the SAM7. More dirty but easier to implement
> is to make some special sectors at the end of the mass-storage media.
> Any read or write will fail on these except if you unlock them with a
> special pattern written. After unlocked read/write to these sectors
> feed/get data from your command processor. When the media is
> formatted, windows will mark the special sector as a bad block and
> will not use it for the file system. You can access the special
> sectors from user space using sector read/write.
>
> Foltos
>
> jeremywang2008 wrote:
> >
> >
> > Hi,
> >
> > I'm working on a handheld equipment running on AT91SAM7XC512.
> > Currently we use USB CDC class to realize virtual COM communications
> > with host, everything is working fine after some modification to
> > ATMEL USB Framework. But the data rate of virtual COM is a little
> > bit low, because we need to download chunk of data from the device
> > to host.
> >
> > We plan to migrate to USB class with higher speed. We need the
> > application on the host to configure the handheld equipment, get
> > configuration from it, issue command to it to do something, and get
> > data from SD card inserted in the device. By the way we use
> > proprietary protocol to talk with each other and the device
> > interprets and executes commands and returns result to host, so
> > simply what we need is transparent USB transportation, we can write
> > bytes to buffer and send via USB, and read bytes from buffer when
> > packets received. The key point is we wanna use generic drivers that
> > Windows has already provided, namely, real plug'n'play, and the
> > application will take care of interpretation of various commands.
> >
> > Which class should we use?
> >
> > Thanks.
> >
> > Jeremy
> >
> >
> >
Reply by ●May 7, 20092009-05-07
Hi,
no, you don't need vendor specific drivers for HID (only 3 library
files from the DDK). But transfer rate is limited. "Normal" reports
are read over the interrupt endpoint and sent over the control channel
or over the optional interrupt endpoint. The interrupt endpoint can
transfer one packet each frame. Thus maximum 64 bytes/ms. If you use
feature reports, then these are transferred over the control channel
in both direction. Speed can be still an issue since the spec only
requires the host to allocate 10% of the bandwidth to the control
channel. Also some full speed host controllers (UHCI) need at least 3
mS for a control transfer. If you send small amount of data may times,
then speed can be an issue again. Of course if the bus is not busy you
will get more bandwidth than 10% but since you will also have a
mass-storage interface working in parallel, if large files are copied
don't expect to see more than 10% (maybe not even that).
Foltos
jeremywang2008 wrote:
> Thank you very much for your valuable information, Foltos.
>
> Due to the constraints of our application, the current CDC speed is
> just 115K. Another reason why we wanna leave CDC is it still needs a
> customized 6119.inf, and in some cases the virtual COM port won't
> work properly, as I explained in the rely to Chen.
>
> I've done some reserch on Mass Storage Class, my concern was it'll
> operate based on drive, so how I can feed commands to application.
> Now I like your solution of virtual files, and probably I'll try this.
>
> By the way, how about HID? It's a pretty generic class, a lot of
> devices can go to this class, like point-of-sales, medical
> equipment, etc. Our device is a little similar to POS, and we also
> scan tags. But I'm wondering, except for keyboard and mouse which
> are plug'n'play, do we need to provide vendor-specific driver?
>
> Regards
>
> Jeremy
>
> --- In A... ,
> Foltos wrote:
> >
> > Hi,
> >
> > what speeds do you get with CDC? When transferring data to the host it
> > can be quite quick. The opposite direction has problems because the
> > default CDC driver on the PC (windows XP) does not send short packets
> > to close the transfer when needed. Thus you can receive only one
> > packet with one transfer. But there is a windows (XP) update for this
> > (KB943198). You can also use timeouts on the embedded side to overcome
> > this. (If no data is received for a period close the transfer.) The
> > second solution is to implement some kind of protocol. First you send
> > a command telling the length of the data filed. The you send the data.
> > You can add extra bytes if the short packet is needed. These can be
> > ignored by the embedded side based on the length received in the
> > command phase.
> > I had good speed results when not using a terminal program for
> > testing. Try "copy some_text_file.txt COMn" in a command window. This
> > results in 100% USB band width usage if your device is fast enough.
> >
> > If you want to get rid of CDC go for mass-storage. You can use vendor
> > specific SCSI commands to implement special functionality.
> > (http://msdn.microsoft.com/en-gb/library/ms810309.aspx
> ) It seems you
> > can send these even from user space using DeviceIoControl
> > (DeviceIoControl
> > > (VS.85).aspx> check
> > this too example code
> > > (VS.85).aspx>).
> >
> > You can go the UNIX way and add some special "virtual" files to the
> > mass-storage device. Data read/written to these can be feed to your
> > command processor. This needs no special drivers on windows side, but
> > needs additional code on the SAM7. More dirty but easier to implement
> > is to make some special sectors at the end of the mass-storage media.
> > Any read or write will fail on these except if you unlock them with a
> > special pattern written. After unlocked read/write to these sectors
> > feed/get data from your command processor. When the media is
> > formatted, windows will mark the special sector as a bad block and
> > will not use it for the file system. You can access the special
> > sectors from user space using sector read/write.
> >
> > Foltos
> >
> > jeremywang2008 wrote:
> > >
> > >
> > > Hi,
> > >
> > > I'm working on a handheld equipment running on AT91SAM7XC512.
> > > Currently we use USB CDC class to realize virtual COM communications
> > > with host, everything is working fine after some modification to
> > > ATMEL USB Framework. But the data rate of virtual COM is a little
> > > bit low, because we need to download chunk of data from the device
> > > to host.
> > >
> > > We plan to migrate to USB class with higher speed. We need the
> > > application on the host to configure the handheld equipment, get
> > > configuration from it, issue command to it to do something, and get
> > > data from SD card inserted in the device. By the way we use
> > > proprietary protocol to talk with each other and the device
> > > interprets and executes commands and returns result to host, so
> > > simply what we need is transparent USB transportation, we can write
> > > bytes to buffer and send via USB, and read bytes from buffer when
> > > packets received. The key point is we wanna use generic drivers that
> > > Windows has already provided, namely, real plug'n'play, and the
> > > application will take care of interpretation of various commands.
> > >
> > > Which class should we use?
> > >
> > > Thanks.
> > >
> > > Jeremy
> > >
>
no, you don't need vendor specific drivers for HID (only 3 library
files from the DDK). But transfer rate is limited. "Normal" reports
are read over the interrupt endpoint and sent over the control channel
or over the optional interrupt endpoint. The interrupt endpoint can
transfer one packet each frame. Thus maximum 64 bytes/ms. If you use
feature reports, then these are transferred over the control channel
in both direction. Speed can be still an issue since the spec only
requires the host to allocate 10% of the bandwidth to the control
channel. Also some full speed host controllers (UHCI) need at least 3
mS for a control transfer. If you send small amount of data may times,
then speed can be an issue again. Of course if the bus is not busy you
will get more bandwidth than 10% but since you will also have a
mass-storage interface working in parallel, if large files are copied
don't expect to see more than 10% (maybe not even that).
Foltos
jeremywang2008 wrote:
> Thank you very much for your valuable information, Foltos.
>
> Due to the constraints of our application, the current CDC speed is
> just 115K. Another reason why we wanna leave CDC is it still needs a
> customized 6119.inf, and in some cases the virtual COM port won't
> work properly, as I explained in the rely to Chen.
>
> I've done some reserch on Mass Storage Class, my concern was it'll
> operate based on drive, so how I can feed commands to application.
> Now I like your solution of virtual files, and probably I'll try this.
>
> By the way, how about HID? It's a pretty generic class, a lot of
> devices can go to this class, like point-of-sales, medical
> equipment, etc. Our device is a little similar to POS, and we also
> scan tags. But I'm wondering, except for keyboard and mouse which
> are plug'n'play, do we need to provide vendor-specific driver?
>
> Regards
>
> Jeremy
>
> --- In A... ,
> Foltos wrote:
> >
> > Hi,
> >
> > what speeds do you get with CDC? When transferring data to the host it
> > can be quite quick. The opposite direction has problems because the
> > default CDC driver on the PC (windows XP) does not send short packets
> > to close the transfer when needed. Thus you can receive only one
> > packet with one transfer. But there is a windows (XP) update for this
> > (KB943198). You can also use timeouts on the embedded side to overcome
> > this. (If no data is received for a period close the transfer.) The
> > second solution is to implement some kind of protocol. First you send
> > a command telling the length of the data filed. The you send the data.
> > You can add extra bytes if the short packet is needed. These can be
> > ignored by the embedded side based on the length received in the
> > command phase.
> > I had good speed results when not using a terminal program for
> > testing. Try "copy some_text_file.txt COMn" in a command window. This
> > results in 100% USB band width usage if your device is fast enough.
> >
> > If you want to get rid of CDC go for mass-storage. You can use vendor
> > specific SCSI commands to implement special functionality.
> > (http://msdn.microsoft.com/en-gb/library/ms810309.aspx
> ) It seems you
> > can send these even from user space using DeviceIoControl
> > (DeviceIoControl
> > > (VS.85).aspx> check
> > this too example code
> > > (VS.85).aspx>).
> >
> > You can go the UNIX way and add some special "virtual" files to the
> > mass-storage device. Data read/written to these can be feed to your
> > command processor. This needs no special drivers on windows side, but
> > needs additional code on the SAM7. More dirty but easier to implement
> > is to make some special sectors at the end of the mass-storage media.
> > Any read or write will fail on these except if you unlock them with a
> > special pattern written. After unlocked read/write to these sectors
> > feed/get data from your command processor. When the media is
> > formatted, windows will mark the special sector as a bad block and
> > will not use it for the file system. You can access the special
> > sectors from user space using sector read/write.
> >
> > Foltos
> >
> > jeremywang2008 wrote:
> > >
> > >
> > > Hi,
> > >
> > > I'm working on a handheld equipment running on AT91SAM7XC512.
> > > Currently we use USB CDC class to realize virtual COM communications
> > > with host, everything is working fine after some modification to
> > > ATMEL USB Framework. But the data rate of virtual COM is a little
> > > bit low, because we need to download chunk of data from the device
> > > to host.
> > >
> > > We plan to migrate to USB class with higher speed. We need the
> > > application on the host to configure the handheld equipment, get
> > > configuration from it, issue command to it to do something, and get
> > > data from SD card inserted in the device. By the way we use
> > > proprietary protocol to talk with each other and the device
> > > interprets and executes commands and returns result to host, so
> > > simply what we need is transparent USB transportation, we can write
> > > bytes to buffer and send via USB, and read bytes from buffer when
> > > packets received. The key point is we wanna use generic drivers that
> > > Windows has already provided, namely, real plug'n'play, and the
> > > application will take care of interpretation of various commands.
> > >
> > > Which class should we use?
> > >
> > > Thanks.
> > >
> > > Jeremy
> > >
>
Reply by ●May 7, 20092009-05-07
--- In A..., Xiaofan Chen wrote:
>
> On Thu, May 7, 2009 at 9:09 AM, jeremywang2008
> wrote:
> > The key point is we wanna use generic drivers that Windows has already
> > provided, namely, real plug'n'play, and the application will take care of
> > interpretation of various commands.
> >
> > Which class should we use?
> > Firstly CDC-ACM is not really plug and play and you still need to have
> your own INF file provided. Maybe HID + MSD composite device?
> The MSD interface can be configured to transfer data. The HID
> interface can be configured to transfer the command and response
> data.
>
> --
> Xiaofan http://mcuee.blogspot.com
>
Thanks, Xiaofan.
Yes, you're right, CDC needs modified 6119.inf. Furthermore, because the virtual COM port number is generated automatically by the operating system, sometimes could be COM16 or more. We have feedback from customers that the virtual COM port just doesn't work, because our application loops all COM ports to detect connected our device, and if the virtual COM port number is not the first COM port of this kind of similar interfaces, it won't work properly. Of course, we can change the port number to a small number manually to solve this problem, but for some end user, it's not easy. That's why we wanna get rid of CDC besides of it's lower speed.
Probably HID + MSD is not necessary, and I believe either one of them works, and I'd like to know which one is easier to implement.
Regards,
Jeremy
>
> On Thu, May 7, 2009 at 9:09 AM, jeremywang2008
> wrote:
> > The key point is we wanna use generic drivers that Windows has already
> > provided, namely, real plug'n'play, and the application will take care of
> > interpretation of various commands.
> >
> > Which class should we use?
> > Firstly CDC-ACM is not really plug and play and you still need to have
> your own INF file provided. Maybe HID + MSD composite device?
> The MSD interface can be configured to transfer data. The HID
> interface can be configured to transfer the command and response
> data.
>
> --
> Xiaofan http://mcuee.blogspot.com
>
Thanks, Xiaofan.
Yes, you're right, CDC needs modified 6119.inf. Furthermore, because the virtual COM port number is generated automatically by the operating system, sometimes could be COM16 or more. We have feedback from customers that the virtual COM port just doesn't work, because our application loops all COM ports to detect connected our device, and if the virtual COM port number is not the first COM port of this kind of similar interfaces, it won't work properly. Of course, we can change the port number to a small number manually to solve this problem, but for some end user, it's not easy. That's why we wanna get rid of CDC besides of it's lower speed.
Probably HID + MSD is not necessary, and I believe either one of them works, and I'd like to know which one is easier to implement.
Regards,
Jeremy
Reply by ●May 7, 20092009-05-07
I got your points. I've gone through the HID v1.11 document, and noticed it
doesn't use bulk endpoint, probably, HID class is used for control, not for
transfering chunk of data.
I really appreciate your comments, Foltos.
Cheers,
Jeremy
--- In A..., Foltos wrote:
>
> Hi,
>
> no, you don't need vendor specific drivers for HID (only 3 library
> files from the DDK). But transfer rate is limited. "Normal" reports
> are read over the interrupt endpoint and sent over the control channel
> or over the optional interrupt endpoint. The interrupt endpoint can
> transfer one packet each frame. Thus maximum 64 bytes/ms. If you use
> feature reports, then these are transferred over the control channel
> in both direction. Speed can be still an issue since the spec only
> requires the host to allocate 10% of the bandwidth to the control
> channel. Also some full speed host controllers (UHCI) need at least 3
> mS for a control transfer. If you send small amount of data may times,
> then speed can be an issue again. Of course if the bus is not busy you
> will get more bandwidth than 10% but since you will also have a
> mass-storage interface working in parallel, if large files are copied
> don't expect to see more than 10% (maybe not even that).
>
> Foltos
>
> jeremywang2008 wrote:
> >
> >
> > Thank you very much for your valuable information, Foltos.
> >
> > Due to the constraints of our application, the current CDC speed is
> > just 115K. Another reason why we wanna leave CDC is it still needs a
> > customized 6119.inf, and in some cases the virtual COM port won't
> > work properly, as I explained in the rely to Chen.
> >
> > I've done some reserch on Mass Storage Class, my concern was it'll
> > operate based on drive, so how I can feed commands to application.
> > Now I like your solution of virtual files, and probably I'll try this.
> >
> > By the way, how about HID? It's a pretty generic class, a lot of
> > devices can go to this class, like point-of-sales, medical
> > equipment, etc. Our device is a little similar to POS, and we also
> > scan tags. But I'm wondering, except for keyboard and mouse which
> > are plug'n'play, do we need to provide vendor-specific driver?
> >
> > Regards
> >
> > Jeremy
> >
> > --- In A... ,
> > Foltos wrote:
> > >
> > > Hi,
> > >
> > > what speeds do you get with CDC? When transferring data to the host it
> > > can be quite quick. The opposite direction has problems because the
> > > default CDC driver on the PC (windows XP) does not send short packets
> > > to close the transfer when needed. Thus you can receive only one
> > > packet with one transfer. But there is a windows (XP) update for this
> > > (KB943198). You can also use timeouts on the embedded side to overcome
> > > this. (If no data is received for a period close the transfer.) The
> > > second solution is to implement some kind of protocol. First you send
> > > a command telling the length of the data filed. The you send the data.
> > > You can add extra bytes if the short packet is needed. These can be
> > > ignored by the embedded side based on the length received in the
> > > command phase.
> > > I had good speed results when not using a terminal program for
> > > testing. Try "copy some_text_file.txt COMn" in a command window. This
> > > results in 100% USB band width usage if your device is fast enough.
> > >
> > > If you want to get rid of CDC go for mass-storage. You can use vendor
> > > specific SCSI commands to implement special functionality.
> > > (http://msdn.microsoft.com/en-gb/library/ms810309.aspx
> > ) It seems you
> > > can send these even from user space using DeviceIoControl
> > > (DeviceIoControl
> > > > > (VS.85).aspx> check
> > > this too example code
> > > > > (VS.85).aspx>).
> > >
> > > You can go the UNIX way and add some special "virtual" files to the
> > > mass-storage device. Data read/written to these can be feed to your
> > > command processor. This needs no special drivers on windows side, but
> > > needs additional code on the SAM7. More dirty but easier to implement
> > > is to make some special sectors at the end of the mass-storage media.
> > > Any read or write will fail on these except if you unlock them with a
> > > special pattern written. After unlocked read/write to these sectors
> > > feed/get data from your command processor. When the media is
> > > formatted, windows will mark the special sector as a bad block and
> > > will not use it for the file system. You can access the special
> > > sectors from user space using sector read/write.
> > >
> > > Foltos
> > >
> > > jeremywang2008 wrote:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'm working on a handheld equipment running on AT91SAM7XC512.
> > > > Currently we use USB CDC class to realize virtual COM communications
> > > > with host, everything is working fine after some modification to
> > > > ATMEL USB Framework. But the data rate of virtual COM is a little
> > > > bit low, because we need to download chunk of data from the device
> > > > to host.
> > > >
> > > > We plan to migrate to USB class with higher speed. We need the
> > > > application on the host to configure the handheld equipment, get
> > > > configuration from it, issue command to it to do something, and get
> > > > data from SD card inserted in the device. By the way we use
> > > > proprietary protocol to talk with each other and the device
> > > > interprets and executes commands and returns result to host, so
> > > > simply what we need is transparent USB transportation, we can write
> > > > bytes to buffer and send via USB, and read bytes from buffer when
> > > > packets received. The key point is we wanna use generic drivers that
> > > > Windows has already provided, namely, real plug'n'play, and the
> > > > application will take care of interpretation of various commands.
> > > >
> > > > Which class should we use?
> > > >
> > > > Thanks.
> > > >
> > > > Jeremy
> > > >
> >
> >
> >
I really appreciate your comments, Foltos.
Cheers,
Jeremy
--- In A..., Foltos wrote:
>
> Hi,
>
> no, you don't need vendor specific drivers for HID (only 3 library
> files from the DDK). But transfer rate is limited. "Normal" reports
> are read over the interrupt endpoint and sent over the control channel
> or over the optional interrupt endpoint. The interrupt endpoint can
> transfer one packet each frame. Thus maximum 64 bytes/ms. If you use
> feature reports, then these are transferred over the control channel
> in both direction. Speed can be still an issue since the spec only
> requires the host to allocate 10% of the bandwidth to the control
> channel. Also some full speed host controllers (UHCI) need at least 3
> mS for a control transfer. If you send small amount of data may times,
> then speed can be an issue again. Of course if the bus is not busy you
> will get more bandwidth than 10% but since you will also have a
> mass-storage interface working in parallel, if large files are copied
> don't expect to see more than 10% (maybe not even that).
>
> Foltos
>
> jeremywang2008 wrote:
> >
> >
> > Thank you very much for your valuable information, Foltos.
> >
> > Due to the constraints of our application, the current CDC speed is
> > just 115K. Another reason why we wanna leave CDC is it still needs a
> > customized 6119.inf, and in some cases the virtual COM port won't
> > work properly, as I explained in the rely to Chen.
> >
> > I've done some reserch on Mass Storage Class, my concern was it'll
> > operate based on drive, so how I can feed commands to application.
> > Now I like your solution of virtual files, and probably I'll try this.
> >
> > By the way, how about HID? It's a pretty generic class, a lot of
> > devices can go to this class, like point-of-sales, medical
> > equipment, etc. Our device is a little similar to POS, and we also
> > scan tags. But I'm wondering, except for keyboard and mouse which
> > are plug'n'play, do we need to provide vendor-specific driver?
> >
> > Regards
> >
> > Jeremy
> >
> > --- In A... ,
> > Foltos wrote:
> > >
> > > Hi,
> > >
> > > what speeds do you get with CDC? When transferring data to the host it
> > > can be quite quick. The opposite direction has problems because the
> > > default CDC driver on the PC (windows XP) does not send short packets
> > > to close the transfer when needed. Thus you can receive only one
> > > packet with one transfer. But there is a windows (XP) update for this
> > > (KB943198). You can also use timeouts on the embedded side to overcome
> > > this. (If no data is received for a period close the transfer.) The
> > > second solution is to implement some kind of protocol. First you send
> > > a command telling the length of the data filed. The you send the data.
> > > You can add extra bytes if the short packet is needed. These can be
> > > ignored by the embedded side based on the length received in the
> > > command phase.
> > > I had good speed results when not using a terminal program for
> > > testing. Try "copy some_text_file.txt COMn" in a command window. This
> > > results in 100% USB band width usage if your device is fast enough.
> > >
> > > If you want to get rid of CDC go for mass-storage. You can use vendor
> > > specific SCSI commands to implement special functionality.
> > > (http://msdn.microsoft.com/en-gb/library/ms810309.aspx
> > ) It seems you
> > > can send these even from user space using DeviceIoControl
> > > (DeviceIoControl
> > > > > (VS.85).aspx> check
> > > this too example code
> > > > > (VS.85).aspx>).
> > >
> > > You can go the UNIX way and add some special "virtual" files to the
> > > mass-storage device. Data read/written to these can be feed to your
> > > command processor. This needs no special drivers on windows side, but
> > > needs additional code on the SAM7. More dirty but easier to implement
> > > is to make some special sectors at the end of the mass-storage media.
> > > Any read or write will fail on these except if you unlock them with a
> > > special pattern written. After unlocked read/write to these sectors
> > > feed/get data from your command processor. When the media is
> > > formatted, windows will mark the special sector as a bad block and
> > > will not use it for the file system. You can access the special
> > > sectors from user space using sector read/write.
> > >
> > > Foltos
> > >
> > > jeremywang2008 wrote:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'm working on a handheld equipment running on AT91SAM7XC512.
> > > > Currently we use USB CDC class to realize virtual COM communications
> > > > with host, everything is working fine after some modification to
> > > > ATMEL USB Framework. But the data rate of virtual COM is a little
> > > > bit low, because we need to download chunk of data from the device
> > > > to host.
> > > >
> > > > We plan to migrate to USB class with higher speed. We need the
> > > > application on the host to configure the handheld equipment, get
> > > > configuration from it, issue command to it to do something, and get
> > > > data from SD card inserted in the device. By the way we use
> > > > proprietary protocol to talk with each other and the device
> > > > interprets and executes commands and returns result to host, so
> > > > simply what we need is transparent USB transportation, we can write
> > > > bytes to buffer and send via USB, and read bytes from buffer when
> > > > packets received. The key point is we wanna use generic drivers that
> > > > Windows has already provided, namely, real plug'n'play, and the
> > > > application will take care of interpretation of various commands.
> > > >
> > > > Which class should we use?
> > > >
> > > > Thanks.
> > > >
> > > > Jeremy
> > > >
> >
> >
> >
Reply by ●May 8, 20092009-05-08
Here is some insight on your CDC issues.
1) You can search the registry for the current COM port (based on VID and PID). Go down HKEY_LOCAL_MACHINE and start at system\CurrentControlSet. You need to go a couple of more layers, but you'll find it.
2) The CDC class with a standard windows driver will go a little faster then 1 Mb/sec (128KB/sec). By the time you write the data to a queue, and pull it out of the queue to write into the hardware fifo in the interrupt handler, you will keep a SAM7 pretty busy with 1 Mb/sec of data.
1) You can search the registry for the current COM port (based on VID and PID). Go down HKEY_LOCAL_MACHINE and start at system\CurrentControlSet. You need to go a couple of more layers, but you'll find it.
2) The CDC class with a standard windows driver will go a little faster then 1 Mb/sec (128KB/sec). By the time you write the data to a queue, and pull it out of the queue to write into the hardware fifo in the interrupt handler, you will keep a SAM7 pretty busy with 1 Mb/sec of data.
Reply by ●May 8, 20092009-05-08
On Thu, May 7, 2009 at 11:24 PM, jeremywang2008
wrote:
>
> Probably HID + MSD is not necessary, and I believe either one of them works,
> and I'd like to know which one is easier to implement.
As others mentioned, Full speed HID is only up to 64KB/s (64Bytes/ms). So that
would not work for you. MSD may be more complicated for I/O.
The other thing is that you can probably achieve faster speed with CDC.
The Windows built-in CDC-ACM driver usbser.sys is known to have problems.
And you already know it is not really plug and play as it needs an INF
file. There are not really many choices under Windows though. USB RNDIS
is difficult to implement and it does need an INF file as well for Windows.
--
Xiaofan http://mcuee.blogspot.com
wrote:
>
> Probably HID + MSD is not necessary, and I believe either one of them works,
> and I'd like to know which one is easier to implement.
As others mentioned, Full speed HID is only up to 64KB/s (64Bytes/ms). So that
would not work for you. MSD may be more complicated for I/O.
The other thing is that you can probably achieve faster speed with CDC.
The Windows built-in CDC-ACM driver usbser.sys is known to have problems.
And you already know it is not really plug and play as it needs an INF
file. There are not really many choices under Windows though. USB RNDIS
is difficult to implement and it does need an INF file as well for Windows.
--
Xiaofan http://mcuee.blogspot.com
