MP3 Decoding from flashcard without decoder chip

Thanks for the quick response, and sorry all for the double post.

>The interface between FS and block device driver is OS dependent.
So what governs the API? Is it the vendor of the FS? If a file system
is POSIX complaint then it is clear what the driver interface (open,
read, etc.) will be right?

>If you are not using an OS, one free FAT file system for you to play
>with is mine, http://www.zws.com/products/dosfs/
Thanks for the link; I'll at least look here to get more of a feel
for the subject.

Thank all for helping my understanding.

larwe wrote:

> 
> If you are not using an OS, one free FAT filesystem for you to play
> with is mine, http://www.zws.com/products/dosfs/
> 
Lewin,

And a great help it is! BTW some time ago I sent you some
patches at zws.com for it (one involving pointer underrun
is necessary); please let me know if you got 'em.

Regards,

Michael Grigoni
Cybertheque Museum

MyUsenetAccount wrote:
> >> Any links to how this is done in practice?
>
> >look for yampp
>
> Thanks but this implementation uses a dedicated decoding chip. I'm
> looking for infos on using a controller to do this.
>
> innix wrote:
> > Most OS would have FAT fs on USB drives/readers.  You might have
> > to do it yourself on SPI.
>
> >What is with this USB fetish?
>
> >>Most OS that have a FAT filesystem would be properly designed, with a
> >>layered driver model. The filesystem driver would not care if it is
> >>reading from SPI or from USB or from anything else, for that matter.

Could be done, but not currently done for most os.

>
> >>As a point of order, a "USB" block device is really an ATAPI device on
> >>top of a USB transport layer.
>
> So I require a fat32 file system on the controller which uses the SPI
> driver to read the files back. I should check the interface that the
> file system requires the SPI driver to support, right? I gather that
> NOT all file systems expect the same interface or is it OS dependant?

Implementations are os specific.  USB storage devices with Fat/Fat32
are standard for Windows and Linux.

> Thanks

Hi!

> And a great help it is! BTW some time ago I sent you some
> patches at zws.com for it (one involving pointer underrun
> is necessary); please let me know if you got 'em.

I didn't get those. I have cyclic problems with antispam measures being
enforced upstream of me. Some days I'll receive four thousand bounced
spams that had zws.com/larwe.com return addresses. Some days I won't
receive any mail at all. Please resend :)

MyUsenetAccount wrote:

> So what governs the API? Is it the vendor of the FS? If a file system
> is POSIX complaint then it is clear what the driver interface (open,
> read, etc.) will be right?

I'm on shaky ground here, but I believe the answer to this is no. POSIX
standardizes what the app layer sees. The way the OS talks to internal
FS components is not part of this equation.

Windows XP has a token POSIX compliance, but XP device drivers,
including installable file systems, are in no way compliant with any
kind of published standard.