RE: [ECOS] USB MSD stack

RE: [ECOS] USB MSD stack

[Doyle, Patrick]

> From: Andrew Lunn [mailto:andrew@lunn.ch] 
> 
> Stupid question. Which end are you interested in? Device or host?  I
> assumed by meant device, so the eCos target is the MSD.
> 
>        Andrew
> 

Silly me... yes, the eCos target is the MSD (along with being a bunch of
other things).

--wpd


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] USB MSD stack

[Frank Pagliughi]

Doyle, Patrick wrote:

>>From: Andrew Lunn [mailto:andrew@lunn.ch] 
>>
>>What you might be able to do is not set a device class. You then need
>>to tell M$ windows that when it sees vendor XYZ it should load both
>>the HID driver and the MSD driver. The HID driver will grab the
>>interupt end point and the MSD driver will grab the bulk in and out
>>endpoints.  A lot will depend on what level M$ does its resource
>>allocations. If it does the allocation at interface level, it will not
>>work, the first loaded driver will win. If it does it at endpoint
>>level you have a chance. Handling control transfers is going to be
>>interesting.
>>
>>Or you could just write a HID and MSD driver for M$. Well, you don't
>>need full drivers, just an intermediate driver which has two
>>interfaces on top and one on the bottom. Does M$ have USB intermediate
>>drivers? I know they exist for the networking stack....
>>
>>         Andrew
>>    
>>
>
>Hmmm... we are hoping to avoid writing any host drivers (or even .ini files,
>if possible).  But we may learn that that is not possible.
>
>Thanks again for your thoughts...
>
>--wpd
>
>  
>
If you can get away without writing a Windows driver, I reccomend it. 
It's at least one less variable when debugging. You may need or want to 
write your own INF file if you've got multiple interfaces.

On most device chips I've seen, interrupt transfers work in a similar 
manner to bulk transfers. It's up to the host to guarantee bandwidth to 
the interrupt transfers and deal with the complexities. So it should be 
no problem doing the device side of the HID in eCos.

For USB questions, the discussion board on usb.org is excelent. The 
person who wrote your USB book may be the one to answer your question. 
The discussion board is at:
    http://www.usb.org/phpbb/

Frank


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] USB MSD stack

[Doyle, Patrick]

> From: Andrew Lunn [mailto:andrew@lunn.ch] 
> 
> What you might be able to do is not set a device class. You then need
> to tell M$ windows that when it sees vendor XYZ it should load both
> the HID driver and the MSD driver. The HID driver will grab the
> interupt end point and the MSD driver will grab the bulk in and out
> endpoints.  A lot will depend on what level M$ does its resource
> allocations. If it does the allocation at interface level, it will not
> work, the first loaded driver will win. If it does it at endpoint
> level you have a chance. Handling control transfers is going to be
> interesting.
> 
> Or you could just write a HID and MSD driver for M$. Well, you don't
> need full drivers, just an intermediate driver which has two
> interfaces on top and one on the bottom. Does M$ have USB intermediate
> drivers? I know they exist for the networking stack....
> 
>          Andrew

Hmmm... we are hoping to avoid writing any host drivers (or even .ini files,
if possible).  But we may learn that that is not possible.

Thanks again for your thoughts...

--wpd

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] USB MSD stack

[Andrew Lunn]

On Thu, May 04, 2006 at 10:25:10AM -0400, Doyle, Patrick wrote:
> > From: Andrew Lunn [mailto:andrew@lunn.ch] 
> > 
> > My USB book is at home....  
> > 
> > I thought you had to select an interface to be in use. So having a HID
> > interface and a MSD interface is not a problem. However i think you
> > can only have one interface selected at once.
> > 
> > But i could be wrong....
> > 
> >     Andrew
> > 
> OK, I see what you're getting at... I have a couple of USB books here (and
> an overload of information), but I've definitely seen a "select this
> interface for use" message somewhere in one of those.  So, I would agree to
> your assertion that I can have only one interface selected at a time.
> 
> Hmmm... I wonder what I should expect a Windows host to do when I plug in a
> device that says it has two interfaces, one an HID and one an MSD?  I'll
> find out soon enough by experimentation, but I suppose it's possible that it
> could select interface 1 when it needed to access the disk and interface 2
> when it needed to access the mouse... hmmm that doesn't feel right -- does
> that mean I can't move my mouse/disk while I'm listing files?
> 
> Ahh... the adventure continues :)

What you might be able to do is not set a device class. You then need
to tell M$ windows that when it sees vendor XYZ it should load both
the HID driver and the MSD driver. The HID driver will grab the
interupt end point and the MSD driver will grab the bulk in and out
endpoints.  A lot will depend on what level M$ does its resource
allocations. If it does the allocation at interface level, it will not
work, the first loaded driver will win. If it does it at endpoint
level you have a chance. Handling control transfers is going to be
interesting.

Or you could just write a HID and MSD driver for M$. Well, you don't
need full drivers, just an intermediate driver which has two
interfaces on top and one on the bottom. Does M$ have USB intermediate
drivers? I know they exist for the networking stack....

         Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] USB MSD stack

[Doyle, Patrick]

> From: Andrew Lunn [mailto:andrew@lunn.ch] 
> 
> My USB book is at home....  
> 
> I thought you had to select an interface to be in use. So having a HID
> interface and a MSD interface is not a problem. However i think you
> can only have one interface selected at once.
> 
> But i could be wrong....
> 
>     Andrew
> 
OK, I see what you're getting at... I have a couple of USB books here (and
an overload of information), but I've definitely seen a "select this
interface for use" message somewhere in one of those.  So, I would agree to
your assertion that I can have only one interface selected at a time.

Hmmm... I wonder what I should expect a Windows host to do when I plug in a
device that says it has two interfaces, one an HID and one an MSD?  I'll
find out soon enough by experimentation, but I suppose it's possible that it
could select interface 1 when it needed to access the disk and interface 2
when it needed to access the mouse... hmmm that doesn't feel right -- does
that mean I can't move my mouse/disk while I'm listing files?

Ahh... the adventure continues :)

I appreciate the dialog -- it helps me to sort through the gush of
information flowing at me right now.

--wpd

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] USB MSD stack

[Andrew Lunn]

On Thu, May 04, 2006 at 10:06:30AM -0400, Doyle, Patrick wrote:
> > From: Andrew Lunn [mailto:andrew@lunn.ch] 
> > 
> > You might also want to add to that list f) find out if USB allows a
> > device to be both MSD and HID at the same time. g) Find out if eCos
> > allows a device to be both MSD and HID at the same time. h) If not,
> > find out if eCos allows the device to dynamically change between HID
> > and MSD.
> > 
> >From what I understand so far, USB allows a device to have multiple
> "interfaces", in which each interface specifes the class of device, number
> and id's of the endpoints, etc...
> 
> >From what I understand so far (hereafter abbreviated as FWIUSF), eCos will
> pretty much allow me to do whatever I want in USB land -- it currently
> provides support for some common client level USB transactions that must be
> supported by all devices, and a sample ethernet-on-top-of-USB driver.
> 
> FWIUSF, eCos supports multiple interfaces on devices, so it should support
> MSD and HID at the same time.

My USB book is at home....  

I thought you had to select an interface to be in use. So having a HID
interface and a MSD interface is not a problem. However i think you
can only have one interface selected at once.

But i could be wrong....

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] USB MSD stack

[Doyle, Patrick]

> From: Andrew Lunn [mailto:andrew@lunn.ch] 
> 
> You might also want to add to that list f) find out if USB allows a
> device to be both MSD and HID at the same time. g) Find out if eCos
> allows a device to be both MSD and HID at the same time. h) If not,
> find out if eCos allows the device to dynamically change between HID
> and MSD.
> 
From what I understand so far, USB allows a device to have multiple
"interfaces", in which each interface specifes the class of device, number
and id's of the endpoints, etc...

From what I understand so far (hereafter abbreviated as FWIUSF), eCos will
pretty much allow me to do whatever I want in USB land -- it currently
provides support for some common client level USB transactions that must be
supported by all devices, and a sample ethernet-on-top-of-USB driver.

FWIUSF, eCos supports multiple interfaces on devices, so it should support
MSD and HID at the same time.

> > All of that being said, I still need to finish the low 
> level driver... off
> > to coding land!
> 
> What device is this? It seems USB has become popular recently with
> eCos. I know of three other device drivers in development at the
> moment.

We are using the OMAP5912 from TI.  I think Paul submitted some patches not
too long ago in preparation for submitting our HAL.  I anticipate submitting
our HAL to CVS sometime in the near future.

--wpd

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] USB MSD stack

[Andrew Lunn]

> So, at that level, I wouldn't have FATFS running locally on eCos (not when
> I'm allowing the host to access the local storage), I will interact directly
> at the block level with the storage device (RAM, flash, SD-Card, etc...).

O.K. That is a simple solution to avoid concurency problems.
 
> As I look at this, I am becoming more concerned about the HID requirements
> for our product because a) I still don't know what I don't know about it; b)
> I've read that it requires "interrupt" transfers; c) I've read that the eCos
> stack in the CVS tree doesn't include "interrupt" transfers; d) I know more
> about SCSI than I do about HID; and e) I don't know very much at all about
> SCSI :-)

You might also want to add to that list f) find out if USB allows a
device to be both MSD and HID at the same time. g) Find out if eCos
allows a device to be both MSD and HID at the same time. h) If not,
find out if eCos allows the device to dynamically change between HID
and MSD.

> All of that being said, I still need to finish the low level driver... off
> to coding land!

What device is this? It seems USB has become popular recently with
eCos. I know of three other device drivers in development at the
moment.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] USB MSD stack

[Doyle, Patrick]

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch] 
> 
> Arn't these commands actually SCSI commands? And i assume these
> commands are for read block/write block. How are you thinking about
> mapping this onto a disk in eCos? How do you think you will solve the
> concurency problems? I guess you will have FATFS running locally on
> eCos and your host also using FAT, both accessing the same block
> storage device.
> 
> If you fancy going down the closed source, commercial path,
> eCosCentric have the Jungo USB protocol stack. I expect this includes
> MSD.
> 
> I think i also remember a press release from ATMEL about a free MSD
> implementation, but i don't remember the details. 
> 
>       Andrew
> 
Hi Andrew,
Thanks for your thoughts...

From what I've learned so far, yes the commands are actually SCSI commands.
They are transferred from the host to the device via one of the "Bulk"
transport pipes define by USB.  The device responds with standard SCSI
status messages via a Bulk transport pipe.  Data sectors are also exchanged
between the host and the device via these pipes.

That's what I know so far.  The SCSI packets include things like "write the
following block of data to sector 123 on your disk" and "please read sector
456 from your disk" (as well as things like "please tell me how many disks
you have and how big they are).

So, at that level, I wouldn't have FATFS running locally on eCos (not when
I'm allowing the host to access the local storage), I will interact directly
at the block level with the storage device (RAM, flash, SD-Card, etc...).

As I said, it strikes me as a pretty simple protocol (read a block, write a
block) and probably will take me longer to think about it than to write the
code, but if somebody else has already thought about it and written the eCos
code, I figured I would stand upon the shoulders of the giants who have
preceeded me.

As I look at this, I am becoming more concerned about the HID requirements
for our product because a) I still don't know what I don't know about it; b)
I've read that it requires "interrupt" transfers; c) I've read that the eCos
stack in the CVS tree doesn't include "interrupt" transfers; d) I know more
about SCSI than I do about HID; and e) I don't know very much at all about
SCSI :-)

All of that being said, I still need to finish the low level driver... off
to coding land!

--wpd

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] USB MSD stack

[Andrew Lunn]

On Thu, May 04, 2006 at 09:02:28AM -0400, Doyle, Patrick wrote:
> Hi troops!
> I'm about to write a very simple MSD (Mass Storage Device) stack for our
> eCos application.

Stupid question. Which end are you interested in? Device or host?  I
assumed by meant device, so the eCos target is the MSD.

       Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] USB MSD stack

[Andrew Lunn]

On Thu, May 04, 2006 at 09:02:28AM -0400, Doyle, Patrick wrote:
> Hi troops!
> I'm about to write a very simple MSD (Mass Storage Device) stack for our
> eCos application.  From what I've seen so far (based on about 15 minutes of
> investigation), it would appear that MSD is fairly simple -- use bulk
> transfers to exchange command and data packets between the host and the
> device.

Arn't these commands actually SCSI commands? And i assume these
commands are for read block/write block. How are you thinking about
mapping this onto a disk in eCos? How do you think you will solve the
concurency problems? I guess you will have FATFS running locally on
eCos and your host also using FAT, both accessing the same block
storage device.

If you fancy going down the closed source, commercial path,
eCosCentric have the Jungo USB protocol stack. I expect this includes
MSD.

I think i also remember a press release from ATMEL about a free MSD
implementation, but i don't remember the details. 

      Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] USB MSD stack

[Stefan Sommerfeld]

Hi Patrick,

> Hi troops!
> I'm about to write a very simple MSD (Mass Storage Device) stack for our
> eCos application.  From what I've seen so far (based on about 15 minutes 
> of
> investigation), it would appear that MSD is fairly simple -- use bulk
> transfers to exchange command and data packets between the host and the
> device.  Of course, as they say, the devil will be in the details (and 
> some
> of those details will include debugging my device driver).
>
> So, being one of the laziest programmers on the face of the earth, I 
> figured
> I would ask if anybody else has done this already.  Any takers?
>
> And as long as I've got your attention, how about HID?  Any samples?
>

I don't know if somebody does this already for eCos, but if you like to 
make such a driver, I suggest looking at the PS2 USB stack. It's fairly 
simple, has an easy interface, there's also a mass storage driver available 
and it doesn't use GPL. Check out www.ps2dev.org.

Bye... 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] USB MSD stack

[Doyle, Patrick]

Hi troops!
I'm about to write a very simple MSD (Mass Storage Device) stack for our
eCos application.  From what I've seen so far (based on about 15 minutes of
investigation), it would appear that MSD is fairly simple -- use bulk
transfers to exchange command and data packets between the host and the
device.  Of course, as they say, the devil will be in the details (and some
of those details will include debugging my device driver).

So, being one of the laziest programmers on the face of the earth, I figured
I would ask if anybody else has done this already.  Any takers?

And as long as I've got your attention, how about HID?  Any samples?

--wpd


Patrick Doyle
Manager, Digital Systems Group
DTC Communications, Inc.
Phone: (603) 546-2179
Fax: (603) 880-6965
Email: wpd@dtccom.com

 

This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above.  If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited.  If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies.  Thank you for your
cooperation.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss