Concerns/Intricacies with dsPIC?

[demedeiros]

Hi all,

Coming up on a new project where I am thinking of using a DSPIC33EP32MC502. This project uses CAN and a quad encoder. Are there any particular issues or intricacies with the dsPICs that I should be aware of? I have really only ever used the 16F line in the past.

Thanks!

[Ttelmah]

Most will involve you in having to program the peripherals with #PIN_SELECT.

The default integer is a signed int16.

Data will often need to be word aligned not byte aligned, or if you try to access on int16 type on an 'odd' byte boundary you can trigger an error interrupt.

There is a RAM based stack, that may well need to be set larger. Unlike the PIC16/18, where the stack is not used for variables, on these chips it is, and can therefore need to be very large.

Look carefully at the 'guidelines for getting started' (section 2 in the data sheet). Particularly the minimum connections and the advice about decoupling. They are low voltage chips and though they have some 5v tolerant inputs they are less forgiving of poor design.

[demedeiros]

Thanks! I appreciate all of the info! Seems like there are some things to be aware of, but not too much overall.

Thanks again!

[RF_Developer]

The change in default int type from 8 bit unsigned to 16 bit signed can cause difficulties, especially when copying old code across from 16s to 24s/dsPICs.

The floating point format is IEEE754 on the 24s/dsPICs, and is different to that used on 16s and 18s.

The CAN hardware is significantly more capable on the 24s/dsPICs and works a little differently. This certainly caught me out and caused a lot of unexpected work.

The ADCs also are considerably upgraded, running much faster and having more options.

Another thing that caught me out is that not all 24s/dsPICs have EEPROM; the DSPIC33EP32MC502 doesn't; so check the data sheets carefully to make sure your chosen PIC does what you need it to.

Most 24s/dsPICs are strictly 3.3V (ish) only , including the DSPIC33EP32MC502, and there are few 5V versions. Many of the 3.3 volters have some/most/many 5V tolerant IO pins, and will accept 5V logic inputs, but by no means all IO pins. At least on the 24s I used, there doesn't seem to be much sense or even a pattern to which pins are tolerant. If you want to exploit this feature, as I did, you need to check the datasheet very carefully, several times.

On a related point, much the same goes for pin select: not all pins are available for selection, and not all functions are pin selectable. Again, careful reading of the datasheet is needed.

All that said, personally I found the transition from 18s to 24s to be generally straightforward.

[temtronic]

You should consider the 'learning curve' and cost of new compiler( if needed). There are several 18F PICs that have CAN, I suppose some 16Fs as well( haven't checked). Quadrature encoder can be done with a simple peripheral like US Digital sells,which 'offloads' the PIC so it can do 'other stuff'. I used USDigitals LS7266(#?) to run helicopters in real time over the internet 20 years ago.
Depending on the requirements it may be an option to stick with what PIC series you're using now. Newer and bigger may NOT be the best choice. Also I have to assume more guys are using the 16/18s than dspics so online help could be faster.
just food for thought..

Jay

[Ttelmah]

Lets give some of the major pluses.

DMA. Used properly can be great. I'm using it for SD cards, ADC's etc., and the sheer ability to move data in the background is great. Some PIC18's do have DMA, but the capabilities on the PIC24 are much better. I had 'back answers' recently on a new chip with the ADC data being transferred through a different register than the application notes said, but that was exceptional and specific to a couple of new chips.
The sheer speed of the maths. Many have hardware divide, and the speed really is massively better.
The actual clock rates and amount of RAM.
In many cases the chips are cheaper than PIC18's!.
So, yes you need to look at the compiler cost, and the learning curve, but it is worthwhile at the end.
Then you do have 64bit integers etc..

[demedeiros]

Thank you all for the information. This is exactly the type of info I was looking for.

I will most certainly look at the offerings of US Digital. Seems like they make an encoder counter to SPI IC, which may work quite well for my application.

Thanks!!

[newguy]

One unique gotcha to watch out for: if porting 18F code to a dsPIC, you must be cognizant of the fact that with the PCH (and lower) compilers, all integers are unsigned by default. With PCD, they're signed by default. That's the reason why I'm always explicit with my declarations now and always include signed or unsigned no matter what. That way I can take code developed for one platform and easily migrate to the other.

Other than that, just read the (usually) chapter 2 of the data sheet regarding the how-to of using the dsPIC/laying out the PCB and you'll be fine. To be honest, I much prefer dsPICs to any of the 8 bit PICs now. Of course, it all depends on the application whether you opt for one or the other but all other considerations being equal, I love the dsPICs.

[Ttelmah]

Yes. The default being signed is a real 'gotcha'. It can catch you in a lot of ways. That's why I put this near the top of my list. Lot's of little things here. It was one of the big differences between CCS and most C's on larger chips, so having to 'unlearn' that can be quite important.

[drh]

Make sure to check the errata document.
http://ww1.microchip.com/downloads/en/DeviceDoc/80000533M.pdf
_________________
David

[Ttelmah]

I must admit that chip family is running towards a 'record' in the errata stakes. Ouch.

[jeremiah]