My microcontroller does not have a C compiler. How do I use a microcontroller to boot my SigmaDSP in assembly?
_________________________________________________________________
In SigmaStudio, a number of things are downloaded to the target hardware when the user clicks the "Link-Compile-Download" button:
That might not sound like much, but for a simple ADAU1781 program like this...
(screenshot of basic ADAU1781 project)
...the data that is downloaded looks like THIS:
(screenshot of the Capture Window in SigmaStudio for the example project download)
These data downloads have to occur in the exact same sequence on your microcontroller in order to get the SigmaDSP into the same operating mode as it is when the code is downloaded via SigmaStudio. That's quite a bit of data.
Unfortunately, the data files generated in the project folder by default (hex_program_data.dat, for example) simply contain the program RAM and parameter RAM contents of the project. That will not suffice. You need to get all of the information shown above in order to make your hardware work properly. In other words, you need to emulate the exact write sequence shown in the capture window above.
There is a way to manually copy this information out to raw address + data files by right-clicking one line at a time, as shown here:
(manually exporting raw data)
However, as you can imagine, that's very time-consuming...
Luckily, there's an easier solution!
First, make sure your project is compiled by pressing the Link-Compile-Download button:
(Link-Compile-Download)
Now, click the button to its immediate right, labeled Export System Files:
(Export System Files)
This generates a huge amount of data in the form of C-compatible include files and raw data files, as you have seen. In the case of assembly programming, the C header files are pretty useless. However, the important files for the initialization download are these two files:
(NumBytes and TxBuffer files)
These two files contain all of the data you need to boot your chip. The file TxBuffer contains the I2C address and write data for every address in the download sequence shown above in the Capture Window.
For example, the first two lines of this file are as follows:
0x40, 0xEB, /* (0) IC 1.Start Pulse */0x0A,
If you refer to the Capture Window screenshot above, you'll see that the first register write is to address 0x40EB, and the data is 0x0A.
The next two lines in TxBuffer are as follows:
0x40, 0xF6, /* (1) IC 1.Sound Engine Run */0x00,
If you refer to the Capture Window screenshot above, you'll see that the second register write is to address 0x40F6, and the data is 0x00.
And so on....
The file NumBytes accompanies TxBuffer in that it shows how many bytes are included in each transaction. For the first two examples I showed above, there are 2 address bytes and 1 data byte. So, as one might expect, the first two lines of the NumBytes file are:
3,3,
When you get down to the program and parameter RAM downloads, you'll see much larger numbers like:
702,226,
The main idea is that you can parse these two files and easily create an I2C write function that will download all of the data in order. No C compiler required!
The NumBytes and TxBuffer files for my example project are attached for your reference.
This FAQ was generated from the following discussion: Loading the DSP via assembly language
I'm trying to use this technique to program the 1761 on our system and I'm not having any success. I took the NumBytes.dat file and for each entry in that file I use that many bytes from the TxBuffer.dat file. The first two are used as the register. If the register is 0x0000, it's a delay and I wait for 100mS and ignore the following two bytes. What I have for code is this:
for (i=0; i<(sizeof(White_Noise_Numbytes) >> 1); i++) {
DSP_reg = White_Noise_TxBuffer[j++]; // high byte
DSP_reg = (DSP_reg <<8) | White_Noise_TxBuffer[j++]; // low byte
if (0 == DSP_reg) { // there is no address 0, so delay
Delay(100);
j = j + 2; // skip over the two data bytes
} else if (3 == White_Noise_Numbytes[i]) { // Just a single byte
write_dsp(DSP_reg, White_Noise_TxBuffer[j++]);
} else { // multiple bytes
DSP_count = White_Noise_Numbytes[i] - 2;
write_dsp_block(DSP_reg, White_Noise_TxBuffer+j, DSP_count);
j = j + DSP_count;
}
write_dsp() is an I2C routine specific to our SiLabs chip that uses the first arg as the register and the second as a single byte, It's doing the I2C write directly with the SiLabs registers and I can see on a logic analyzer that it's working correctly. Similarly, write_dsp_block() uses the address as well as a pointer to a block of data and uses a third count argument. The analyzer confirms that those bytes look correct and get ack'd by the DSP.
The two data structures are the numbytes.dat and the txbuffer.dat files with array inits wrapped around them like this:
unsigned short White_Noise_Numbytes[] = {
3,
8,
(more of the same)
char White_Noise_TxBuffer[] = {
0x40, 0xEB, /* (0) IC 1.Sample Rate Setting */
0x7F,
0x40, 0xF6, /* (1) IC 1.DSP Run Register */
0x00,
0x40, 0x00, /* (2) IC 1.Clock Control Register */
0x0F,
0x40, 0x02, /* (3) IC 1.PLL Control Register */
0x00, 0x01, 0x00, 0x00, 0x20,
0x03,
0x00, 0x00, /* (4) IC 1.Delay */
0x00, 0x64,
Is it as simple as using the lengths in numbytes to then pick an entry out of txbuffer, spew each of them out via I2C and watch it work? Is there another trick and if anyone has ever done it on any processor, is there code they can share? I'll swap my SiLabs Gecko code for it, or pay for your next six-pack.
Thanks!
Howard