slackdsPIC - some experiments with dsPICs for audio mangling purposes

[slacker]

For the past few months I've been experimenting with dspPICs for creating effects and thought it was about time I posted something about it.

I chose dsPICs because they're relatively cheap, about £4, available in through hole, the development tool Microchip's MPLABX is free and cross platform and they can be programmed using a PicKit2 which I already had. At the minute I'm not actually using any of the built in DSP functionality I chose them more for the speed, amount of memory and peripherals they have.
At the minute I'm using a dspIC33FJ64GP202 which has 64K of program memory, which should be plenty for anything I'm likely to do, my experiments so far haven't used more than 10% of that. It's also got 8k of RAM, which you can use some of to create delay effects, there's enough for chorus/flanging or slap back delays and more interestingly from my point of view pitch shifting .
In order to get some longer delays I took a lead from Cloudscapes and got some 23K256 and 23LC1024 SRAM chips, these are good for a few seconds of delay, and meet the same criteria as the dsPIC, they're cheap and available in through hole.

To get signal in to the dsPIC I'm using the built in 12bit ADC and to get it out again I'm using the chips PWM module as a DAC. 

Anyway enough waffle, here's a sound clip, showing some delay and pitch shifting effects.

Sound clip

Hopefully this gives an idea of the sort of stuff this can do.

Here's the schematics for the circuit used to create the clip above, this is out of date as I've since made some changes to improve sound quality. I'll post some more info about the design and share the code once I've found somewhere suitable to host it.

Analogue schematic

Digital schematic

Device info

dsPIC33FJ64GP202
23K256
23LC1024

[samhay]

Nice work - very cool. I have been taking baby steps down this road, so I'm afraid I have a couple of questions:
Can you still realistically programme dsPICs in assembly, or are you using C?
I take it the analogue filtering on the wet signal is to get rid of PWN noise? Why is that op-amp biased at 3V?

[deadastronaut]

very cool.......

[Ice-9]

Excellent stuff Ian.

[slacker]

Cheers chaps.

Sam, I'm using C I don't think there's anything to stop you using assembly if you wanted to though, for example this is all done in assembly http://burnit.co.uk/sdiy/index.php?page=4xd. I think to use the actual DSP engine you have to use assembly, I haven't really investigated that too much though, it's a bit over my head.
Yeah the filtering on the output is to get rid of the PWM noise, at the minute it cuts above ~2KHz, I've since upped the PWM frequency considerably though so I might be able to raise it a bit.
I take it you mean why 3V instead of 4.5V? The output of the PWM is 0 or 3.3V, which is then filtered by the 1k/22n to give a rough analogue signal. At rest the duty cycle is about 50% so it sits at about 1.65 Volts. To the non inverting input, at frequencies below the filter cutoff,  the stage has a gain of a bit less than 2 and for the inverting side about -1. So if you use 4.5V the output would sit at about 7.4 Volts, which causes loud signals to clip against the positive rail, using 3V makes the output sit a bit below 4.5 Volts. Doing it like this lets you use common or garden TL072s, another way would be to use a fancy pants rail to rail/single supply opamp and bias the non inverting input to 1.65V.

Here's a link to the code https://github.com/slackDSP/slackdsPIC very much a work in progress.

[samhay]

^I take it you mean why 3V instead of 4.5V?
Yeah, sorry I should have had my morning coffee before typing - your approach makes perfect sense for a PWM output. I guess you could bias off the 3.3V regulator supply though...

I was hoping your were going to be using c - I have no great desire to start using assembly again, and am mostly contented using c and the xc compilers (although some of the limitations in the free version are a little irritating). I guess you are running this in linux?

[slacker]

I might try biasing off the 3V3 reg, I avoided it originally because I did that trick on the Echo Base and in hindsight it turned out to be a bit of a mistake. I assumed the reg would give a nice clean voltage but it ended up having quite a bit of noise on it which got into the audio side of things.
Yeah I run Linux, I'm using MPLABX and the XC16 compiler, these are also available for Windows and OS X. I haven't hit any compiler limitations, yet, from what I understand the free 16 and 32 bit compilers aren't as crippled as the 8 bit one.

[samhay]

Fair enough - thanks for the insight.

^ from what I understand the free 16 and 32 bit compilers aren't as crippled as the 8 bit one
That's good news.

[free electron]

According to the MPLAB XC site:

MPLAB® XC Free Edition:

• Supports all the devices and commands of the Standard and PRO Editions
• No time or memory restrictions
• Limited code optimizations
• Unrestricted use—ideal for a low-cost academic or commercial solution
• Allows for all the code optimization and commands of the PRO Edition for 60 days – you decide when to turn it on.
• An option to activate the use of the PRO Edition features and optimizations is included. After 60 days, the compiler will revert back to the levels of the Free Edition

[samhay]

^Limited code optimizations
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

[slacker]

Interesting link Sam, I'd read about the free xc8 deliberately generating poor code but never seen examples before. Not sure if xc16 does the same thing, I think you are just limited by what optimisations you can use.

[MstrKurt]

That's fantastic, Slacker!. Well done!.

EDIT: I seen you utilized the Serial RAM. Was it useful doing this in terms of long delay?, and was it fast enough to keep up with the real time software?.

[slacker]

Thanks, be interesting to see how it compares to your project.

It will depend on how fast your sample rate is as to how long a delay you can get with the SRAM which I guess will be a factor in how useful it is. I'm sampling at 32.768KHz, partly because it seemed like a nice compromise between audio quality and having enough time between samples to do stuff but also because it divides into the amount of SRAM nicely. With the 23K256 you have 32,768 bytes, each byte is 8 bits so as I'm using 16 bits for each sample I need two bytes to store a sample, which means I can store 16,384 samples, which at 32.768KHz gives half a second of delay.
With the 23C1024 I can store 65,536 samples which gives 2 seconds of delay. If you lower the sample rate you can get longer delays, for example 8KHz gives 8 seconds of reasonable quality delay with the 23C1024. The delays in the sound clip I posted are done with the 23K256 at 32.768KHz.

Whether they are fast enough will again depend on how fast your sample rate is and how fast you can run the SPI clock. I'm using a 10MHz SPI clock and to read or write a sample takes about 6uS for the 23K256. At 32KHz I have about 30uS per sample to do stuff, so I can do maybe 2 or 3 reads or writes per sample depending on what else I'm doing. This is fine for simple delays where you just write a sample to the SRAM and read another one out but you probably couldn't do a reverb or anything else needing multiple reads and writes.
Using the PIC's internal RAM is much faster but to get ones with enough to do more than short delays means going to large pin count chips in DIY unfriendly packages.

[slacker]

Interesting link Sam, I'd read about the free xc8 deliberately generating poor code but never seen examples before. Not sure if xc16 does the same thing,

In the interests of science I thought I'd do a quick test to see if the free xc16 compiler was crippled in the same way as xc8. I compiled my code using no optimisation and optimisation level 1 which is the highest you can use in the free version and saved the hex files. I then installed the 60 day trial Pro license and compiled the code again using no optimisation and level 1. I then used md5sum to compare the hex files with the ones produced by the free version which showed that the files were identical in both cases. This would suggest that there's no deliberate crippling of the compiler and the only differences are the optimisations you can use.  

[kingswayguitar]

slacker (or anyone else)
i'm light years away from any microcontroller stuff but if one wanted to get started i read that a DIY programmer (pickit2 clone) requires another programmer to get it started. is there any truth or any way around it?

Building PICKit 2 clone is ... a chicken-egg problem as another programmer is required to program the firmware into the PIC18F2550

from: http://www.obddiag.net/picprog.html

maybe the dspIC33FJ64GP202 chip you are using is different? i would be interested in a DIY kit.
cheers!

[slacker]

Yes, if you want to make your own Pickit2 clone you have the chicken and egg situation of needing a programmer to program your programmer. There's a few ways round this, in no particular order.
Buy a real pickit2/pickit3 or a clone instead of making your own.
Find someone to program the PIC18F2550 for you.
If you have a computer with a serial or parallel port you can make a programmer that uses either of those, have a look here for info http://www.members.aon.at/electronics/pic/picpgm/ I've used the JDM programmer in the past. You could just build that on breadboard and use it to program the PIC18F2550, or skip building the pickit2 and just use one of those programmers, that software supports most PICs including the one I'm using.

At the minute my project needs a programmer to load the firmware to the dspPIC but I'm planning on adding a bootloader this would allow the firmware to be loaded using a USB to serial cable or a real RS232 serial port. This is a nice cheap solution, USB to serial cables can be had for a few £/$.
You still have the chicken and egg situation in that you need a programmer to get the bootloader on to the to chip in the first place, what I'd probably do if there's any interest is sell pre-programmed chips.

[kingswayguitar]

Thanks for the link and the advice

I'm not quite there yet but if a pre-programmed IC is in the $5-10 range I'd go for it and then have it for a month or so down the road when I get cracking.  I was really thinking of the same IC you used for you project dspIC33FJ64GP202, the 18F was just an example from some internet research.

[deadastronaut]

i'd defo be up for a nice long delay programmed chip..

could the delays be 'jumped' like in the abductor?..

[slacker]

Got round to boxing this up, as I mentioned earlier I've also added a bootloader to the dsPIC allowing it to be programmed using a USB to serial cable from Windows, Mac or Linux machines. http://mrmackey.no-ip.org/elektronik/ds30loader/downloads.php for more info on the bootloader.



Here's a little demo showing a 2 second delay, I was hoping to do one showing the 4 or 8 seconds using the 23LC1024 SRAM chips but I'm having some problems with them. I didn't read the data sheet properly and missed that one of the pins is supposed to have a pull up resistor and I just had it floating so I might have damaged them or I might have some other software or hardware issue, bit strange as I had them working previously.
In the demo the delay time is set by a pot and one of the switches doubles/halves the delay speed, the other switches between delay and looping mode and switches the LEDs to show which mode it's in.

[deadastronaut]

sick, nice one ian..

look forward to the 8 seconds version man..