MP3 Playa (p. deux)

After giving some thought on the software, I've come up with several ideas.. These basically cover the interrupt driven aspects and several other key specifications.. No details yet.. Just some ideas...

Firstly, for the FAT filesystem.. The MMC cards store files in a FAT filesystem.. I intend to use the FAT filesystem so that these cards can be easily interfaced to PCs so that I can easily download my favourite MP3s onto it.. Also, it would not require me to place the files sequentially and allow me to add/remove files from the MMC as I wish.. For this, we will reserve 512bytes of RAM (the F2410 has 768 bytes of RAM), for a table of indexes.. This table will hold the first sector of data for each file.. A playlist so to speak.. This allows me to quickly jump to the associated part of the MMC and download the file.. So, for random plays, we can just jump around the RAM table randomly.. And we can reserve one of the FSR for use as a pointer to the playlist..

But the problem would obviously be filling up the list.. We will need to parse throught 1Gb worth of data.. Which isn't a very nice prospect.. So, instead of filling up the playlist immediately on startup, I propose that we fetch data from the MMC as and when necessary.. Obviously sector 0x0000 is reserved for the MBR and therefore doesn't contain any 'data'.. So, if an entry in RAM space is 0x0000, we will seek to the last known sector in the list and populate the list from there.. Another possible technique would be to run a background process the fills up the list at regular intervals.. But I think the Fill-as-u-Go method is the best.. When first presenting a list for selection, we can just fill it up sequentially.. And when we're playing a random list, just ensure that when we do a random jump, we don't jump very far, maybe within 16 spaces and so ensuring that we'll only need to parse through 16 more files at a time..

Using 512bytes would be suitable for a 1Gb MMC card.. Assuming that an MP3 consumes about 4Mb of space, we can only have 250 files on it.. Multiply it by 16bits for each entry, gives us 500 bytes.. Therefore, having 512bytes should be just sufficient.. We've got 768 bytes on the 2410... So, we can probably allocate a little more RAM if it is needed.. Maybe up to 640bytes.. If more memory is needed, we can simply upgrade the 2410 to either the 2510 or 2515...

Then comes the LCD.. We will be reserving a 14x6 (84 bytes) array of RAM for the 'video buffer' so to speak.. Each buffer will contain a ASCII character.. The actual font table will be kept in programme memory.. During our screen updates, we will just parse through this video buffer and update the screen.. Custom graphics can be built by using custom fonts... Not a problem.. Also, we will send a blank spacer before actually drawing the characters.. This will ensure minimum codespace required.. But after some thinking, instead of updating the screen on a regular basis, we will only update the screen as-and-when required in order to conserve battery power.. Thus reducing one interrupt flag..

Some mock screen shots (ASCII)

+--------------+ +--------------+ +--------------+ +--------------+

|              | |   PLAYLIST   | |              | |     MENU     |

| 44k 0259 320 | | LONGFILENAME | |              | | MENU ITEM #1 |

| LONGFILENAME | | LONGFILENAME | |    VOLUME    | | MENU ITEM #2 |

|              | | LONGFILENAME | | [=====I====] | | MENU ITEM #3 |

| [====I=====] | | LONGFILENAME | |              | | MENU ITEM #4 |

|              | | LONGFILENAME | |              | | MENU ITEM #5 |

+--------------+ +--------------+ +--------------+ +--------------+

Also, we will be using both high and low priority interrupts.. During playback, we will definitely have to serve the DATA_REQ interrupt when the STA013 asks for data.. Everything else is secondary.. Hence, this will be the high priority interrupt.. As for the KBIO, it will be run in the low priority interrupt.. This makes things so much easier.. If it's a high priority interrupt, it's from DATA_REQ.. If it's a low priority one, it's from KBIO.. No need to sort through multiple flags.. Maybe just one more low priority interrupt, a sleep timer.. After XX seconds of being idle, the whole unit will go into sleep mode, until woken up by the user (KBIO).. But not strictly necessary.. We should double one of the buttons as a OFF button.. Hold it down for 5 secs to turn the unit OFF or something like that..

Also, we will still need to sort out a mechanism to detect card inserts and removal.. For the moment, we will have to assume that the card is inserted at all times.. But in actual fact, we will need another method.. I guess the easiest way is to regularly poll the card to check that it's there.. We can run under the 32kHz INTRC for this to conserve power.. Send the MMC Identifier command and check for a valid reply..

That's all for now..