I'm curious who else is using these, and what your setup is. I have a development board and compiler from mikroElektronika. The board is great, but I can't say the same about their C compiler package. It is terribly inefficient, and the software simulator is unreliable. I'll spare the specifics unless anyone needs to know.

I've been using a dsPIC30F4013. Until a couple days ago I was using standard PIC functions, but now I'm starting to incorporate the 40-bit accumulator and it is very nice.

What other compiler options are out there? I know Microchip has C30 for $495.

I tried the MicroChip C30 compiler for the PIC24 a bit, it seemed OK to me, be it a bit inefficient with the standard settings (I didn't check the optimizer as I was not interested in that aspect at the time, I wanted the generated code to be as readable as possible instead). There might still be a student version of the C30 compiler to check it out for 30 days with all optimization options available ... ah yes, here it is, and full featured for 60 days even.

I did use the emulator extensively for the pic24 (to test some library assembly code that I wrote) but only for code not involving peripherals, it seemed OK to me for both C and assembly (one particular nice feature was that debug messages can be sent to the IDE using printf statements).

Don't know if the MicroChip IDE is able to communicate with the board you bought though (for programming and debugging)._________________Jan

I think highly of PICs, especially these dsPICs, however I cannot program them because I have a Mac. It is completely irresponsible for Microchip to put out such shoddy software on only one platform and then ask money for it. There are all sorts of cross-platform applications out there so I see no reason for Microchip to be so ignorant in their software development practices.

Yes there is some freeware for Mac, but not one simulator and how am I to develop microprocessor code without a simulator (or an emulator for that matter)? Also the tools are sketchy at best. Linux has a complete toolkit but I don't know how good it is. And the PC tools are expensive and don't always work.

I've been using dsPICs for pro modular synth products for a couple of years now. They're very useful for certain things like oscillators, effects, communications, etc.

The dsPIC30 series parts are a bit slow and power hungry, but have the advantage of running from 5V supplies for those who still haven't made the jump to low-voltage digital. The dsPIC33 series parts are a bit faster, have lots of interesting peripherals, plenty of RAM and Flash and consume a bit less power. Both families are available in PDIP packaging, so they are very DIY-friendly.

dsPICs compare well with other embedded processors from a function vs cost standpoint. The DSP features are somewhat limited by the standards of pro-audio DSP, primarily due to the slower CPU speed and 16-bit wordsize - most pro-audio uses parts that run several hundered MHz and have 24 - 32-bit data words. Despite that, a 16-bit dsPIC can execute some DSP functions much faster than more conventional MCUs such as the ARM family and that makes it attractive for some applications.

As noted elsewhere in this thread, the development tools are a bit of a choke-point. There are really only two ways to code a dsPIC - either using Microchip's free MPLAB IDE, or on Linux / Cygwin with the open-source version of the dsPIC GCC compiler. It might be possible to get GCC running on a Mac, but then you're stuck without a way to load code into the hardware. As with many engineering applications, if you don't have a WinXX system handy you'll find that it's tough to get much done.

I like dsPICs and I've really come to appreciate the architecture and development environment - despite being locked into WinXX, MPLAB is a fairly decent tool and the free student version of the C compiler works fairly well, even though it only allows optimization level 1. With the recent introduction of 33-series parts that have on-chip audio-quality DACs, I've been able to crank out a number of interesting synthesizer functions with a minimum of hardware.

Does MPLAB support inline assembly within C? Also, does it give a breakdown of the time each line of C code takes to execute?

I've been using the 30F4013 to control older +5V sound chips, and compared to the chip's I'm driving they're not terribly power-hungry. I guess that's the difference 20 years of technology can make. The chips I use at work are all 3.3V, 1.8V, 1.5V, so I cringe every time I calculate power consumption on my personal projects. An Atari Pokey running at 2MHz takes 125mA at +5.

When I get into designs that use only one processor I'd like to go with 3.3V, but by then it might be worth switching to floating point and getting a 32-bit architecture all at once. How much current does the 33F series take at 40 MIPS? Does it use the same system of 4 clock cycles per instruction?

So far the only development tools I've used have been for dsPIC, SAM7, and Altera FPGAs. Setting up for SAM7 was a nightmare, and scared me back into dsPICs for a while :)_________________Software and Hardware Design

Does MPLAB support inline assembly within C? Also, does it give a breakdown of the time each line of C code takes to execute?

MPLAB C is a variation of GCC, which does support inline assembly. Also, it's extremely easy to link in assembly-coded subroutines. MPLAB C doesn't explicitly tell you what the execution time of each line of code is, but you can pull up the disassembly listing which shows the C source interwoven with the resulting assembly and get a pretty accurate estimate from that.

skrasms wrote:

How much current does the 33F series take at 40 MIPS? Does it use the same system of 4 clock cycles per instruction?

In my experiments, depending on how many peripherals are in use a typical 40MIPS dsPIC33 processor project is pulling 70-80mA. Compared to roughly 2x that for the same application in a dsPIC30F part it's not too bad. Compared to an ARM7 processor from Atmel or NXP which would pull about 30mA running at 40MIPs it looks like a lot.

skrasms wrote:

So far the only development tools I've used have been for dsPIC, SAM7, and Altera FPGAs. Setting up for SAM7 was a nightmare, and scared me back into dsPICs for a while

Building an ARM GCC application from scratch does take a fair amount of setup & configuration. After you've done it once though you can build on that for the next project and it's not so bad.

Can anyone compare and contrast dsPIC vs PIC32? My friend has been trying to get me into PIC32. I have the most experience using AVR.

Inventor I think you'll find lots of EDA tools that are only for Windows and possibly Linux. The tools are very complex and cost a lot to maintain, its easy to see why they run on few platforms and often have bugs. I guess there are just too few people using the tools to give them away. I would much rather be working on Linux or MacOS but I have come to accept that Windows is required for majority of engineering work.

Inventor I think you'll find lots of EDA tools that are only for Windows and possibly Linux. The tools are very complex and cost a lot to maintain, its easy to see why they run on few platforms and often have bugs. I guess there are just too few people using the tools to give them away. I would much rather be working on Linux or MacOS but I have come to accept that Windows is required for majority of engineering work.

Yes, you are definitely correct in that, urbanscallywag. It's been nearly 10 years since I worked in engineering, well 8 anyway, so I forgot how PC dominated the industry is. My hatred of Microsoft after decades of being punished by their horrible software has made me grow a bit cold-hearted, unfortunately. I insist on cross-platform freeware tools and that limits me sometimes, i.e. no PICs in my hobbying. Oh well, there is plenty to do without submitting to the evil empire of Microsoft. To each their own I guess._________________"Let's make noise for peace." - Kijjaz

Can anyone compare and contrast dsPIC vs PIC32? My friend has been trying to get me into PIC32. I have the most experience using AVR.

I've looked briefly at the pic32 (but did some stuff on an evaluation board like a year ago ... so I forgot a lot ) and decided I don't need it yet ... anyway, apart from the obvious 16 vs 32 bit and a different architecture (pic32 is more von Neuman like where dsPIC resembles more the "old" PICs 16, 18 etc.) it's not a DSP although there is a DSP library for it :

With the latest release of MPLAB C32 compiler v.1.04, Microchip has added a complete set of DSP functions for the PIC32 to complement the standard math libraries.

and also :

Quote:

Once I reassured him that the PIC32 was a very simple, general purpose, 32-bit microcontroller that just happened to run C code very fast, I saw him sigh with relief. He grabbed a copy of the brochure and disappeared rapidly in the crowd heading toward the development tools counter.

It seems to be targeted to fight the Arm processor._________________Jan

Thanks for the information. My real interest in PIC32 are the peripherals and ease of use of them. Things like ADC, USB, and DMA transfers are pretty neat. I would like to do ADC or USB DMA transfers to FPGA.

I'm curious who else is using these, and what your setup is. I have a development board and compiler from mikroElektronika. The board is great, but I can't say the same about their C compiler package. It is terribly inefficient, and the software simulator is unreliable. I'll spare the specifics unless anyone needs to know.

Instead of using the famous open platform like Wiring, Arduino. I have LV24-33 and MikroBasic and use this board as a sensor interface. And I'll use dsPIC in some art projects.

Hello! Not my first post, but my previous user name was inaccessible for some reason.

I've been throwing ideas around for a while concerning DSP chips and synth design, and am finally ready to make them a reality. I had settled on developing w/ the dsPIC33 series using the Mikro Elektronika EasydsPIC4 board + ME C compiler, though after reading this thread I'm not so sure.

Is the ME C compiler really that bad? And if so, bad relative to what? I haven't used C since high school, thought I am familiar w/ Python, Pure Data, and fairly complex CMOS circuit design. As long as there is decent documentation and the ability to test/debug, I'll be fine.

Would the ME board be a bad choice? If all the compilers are bad, is the ME one significantly worse?

I was hoping to dive into this stuff at the end of the month, but now I'm hesitant. Perhaps there is a resource for beginners detailing the pros and cons of whatever options are available?

Looks like a nice board with lots of peripherals for learning stuff. I'm not sure if it supports the dsPIC33 series parts though - it appears to be set up for a 5V supply and the analog reference is 4.096V - well outside the max range for the '33 series parts.

Don't know why you'd need to fool with a 3rd-party C complier either. MCHP provides the 'student' version of theirs for free and the only downside is that you're limited to optimization levels 0 and 1 which I've found work just fine.

Overall I'm very happy with the things I've done using the dsPIC. You can see some of my projects, both commercial and personal here:

I was unsure if that board supported the dsPIC33 as well as the 30, but assumed that 'dsPIC' was a blanket term for the entire family and that it wouldn't be a problem. We all know what happens when we assume!

If I were to use the free IDE/compiler, would the process of debugging be compile to assembly > load to chip via the board's software > test > repeat? I'm really not sure how real-time this sort of thing is done, but it seems slower then I had pictured. Python and PD probably ruined me in terms of patience.

One thing I have been looking for, but have not found yet, is some functioning examples of basic synth functions (sine wave generation, amplitude control, etc). I found some examples in ME C, but they all relied on libraries not included in the examples, making them worthless to me. Is there a decent book on the subject that I should put on my list?

Judging by those Modcan modules you designed, I seem to be talking to the right person! Thanks for nudging me in the right direction.

If I were to use the free IDE/compiler, would the process of debugging be compile to assembly > load to chip via the board's software > test > repeat? I'm really not sure how real-time this sort of thing is done, but it seems slower then I had pictured. Python and PD probably ruined me in terms of patience.

The MCHP MPLAB IDE is pretty well integrated - you edit / compile / debug all within one application. There's source-level debugging for both assembly and C. The main slowdown comes when your programming a large device - that can take up to a minute or so, but it's really not that big a deal. It works well for me - no idea how it compares to what you're used to.

Astronomical Horse wrote:

One thing I have been looking for, but have not found yet, is some functioning examples of basic synth functions (sine wave generation, amplitude control, etc). I found some examples in MC C, but they all relied on libraries not included in the examples, making them worthless to me. Is there a decent book on the subject that I should put on my list?

There are a lot of resources online you can use. One that I came across recently is this:

Seems to have a fair amount of good synthy stuff in it. But when it comes down to it you'll still have to translate it into your target hardware & optimize for the resources at hand. That's part of the fun.

Very cool. This Sound Processing book looks great! No doubt it will come in handy.

Any other useful tips to get me on a proper start? Little experiments that lit that bulb over your head?

You were right, the ME dev boards are dsPIC30 only. The examples + goodies that it provides are very tempting.. would I be making a mistake in using the 30s? Still unsure of the practical differences between the 30 and 33 series. Is there a comparable beginner's package out there?

Hopefully I'm not bugging you with all this! There are so few people who are knowledgeable on this particular subject that it would be unwise not to seize the opportunity to get educated. _________________Astronomical Horse

You were right, the ME dev boards are dsPIC30 only. The examples + goodies that it provides are very tempting.. would I be making a mistake in using the 30s? Still unsure of the practical differences between the 30 and 33 series. Is there a comparable beginner's package out there?

The ME dev boards look fine, although the peripherals maybe not well suited for synth applications. I started off just using bare PDIP parts in a plug-in protoboard, but if you're not hardcore into hardware then that may not be a good solution.

The '30 parts are probably fine - downside is that they're an evolutionary dead-end - no new parts in that family. They're slower (30MHz instead of 40MHz on the '33 parts) and don't have as many new & interesting peripherals. I like the new dsPIC33FJXXGP80X parts that have a built-in audio-speed stereo DAC that's good for synth stuff.

If you don't go with the ME board you'll need a programmer - I use and MCHP ICD2, but there are 3rd-party programmers that work as well. MCHP also has a cheaper programmer that may also work with the dsPIC.

Astronomical Horse wrote:

Hopefully I'm not bugging you with all this! There are so few people who are knowledgeable on this particular subject that it would be unwise not to seize the opportunity to get educated.

Looks like a nice board with lots of peripherals for learning stuff. I'm not sure if it supports the dsPIC33 series parts though - it appears to be set up for a 5V supply and the analog reference is 4.096V - well outside the max range for the '33 series parts.

Don't know why you'd need to fool with a 3rd-party C complier either. MCHP provides the 'student' version of theirs for free and the only downside is that you're limited to optimization levels 0 and 1 which I've found work just fine.

Overall I'm very happy with the things I've done using the dsPIC. You can see some of my projects, both commercial and personal here:

Hi Eric,
I really like your work!
Have you done much with PsOC? I have done no programming, but i've started to look at what can be achieved with programmable chips, mostly inspired by some of the things you've done.
I like how PsOC uses a graphical programming environment, which i think makes things much easier to program (i think they call it that).

Have you done much with PsOC? I have done no programming, but i've started to look at what can be achieved with programmable chips, mostly inspired by some of the things you've done.
I like how PsOC uses a graphical programming environment, which i think makes things much easier to program (i think they call it that).

A few years back I did a simple little digital VCO with a low-end PSoC. Here's a link to it:

During that project I found the PSoC CPU architecture to be somewhat underpowered for synthesis projects. The graphical programming environment is primarily used to configure the peripherals - I still had to write the code to link them together in a meaningful way. Unless that's changed since the time I built the Digital VCO, I wouldn't expect the graphic IDE to be a major simplification.

Have you done much with PsOC? I have done no programming, but i've started to look at what can be achieved with programmable chips, mostly inspired by some of the things you've done.
I like how PsOC uses a graphical programming environment, which i think makes things much easier to program (i think they call it that).

A few years back I did a simple little digital VCO with a low-end PSoC. Here's a link to it:

During that project I found the PSoC CPU architecture to be somewhat underpowered for synthesis projects. The graphical programming environment is primarily used to configure the peripherals - I still had to write the code to link them together in a meaningful way. Unless that's changed since the time I built the Digital VCO, I wouldn't expect the graphic IDE to be a major simplification.

Thanks for the interesting insight.
It will save me from barking up the wrong tree
Keep up the good work!

Running a PIC32 chip at 80MHz runs at 120MIPS instruction speed approximately.
Note that you can activate DMAs and let the CPU sleep during the DMA, so there are many opporunities to get very low power running this chip. It also runs the MIPS16 instruction set (16 bit) which compresses the code and runs it faster if you want.
Also, the DMA unit is very powerful, being able to transfer arbitrary waveforms out to GPIO pins. You can also do the same for arbitrary PWM waveforms which can be fed to a filter to output pretty much any waveform you want in PWM format. PWM can be running at 40MHz, so I'm pretty sure a 20KHz waveform is easily possible giving you some great music generation possibilities. It can also do pattern matching as part of the DMA input, which could allow for really fast correllation functions as part of a sound synthesis based on recording samples. It also as already got the A/D's built-in. It has loads of IO and multiple buses, so implementing midi and midi over USb shouldn't be too difficult.

Pretty amazing chip in all.

Note that it has the MIPS4Km core, which means there may already be assembler code for decoding MP3 and other formats already available (and possibly encode).

The only problem is that it's a more complex chip than has traditionally been available by PIC and there are not a lot of eval boards for breadboarding and experimentation yet. The best so far are the UBW32 board, and you can get a 64-pin version from eflightworks.net and they'll add a custom PIC32 for you if you ask. The UBW32 has more support at the moment, but it is a fixed chip on that eval board.

The Microchip kits are a bit spendy....so these other options mentioned are probably better for prototyping.

The Microchip kits are a bit spendy....so these other options mentioned are probably better for prototyping.

A dsPIC33F in the 28 pin DIP package can be prototyped on stripboard. I've used 4 dsPICs this way with zero problems. They all use a 20 MHz xtal and will operate at 40 MIPs with max DAC sample rate of about 89 kHz. I can't think of a method less expensive than stripboard - and hey - you get to solder stuff!

These Microchip devices are very cool. I like to download the documentation and store it on a LAN web server. Whether you do that or not, I'd like to suggest that a review of the errata sheets is a good idea - and to do that on perhaps a regular basis. It's also important to be able to find the device version so that you can correctly associate the ICs you have with the correct errata information.

If you are wondering why I might be writing this - it's because I found something that I thought was a bit weird.

I had downloaded an apparently older errata sheet that doesn't appear to apply to the dsPICs I have. (I'm not home so I can't look at them yet, I will in a couple of days and hopefully will remember to edit this post). That errata sheet said that DMA one-shot mode doesn't work. But I have code in which I use DMA one shot mode for the ADC that does in fact work. I have a new need for DMA and I need to use one-shot mode for it as well (this is concerning connecting an SPI SRAM and using DMA to read/write the SRAM).

The errata sheet I had was for revisions A0 and A1. Today, I downloaded two new errata sheets that contain information for A3 through A5 and the notation regarding DMA one-shot mode is no longer there. I am going to assume for now that my dsPICs are revision A3 or better - since I already know that my code works - so I'm assuming that Microchip fixed this in those later revisions. Somewhere in those docs, they show how to get the revision information.

The PDF files are:
80259b.pdf
80371B.pdf
80443H.pdf

listed from oldest to newest.

I found it easiest to go to www.microchip.com, click on the device type and then look around for "errata" to find the information.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.