How can I store audio files in the uC ROM so as to serially transmit it to a decoder chip?

Question

I am using an NXP micro controller (P89V51RD2) with on board flash of 64kB. I want to interface it with an audio decoder IC, probably VS1011 (if I can get the IC). What should I do to use on board ROM to store the audio files, so that I can serially transmit them using SBUF to the decoder.

I tried incorporating a .amr of 8kB file recorded from my mobile but it was unsuccessful.

I used this code :

xdata char mp3[]={
#include"one.amr"
};

I saw this question but the answer gives pre-built projects.

Also, I have trouble getting any of the VS10xx series so any alternative ICs which provide same functionality are welcome.

Answer 1

All files are simply sequences of numbers. Each byte in a file represents a number in the range [0..255]. A text file is such a sequence of numbers, but the values of bytes making up the text file tend to be limited to the range [32..126] with a few others like 9, 10, 13. That's because this range of numbers is also defined to have textual meaning according to the ASCII table:

An .AMR (Adaptive Multi-Rate audio) is a binary file, meaning that the data it contains doesn't represent text, and it probably uses the full range of [0..255]. If you tried to open such a file in a text editor like notepad, it would look like total gibberish. If you want to have a look inside a binary file, it's best to use a Hex editor. You'll find that your file looks something like this:

Still gibberish, but at least you can see the data represented in a number of ways. On the far right, is how the file might look if opened in a very good text editor. (In Notepad it would probably look worse than this). You can see a lot of random letters, punctuation, and funny looking characters that don't appear in the ASCII table above. That is basically what your C compiler thinks you're trying to say when you #include the .ARM file.

In the central panel you can see the bytes represented as hexadecimal numbers instead. This is a more meaningful way to view a binary file. And this is roughly how you need your .AMR file to look before your C compiler will understand it.

If I wanted to compile that file shown in the picture above, my C compiler would want to see this:

xdata char mp3[]={
  0x1D, 0x50, 0xAA, 0x37, 0xD5, 0x80, 0x9B,  .......  
};

So what you need is a tool which can turn a binary file into the C code where each byte of the file is written out in hex.

Fortunately, other people have run into this problem before, and written tools to do it. You might try this one which is called bin2h, or even this one, which is also called bin2h.

Answer 2

Check this out: http://www.deadnode.org/sw/bin2h/

Depending on the size you have for storage, you might want to tell the linker to put the resulting data into some specific storage. If all you got is some flash space, this will usually only suffice for very small amounts of data.

Answer 3

The AMR file is not directly linkable to the project. The compiler/linker has no idea what to do with those bytes that you've asked it to include.

There are several options. The main one is to take each byte of the amr file and convert it to a C array:

const uint8_t amrArray[] = { val1, val2, ....}

Usually I write my own little C program for this. This is very simple since all you need to do is iterate through the bytes in the amr file, then using fprintf write it as an array.

Note that above I assume 8 bits per value, change as necessary. Another very important thing is that I used the word const. Becuase of const, the compiler is going to know that amrArray cannot change the data and so the linker will likely place it in FLASH instead of RAM, which is usually what you want. You can also be more specific and change the linker file to place it at a certain location, but const usually works with compilers as is.

Be careful of large arrays you place in RAM (not FLASH) because their initialization takes time and a watchdog timer can trigger.