# Switching away from PIC, need advice/options, CAN related

Status
Not open for further replies.

#### iso9001

##### New Member
Hey,

I'm not sure this is the best place on the internet to get an answer to this, but I'm currently using PIC 8bit series, and I've outgrown them.

I need a processor with at least 2 CAN modules, a DMA would be nice, and if I could find something that scaled from 8 to 32bit using roughly the same foundation that would be great. My company makes modules/projects that range from 100 units to 10,000 but normal product volume is 500-1000 (niche product). I have no idea what I'm paying for PICs right now, but it's probably between $5 and$8. I'm also the only engineer at my company so I need something less than obscure, something with a community would be nice. Also, I rarely need packages larger then QFP44, but I haven't found anything that meets my requirements less the 80pin so I'd like to be around there.

Does anyone have an advice or a series to stay away from ?

I've been looking into:
• Freescale (HC08, HC908)
• Renesas (MC16)
• PIC 16bit series (if I'm switching away from pic I might as well go all out)
• Infinion, STM, ???

Of those, Freescale is expensive and doesn't scale at all between 8/16/32 without changing architectures plus as far as I can tell their MSCAN has 1 buffer (wtf), Renesas is rare for english speaking noobs, the PICs might work but I'd rather find something to grow with, I know very little about other mfgs.

#### iso9001

##### New Member
As far as I know AVR CAN is fine, and they include some nice drivers for it, but they have no chips in any series with dual CAN.

#### qratman

##### Banned
It might be more important to pay attention to the base architecture rather than the peripherals, you can get CAN IC drivers that are easy to interface to, so not sure how important having the peripherals onboard really is to you though. In the end it can very often be cheaper to use a general purpose processor with good generic interfaces and purchase peripheral drivers for the specific application. Requires a lot of number crunching and looking around for the right devices though.

#### arhi

##### Member
if you already have experience with pic, and you want scale why not scale up with PIC . you have 8bit, 16bit and 32bit series. All with similar architecture, all work with similar / same tools (same programmer to programm all of them, same C compiler for all of them .. same libraries, same ide ..) .. you can easily scale up.. you have 20 different microchip PIC uC's with dual CAN hardware (from TQFP100 dsPIC33FJ256MC710 and PIC24HJ256GP610 to TQFP64 dsPIC33FJ64GP706)

check out the Main for more details

As for "other" uC's .. AVR is the next in line on the "easy" and "community" ... everything else might be better on cost/power side or on the tools price, availability etc ... but if you want "community" .. AVR and PIC are #1 ... donno if AVR have 2CAN driver solutions .. but, how important is to have 2 CAN drivers inside the uC ??? you can always use SPI to attach as many as you need ?

http://www.datasheetcatalog.org/datasheet/philips/SJA1000_3.pdf

Digi-Key - 568-1123-1-ND (NXP Semiconductors - SJA1000T/N1,118)
Digi-Key - 568-3994-5-ND (NXP Semiconductors - SJA1000T/N1,112)
Digi-Key - 568-1123-2-ND (NXP Semiconductors - SJA1000T/N1,118)

#### iso9001

##### New Member
I've run into some of pic's limitations and sometimes I smack my head and just want a real microcontroller - no joke. Arrays and Interurpt latency for instance.

I'll look at the new pic line again. It does make the most sense for me unless I see something better around.

##### Banned
I haven't looked into anything other than 8 bit chips really, I'm just a hobbyist who plays with them on the weekends. I imagine your choices nowdays are.... exhaustive to say the least, that's the biggest problem. Only way to really narrow things down is to come up with a chart of the features you absolutely require, the performance that you think need including overhead for future use and then start excluding the ones that don't mean your requirements from there. ARM chips are really hot commodities nowdays because so many devices use them, but that's the next level past even a micro controller upgrade. You may actually not be setting your sites high enough.

Last edited:

#### Diver300

##### Well-Known Member
I have moved from 8 bit to 16 bit PICs, and there is so much more that the 16 bit ones can do.

Most of the 16 working registers can be used as indirect registers, accessing all of the registers. In general in the 16 bit machines, indirect addressing gives more options than direct addressing. Array handling becomes much easier.

For example, moving data from one part of memory to another, in a 16 bit PIC can be done at 16 bits per instruction, and the instruction clock is half the oscillator frequency, not a quarter like in 8 bit PICs.

##### Banned
AVR 8 bit micros do that already. 16 working registers valid for any IO/math operation, and 16 more for general use though they don't work with all instructions. Even the 8 bit micros have plenty of instructions that work on words (16 bits)

#### iso9001

##### New Member
I have two designs in production with the standalone 2515 right now. It's not for me. It's fine for talking and receiving bus network traffic at moderate speeds. But when you get to 750-1000kpbs and need to dynamically filter, add, modify data with math functions on two or more busses it's too damn slow ESPECIALLY over SCI. I suppose I could consider looking at it a parallel mode chip again, but the SJA series only has 1 receive buffer...

The Atmel has no chips with dual can, so it doesn't matter if their 8bit handles XXXX or YYYY better, they are disqualified.

I think ARM's features would be wasted in most of my products.

As far as continuing with PIC goes... The 24F series is nice, but the only 2 can in that series is a 100pin unit, which would be a waste of pins and real estate on my pcbs. Likewise, the DSPic33 has 2 cans on a 64pin unit, but with all the disadvantages of DSP (low current sink/source being the biggie). So if I go with the DSP I'll probably need drivers/fets/buffers to do simple work that I may have been able to use a non-DSP earlier. At that point the 100 pin seems better.

Eh!!!!

Last edited:

#### EEman

##### New Member
read the "PIC32 Overview Brochure" on the first link. it lists "Dual CAN2.0B" coming to the 32 bit products - PIC32. that would be a good option, especially if you already have microchip software for their CAN chip.

#### iso9001

##### New Member
Yea....

The pic32s don't seem like they are nearly in full-effect yet. They say pin compatible with the 16bit series which is cool (and will either drive the price of the 16s down or keep the 32s artificially high).

I would expect the 32bit dual can to be as large as the 16bit dual can (100pins). I almost think that years ago I should have invested more time into FPGAs. Ah well.

I'm thinking I will probably stay in the pic series since it of any other controller is showing the most growth while still being relevant to my interests.

I'll probably look at the SJA again as I have a better understanding of it's FIFO that I could probably make it fast enough to be handy. I just need to see if the DSPic or the PIC24 is more appropriate for my next projects.

Thanks for the help and links,

#### Noggin

##### Member
Just FYI if you go with PIC32 and Microchip's compiler, these are a couple of gotchya's

1. If you use printf, it doesn't use putch( char c ) like most other compilers. Instead, it uses _mon_putc( char c ). There is a default _mon_putc defined that it will use, so if you write a putch function you get no warnings. This took me a day or two to figure out, it wasn't documented very well.

2. Printf, by default, will buffer anything you write to it until you send a carriage return. So if you output a bunch of . or something trying to debug something, you won't see them until you send something with a carriage return. This happens whether or not you define your own _mon_putc function. There is another function you have to call to tell it to transmit everything as you call printf

3. You MUST set interrupt priorities else they won't actually interrupt the processor.

Last edited:
Status
Not open for further replies.