View previous topic :: View next topic |
Author |
Message |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
OT - Transition to dsPIC from 18F6627 (dsPIC Experts?) |
Posted: Mon Jul 23, 2012 6:15 pm |
|
|
I have a prototype that I based upon the 18F6627 because I had experience with 18F parts and the compiler. The project collects analog samples from a microphone and performs some FFT math (using the Goertzel algorithm). It runs at 40MHz (10MHz w/ x4 multiplier).
Some of the basic hardware I rely on:
1 comparator for wake-up
2 ADCs
2 UARTs
SPI
I would like to have a low power solution, but that is not critical due to the MCU sleeping a major portion of its life.
It is currently running at 5V, but from what I recall that was required by the 40MHz processor speed. I think I can very easily adjust to a 3.3V supply.
Pin compatible w/ the 6627 would be nice but doesn't look possible.
I have looked at the options and tried to decipher the nomenclature and use the parametric search. But, I was hoping for some experienced input on my options.
Can anyone offer any wisdom on picking a replacement part?
Can anyone guess how my performance might be increased? I'm currently able to run samples at about 1Hz with all the math involved.
Thanks in advance,
John |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1908
|
|
Posted: Mon Jul 23, 2012 10:10 pm |
|
|
Timely. I'm presently migrating an entire product family to the dsPIC33 family of processors. I just finished laying out the first two PCBs and now have to start on the code.
I did buy the CCS DSP evaluation board some time ago, and it wasn't difficult at all to do...well anything with it. It's a PIC, and you're using CCS to control it. It's seriously as easy as any other PIC/CCS project you've ever done. Don't be intimidated. |
|
|
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Tue Jul 24, 2012 2:35 pm |
|
|
Thanks.
I guess I'll just have to dive in. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1908
|
|
Posted: Tue Jul 24, 2012 3:26 pm |
|
|
Sorry for being so short yesterday - typing on a tablet isn't fun.
The only gotcha that tripped me up with the CCS DSP Analog kit was the clock. The kit comes equipped with a 12MHz crystal connected to the processor and I had a devil of a time getting the processor to reliably start oscillating using the CCS examples as a template. It took a long time but I finally figured out why - the processor is not spec'd to start at powerup using that particular frequency of crystal (it actually can't), so you must instead power up using the internal oscillator, then switch over to the external crystal. Once I found that out, I had no problems. Search for posts by me and "dspic" around March of this year for the thread & solution. I have to tell you I was a little annoyed that CCS didn't document this little snafu with their DSP kit....to be honest, I'm sure they don't know about it.
Things like DMA are nice to play with on the dsPICs, and I'm still learning that particular set of ropes but as I've said before, CCS still makes things super simple. Just code as you have for the 18 series or 16 series or whatever, and the code you write for the dsPICs will run without any headaches.
From a hardware perspective, just consult the "Guidelines For Getting Started" chapter in the processor's datasheet. The only real hardware change is the addition of a capacitor for the Vcap pin and the possibility of up to 3 ICSP "ports" from which you can choose depending on which one is more convenient once you've laid out your PCB.
I would hazard a guess that your existing application's code, once ported, will run faster on a dsPIC. 16 bit architecture coupled with DSP specific hardware like 40 bit accumulators and a 17 bit multiplier should guarantee this. |
|
|
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Wed Jul 25, 2012 8:38 am |
|
|
Excellent. All really nice things to know. I appreciate the time that you invested to share.
Looks like the hardware swap should be fairly simple. I should be able to just rip up the tracks at the MCU and run them to their new pins. At least for a quick test solution.
Probably my biggest hurdle will be porting 3.249 code.
Thanks again,
John |
|
|
|