Looking for USB stack with permissive licence (mass storage)

In article <jmgql7$2lg$1@dont-email.me>, root@127.0.0.1 says...
> 
> Mark Borgerson wrote:
> 
> > Noob wrote:
> > 
> >> Mark Borgerson wrote:
> >>
> >>> Noob wrote:
> >>>
> >>>> USB 2.0 "Hi-Speed" mode is 480 Mbit/s. My goal is 30 MB/s (240 Mbit/s)
> >>>> of "useful" bandwidth (i.e. considering actual data transferred only).
> >>>> IIUC, the overhead in the USB protocol is fairly significant.
> >>>
> >>> That seems to be a pretty ambitious target.
> >>
> >> I can live with 20-25 MB/s  ;-)
> >>
> >>> Where is all that data going to go (or come from)?
> >>
> >> A recent 3.5" HDD in a USB2 enclosure (nowadays, 3.5" HDDs
> >> sport 64 MB of cache, and can sustain 50 MB/s over SATA)
> > 
> > That's fine for SATA.  Have you measured the sustained throughput
> > with USB?
> 
> "With the current stack, I've measured 18-20 MB/s sustained."
> But this stack was compiled with gcc -O0, with message queues
> re-implemented using interrupt masking (!!) instead of using
> the OS implementation, with bounce buffers used everywhere,
> and every dynamic memory block allocated from an uncached
> memory pool.
> 
> > That sounds like a good recipe for disk thrashing.  What kind
> > of file system are you planning to use on the HDD?  If it's
> > FAT32,  how will maintaining the FAT for 3 files being written
> > affect your throughput?   If it's a large disk, caching the 
> > whole FAT could use up a lot of your RAM.
> 
> FAT sucks. We use ext2 with large blocks.
> 
> > To what degree is the throughput constrained by the HDD and file
> > system and not the unnecessary copies?
> 
> Seriously? Modern HDDs can sustain 100+ MB/s sequential R/W on the
> outer tracks, 50+ MB/s on the inner tracks. Whatever is the bottle
> neck, it's not the HDD.

Even if the user is maintaining a FAT?  How does track access time 
affect those throughput numbers?
> 
> > And just when you thought USB 2.0 was good, there are now HDDs comming
> > out with USB 3.0 interfaces!   ;-)
> 
> I don't think the higher bandwidth of USB 3 brings anything
> to the table for a PVR product. Can one plug a USB3 enclosure
> into a USB2 port?

Good question. You can plug a USB-2 thumb drive into a USB-1 port.
It works, but the OS complains that it could run faster with a
USB-2 port.  I don't know if the same works with USB-2 and USB-3
> 
> Regards.

Mark Borgerson

Hi Mark,

On 4/16/2012 7:49 AM, Mark Borgerson wrote:

>>> And just when you thought USB 2.0 was good, there are now HDDs comming
>>> out with USB 3.0 interfaces!   ;-)
>>
>> I don't think the higher bandwidth of USB 3 brings anything
>> to the table for a PVR product. Can one plug a USB3 enclosure
>> into a USB2 port?
>
> Good question. You can plug a USB-2 thumb drive into a USB-1 port.
> It works, but the OS complains that it could run faster with a
> USB-2 port.  I don't know if the same works with USB-2 and USB-3

Yes, you can plug a USB3 device into a USB2 port.  Though
the USB3 end of the cable is very different from a "regular"
USB connection.

On 2012-04-16, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
> Whoops, I think missed hte 'host' part somewhere. The Atmel example is
> device only, sorry.
>

Microchip do a USB host stack for their OTG devices; I've no idea if it's
any good however. See:

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en537044

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On Apr 17, 2:57=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2012-04-16, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
>
>
> > Whoops, I think missed hte 'host' part somewhere. The Atmel example is
> > device only, sorry.
>
> Microchip do a USB host stack for their OTG devices; I've no idea if it's
> any good however. See:
>
> http://www.microchip.com/stellent/idcplg?IdcService=3DSS_GET_PAGE&nodeI..=
.
>
> Simon.
I've used it - it worked 'out the box', not that it means that it is
good. However, I think they get grumpy if you use it on a non-
Microchip processor.

Rocky wrote:

> I've used it - it worked 'out the box', not that it means that it
> is good. However, I think they get grumpy if you use it on a non-
> Microchip processor.

I was looking for something with a permissive license, such as
BSD or MIT. I've given up :-(

The quality of the current proprietary solution is appalling,
but I guess I'll have to live with it, and our customers will
have to learn to unplug/replug or even reboot the STB.

Regards.

On 4/17/2012 9:00 AM, Noob wrote:
> Rocky wrote:
>
>> I've used it - it worked 'out the box', not that it means that it
>> is good. However, I think they get grumpy if you use it on a non-
>> Microchip processor.
>
> I was looking for something with a permissive license, such as
> BSD or MIT. I've given up :-(

Then port one of the {Open,Net,Free}BSD stacks!

> The quality of the current proprietary solution is appalling,
> but I guess I'll have to live with it, and our customers will
> have to learn to unplug/replug or even reboot the STB.
>
> Regards.

On 2012-04-17, Rocky <robertgush@gmail.com> wrote:
> I've used it - it worked 'out the box', not that it means that it is
> good. However, I think they get grumpy if you use it on a non-
> Microchip processor.

So Microchip apply the same license to their USB stack as they do to their
header files ?

I should have realised. :-) As I said, I've never actually used it, but I
just saw the "royalty free source code" reference on the Microchip USB
Framework page.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world