CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Concerns/Intricacies with dsPIC?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
demedeiros



Joined: 27 Dec 2013
Posts: 35

View user's profile Send private message

Concerns/Intricacies with dsPIC?
PostPosted: Thu Jan 25, 2018 9:04 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 12987

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 9:14 am     Reply with quote

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



Joined: 27 Dec 2013
Posts: 35

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 9:56 am     Reply with quote

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



Joined: 07 Feb 2011
Posts: 837

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 10:26 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 6032
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 10:49 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 12987

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 12:19 pm     Reply with quote

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..
Very Happy
demedeiros



Joined: 27 Dec 2013
Posts: 35

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 1:42 pm     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1478
Location: Edmonton, Alberta

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 1:44 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 12987

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 2:59 pm     Reply with quote

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



Joined: 12 Jul 2004
Posts: 189
Location: Hemet, California USA

View user's profile Send private message

PostPosted: Fri Jan 26, 2018 8:49 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 12987

View user's profile Send private message

PostPosted: Fri Jan 26, 2018 9:05 am     Reply with quote

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

Crying or Very sad
jeremiah



Joined: 20 Jul 2010
Posts: 979

View user's profile Send private message

PostPosted: Sat Jan 27, 2018 3:03 pm     Reply with quote

Ttelmah wrote:
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.


The worst part about this was that it used to be unsigned for PIC24's. We were updating a slightly older project which was previously compiled on a version of PCD where they were unsigned. The newer version of PCD at the time was the first to make them signed and I didn't catch that. That led to quite a few bugs that were difficult to track down. After all, that if statement is pretty simple and it always worked before...so it couldn't be that part...right?
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group