MCU Slection: need lots of input captures (also CAN and EXT. Temp Range) - Page 1
Forum section: electronics / general

author: JPortici
author_rank: Super Contributor
timestamp: September 24, 2017, 09:12:56 am
content: 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 dsPIC33EP256MU810http://www.microchip.com/wwwproducts/en/dsPIC33EP256MU810plus:- Already have most of the code written for it, it will be an upgrade to a board using the dsPIC33EV series- 16INDEPENDENTInput 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 featureminus:- 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.

author: danadak
author_rank: Super Contributor
timestamp: September 24, 2017, 12:21:54 pm
content: Consider PSOC 5LP, it has CAN, Sequencing SAR, digital filter, routable internaland external (both some limitations). I was able to fit 18 PWMs on a part foranother request. This was done in additional to fixed resources in its UDB fabric.For me what stands out is -1) Routability2) Fast 12 bit SAR A/D and slow 20 bit DelSig3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFBcan be used as a GP fast processor block, similar to RISC block4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGAlike capability5) Onboard Vref6) 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, USB9) Custom components capability, create with schematic capture or Verilog10) DMA to offload processes like filters, COM, Display11) ARM M0 (PSOC 4) or M3 (PSOC 5LP) or 8051 core(PSOC 3) or M0+/M4 dual core PSOC 612) Extensive clock generation capabilities13) All components supported by extensive prewritten APIshttps://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=truehttp://www.cypress.com/documentation/code-examples/psoc-345-code-examplesGreat video libraryAttached component list. A component is an on chip HW resource.Free GUI design tool with schematic capture, "Creator". Components have rich API library attachedto 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-psochttp://www.cypress.com/products/32-bit-arm-cortex-m-psochttps://brightcove.hs.llnwd.net/e1/uds/pd/1362235890001/1362235890001_5241352463001_2606504288001.mp4?pubId=1362235890001&videoId=2606504288001Regards, Dana.

author: JPortici
author_rank: Super Contributor
timestamp: September 24, 2017, 01:08:45 pm
content: 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.

author: voltsandjolts
author_rank: Unknown
timestamp: September 24, 2017, 03:41:34 pm
content: Ignore this if you don't like STM32.https://www.digikey.co.uk/product-detail/en/stmicroelectronics/STM32L496VGT3/497-17175-ND/6709880

author: nctnico
author_rank: Super Contributor
timestamp: September 24, 2017, 03:42:41 pm
content: NXP LPC1500 series may have some interesting devices (-40 to 105 deg. C). The SCT timer module is a very versatile timer & event module.

author: kripton2035
author_rank: Super Contributor
timestamp: September 24, 2017, 03:50:24 pm
content: Quote from: JPortici on September 24, 2017, 01:08:45 pmPSOC 3 has an automotive range, and is quite capable compared to PSOC 5. same IDE.

author: funkathustra
author_rank: Regular Contributor
timestamp: September 24, 2017, 06:20:19 pm
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: September 24, 2017, 07:46:19 pm
content: Well, i wrote the requirements in the first post.At least 9 independent* 16 bit ICAt least 8 independent* 16 bit OCs6/8 PWM1xCAN10/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

author: NorthGuy
author_rank: Super Contributor
timestamp: September 24, 2017, 08:19:37 pm
content: 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 + offsetIn 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.

author: JPortici
author_rank: Super Contributor
timestamp: September 25, 2017, 06:15:18 am
content: 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.

author: forrestc
author_rank: Unknown
timestamp: September 25, 2017, 06:45:47 am
content: Quote from: JPortici on September 25, 2017, 06:15:18 amI 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.

author: forrestc
author_rank: Unknown
timestamp: September 25, 2017, 06:47:44 am
content: I'm curious about this:Quote from: JPortici on September 24, 2017, 09:12:56 amWhy does that worry you?

author: Jeroen3
author_rank: Super Contributor
timestamp: September 25, 2017, 07:19:19 am
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 25, 2017, 08:28:55 am
content: 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.

author: capt bullshot
author_rank: Super Contributor
timestamp: September 25, 2017, 08:39:09 am
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: September 25, 2017, 12:39:46 pm
content: Quote from: forrestc on September 25, 2017, 06:47:44 amNo 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

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 25, 2017, 01:14:15 pm
content: Quote from: JPortici on September 25, 2017, 12:39:46 pmIf 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

author: jnz
author_rank: Frequent Contributor
timestamp: September 25, 2017, 05:35:42 pm
content: Quote from: JPortici on September 24, 2017, 09:12:56 amThe 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 25, 2017, 06:11:15 pm
content: Quote from: jnz on September 25, 2017, 05:35:42 pmI 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.

author: jnz
author_rank: Frequent Contributor
timestamp: September 25, 2017, 06:48:02 pm
content: Quote from: NorthGuy on September 25, 2017, 06:11:15 pmYea, 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 25, 2017, 08:35:32 pm
content: Quote from: jnz on September 25, 2017, 06:48:02 pmI 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.

author: JPortici
author_rank: Super Contributor
timestamp: September 26, 2017, 11:29:27 am
content: Ah, yes. i HATE the controller in the older FJ parts, but AFAIK all 33EP are using the kvaser can module. Also pic32who 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 myselfDoes 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 3Kinetis lacks 2 3 and 4 (seriously, I tought i'll never see a reference manual worse than ST)Infineon 1 3 and 4ATSAM lack 1

author: NorthGuy
author_rank: Super Contributor
timestamp: September 26, 2017, 02:08:32 pm
content: Quote from: JPortici on September 26, 2017, 11:29:27 amI looked at the docs, and 33EP CAN module looks nearly identical to 33FJ CAN module.