Just one more thing: I suppose if you use an MCU and an SD card, that you could reference a specific memory location like you always have done, say by using hexadecimal notation.

 

Just one more thing: I suppose if you use an MCU and an SD card, that you could reference a specific memory location like you always have done, say by using hexadecimal notation.

Not really.
If I am accessing memory locations, I might want to supply a memory address such as 0x00020000, i.e. the third 64KB page.

If I am accessing a particular block on SD ram, I might want to start at block #9876. In any case, I would never be using a specific block number. This number would be determined by calculation in my system software and will be supplied as a constant or variable such as STARTING_BLOCK or Starting_Block, respectively.

 

I haven't read/written to SD cards, but I have read/written to memory modules that use the SPI interface, for reading/writing audio specifically. In my case I stored multiple audio files on the memory module, then read the audio from the memory module over the SPI interface, and sent the data to an audio playback amplifier over the I2S interface.

For the SPI memory modules that I worked with, it's not as simple as just randomly accessing an address. There is a specific procedure for writing to memory. You have to set registers on the memory module to enable the write, and memory has to be erased before it can be written to. After initiating a write you have to poll the memory to be sure the write is complete (make sure the module is not "busy" before issuing another command). There is a specific procedure for reading/writing/erasing the memory, and you have to be careful about writes that overlap the page boundaries, etc.. The datasheet for the memory module will explain all of this in detail. Also depending on the MCU, you may have the option of using DMA such as for your SPI transfers, freeing the rest of the processor to do other work while the memory transfer is taking place. Also your data transfers might have size limits. In my case the SPI data count register was 8-bit, so each SPI transfer could not exceed 255 bytes. The devil is always in the details.

If someone provides a library for your target platform that gives you a nice simple random access interface to your memory then that's great, but if you're talking directly to the hardware yourself then it's likely more involved.

Edit --> I was using a memory chip similar to this one:
https://www.winbond.com/resource-files/w25x40cl_f 20140325.pdf
The data sheet explains how to work with it. Basically it has registers that you write commands into, and registers that you check for status, and this is how you control the chip.

 

Hi. What it is is that I've been reading about Segmentation & Offset and also looking at specialised voice playback chips.

From my Segment & Offset studies I've been thinking maybe this technique is still practiced with certain MCU's. And from what has been said, I gather if it ever was used with MCUs, Segment & Offset use is old hat. And that today one just selects an MCU with the memory required, or that can address the required external memory (probably PROM, EEPROM). Or, if one wants to access a lot of memory use an MCU with SPI that can access an SD card.

As to why I've been talking about referencing to memory addresses: When examining some dedicated voice playback IC, I came across a system whereby selection of a voice group was accomplished by setting the last 10 bits of a binary string. In other words, the data in memory (say PROM) was in a static and known memory location. That seemed to make voice selection a matter of writing a table in the programming process, the first voice group having the last 10 bits 0000000000 and the last one 1111111111. So, that is making me think perhaps that might be a way to tackle how a program is going to tackle selection of a voice/file using a regular MCU IC rather than a dedicated voice playback IC. But of course, the voice IC that I was studying must have had some proprietary rules for storing WAV files, so that one knew before they were even stored, what locations any WAV file would be at.

Then comes in SPI and SD cards. From what is said, selecting a file to play is certainly not going to involve specifying a memory location or range by hexadecimal or binary string. It will involve, I think, simply referencing a WAV filename. So, if there is going to be a table, it will be filenames. Anyway, this is where I've been at.

Anyway, I am quite happy in what has been said about MCU's and their selection. I've progressed my understanding. Thanks.

EDIT: I said "From what is said, selecting a file to play is certainly not going to involve specifying a memory location or range by hexadecimal or binary string. It will involve, I think, simply referencing a WAV filename."

That is how most people would handle this with SD card. Playing a file would involve specifying a file name and the system would find it's storage location, even with MCU. But, from reading Mr Software's post and the link to an SD card data sheet (not read yet), I think there will be a technical solution to a task of copying a file from a PC and specifying it's start location on an SD card.

 

The pdf I linked is actually for a flash memory module, not an SD card. I haven't used an SD card in any projects myself yet so I can't tell you if access is similar or not at the low level. If you want to specify a file name to read, then you'll need a file system driver or some other code that can read the file system and locate the data by the file name. For the memory module that I linked, I just wrote raw data to the sectors and used memory offsets to locate the audio clips. It was an embedded system and the audio recordings were permanent, so for that case a file system was not required.