This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Anyone need a C2000-based audio F/X processor?

Other Parts Discussed in Thread: TMS320F28069, ENERGIA

I'm about to design a small audio F/X processor and "ROMpler" synthesizer to support several classes next year.  It will mostly be used as a sample synthesizer for music classes, but will double as a general-purpose audio signal generator and effects processor.

The hardware will include:

TMS320F28069

TLV320AIC23 codec with mic and line in, headphone and line out.

MIDI in and out

LTC4053 battery manager

space for up to 2 S70FL01GS NOR flash chips for sample stoage

a bit of EEPROM for parameter storage

USB through the 28069

microSD card reader to load code and wav files

3-axis accelerometer

breath pressure sensor

misc analog and digital I/O for switch closure detection, pressure sensing, etc..

small graphical OLED with select/adjust encoders.

Can function as SPI slave to Arduino, etc.

CAN interface because I really like CAN.

I'm not expecting too much trouble.  The only piece of the hardware/firmware that I haven't already implemented in some form is the USB, and if I can't get that to work, I can hobble along.  I'll put all of the hardware and firmware files onto my lab's site when they're ready.  So I have two questions:


1)  Does anybody care?  As you know, there's a big time difference between writing code that will get the job done and writing code that other people can read.  If there's sufficient interest, I could put some extra care into the documentation.  If not, I'll get some sleep.

2) What hardware did I forget?  I'm pretty sure I've got everything I need, but not necessarily everything you need.  If you think of something that wouldn't take up too much real estate, let me know.  Odds are somebody else wants it too.

Thx,

Jim MacArthur

Harvard Electronic Instrument Design Lab

  • Hi Jim,

    Sounds like a cool project. Are you loading the code via SD card only to update the firmware, or do you want to allow the users of the board to load some of their own custom code to generate their own effects? If the second, what about using one of the smaller variants of the F2837xD devices? These have two C28x cores, so you could build all the code to interface with everything on one core, and then if a user wants to write their own code they can do so freely on the second core? (this family also has more and faster SPI modules...seems like you are going to need quite a bit of SPI bandwidth)
  • Hi Devin,

    Re the two-core 2837x, you've neatly identified the basic problem with the design -- how to combine the tight assembly code necessary to run polyphonic audio with a hackable space for students to add their own processing. I've been dealing with this problem literally for decades, and only recently have some possible solutions appeared.
    The maximum technical sophistication I can expect from my students is the ability to work in an Arduino environment, so full-blown Code Composer Studio isn't going to happen for them. However, Energia is. So a possible architecture for me to consider is, as you suggest, a dual-core 2837x with one core running the serious code and the other running the user code, with both processors loading from the SD card. (I've got some cute code that looks for an xxx.out file on an SD card, then loads and executes it.) That's kind of cooler than my original idea of running the serious code on a Piccolo and the control code on an Arduino or RaspPi, controlling the Piccolo over SPI. So yeah, at the risk of "walking the project upstairs" I look into a 2837x solution, while simultaneously testing my students' reactions to Energia. Thanks for your comment!
  • Hi Jim,

    Using Energia for the second core code would be really cool.

    I think we have released (or will shortly) a launchpad XL based on a dual-core F2837xD. You could put all your external components on a stackable booster-pack and dock them with the off-the-shelf board. Alternately, you could build your board as a launchpad and be able to accept existing or custom booster-packs (see spec's here: processors.wiki.ti.com/.../BYOB. Either way, this could allow you to leverage existing booster packs to keep your HW development focused on audio, and you would have the flexibility to maybe add some interesting features later (e.g. bluetooth or motor control could be interesting).

    (sorry, I don't think I am helping with the feature creep here)