MCU Slection: need lots of input captures (also CAN and EXT. Temp Range)

MCU Slection: need lots of input captures (also CAN and EXT. Temp Range)
Posted by JPortici on 24 Sep, 2017 09:12
New automotive project coming, i will need many independent input captures and output compares. At least nine. Along with other standard peripherals, including at least 1xCAN.
Other two requirements is extended temperature range and more than 64 pins.
I was hoping to do that with a PIC32 MK, as it has 16 IC modules, but they use the GP timers for the counting and i need them to be independent to each others.
Device has 8 timers that can be linked to the IC modules, which means i have 8 ICs, I can make it work but I don't want to do this again a year from now.

The only candidate MCU for now is dsPIC33EP256MU810
http://www.microchip.com/wwwproducts/en/dsPIC33EP256MU810

plus:
- Already have most of the code written for it, it will be an upgrade to a board using the dsPIC33EV series
- 16 INDEPENDENT Input Capture. Each peripheral has its own timer counter, buffer.
- 16 independent output compare. Same, independent counter/register etc. that are to be used in pair with the ICs
- 12 more PWM, will be used as DACs.
better:
- 2xCAN, but 1x is enough
- 1xUSB
- 100 Pin so i can actually route everything
- ADC with scan feature

minus:
- Worse Errata that i'd like, but nothing showstopping. All the DMA/CAN related issues have workarounds
- Part has been around for 5 years, only one silicon revision. that worries me the most.

I'm trying to look at the LPC/Kinetis parts, but i don't really understand their Input capture or equivalent peripheral.

#1 Reply
Posted by danadak on 24 Sep, 2017 12:21
Consider PSOC 5LP, it has CAN, Sequencing SAR, digital filter, routable internal
and external (both some limitations). I was able to fit 18 PWMs on a part for
another request. This was done in additional to fixed resources in its UDB fabric.

For me what stands out is -

1) Routability
2) Fast 12 bit SAR A/D and slow 20 bit DelSig
3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFB
can be used as a GP fast processor block, similar to RISC block
4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGA
like capability
5) Onboard Vref
6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....
7) LCD, COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB
9) Custom components capability, create with schematic capture or Verilog
10) DMA to offload processes like filters, COM, Display
11) ARM M0 (PSOC 4) or M3 (PSOC 5LP) or 8051 core(PSOC 3) or M0+/M4 dual core PSOC 6
12) Extensive clock generation capabilities
13) All components supported by extensive prewritten APIs

https://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

http://www.cypress.com/documentation/code-examples/psoc-345-code-examples

Great video library

Attached component list. A component is an on chip HW resource.

Free GUI design tool with schematic capture, "Creator". Components have rich API library attached
to each component. Compilers free as well.

PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as well. PSOC 6 dual core M0+/M4.

https://www.elektormagazine.com/labs/robot-build-with-cypress-psoc

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc

https://brightcove.hs.llnwd.net/e1/uds/pd/1362235890001/1362235890001_5241352463001_2606504288001.mp4?pubId=1362235890001&videoId=2606504288001

Regards, Dana.

Component List (2).doc

#2 Reply
Posted by JPortici on 24 Sep, 2017 13:08
Thanks for the wall of text, but AFAIK PSoCs aren't available with industrial/extended temperature range. This alone crosses them out of the list.
Also, if i understood it right there are as many input capture modules as there are times, so in this case 4 (max). i need at least 9.

#3 Reply
Posted by voltsandjolts on 24 Sep, 2017 15:41
Ignore this if you don't like STM32.
https://www.digikey.co.uk/product-detail/en/stmicroelectronics/STM32L496VGT3/497-17175-ND/6709880

#4 Reply
Posted by nctnico on 24 Sep, 2017 15:42
NXP LPC1500 series may have some interesting devices (-40 to 105 deg. C). The SCT timer module is a very versatile timer & event module.

#5 Reply
Posted by kripton2035 on 24 Sep, 2017 15:50
Quote from: JPortici on 24 Sep, 2017 13:08
Thanks for the wall of text, but AFAIK PSoCs aren't available with industrial/extended temperature range. This alone crosses them out of the list.
Also, if i understood it right there are as many input capture modules as there are times, so in this case 4 (max). i need at least 9.
PSOC 3 has an automotive range, and is quite capable compared to PSOC 5. same IDE.

#6 Reply
Posted by funkathustra on 24 Sep, 2017 18:20
I wish you'd lay out your specific requirements (how many input capture, how many PWM, etc), because otherwise, we're just throwing parts out there that we're fanboys of, without really knowing what you're looking for.

Either way, when I think of "industrial controls" I think of the Infineon XMC stuff -- either the XMC1000 for low-end Cortex-M0 stuff, or the XMC4000 for big, beefy projects. The XMC4500, in particular, has 32 total channels of capture/compare. Available in a large package with 91 I/O, USB, Ethernet, CAN, and all that stuff: XMC4500F144K1024ACXQMA1 on DigiKey.

#7 Reply
Posted by JPortici on 24 Sep, 2017 19:46
Well, i wrote the requirements in the first post.
At least 9 independent* 16 bit IC
At least 8 independent* 16 bit OCs
6/8 PWM
1xCAN
10/12xADC channels, at least 10bits. Scan/automation features are welcome.

*independent meaning that each peripheral has its dedicated counter. Many times you have many channels, but they all share the same counter.

Anyway, suggesting parts you are a fanboy of is not a bad thing. If you keep using them they can't be that bad.

I'd give a look at infineon and NXP

#8 Reply
Posted by NorthGuy on 24 Sep, 2017 20:19
About the independence of ICs.

A timer consists of 2 things - a clock source and a counter register which counts the pulses of the clock source.

Each IC module in dsPIC33EP GU has its own counter, but it doesn't have its own clock source. If you have 2 free running counters from the same clock source with the same period, the difference between them stays the same over time. For example, if ICx runs from the same source as TMRy, then the following holds true:

ICxTMR = TMRy + offset

In this case, the counter inside the IC module is redundant. Even though PIC32MK doesn't have the counters inside their IC modules, the corresponding value can be calculated from the GP timer using the above formula. Therefore, PIC32MK IC modules are not really less independent than dsPIC33EP GU IC modules. The only complication is that you need to maintain an offset for each IC module in your software.

#9 Reply
Posted by JPortici on 25 Sep, 2017 06:15
You have a point. At the simplest what i have to do is to time stamp every pin state change (measure low pulse width, measure period width -> digit. and so on)
To put it simply, among other things i have to read data from 8 SENT sensors.

About the indpendence of ICs, that may come from me using dsPICs so much, there is scarcity of timers and they are always used to generate high resolution low frequency square waves. they can't be left free-running, i can only get the clock from them so independent counters are always welcome.

#10 Reply
Posted by forrestc on 25 Sep, 2017 06:45
Quote from: JPortici on 25 Sep, 2017 06:15
You have a point. At the simplest what i have to do is to time stamp every pin state change (measure low pulse width, measure period width -> digit. and so on)

I don't think I've ever used more than one timer/counter with the IC modules to do this. Generally I set up a timer/counter to run at whatever clock rate gets me the accuracy I need. Then I set up all of the IC's to capture that clock source. Depending on the speed of the events, I'll then use the IC 'capture has occured' interrupt to trigger off the software which is needed to process the captures. Or at least grab the data for later.

This is especially useful where you are curious about relative timing of the input events, since really what you get is a consistent timestamp across all of the IC modules.

#11 Reply
Posted by forrestc on 25 Sep, 2017 06:47
I'm curious about this:

Quote from: JPortici on 24 Sep, 2017 09:12
- Part has been around for 5 years, only one silicon revision. that worries me the most.

Why does that worry you?

#12 Reply
Posted by Jeroen3 on 25 Sep, 2017 07:19
Renesas has some massive parts that could fit. They even have those automotive processors with SENT interface. But not enough for you.
I have no further experience with Renesas, so can't help you with that. Renesas isn't very accessible for low quantities.

Instead of asking for 25 timers, which is ridiculous, you might want to consolidate some of them into pairs that can use the same timebase.
Otherwise you will indeed end up with FPGA or multiple MCU.
Because, 8 SENT interfaces look like they use same base clock. Thus you can use 2 timers with 4 channels on an ST for example. But imho, it would be a waste of time doing this in software.

#13 Reply
Posted by mikeselectricstuff on 25 Sep, 2017 08:28
Unless you need different prescalers or clock sources, I can't see why you need seperate timers for input capture. It should be possible to just apply an appropriate offset based on the previous captured value.
Maybe slightly more complicated, but simplifies peripheral requirement.
A small FPGA might be worth considering, as it removes a lot of constraints from the MCU, and you can customise the peripherals to do exactly what you need in terms of counter widths, buffering etc.

#14 Reply
Posted by capt bullshot on 25 Sep, 2017 08:39
Infineon XE16x series (industrial) / XC2x00 series (same beasts, but automotive targeted)
These have a special CC (CAPCOM2) unit with at least 16 inputs/outputs acting as capture / compare. I believe the concept of such a CC unit is quite common in automotive / ECU applications.
Quite old stuff, but appears to be targeted to automotive and knowingly used (by my company) in industrial stuff. You can still buy very old members of this family, so I'd expect them to be long lived.

The infineon XMC appear to be a dead end, since there's no roadmap on these, and they are younger than the XE / XC2x00. IMO the XMC series is a "me too" from Infineon to Cortex-Mx devices, but they realized that they can't compete with the many other Cortex-Mx manufacturers on the long run.

#15 Reply
Posted by JPortici on 25 Sep, 2017 12:39
Quote from: forrestc on 25 Sep, 2017 06:47
I'm curious about this:

Quote from: JPortici on 24 Sep, 2017 09:12
- Part has been around for 5 years, only one silicon revision. that worries me the most.

Why does that worry you?

No real reason to be worried, just the fact that other dsPICs had more silicon revisions across the years.. Is it because they didn't sell many and will be "phased out" by increasing the cost over time? -as we know microchip almost never discontinue chips-
While it's true that all the bugs i care for have workarounds, this part and the EV part are both different than other dsPICs: the MU80x has a ton of IC/OC and USB, the EV is the only 5V series and has hardware SENT peripheral.

--
I had the same feeling about the Cortex from infineon. Nothing special at all.
The XC2300 series looked promising but it appears it's EOL'd :/
FPGA, i don't want to dabble into that yet, a way to have timestamped I/O changes is enough.. Probably Input capture is enough. I Can also tell which event it was, as the low pulse has a fixed width

#16 Reply
Posted by mikeselectricstuff on 25 Sep, 2017 13:14
Quote from: JPortici on 25 Sep, 2017 12:39
I had the same feeling about the Cortex from infineon. Nothing special at all.
The XC2300 series looked promising but it appears it's EOL'd :/
FPGA, i don't want to dabble into that yet, a way to have timestamped I/O changes is enough.. Probably Input capture is enough. I Can also tell which event it was, as the low pulse has a fixed width
If you nedd a few extra captures, you can probably get a very close approximation to a hardware capture by using a pin interrupt to trigger the DMA of a counter value into memory

#17 Reply
Posted by jnz on 25 Sep, 2017 17:35
Quote from: JPortici on 24 Sep, 2017 09:12
- Worse Errata that i'd like, but nothing showstopping. All the DMA/CAN related issues have workarounds

The DSP33F is the single WORST chip for CAN I've ever had the misfortune of using. An absolutely STUPID way to create and manage the peripheral RAM. I hated every single second of that chip. The 33F series is one of the reasons I dumped microchip all together for micros.

I'd recommend a standalone SPI CAN chip (microchip has a new one that looks good af) way before I'd ever even consider approaching a 33F again.

Just go to ARM now and thank yourself later.

#18 Reply
Posted by NorthGuy on 25 Sep, 2017 18:11
Quote from: jnz on 25 Sep, 2017 17:35
The DSP33F is the single WORST chip for CAN I've ever had the misfortune of using. An absolutely STUPID way to create and manage the peripheral RAM. I hated every single second of that chip. The 33F series is one of the reasons I dumped microchip all together for micros.

I used CAN with PIC24HJ and TI transceiver (must be the same as dsPIC33F). It worked very well. I managed to create filters, so that the hardware classified all the incoming CAN messages and put every kind into a separate buffer, and then with very little code I managed to create a separate handler function for every kind of the CAN message I wanted to handle. And the CAN messages I didn't want to handle were dismissed by hardware without my program ever knowing that such message arrived. Very neat. Timing also was rather easy to master - I even managed to run it without crystal by tuning the internal oscillator, but then decided to use crystal anyway.

I don't know if dsPIC33EP has the same kind of the CAN module.

#19 Reply
Posted by jnz on 25 Sep, 2017 18:48
Quote from: NorthGuy on 25 Sep, 2017 18:11
Quote from: jnz on 25 Sep, 2017 17:35
The DSP33F is the single WORST chip for CAN I've ever had the misfortune of using. An absolutely STUPID way to create and manage the peripheral RAM. I hated every single second of that chip. The 33F series is one of the reasons I dumped microchip all together for micros.

I used CAN with PIC24HJ and TI transceiver (must be the same as dsPIC33F). It worked very well. I managed to create filters, so that the hardware classified all the incoming CAN messages and put every kind into a separate buffer, and then with very little code I managed to create a separate handler function for every kind of the CAN message I wanted to handle. And the CAN messages I didn't want to handle were dismissed by hardware without my program ever knowing that such message arrived. Very neat. Timing also was rather easy to master - I even managed to run it without crystal by tuning the internal oscillator, but then decided to use crystal anyway.

I don't know if dsPIC33EP has the same kind of the CAN module.

Yea, that's how CAN filters work.

And it works - until it doesn't.

True, I don't remember that part I used and if it's the same CAN module. It was BAD so if they changed it I wouldn't be surprised. That said, Microchip isn't even doing their own CAN modules anymore because they're pretty bad at them, Kvaser is doing their new stuff. The first part, the 2517 is awesome on paper. So that might be a clue to you on the other stuff.

#20 Reply
Posted by NorthGuy on 25 Sep, 2017 20:35
Quote from: jnz on 25 Sep, 2017 18:48
That said, Microchip isn't even doing their own CAN modules anymore because they're pretty bad at them, Kvaser is doing their new stuff.

I didn't get to the point where it doesn't work, so their CAN module was good for me.

I don't think Microchip does much of new development. They license stuff and put them into their new chips, often don't even document what the module does. They shuffle things around. Now they bought Atmel, so they have more stuff to shuffle. Get ready for new ATPIC monsters.

#21 Reply
Posted by JPortici on 26 Sep, 2017 11:29
Ah, yes. i HATE the controller in the older FJ parts, but AFAIK all 33EP are using the kvaser can module. Also pic32
who cares if microchip isn't doing its own can module? they are buying the IP from a company that does its job very well, that's good for me.

Frankly i don't see the appeal in switching to ARM for the sake of being ARM, and i never will.

I'm looking at something and i ask myself
Does it have the peripherals/form factor I need?
Is the documentation clear, detailed and easy to understand?
Is the chip actually available?
Does the cost of the chips justify rewriting all the code and drivers and getting deep into this particular implementation of ARM core + what really matters (the chip architecture and the peripherals)?

Many ARMs i've looked at are lacking from at least one of these three aspects.
ST usually lacks points 2 and 3
Kinetis lacks 2 3 and 4 (seriously, I tought i'll never see a reference manual worse than ST)
Infineon 1 3 and 4
ATSAM lack 1

#22 Reply
Posted by NorthGuy on 26 Sep, 2017 14:08
Quote from: JPortici on 26 Sep, 2017 11:29
Ah, yes. i HATE the controller in the older FJ parts, but AFAIK all 33EP are using the kvaser can module.

I looked at the docs, and 33EP CAN module looks nearly identical to 33FJ CAN module.