ToneCore DSP Developer Kit Guide - Projects - Audio Artillery

ToneCore DSP Developer Kit Guide

  1. So you want to design your own effects?
  2. Specs
  3. Signal Processing for Dummies
  4. Assembly Programming
  5. Program Flow
  6. Delay Pedal Example
  7. Debug Interfaces
  8. Using the Simulator
  9. Prototyping in Python
  10. Developing under Linux (or OS X)
  11. Code Library

Debug Interfaces

What you really need is a JTAG emulator and maybe an ETM. What you have is a GUI that can read four special memory locations and write four others. Good thing we're real men.

For simple unit testing of a routine you can use the writable debug registers ("Debug write to DSP X") to input values and the readable debug registers ("Debug read from DSP X") to output results. This is quite useful for many things. You can also just output interesting things (for example, the input and output values) to the readable registers. You can't really read the data fast enough but it can give you a clue what is going on (you can see if any signal is getting into your device, for example).

There is one more interface you've probably overlooked. The dev kit pedal is a stereo pedal. Unless you're doing a stereo effect you can shove all kinds of data out the 2nd channel. You could then record both channels into your PC and have a pretty nice waveform of the output of your effect plus some debug value. I haven't done this yet but it is possible.


 

Using the Simulator

Configuration steps:

  1. Start gui56300.exe.
  2. Configure device (Dv0) to be 56364 processor.
  3. Load COFF and select your .cld output file.
  4. Add a working path so that it can find your source code. It didn't work initially for me, but did the 2nd time.
  5. Do normal debugging things (run, stop, set breakpoint, etc). The Source window is what you want to be looking at.
Note that the sample in/out interrupts (esai_xxxx_isr) will not be firing in the simulator, but the main loop will be functional.


 

Prototyping in Python

Because of the difficulty in debugging assembly code on target (and even in the simulator) it makes sense to prototype some things first. I use Python. That way I can get all the kinks worked out of an algorithm and then port it to the native assembly. For more complex things like signal processing I can leverage PyLab to manipulate large amounts of data, graph things, etc.

Here is a simple example of a routine I wrote to do integer multiplication. I first implemented in Python:


(click for full size)

Then copied it into my assembly project, commented out all the Python code, and filled in the equivalent assembly code:


(click for full size)

Note that the selection of registers is arbitrary in most cases. You're limited to A/B registers when doing multiply/accumulate instructions but otherwise it's mostly up to you, you're the compiler. When everything is done you can rip out the Python comments:


(click for full size)

But I usually leave them in. That way if I find bugs I can fix them in the Python version and propagate the change easily.


 
< previous page | next page >