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 (https://soundcloud.com/slack3r/slackdsptest1)
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 (http://www.aronnelson.com/gallery/main.php?g2_view=core.DownloadItem&g2_itemId=50644&g2_serialNumber=1)
Digital schematic (http://www.aronnelson.com/gallery/main.php?g2_view=core.DownloadItem&g2_itemId=50648&g2_serialNumber=1)
Device info
dsPIC33FJ64GP202 (https://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en532308)
23K256 (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039)
23LC1024 (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en559066)
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?
very cool....... 8)
Excellent stuff Ian.
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 (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 (https://github.com/slackDSP/slackdsPIC) very much a work in progress.
^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?
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 (https://www.microchip.com/pagehandler/en_us/devtools/mplabxc/) 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.
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.
According to the MPLAB XC site:
QuoteMPLAB® 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
^Limited code optimizations
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/
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.
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?.
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.
Quote from: slacker on April 03, 2014, 06:02:14 PM
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.
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?
QuoteBuilding 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 (http://www.obddiag.net/picprog.html)
maybe the dspIC33FJ64GP202 chip you are using is different? i would be interested in a DIY kit.
cheers!
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/ (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.
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.
i'd defo be up for a nice long delay programmed chip.. ;)
could the delays be 'jumped' like in the abductor?..
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 (http://mrmackey.no-ip.org/elektronik/ds30loader/downloads.php) for more info on the bootloader.
(http://img.tapatalk.com/d/14/05/27/ygereget.jpg)
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.
sick, nice one ian.. 8)
look forward to the 8 seconds version man.. 8)
nice one Ian.
I must get back to the proper digital stuff soon. Your analogue schem doesn't mention the pot values - are they all 10k?
Awesome work man! Just think how good it would sound with Germanium voltage regulators! :icon_mrgreen:
Did you write your own pitch shift code? I have been trying to fix the ramp LFO simulation in SpinCAD Designer for about a year now, what a pain! I think I'm getting close, but some of the sounds that come out in the meantime are occasionally hilarious.
Cheers folks :)
I've got some more chips on the way Rob, hopefully that solves the problem otherwise I'm a bit stumped.
Pot values aren't critical Sam, anything from 10k to 100k should work fine, I'm using 100k because I had them to hand.
Germanium voltage regulators, could be just what I need to mojo up those 1s and 0s. Yes I wrote my pitch shift code, it's essentially same method the FV-1 uses, as described in the LFO appnote. The actual pitch shifting was pretty straightforward but it took me ages to get the cross fading between the two taps working properly, Sean Costello's excellent articles on the subject really helped me understand the concept http://valhalladsp.wordpress.com/2010/05/06/digital-pitch-shifting-early-work/ (http://valhalladsp.wordpress.com/2010/05/06/digital-pitch-shifting-early-work/). The code is here https://github.com/slackDSP/slackdsPIC/blob/master/slackdsp.c (https://github.com/slackDSP/slackdsPIC/blob/master/slackdsp.c) afraid I haven't got round to commenting or documenting it.
After a fair bit of head scratching I finally figured out the problems I was having with the 23LC1024 SRAM. Thinking I'd damaged them by leaving one of the pins floating I added the required pull up resistor and stuck a new chip in, still the same problem, no output from the chip. Totally confused me because I had them working on the breadboard albeit with some distortion, which I put down to the missing pull up. I started poking about with the scope and noticed that if I probed the clock pin the thing would work, I then tried holding a resistor between the clock pin and ground and that made it work as well. Armed with something to google I found a forum post about the exact same problem, luckily with a solution :)
The problem was with the set up of the PIC's SPI port used to talk to the SRAM, this works by having a clock signal and a data signal, on the rising edge of each clock pulse the SRAM reads in a bit of data. There's a setting that tells the PIC to change the data either on the rising edge of the clock or the falling edge, I had this set wrong so I was changing the data on the rising edge, which is the same time the SRAM is trying to read it so it was just reading garbage and as a result it wasn't doing anything useful. Correcting it to change the data on the falling edge and everything worked as it should because the data has time to settle before the next rising edge comes along and the SRAM tries to read it. What must have happened was that the capacitance of the scope probe was enough to slow the rising edge of the clock down just enough for the data to have settled, the breadboard must have done the same thing but not quite as well which probably explains the distortion. No idea why the 23K256 works fine with the same incorrect settings, there's no obvious difference I can see in the data sheets.
Here's a demo with 8 seconds delay. Starts with the delay set a 2 seconds, then switches to 4 and finally 8, then I loop it and finally play the loop in reverse. The hiss in the clip is from my camera not the pedal. Apologies for the fret wankery I got a bit carried away.
:icon_eek:@#$%ing @#$%ing @#$% :icon_eek: @#$%ing :icon_eek: @#$% ...man i @#$%ing want/need one of those!!!!!!!!..or even 2.. :icon_twisted:
totally epic work man!!!!!! UBER COOL. 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8)
could it have a time indicator..like a countdown or something to tell you when the max loop is near/end type thing?..
what size box is that?..
Cheers Rob thought you'd like it. It still needs work, it's probably too noisy for general use, it's OK at bedroom levels but at gig levels it adds a noticeable amount of hiss and noise but it's proved the concept and given me something to try ideas out with.
I like the idea of a time indicator, you could use the LEDs as some sort of indicator maybe have one light up as you get near the end, or have it flash and make the speed increase as you get near the end.
The box is a 1590XX, the same size as the big EHX pedals.
yeah man love it, something really cool to look forward to for sure.. 8)
a delay time indicator would be useful too... me and my led addiction eh...... ;D
Tap tempo delay and flashing LED is doable. If I switched to a bigger PIC I could go the whole hog and fit an LCD screen that could do all sorts of cool stuff, that would mean going to SMD though, not sure I fancy that for now.
excellent,
yeah smd is off my list, my eyes are too buggered ... :)
Quote from: slacker on April 04, 2014, 01:03:24 PM
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.
Slacker, how do know how much time it takes to write the RAM?
Sorry for the bump!
I can't remember exactly how but I measured it, the code sets the chip select pin low at the start of the read/write sequence and high again at the end so I probably just measured that with my scope. Most of the time it takes is the actual communication between the PIC and the SRAM, with a 10Mhz SPI clock each bit takes 100ns so each byte takes 800ns, reading/writing a 16 bit value takes 5 bytes, one byte to set read or write mode + two address bytes + two data bytes so that's 5 x 800ns = 4us. That's the real limiting factor, which you can only get round by increasing the SPI clock speed.
Hey, snap! While you've been busy with this, I've been working on something virtually identical:
http://electricdruid.net/diy-digital-delay/
Same idea - dsPIC with serial SRAM, for the same reasons (handy DIP format for prototyping). The major difference is I was using the 33FJ64GP802, since it's one of the two chips that includes a 16-bit DAC for the audio output. That makes life a bit easier. I suppose the other difference is I used ASM not C. Otherwise, pretty similar - I've also got a 32KHz sample rate - as you say, convenient. I had similar problems with getting the SRAMs running, needing to put pull-ups on the correct lines. I've been playing with delays, and have added high and low shelving tone filters which give a nice effect with the long delays. Currently I'm struggling with working out how best to make the delay time smoothly variable, since I'd like to add an expression input for that.
It's very interesting to see how someone else has approached something you've worked on yourself. Thanks for sharing, Ian.
Tom
Great minds etc... That looks very interesting look forward to hearing it in action, like you say the audio quality is plenty good enough for delay based effects. Be very cool if you end up selling programmed chips for it as you'd have a delay people could just build but those who wanted to could develop their own firmware for it, might get more people into DSP.
I'd be interested to see what you come up with regarding getting smooth variable delays, that's something I haven't figured out yet either, Cloudscapes did a similar project and he seemed to have it cracked, I'll see if i can find a link to it.
I was going to try one of the chips with the built in DACs, not sure why I didn't in the first place but instead I redid the whole thing using a WM8510 audio codec, this gives you 24 bit audio at up to 48Khz, although I'm still using 16 bit at 32Khz. The sound quality is much better but it does mean at least some SMD is involved.
I need to get round to posting it here.
For smooth variable delay, I had the entire delay line and sample address counter in a timer, and elsewhere had potentiometer adc input control the timer's reset. it was pretty smooth. I'd range it from something like 6khz to 72khz (from memory, so I may be off a little).
input pots I'd sample only 50 times a second or so, including thje delay time pot. you don't need to waste cycles for something as slow as a human hand turning a pot. but where I'd update the timer period register was in the timer interrupt's routine. same place I put all the audio-rate stuff, like cycling memory address, using the dac and adc, etc. I found that if I updated the period register at a slower rate (like at the same rate as sampling input pots) I''d get occasional audible glitches and pops where it would drop a few samples. I think it was when it would update the period register to a value much lower than the counter was currently at. something like that.
Quote from: cloudscapes on July 04, 2016, 07:38:36 PM
For smooth variable delay, I had the entire delay line and sample address counter in a timer, and elsewhere had potentiometer adc input control the timer's reset. it was pretty smooth. I'd range it from something like 6khz to 72khz (from memory, so I may be off a little).
input pots I'd sample only 50 times a second or so, including thje delay time pot. you don't need to waste cycles for something as slow as a human hand turning a pot. but where I'd update the timer period register was in the timer interrupt's routine. same place I put all the audio-rate stuff, like cycling memory address, using the dac and adc, etc. I found that if I updated the period register at a slower rate (like at the same rate as sampling input pots) I''d get occasional audible glitches and pops where it would drop a few samples. I think it was when it would update the period register to a value much lower than the counter was currently at. something like that.
Ok, so you went with a variable sample rate scheme. I can see the advantages!
Currently my code works the other way - a write pointer and a read pointer chasing each other around a circular buffer (the whole RAM). Changing the size of the gap between the pointers alters the delay time. The sample rate stays the same. This has the advantage that I've always got the same bandwidth, so no crunchiness at longer delaytimes, and no audible aliasing creeping in. The disadvantage is that that if you jump the read pointer to a new location, you get a glitch. Your variable sample method is guaranteed to read out every sample - my way isn't. The only way round that is to either crossfade between the old location and the new, or to "speed up" the read pointer so it (say) starts to catch up the write pointer. Since this is a fixed sample rate, that means doing some interpolation to find samples in-between samples, and if you push it too far, you get weird artefacts, but if you don't, it takes ages to change delay time. I'm not sure what to do for the best.
I've been doing a few other things while I mull it over, hoping that inspiration might strike if I put the project down for a bit, but so far, no luck.
Tom
I can upload my program for the delay I wrote later today, it's in C and used in a PIC32. It's a bit messy and has a lot of extra features (like reverse delay) you don't need but maybe it'll provide a tiny bit of help. This is my build log, with the finished delay at the last couple pages of the thread.
I haven't messed with interpolation at audio rates since I'm bad at that stuff. Did do a bit of cross fading.
http://www.diystompboxes.com/smfforum/index.php?topic=109314.0
Personal opinion, I think fixed bandwidths/samplerates in a delay is a bit unnecessary. ;) You would need more aggressive filtering obviously if you're doing variable, but, shrug. It might come down to personal taste, but I don't mind that it gets a little crunchy at the low end of the bandwidth in a variable delay. Nostalga trip to 80s/90s digidelays where everything ran on a variable master clock before SHARC dsps took over.
If you want to stick with a fixed bandwidth/samplerate, you might be able to avoid the glitch by having the program keep track of areas of memory that are "unsafe to read", until new audio data is written to it. An interesting detail on how older digidelays switched over to longer delay ranges (kind of what you're doing, increasing the memory size for longer delay). If I switch my PDS8000 from a short delay range to a long delay range, it "switches modes" for a couple seconds where there is absolute silence. I think it goes through the entire memory once over in silence to avoid glitches.