I finally have a project I want to pursue involving the dsPIC, involving generating a load of sine waves. So, is the PICKit 3 an unusable POS, or will it work? Will there be any updates in the future? Is there a possibly better option out there for me?
Thank you all for the help, and for the great forum.
For this application, I'll need to most powerful dsPICs I can get my hands on. Heck, the PICKit3 might not even be good enough, since it can't program the 32-bit chips (though I don't know if Microchip are making 32-bit dsPICs at the moment).
Maybe I should explain my application a bit more.
I want to build an additive synthesizer (of the musical variety). The best of the best additive synths have 128 sine waves (partials) per voice, where each partial gets its own pitch and amplitude envelope. Now, there's a metric assload of processing power required for that (each voice is basically a high-powered SHARC processor), so I had my own ideas for a voice design that is simpler.
Each voice (one note pressed on the music keyboard) which consists of a minimum of 32 partials, will have one amplitude envelope. Each partial will then get a coefficient that is applied to the envelope and then that result is applied to the amplitude of the partial. So all partials get affected by a single envelope, but not equally. You could even do negative coefficients (the partial gets louder as the envelope goes down). 32 partials might sound like a lot, but keep in mind that a sawtooth wave at 20Hz and band-limited to 20kHz contains over 2000 partials. If I can get 64, that would be even better. 128 and I'd be over the moon.
I haven't decided yet how to mess around with the pitch of each partial. I might do the same thing, a coefficient applied to an envelope and/or an LFO.
Of course, all of this depends on how much processing power I can get my hands on for each voice, and how well I can code it all. One processor per voice is likely going to be my approach, so the number of total voices, ie, the number of keys on the keyboard that can be pressed and still make a sound, would depend on the number of processors I include. There would be an extra processor for the user interface and managing voice allocation, but I have an idea that might make the second part unnecessary.
Let me know if anything needs to be clarified.
It never was an unusable POS. It was just a very poor upgrade compared to the PICkit2.
It's had lots of updates since I last used it.
Just get one!
Dave.
Look at the PIC32. They should be cheaper than any ARM solution.
Not sure how a PIC32 would compare with a dsPIC for this application, you'd have to do do the leg work to find out.
But if you are going to dedicate one processor per voice, then you might have a fair amount of headroom.
The PICkit3 can program the 32bit PICs.
Dave.
The PICkit3 can program the 32bit PICs.
Really? Looks like you're right, but up until now, everything I was reading said that it couldn't. Oh well, more options for me.
Once upon a time, I had created a sawtooth oscillator in a DSP-oriented programming language that was part of a digital audio workstation (I'm talking about Reaper and JS-Script for those who might know what those are), using the most inefficient method possible: I used the sin() function to generate sine waves of the correct frequencies, multiplied each one by an amplitude coefficient, then added as many together as were needed up until the band limit of 20kHz using a for loop. It wasn't so bad on CPU in the highest notes, but hitting a bass note shot the CPU up to 70-80% on my then 1.8GHz single-core Athlon. That was with all 2000 partials going, and considering that the JS-Script doesn't compile to the most possible efficient code, and the C/C++ sin() function (which is what JS-Script uses) is a fairly inefficient method of generating a sine wave for DSP, I think getting 64 partials out of a modern embedded micro isn't asking for the moon. EDIT: I should point out that all of these calculations were happening 44,100 times a second, too.
This is all back-of-the-envelope, of course. Experiments will need to be done, but I'd like to investigate the possibilities so I don't waste money on dead ends. I don't have that much of it to begin with.
Thank you very much for the help, Dave!
1st... if microchip is producing 32bit dsPIC, and.... the pickit3 cant program it, then the postulate is simple! they must have produced the programmer for it as well! find it in their web if any, if not, then simple also.... they are nuts! they produce an mcu but not the programmer?!
The PICkit3 is capable or programming *every* PIC device from the 8 bit range through to the 32bit range.
Yeah, they don't make it that obvious!
Dave.
The PICkit3 is capable or programming *every* PIC device from the 8 bit range through to the 32bit range.
Yeah, they don't make it that obvious!
Dave.
Yeap, it says so here:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340&redirects=pickit3The PICkit 3 can now also reprogram any PIC microcontroller
with a simple push of a button:
Find out more about Programmer-To-Go function
Although there are some antique PICs like the
PIC16C751 that require UV light
About PIC32's... what I didn't like about them is that they need a cache to load the program memory. If you use the PIC32 without cache, then it behaves as a very slow uC, and it's dissapointing. I tried to generate a square signal by putting a pin on 1 and 0 (a pulse train) and the fastest speed I achieved was 6MHz, running on an 80MIPS PIC32 and enabling the cache.
I'll stick with PIC24F or H until I need more speed.
you are programming in C right?
About PIC32's... what I didn't like about them is that they need a cache to load the program memory. If you use the PIC32 without cache, then it behaves as a very slow uC, and it's dissapointing. I tried to generate a square signal by putting a pin on 1 and 0 (a pulse train) and the fastest speed I achieved was 6MHz, running on an 80MIPS PIC32 and enabling the cache.
I'll stick with PIC24F or H until I need more speed.
Somehow I'm not very surprised
It is quite funny but many "high-performance" MCUs are really quite slow for simple tasks, like bit-banging. They are primarily faster for complex calculations (like DSP-like tasks or similar) with wide data. For example in ARM7, program branches or interrupts are really a performance killer, they like to execute sequentially. Ever wondered why there is a conditional execution option in ARM7 for each instruction? Now you know, no branch overhead! Cortex-M3 seems to be improved these, but haven't tried it out yet.
It's a bit like comparing a large passenger airplane maneuverability to a top-notch military fighter aircraft
Regards,
Janne
wide data. For example in ARM7, program branches or interrupts are really a performance killer, they like to execute sequentially. Ever wondered why there is a conditional execution option in ARM7 for each instruction? Now you know, no branch overhead! Cortex-M3 seems to be improved these, but haven't tried it out yet.
if you are talking about single cored CPU, then there is no such thing as parallelism, only "virtual" or "simulated" paralellism. and worst, with all those scheduling and prediction crap overhead. AFAIK.
wide data. For example in ARM7, program branches or interrupts are really a performance killer, they like to execute sequentially. Ever wondered why there is a conditional execution option in ARM7 for each instruction? Now you know, no branch overhead! Cortex-M3 seems to be improved these, but haven't tried it out yet.
if you are talking about single cored CPU, then there is no such thing as parallelism, only "virtual" or "simulated" paralellism. and worst, with all those scheduling and prediction crap overhead. AFAIK.
Sorry for being somewhat vague, I didn't mean parallel execution, but that program branches (jumps or subroutine calls) or interrupts are relatively "expensive" operation on ARM7 due to pipeline flush etc. Same goes for many other 32-bit CPUs. If you bit-bang on a loop, most of the CPU time is spent in pipeline inefficiency. Try putting several pin-toggles sequentially without any loop and see the toggle rate to dramatically increase.
Another thing which may cause high-end MCU to run slowly is that often the IO-peripherals run in different clock domain than the CPU itself. Synchronization issues between those clock domains will also cause slow down when IO is accessed many times without doing other things.
And finally like mentioned earlier, internal flash is often slower than the MCU itself, so using instruction cache is mandatory to squeeze the performance out of the MCU. Slower 8 bit things are slow enough that flash memory can easily keep up.
Regards,
Janne
About PIC32's... what I didn't like about them is that they need a cache to load the program memory. If you use the PIC32 without cache, then it behaves as a very slow uC, and it's dissapointing. I tried to generate a square signal by putting a pin on 1 and 0 (a pulse train) and the fastest speed I achieved was 6MHz, running on an 80MIPS PIC32 and enabling the cache.
I'll stick with PIC24F or H until I need more speed.
Somehow I'm not very surprised
It is quite funny but many "high-performance" MCUs are really quite slow for simple tasks, like bit-banging. They are primarily faster for complex calculations (like DSP-like tasks or similar) with wide data. For example in ARM7, program branches or interrupts are really a performance killer, they like to execute sequentially. Ever wondered why there is a conditional execution option in ARM7 for each instruction? Now you know, no branch overhead! Cortex-M3 seems to be improved these, but haven't tried it out yet.
It's a bit like comparing a large passenger airplane maneuverability to a top-notch military fighter aircraft
Regards,
Janne
This is where details of the memory architecture of specific implementations can make a big difference, e.g. the NXP ARM7 parts have a 128-bit wide internal flash bus for fast access to sequential instructions, although still not quite as fast as running from internal RAM.
I seriously doubt I'll be using the ARM for this one. I'd rather use a specialist processor, like this Alesis chip made by Wavefront:
http://www.wavefrontsemi.com/products/AL3101pop.htmlThe main reason dsPIC is attractive to me is no other reason than it's available in through-hole models. Surface mount DIY scares me, especially since it would be so easy to blow out a bunch of $8 chips until I get it right. The dsPIC also has two 16-bit DACs, which is useful, though the Alesis chip beats it with four 24-bit DACs. Surface-mount only, though.
you are programming in C right?
Yeap, I'm using C. Here's a link where I found about about the bit-banging actual speed...
http://www.microchip.com/forums/tm.aspx?m=500760Assembly language for PIC32 works with MIPS32 instructions and those ones are kinda weird.
They're so different from the PIC16 and 18 instructions.
It is quite funny but many "high-performance" MCUs are really quite slow for simple tasks, like bit-banging. They are primarily faster for complex calculations (like DSP-like tasks or similar) with wide data. For example in ARM7, program branches or interrupts are really a performance killer, they like to execute sequentially. Ever wondered why there is a conditional execution option in ARM7 for each instruction? Now you know, no branch overhead! Cortex-M3 seems to be improved these, but haven't tried it out yet.
It's good to know that other 32 bit microcontrollers also have this problem. I was thinking of dismissing PIC32s until they fixed the flash eeprom read times.
The main reason dsPIC is attractive to me is no other reason than it's available in through-hole models. Surface mount DIY scares me, especially since it would be so easy to blow out a bunch of $8 chips until I get it right. The dsPIC also has two 16-bit DACs, which is useful, though the Alesis chip beats it with four 24-bit DACs. Surface-mount only, though.
Don't fear SMD soldering, you can request for free samples from Microchip and they'll send them, no problems at all. So you can try soldering them as many times as you want.
I requested 2 x PIC32MX420F032H which come in a TQFP64 package... built the board and then soldered it. The board is so huge, it occupies half protoboard but it works perfectly. It's helped me to start using this PIC family.
http://img260.imageshack.us/img260/7033/dsc00406wc.jpgTry it, it's good to learn soldering SMD stuff.
Surface mount DIY scares me, especially since it would be so easy to blow out a bunch of $8 chips until I get it right.
I understand, but I've got a plan for myself when I start doing more SMD work than resistors and caps. I've got a heap of old computer cards lying around, and I plan to desolder the chips with a heat gun and resolder them by hand. Ideally I'd reduce some nitric acid and melt the top down to expose the bonding wires so I could test connections, but I may not go that far. It'll be good practice, and should show me if I need more or different equipment to do it properly.
Alternately there are a load of breakout boards out there for SMD chips. I've heard good things about
Schmartboards. If you check them out watch their video, it'll make a lot more sense after you do.
Hope that helps.
Surface mount DIY scares me, especially since it would be so easy to blow out a bunch of $8 chips until I get it right.
scare is not an issue. willing to spend time and learn is.... and willingness to salvage smd parts from dustbin as learning materials
Yeap, I'm using C. Here's a link where I found about about the bit-banging actual speed...
the fastest that i can program a chip to simulate oscillation, or led flip-flop (on-off) is 4 instructions. if anybody can do better, pls let me know, it goes something like:
loop:
bsf PORTB, PB1
bcf PORTB, PB1
goto loop
so for a 80MIPS cpu, its should be 80/4 = 20MHz
there are lot of things going on behind the C that you have no control of, thats the compromise of portability vs speed.
i will surely pick C when i got a super complex real number math algorithm and not care about the speed.
Assembly language for PIC32 works with MIPS32 instructions and those ones are kinda weird. They're so different from the PIC16 and 18 instructions.
microchip got many styles of designing fancy asm structure.
I actually learned MIPS in my ECEN 350 class. It's really quite easy.
Don't fear SMD soldering, you can request for free samples from Microchip and they'll send them, no problems at all. So you can try soldering them as many times as you want.
I requested 2 x PIC32MX420F032H which come in a TQFP64 package... built the board and then soldered it. The board is so huge, it occupies half protoboard but it works perfectly. It's helped me to start using this PIC family.
Try it, it's good to learn soldering SMD stuff.
I use PIC32s as well and program them with the PICkit3 (works awesome!). But I like to use the square kind of breakout boards as they take up a lot less board space.
I buy the ones I like off ebay:
http://cgi.ebay.com/5-pcs-LQFP-64-QFP-64-Adapter-PCB-SMD-Convert-DIP-QFP-64-/350233589737?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item518b8c77e9Surface mount DIY scares me, especially since it would be so easy to blow out a bunch of $8 chips until I get it right.
Like stated above, don't be afraid of SMD. I soldered a PIC32 (64pin TQFP) on my first try, and that was using a $13 soldering station! Now, I don't even consider using through hole for anything as I think it takes up to much space and just looks very "newbish" although I still am a newbie. Plus, all the good components only seem to come in surface mount these days. sparkfun.com has lots of good tutorials on how to go about doing it as well.
Anyway, I highly recommend the PICkit3 and the PIC32 along with the book "Programming 32-bit Microcontrolers in C: Exploring the PIC32" by Lucio Di Jasio. So far my experience has been relatively painless learning the 32bit pics but I have yet to actually put them in a project yet. BTW, MPLAB and the PICkit3 both work perfectly fine and a very painless to install on W7 64 and 32-bit versions. Don't believe all the nonsense out there that says they don't.
I've got the ICD2 currently, it does the job but can be slow and it plays up sometimes when I sleep the computer and can be a pain getting it working again.
Would it be a worthwhile upgrade to the pickit 3?