MCU choice

Hardware inside and outside of the ECU
Post Reply
ssmith
Posts: 92
Joined: Sun Oct 17, 2021 10:21 pm

MCU choice

Post by ssmith »

I'm starting to get more serious about building my own board, of course MCU choice is a big concern. I've done a bit of research (as I'm sure others have done), so I thought I'd list it and get some feedback. FWIW I need around 30 analog inputs and 16 digital inputs (at least 9 with input capture capabilities).

1. PIC32MZ*EF or PIC32MK*MCM.
Ok try not to laugh. PIC peripherals are awesome. 40+ analog inputs in a 100 pin package - 5 dedicated (1 pin at a time) 3Msps and 1 shared (all the other pins) 2-3Msps ADC. 4 deep FIFO on 9-16 input capture pins, or just use the interrupt method on port changes (capturing an interrupt per port, with each pin being separately configurable for rising and/or falling edge). USB, 2+ CAN. Dual bank flash (for burn while engine is running) with lots of RAM. Shadow registers (7 sets on MZ and 2 sets on MK) for faster interrupts (necessary to compete with ARM). 0 wait state up to 60 MHz flash.

Downside - not in the ARM world, so get your own compiler etc. No ChibiOS support (so switch to FreeRTOS? plus roll your own HAL). Some chips have horrible erratas (PIC32MZ*EC and PIC32MK*MCF are unusable), PIC32MK*MCM is pretty new so errata isn't flushed out yet. I would be blazing a lot of new ground with this chip.

Analog would work well for my needs - 2 knock ADC, 1 for WbO2, and 2 for ion sense - you can switch the dedicated ADC between two pins, so I could put two cylinders on one ADC and the other two cylinders on the other ADC, and just switch the active pin each time there's an ignition event.

2. Cypress S6E2C or G. Only 24 analog on 144 pin but 32 analog on 176 pin. 2Msps with the right impedance. 3 separate ADC so some channels can be sampled faster than others. S6E2C has dual bank flash while S6E2G is only single bank. 5V capable so no voltage divider needed. USB, dual can on S6E2C, single can on S6E2G. Major downside is external interrupt capture only supports rising or falling edge, but not both.

Prices for S6E2G are quite cheap on Arrow.com, I get the sense that Infineon doesn't really want to continue the line and will probably kill it off when they can.

3. Most Renesas MCU don't have enough analog, but RA6M5 has 29 analog inputs on the 176 pin package. Not sure it's compelling enough to get though.

4. STMH7 - seems that ST Micro finally got the memo that you should have more analog inputs, which is very reassuring as other brands seem to be going the opposite direction. 28 analog inputs on 144-pin, 32 analog inputs on 176-pin. Downside is availability, though maybe I should just remove the chip from my Nucleo board to use on my ECU :-) Newark does have a small supply of 176-pin chips available.

5. ATSAME54P20 - can't get it, but the 128-pin package has 28 analog inputs.

6. So far my favorite is probably NXP MKV5*. Major downside is only single bank flash and no USB, though I'm fine using an MCP2221A to handle UART to USB at 460kb/s and ditching mass storage/etc. On the plus side, 100-pin package has 40 ADC divided into 4 modules that can sample at 5Msps. USB, 2+ CAN, 105C temp range, ability for any pin to be used for interrupt notification (port-based with each pin configurable as rising and/or falling edge). Also it has 4 onboard comparators against a 6-bit DAC, with the ability to map the output of the comparison directly to pins without CPU intervention, so I could actually implement the GDI solenoid driver using the chip. Being able to combine the engine computer, wideband, and GDI controller with a single 100-pin package is pretty alluring from a layout consideration (more space for other things). 1MB flash / 256k RAM 160-240MHz M7 proc. 32 DMA channels so I could dedicate a pair to handle timestamp capture on input pin change for no-wait no-interrupt input capture.

100-pin is tight but I think I can fit what I need. It is made in 144-pin though it isn't in stock right now. I assume I'd have an external flash chip for logging. I need something like 30 analog inputs, 16 digital inputs, and 25 digital outputs (assuming 4 for injectors; if I'm bringing GDI on board I probably need more like 10-12). 4 for dual CAN and 2-4 for UART (4 including reset pin and a pin to indicate to the bootloader that it shouldn't run the application, that way I can reprogram the board even if I program broken code without having to open the case and reset it).

So, thoughts? I really really want to like the PIC32 solution but I know it'd be a lot of work to get up and running. I see "coming soon" availability on MicrochipDirect.com (some that were supposed to be avail early December already sold out, but there's some coming by Feb). STMH7 is an obvious easy choice though it's large and would still require the GDI controller. NXP would be relatively easy to get up and running...
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: MCU choice

Post by AndreyB »

208 pin H7?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
ssmith
Posts: 92
Joined: Sun Oct 17, 2021 10:21 pm

Re: MCU choice

Post by ssmith »

AndreyB wrote:
Fri Nov 26, 2021 11:06 pm
208 pin H7?
I'm not sure what problem that solves? It doesn't seem more readily available than the 176 pin, and the 176 pin already has enough analog inputs, and it takes more board space.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: MCU choice

Post by AndreyB »

Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
Dron_Gus
contributor
contributor
Posts: 450
Joined: Wed Nov 13, 2013 1:11 pm
Location: S-Pb
Github Username: dron0gus

Post by Dron_Gus »

STM32F7/H7 has QSPI module that can map external flash to CPU address map. This is cool feature. I use it to store settings. QSPI flash erase+write is much faster than internal.
Some STM32 already support CAN-FD.
ssmith
Posts: 92
Joined: Sun Oct 17, 2021 10:21 pm

Re:

Post by ssmith »

Dron_Gus wrote:
Sun Nov 28, 2021 4:00 pm
STM32F7/H7 has QSPI module that can map external flash to CPU address map. This is cool feature. I use it to store settings. QSPI flash erase+write is much faster than internal.
Some STM32 already support CAN-FD.
I don't think we need more flash addressable by the CPU, right? External flash is useful for logging, and providing burn-while-execute for MCU that don't have dual bank flash, but neither purpose needs memory mapped IO.
User avatar
Dron_Gus
contributor
contributor
Posts: 450
Joined: Wed Nov 13, 2013 1:11 pm
Location: S-Pb
Github Username: dron0gus

Re: Re:

Post by Dron_Gus »

ssmith wrote:
Mon Nov 29, 2021 4:25 am
I don't think we need more flash addressable by the CPU, right? External flash is useful for logging, and providing burn-while-execute for MCU that don't have dual bank flash, but neither purpose needs memory mapped IO.
Some users want switchable tables/tunes. With memory mapped flash there is no need to load it to ram, for example.
nmstec
contributor
contributor
Posts: 124
Joined: Tue Oct 05, 2021 9:02 pm
Location: Vancouver

Re: Re:

Post by nmstec »

Dron_Gus wrote:
Mon Nov 29, 2021 11:48 am
ssmith wrote:
Mon Nov 29, 2021 4:25 am
I don't think we need more flash addressable by the CPU, right? External flash is useful for logging, and providing burn-while-execute for MCU that don't have dual bank flash, but neither purpose needs memory mapped IO.
Some users want switchable tables/tunes. With memory mapped flash there is no need to load it to ram, for example.
Multi-maps would definitely be something I'd be interested in.
"Dave B. 5:03 PM
Mark is an ass but by far the most potent combination of knowledgeable ass, smart ass, get it done ass and determined ass. and his ass consistently puts in time."

-Dave B, Hero, Tuner, and probably has a car.
ssmith
Posts: 92
Joined: Sun Oct 17, 2021 10:21 pm

Re: Re:

Post by ssmith »

Dron_Gus wrote:
Mon Nov 29, 2021 11:48 am
Some users want switchable tables/tunes. With memory mapped flash there is no need to load it to ram, for example.
Well this conversation probably deserves it's own thread, but...

How many tables/tunes? Do you really want completely separate tunes or just separate tables for a few things, like ignition, fuel, max boost?

Most aftermarket EMS handle this by having some tables be switchable by some external input. Dual fuel using an ethanol sensor usually has it's own setup as it interpolates between tables instead of blindly switching from one to another. It's nicer to have everything in one tune so if, for example, you change the VVT PID parameters, you don't need to go and update all N maps.

RAM pressure is reduced in the latest code (there's already 9000 bytes free), and there are future improvements in the works (another 20,000 bytes, a full tunes-worth.) If it doesn't get all gobbled up by Lua then there should be plenty of memory for multiple maps within a single tune.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: MCU choice

Post by AndreyB »

Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply