Sign in
Search AT91SAM
Subscribe to AT91SAM
Ads
Discussion Groups
See Also
Discussion Groups | AT91SAM ARM | USB class choice for AT91SAM7XC USB interface
For users of the Atmel AT91SAM7 and AT91SAM9 ARM CPU chips. Atmel has taken a new direction by combining on chip flash and ram with the ARM CPU on a single die. This provides low cost devices for small systems using the ARM CPU. This group is to exchange information to help users get started and learn how to use the devices.
USB class choice for AT91SAM7XC USB interface - jeremywang2008 - May 6 21:10:04 2009
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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: USB class choice for AT91SAM7XC USB interface - Xiaofan Chen - May 7 1:02:06 2009
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
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> 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
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: USB class choice for AT91SAM7XC USB interface - Foltos - May 7 4:09:10 2009
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
>
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
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
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
>
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: USB class choice for AT91SAM7XC USB interface - jeremywang2008 - May 7 11:07:08 2009
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...@yahoogroups.com, 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
> >
> >
> >
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
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...@yahoogroups.com, Foltos
>
> 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
>
> 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
> >
> >
> >
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: USB class choice for AT91SAM7XC USB interface - jeremywang2008 - May 7 11:25:06 2009
--- In A...@yahoogroups.com, 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
>
> On Thu, May 7, 2009 at 9:09 AM, jeremywang2008
>
> > 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
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: USB class choice for AT91SAM7XC USB interface - jeremywang2008 - May 7 11:42:32 2009
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...@yahoogroups.com, Foltos
>
> 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...@yahoogroups.com
> > Foltos
> > >
> > > 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
> >
> > > can send these even from user space using DeviceIoControl
> > > (DeviceIoControl
> > >
> > > 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
> > > >
> >
> >
> >