I spent some time thinking about this and I think this thread is an awesome discussion.
I think the biggest hurdle here is to have a configurable engine position input. Determining the engine position is the very heart/core/soul of the ECU and determines its performance. For any OEM this engine position is fixed, so no OEM ever needs to have a runtime configurable engine position input.
Recently a friend of mine placed a Mitsubishi based 4B12 engine in his Dodge finding out the Mitsubishi crank wheel differs from the Dodge and he asked me to change the code of the Dodge ECU to accept the Mitsubishi wheel... Obviously that caused me to laugh as decoding the wheel goes very deep into the core of the ECU code and he had to swap the crank wheel...
So next step is obviously to check how other aftermarket ECU's tackle this problem. VEMS, MS-II, MS-III are able to decode 60-2 wheels all the way up to 10.000 rpm and above. None of these MCUs come even close to the speed of the STM32F4. Both MS-II and VEMS are MCUs running at a mere 20 or about MHz with 8 / 16 bits. The STM32 with its 32 bits and 144MHz is quite a beast compared to them.
So why can these ECUs handle those wheels? It simply boils down to heavily optimized code and clever use of the timer / interrupt peripherals available in these MCUs. Also: every type of input has its own specialized code. So this means 60-2 wheels use different code compared to 44-2-2 wheels for instance. Obviously realizing engine decoding in such a way creates quite a lot of platform dependent code which is not easily portable. Still: I think changing to an even more powerful MCU or dedicating an extra MCU / FPGA purely for decoding does not really simplify things either and also makes things more expensive. The SW architecture can still be somewhat flexible, but it would require dedicated code for a combination of platform and engine decoding wheel. That way the STM32F4 easily beat the accuracy of the MS-II / VEMS.
The MS-III and TMS570 are different beasts compared to the STM32F4 / MS-II / VEMS as they have some sort of co-processor for timing related stuff. The MS-III has the XGATE co-processor and the TMS570 has the N2HET timer/co-processor. Decoding wheels and determing engine position with the XGATE and N2HET faces exactly the same problem as with the 'traditional single core' approach as it needs specific code for any combination of platform and engine wheel. So from a maintenance/stability point of view such approaches do not offer any advantage. Obviously with a dedicated piece of hardware the performance/accuracy can easily be improved.
So circling back to the question: "Is the STM32F4 the right chip" I think the answer is yes. In terms of timers / performance it is much more powerful than the MS-II / VEMS so it can easily be as good if not a bit better than those solutions when it comes to timing performance / accuracy. Looking at different hardware platforms does not hurt, but in my opinion the performance that can be obtained with this platform is enough to satisfy any of the current cars running rusEFI. I think bringing rusEFI up to the level of the MS-II should be one of the first priorities.
I think a good architecture for determining the engine position should be defined. There will be a great dependency on timers so the HW design is also important. For some inputs/outputs it might be desired to have them on timer inputs/outputs. Then it would require dedicated code for different trigger wheels. Again: I did not have a look at the current schematics / source code so I do not know what has been done already (shame on me
), but there are many ways to solve this problem. Determining the architecture needs some multi-dimensional thinking as it involves interrupt(latency), timers, inputs/outputs (potentially to timers), software routines and other details I am not thinking of now. Best way to start in my opinion is with requirements and discuss those first before diving into implementation details.
I would start with requirements something like this (I am making these numbers up just for illustration):
-Support for 36-1, 60-2 wheels up to 15000 RPM
-Sequential fuel and spark up to 8 cylinders (8 individual spark and fuel outputs)
-Fuel accuracy down to 0.5 microseconds
-Spark accuracy down to 0.5 degree
If you write these numbers down you can start to explore different implementations and judge them on performance / maintainability / flexibility (w.r.t. HW designs) etc. and go for the most suitable implementation.