Looking for PIC with CAN and decent ADC

[pmuldoon]

Hi everyone,

I get so exhausted looking thru errata sheets when I need a PIC chip that I thought I'd see if anyone had any recommendations from their past projects. A lot of chips fit my requirements, but after I look at the errata sheet I have to put them aside. I really wish mchp would identify working and broken chips better. Mostly it's a broken ADC that's the show-stopper.

Anyway, here are my requirements (not very demanding):
- supported by CCS (hopefully long enough to have any major issues resolved)
- 8-bit, because I'd rather not use the PCD and high-end PICs, rather just go to ARM chips if my life needs to get that complicated.
- CAN controller (I think any version would probably work - I just need to support J1939 29-bit addr)
- ADC with at least 4 channels and 10-bit resolution ( I might be able to get by with a very solid 8/9-bit resolution, but I'll shoot for 10)
- at least 29 IO lines.
- current non-CAN code is about 68% of 64KB per CCS lst file - 18F66K22)
- and, of course, low cost.

I did find the 18F47Q84 with minimal errata. Maybe it's too new for the errata sheet to have evolved because CCS doesn't support the part.

PIC18F66K80 might work but the ADC is sketchy.

Any suggestions?

[temtronic]

Hmm....could you use a TTL<>CAN interface module instead of an embedded CAN micro ??
that'd expand the # of PIC choices.....
options, always thinking of options....

[Ttelmah]

I don't remember the 66K80 having any particular ADC issues. Remember
that to genuinely get beyond perhaps 7bits, you always have to use
a proper external Vref. For most of the PIC's with ADC errata, all it involves
in general is storing your own zero and full scale calibration values. The
commonest error is an offset in the ADC value.
Consider just splitting the needs into two chips. One handling the CAN
communications and the other doing the ADC etc.. High speed TTL serial
is fine between two chips on the same board,

[pmuldoon]

It's going to have to fit on a pretty small pcb, so I'd prefer not to go with a separate CAN controller if I don't have to. But if it were small and integrated the driver...might be worth considering. Just looked up mchips version, but it seems to need a lot of IO

I had allocated 10 PIC lines for a 7-seg x 3 display and another 10 for 5 bi-color LEDs, but I am looking at using a couple of TLC5925 led drivers to do that with 4 PIC lines. They are big chips, but they will eliminate any multiplex flicker and may expand my PIC choices. I should only need about 21 I/O and ADC lines total, now. It may help if we need to go to a 2-pcb stack with only a few lines between to drive the display & leds.

I do have an external adc we use on other products. It's a small 2-channel SOT23-6. I may jump to that for the more critical ADC inputs and make the internal adc work for the rest.

It's all still at the pencil sketch level, so I'm still all over the map with approaches.

[newguy]

I've used the 18LF26K83 in some CAN-based implementations. I didn't really use the A/D though. That said, it worked fine. The bad errata were on things I didn't need/use.

Edit: I just remembered I did use the A/D. No issues with it that I can recall.