caching_strategy.txt

一款MP3 Player Firmware 的原代码,非常有参考价值

Date: Fri, 11 May 2001 00:35:14 -0700
From: [e-mail]
To: *************
Subject: Re: Yeah yeah... more questions... :-)



I'll probably copy portions of this explaination into some of the docs...

>I am really getting frustrated with this code. I hate to be a wussy but are
>you planning on porting the whole drivers file to C? I have been 
>staring at it for at least 3-4 hours today and I am really having a tough 
>time figuring it out. I looked at the file_cache routine to check how you 

Those routines will remain in assembly language, and there's really
no need to do much with them, since they're already working.

>were doing that.  I would really like to help out with the file caching 
>problem but other than advice I am not going to be much good to you. I 
>can't reverse engineer Assembler code. Rather than wasting your time 
>explaining stuff to me, I would rather be useful some other way. I would 

What I meant by a "caching strategy" has nothing to do with the
code that's inside file_cache and file_cache_work.  The caching
strategy involves how and when the main program decides to call
these functions and what parameters are passed to file_cache.
The driver API has been carefully designed to allow the main
program to have a lot of control over what gets cached and when.
Please take a look at this web page:

http://www.pjrc.com/tech/mp3/library.html

Begin reading the section "File/Directory Reading".  The file_cache,
file_cache_work, file_seek, and other functions are intended to give
the application complete control over what data gets cached... so the
caching strategy is completely under the control of the main program.
Those functions provide you with a relatively high level of abstraction,
so you can think of files as streams of bytes, more or less like using
the functions in a standard C library.  My goal was to make the API
similar to using standard C library functions, but to give much more
control over the disk activity, which is what file_cache and
file_cache_work do for you.  Remember, the "read" functions don't
ever cause disk activity... they either find the data in the cache
or return an error.  The drivers manage the cached sectors and clusters
for you, more or less like an operating system would do.

Very briefly, after you've opened a file, you call file_cache to
set up a transfer of bytes.  file_cache only sets up some parameters
inside a structure associated with that file (yes, each of the 64
possible open files by have a caching operation in progress).  To
actually cause something to be done towards to ultimate goal of
getting the data read into the cache, you call file_cache_work.  It
will return one of three things: still working, complete, or ran
out of memory.  file_cache_work doesn't even really do the I/O
operation... it writes into a request queue for the IDE driver and
returns back to the main program as quickly as possible.  As you
know, there's a lot of really complicated things these functions
do... the idea is that you really don't need to worry about how
they accomplish their job, just like how most C programmers really
don't dig inside fprintf, fgets, fopen, etc.

Today there is a function called do_ide_loop(), which will
eventually go away.  Calling this is what actually causes the
disk operations to take place.  Later all disk operations will
be interrupt driven and do_ide_loop will vanish.

>really like to help out but unless there is a lot more commenting as to 
>what's going on or it's in C I am going to be pretty useless to you. Is 
>there something that I can work on that hasn't been implemented yet that I 
>can do on the side and you can include later? Or even write C code with 

The truth is you're a bit early in the game, as there's still a few
problems in the SDCC-AS31 glue code, but I'm rapidly working those
out.  Most of the functions work as documented.  There's also a couple
important functions that are still missing, the most important one
being file_uncache, which will allow you to tell the drivers to free
a portion of the file.

Still, now is a good time to start coming up with a strategy.  The
main program will almost certainly get re-arranged quite a bit.
Today it's very simple (and not very smart).  You can see there's
five states, and the flow is always:

S_READ_DIR -> S_CACHING -> S_PLAYING_AND_CACHING ->
	S_PLAYING -> S_FINISH_PLAYING

The S_FINISH_PLAYING state is when the program has sent all of the
file to the drivers for playback.  There is considerable buffering
in the playback driver, so the program has to wait until the driver
has actually played all the buffered data before closing the file.

Now, as an example of improving the caching strategy, it would
make a lot of sense to call file_uncache on the part of file that's
not being buffered (hmm... is it possible to figure out what part
isn't in the playback driver's buffer?)  After the call to file_uncache
(damn, I really need to get that written), then there will be lots
of free memory again, so the drive could be started (ide_wakeup) and
the next file could be opened and some of it could be cached.
In general, calling file_cache_work end up resulting in calls to
malloc_blocks, and calling file_close calls free_blocks for all the
blocks that were allocated.  Someday soon file_uncache will exist,
so you can cause free_blocks to be called on only a portion of the
file that you don't need anymore (and you need memory freed up).

There's a balancing act between turning the drive on too soon and
draining batteries needlessly, and turning it on too late and not
having data in memory to play.  This will ultimately require an
API to some timer drivers.  It's on my to-do list, after fixing
bugs and writing file_uncache.

This is just one simple thing to do... you can have up to 64 files
open at once (directories count as files).  You could open up and
cache perhaps the first 100k of a few upcoming files, so when/if
the user presses the next button, you've got some in memory and
they're just a file_seek and file_read/file_read_block away, instead
of making the user wait for the drive to spin up when they press a
button.

The API is designed to give the main program complete control of
what portion of what files gets cached when.  Calls to file_cache_work
cause small increments of the file to get loaded into the cache.
It is legal to have many files open and have each one with a pending
file_cache set of parameters established.  You get to decide when to
get each one to read another chunk.  Perhaps 9 times out of 10 you
call file_cache_work for the file that you're playing right now, and
1 of 10 times call it for portions upcoming files, in anticipation
of the user pressing a button.

>Sorry to be such a pain in the ass... Put me to work, just not something so 
>hard as the file cache... :o)

Please please please read this web page:

http://www.pjrc.com/tech/mp3/library.html

Some parts are slightly out of date, so also refer to as31glue.h
for a list of all the API to the drivers.  Once the code is more
stable, I'll update this page.  The API is still open and some
more calls will need to be added to accomplish some things, but
it's important that you understand what the functions do and how
to call them.  That's why I spent quite a bit of time to write
that page documenting the driver API.


Paul