Page 2 of 6

Re: Is stm32f4 the right chip?

Posted: Mon Feb 09, 2015 9:27 pm
by Sergey89
kb1gtt wrote:Also in the logic analyzer capture, what was the sample rate? AKA 24MHz sample clock in the analyzer will add a certain level of +/- tolerance jitter in the measurements.
The sample rate of the logic analyzer is 200 MHz.

Definitely is not a problem to obtain 0.1 or even 0.01 deg resolution for ignition events when using STM32F4 hardware timers with the associated output pins.

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 2:09 am
by abecedarian
Sergey89 wrote:
kb1gtt wrote:Also in the logic analyzer capture, what was the sample rate? AKA 24MHz sample clock in the analyzer will add a certain level of +/- tolerance jitter in the measurements.
The sample rate of the logic analyzer is 200 MHz.

Definitely is not a problem to obtain 0.1 or even 0.01 deg resolution for ignition events when using STM32F4 hardware timers with the associated output pins.
I'm curious as to what you consider an ignition event?

Coil pre-charge would be one event; coil discharge is another. Even if you're dealing with LSx type coils, dwell is 4-7ms... and driving IGBT or similar might be dwell = 45 degrees as opposed to some temporal-based calculation... which could probably be converted between the domains, but that's not my point.

If you have to fire an interrupt to charge the coil, then fire another to fire the coil, you have at least 13ns spent jumping into the IRQ handlers for one cylinder, and that doesn't include the time spent actually executing the code necessary to handle the interrupts properly. Overlapping processes will turn into the equivalent of pushing and popping from the stack, but it's entirely possible the stack might need modified and/or re-ordered, which would require more cycles and thus introduce latency....

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 4:08 am
by kb1gtt
@abecedarian STM has features that include "tail chaining" which is a cool stack thing, so it doesn't push and pull from the stack more than once. The link from Sync is very informative.

@Sergey89 About the .1 degree or .01 degree, at what maximum RPM can that be obtained? I know it can be obtained at 6kRPM, but how much faster can it be obtained?

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 4:54 am
by abecedarian
kb1gtt wrote:@abecedarian STM has features that include "tail chaining" which is a cool stack thing, so it doesn't push and pull from the stack more than once. The link from Sync is very informative.
....
Well, most ARMv7 has that, including the TMS570 chips mentioned elsewhere, so I'm glad you found that link informative.

Maybe now you can appreciate what I wrote:
The easiest ways to minimize interrupt latencies are to either get out of the IRQ handler as quickly as possible so you can respond to the next interrupt, or do your best avoid generating interrupts in the first place. The first might require something be handled in the system's "main()" function, which is fine, but that only moves any delays to the 'main()' loop, outside of the IRQ handler, and may mean something has to wait until the processing of things starts again. The latter requires either software to poll things and respond accordingly, or have hardware that does that itself.

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 4:56 am
by Sergey89
abecedarian wrote:If you have to fire an interrupt to charge the coil, then fire another to fire the coil, you have at least 13ns spent jumping into the IRQ handlers for one cylinder, and that doesn't include the time spent actually executing the code necessary to handle the interrupts properly. Overlapping processes will turn into the equivalent of pushing and popping from the stack, but it's entirely possible the stack might need modified and/or re-ordered, which would require more cycles and thus introduce latency....
You don't need to change the state of the output in the IRQ handler. All you need is to write the output compare register in the primary trigger IRQ handler and the state of the output will be changed on the hardware level without any significant delay.

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 5:05 am
by abecedarian
Sergey89 wrote:
abecedarian wrote:If you have to fire an interrupt to charge the coil, then fire another to fire the coil, you have at least 13ns spent jumping into the IRQ handlers for one cylinder, and that doesn't include the time spent actually executing the code necessary to handle the interrupts properly. Overlapping processes will turn into the equivalent of pushing and popping from the stack, but it's entirely possible the stack might need modified and/or re-ordered, which would require more cycles and thus introduce latency....
You don't need to change the state of the output in the IRQ handler. All you need is to write the output compare register in the primary trigger IRQ handler and the state of the output will be changed on the hardware level without any significant delay.
Why go through the hassle of writing to some compare register when you could do atomic manipulations on port registers?

The fact remains, whichever way, an interrupt has to occur for something to happen; whether it turns something on or off is inconsequential.

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 7:25 am
by Sergey89
abecedarian wrote:Why go through the hassle of writing to some compare register when you could do atomic manipulations on port registers?
Because it provides the highest possible accuracy.
The fact remains, whichever way, an interrupt has to occur for something to happen; whether it turns something on or off is inconsequential.
Interrupt will happen after the MCU is already turned the output.
kb1gtt wrote:About the .1 degree or .01 degree, at what maximum RPM can that be obtained? I know it can be obtained at 6kRPM, but how much faster can it be obtained?
For example:

timer tick = 0.25 us
desired resolution = 0.1 deg
1 / (0.25 * 360 * 10) = 0.00111... rot/us
0.00111 * 1000000 * 60 = 66000 rot/min

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 11:12 am
by kb1gtt
Looks like the key difference is that Sergey89 is considering it to be 1 IRQ per .1 deg I'm considering it to be 4 to 6 IRQ's per .1 deg.

.000000265 S/tick = Min CPU tick
.1 deg = Desired Accuracy
3600 ticks/rot

Time/rot = .000000265S/tick * 3600 tick/rot = .000954 S/rot
RPM = (1/.000954S/rot) * 60S/Min = 62.8kRPM.

However with my 4x we get 62.8kRPM / 4 = 15.7kRPM.

Ultimately I'm guessing that it's 4 to 6 IRQ events that need to be captured in that .1 deg. I'm also guessing the IRQ's will need around 30 cycles which I'm guessing because that's the same as the initial latency. So ultimately I'm guessing at many critical items which I really don't know. I'm sure Sergey89 has a better understanding of this latency thing. He's probably correct that it can easily handle above 12kRPM.

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 8:32 pm
by Sergey89
The key difference is that in my case waveform is generated via the ouput compare unit.

For example, we need to generate a signal with 10 us delay relative to the captured signal. Actually we get 10.12 us delay and it does not depend on the number of interrupts ;)

Re: Is stm32f4 the right chip?

Posted: Tue Feb 10, 2015 9:35 pm
by abecedarian
Maybe I'm confused but the only interrupts you should be dealing with are the teeth and cam events, a timer compare/match to turn on/off injectors and a timer compare/match for firing spark... okay maybe two each for injection and spark since you need to control injection time and dwell.

That's 4-6 unique interrupts for a full 720 degree engine cycle.


Oh, you say you need an interrupt pool so you can control events for each cylinder independently?
Please explain.

Re: Is stm32f4 the right chip?

Posted: Wed Feb 11, 2015 6:30 am
by abecedarian
After some thought, I should correct myself and say "4-6 interrupt sources".

Re: Is stm32f4 the right chip?

Posted: Wed Feb 11, 2015 7:13 am
by Sergey89
Ok. What I want to say is that you don't need to use interrupt to change the state of the output. You need to use interrupt to *plan* this change with a specified delay relative to the captured tooth or to the previous event. The MCU itself will change the state of the output after the specified delay is over.

Re: Is stm32f4 the right chip?

Posted: Thu Feb 12, 2015 10:01 am
by abecedarian
I'd like to see things represented as a state diagram / machine.

Re: Is stm32f4 the right chip?

Posted: Sat Feb 14, 2015 10:15 am
by DaWaN
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 :oops: ), 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.

Re: Is stm32f4 the right chip?

Posted: Sun Feb 15, 2015 5:00 am
by abecedarian
DaWaN wrote:I spent some time thinking about this and I think this thread is an awesome discussion.
I just spent about 4 hours bouncing back and forth trying to organize my thoughts, directly addressing (and contradicting) some of what you posted, only to arrive at the following. ;)

I think it would have been an awesome discussion back when things started out.

Anyhow, as it stands now, Andrey now has TMS570LS1224 hardware in his hands, and many of the points raised are moot pending TI addressing the request for more documentation and example code for using N2HET. Making assertions or asserting conclusions based on what people assume as opposed to making informed decisions is not wise; that is only subjective and not objective reasoning.

Re: Is stm32f4 the right chip?

Posted: Sun Feb 15, 2015 5:11 pm
by Sync
Well, I think the takeaway is that rusEFI needs a more closer to the hardware implementation, at least for the position capture.

It does not matter which MCU it is in the end, but the question rather is if you really want to use one that has no community support (as in actual opensource community). You also loose all developers that might be interested in contributing due to the fact that there are only so many that have actually used the TMS before and know its quirks.

I wonder why you are so fixiated on using the TI stuff, instead of spending the same time figuring out how to make the existing hardware perform properly.
The N2HET coprocessor sure is a nice unit, but there is not much benefit in such a simple application like ours.
If the position tracker really robbed that much resources it's entirely possible to just add a coprocessor in the form of a second STM32 and have it communicate with the highlevel processor.

I don't think that the discussion is moot or over, it is one of the core decisions that have to be made before a lot of time is spent. I think the amount of posts in such a short time clearly shows that there is a lot of interest and room for exchange on this topic.

I don't really see how you come to the conclusion that most of the results here are not objective? It's the same with the TMS, just because you know that the hardware should have enough performance does not mean it actually has. It is basically the same deal as with the STM32. Of course it has, but that depends on the code, same with the STM32.

I'll try to find the time to post some actual results for timing jitter and accuracy with a simple interrupt driven 60-2 trigger wheel decoder in the next few weeks, then we should be able to see if there is a huge issue or not.

Re: Is stm32f4 the right chip?

Posted: Mon Feb 16, 2015 12:35 pm
by kb1gtt
I tend to think the STM is a good choice. I can't find any specific physical limits of concern.

The only things I see it potentially lacking are some automotive specifications, which may or may not offer features we are interested in. I understand there is some potential that an AEC or ISO automotive qualified part will have 100% burn in testing which removes the potential for final defects, or they might offer some beneficial fail safe modes. However if we can't get the specifications, we can't know what those features are. We have to rely on details specified in the MFG datasheet instead of relying on an AEC or ISO specification.

I see other chips get the automotive check mark by following ISO/TS16949 which is purely a quality control system to prevent defects, and appears to have little to do with the underlying technology or reliability of the final system design, it appears it just means that it was manufactured too the engineering specification and that MFG did not create any defects that were outside of the engineering specification. AKA 100% burn in simply means it meets specification, not that it's correct for the application.

I see AEC Q100 and it's other specifications which appear to be based more on the underlying technologies, but seems to have a minimal traction as it's Ford, GM and Chrysler pushing their own agenda. ISO or IEC standards seem to be far more international, and driven by a much more broad set of efforts, as well as driven by much larger companies like Bosh, VW, ect.

From the basic look at AEC Q100 and TS16949, it appears those get into the technology of a product, but doesn't seem to address the actual design, just the MFG of the design. I see SAE's J2886 which covers failure modes, but seems to have minimal adoption in the automotive industry.

Ah here we go, looks like these ISO standards covers items we might have interest in http://en.wikipedia.org/wiki/ISO_26262 http://en.wikipedia.org/wiki/IEC_61508 They first determine when and where functional safety needs to be address, and what needs to be done to address it. Keep in mind these are a minimal set of requirements and suggestions. Think of them more like a check list to remind you of the things you might want to consider. They include a rating system for identifying features, failure modes and the effects that failure could have on a particular feature. They have ways to rate the probability of the issue happening, and they allow specific allowable limits upon different things like "Multiple loss of life", "Loss of a single life", ect. I also like that they define a bunch of vocabulary, which helps create common language and stream lines collaboration. However these don't seem to apply to the chip level of a component, it's more of a design cycle thing, and the design cycle needs to address the underlying technology.

What about EMC, that's another item and it seems the chips don't advertise if they are friendly to EMC or not. It makes sense as the chips doesn't have antennas and it really depends on the layout. I see a list of specs found here http://www.cvel.clemson.edu/auto/auto_emc_standards.html

So when it comes to chip selection, I see a benefit in functional safety and EMC regulatory specs as applied to a chip. However I don't see anything that specifically ties certain technologies like AEC or ISO to those chips. So I see little need for an AEC or ISO certified chip. Instead I think the design cycle and life cycle need to include specific consideration for the feature sets, failure modes and how they apply to the final device.

Because of this, I think the STM chip is a good choice. However I would like to learn more about what failure modes it's IO could how those failure modes could be changed with a different chip.

Re: Is stm32f4 the right chip?

Posted: Tue Feb 17, 2015 9:01 am
by abecedarian
I think the horse is dead; stop beating it. ;)


Anyhow, if Andrey wants to fork for TMS, so be it. That doesn't mean STM32 is dead.

*cheers*

Re: Is stm32f4 the right chip?

Posted: Tue Feb 17, 2015 10:34 am
by kb1gtt
I'm just trying to get a basis for decision making. AKA, the TMS has a couple features like redundancy in the validation of CPU execution, ect. These are features that enhance the functional safety. I'll inquire about the features of the TMS in another thread. The big thing I was blabbing about here is that I'll lobby that rusEFI look at features not generic automotive grade specs.

Re: Is stm32f4 the right chip?

Posted: Tue Feb 17, 2015 11:05 pm
by abecedarian
@kb1gtt - Find the "safety" compliance docs for STM32F4 yet?
Their suggestions for how to meet stuff and such are an interesting read.

Re: Is stm32f4 the right chip?

Posted: Wed Feb 18, 2015 10:46 am
by kb1gtt

Re: Is stm32f4 the right chip?

Posted: Sun Mar 08, 2015 9:26 am
by abecedarian
kb1gtt wrote:Do you mean this http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/LN1900/PF261567?icmp=pf261567_pron_pr_feb2015&sc=safesil-pr

Just found that link, I have no idea what is inside yet.
What did you find?

Re: Is stm32f4 the right chip?

Posted: Sun Mar 08, 2015 10:53 am
by kb1gtt
I've been focusing on getting the red suby setup, but even then the real world has limited my hobby efforts. I still haven't gotten to look into the safety document very much.

Re: Is stm32f4 the right chip?

Posted: Wed May 06, 2015 3:22 am
by Simon
Hi,

I am looking at some recent post and two issues seems to prevail: i/o and timing. (The two are also a big constraint at work, and i'm actually doing the thinking for both here)

Any microcontroller is going to have issue when trying to have absolute timing using interrupt or a really big number of io, witch make me thinking of CPLD/FPGA...

The logic needs to remain on a microcontroller, just because it is easier to maintain. Also communications are much simpler to handle with c/c++ code so by combining a uC with an FPGA we get something quite interesting.

Lattice ICE40UL and XO3L families seems to be quite low cost and some package are... not BGA...
Also, dev board similar to the discovery and launchpad are availableé ( http://www.digikey.lu/product-detail/en/LCMXO3L-6900C-S-EVN/220-1935-ND/5039065)

I don't have a lot of experience with FPGA, but I don't think it is a reason to not look into them...

So, what are your opinions?

(Edit: maybe http://www.digikey.lu/product-detail/en/ICE40LP384-SG32/220-2646-ND/3974680 )

Re: Is stm32f4 the right chip?

Posted: Wed May 06, 2015 10:05 am
by kb1gtt
Hello and welcome along.

About FPGA ECU kind of stuff, there was some discussion in this thread. http://rusefi.com/forum/viewtopic.php?f=13&t=803

For typical engines and even many CDI and direct injection engines, which can have multiple spark or fuel pulse events during combustion, the IO count and speed are technically fast enough, even for up to around 12kRPM. However it requires someone to optimize some bits of code. For example, some bits of code are currently written in a free C compiler which isn't going to make the fastest or most optimized code, so if you were to write those section(s) is assembly language or re-write some Chibios functions to be a bit more light weight, then several areas of latency can be removed. The issue we have isn't the hardware latency, it's the shortage of developers. What would really help this project would be if we can get more software developers to identify bottle necks, then optimize where required, then post a patch. The philosophy has been to get it working, then to get it optimized. Often a project can have bits of code that aren't perfect, but are functional. The goal has been to focus on function first. Then when two function conflict with each other, address the conflict.

We have also developed a prelimary equiv dev board with additional IO's found here http://rusefi.com/forum/viewtopic.php?f=4&t=749

Re: Is stm32f4 the right chip?

Posted: Wed May 06, 2015 11:04 am
by AndreyB
Simon wrote:I don't have a lot of experience with FPGA, but I don't think it is a reason to not look into them...

So, what are your opinions?
I do not have an opinion - I do not have enough information to have an opinion :( Would you be available to implement a HelloEngine codebase for this platform?

Re: Is stm32f4 the right chip?

Posted: Thu May 07, 2015 8:35 pm
by DaWaN
I have some experience with FPGA's and writing code for them in VHDL.
Ultimately a hardware solution realized in a FPGA is superior to a software/timer solution in a MCU.
However: what do we really need?

All I can say I have to agree with kb1gtt. The current MCU should be well capable of the timing requirements for an ECU like rusEFI I think.
So I do not see the added value of adding extra cost and complexity (2 codebases!) while we can achieve the same goal by better optimized software.

Re: Is stm32f4 the right chip?

Posted: Fri May 08, 2015 1:43 pm
by Simon
It was also my conclusion at work but the part where you need to tune everything ups takes much more time than what was first planned that I was wondering how much time could have been saved by taking a different avenue...

I am still getting over the code for the next months... But my real conversion project will have to wait for my warranty to be finished :P

Out of curiosity, do you have the % of time in interrupt and sleep?

Re: Is stm32f4 the right chip?

Posted: Fri May 08, 2015 5:52 pm
by AndreyB
Simon wrote:Out of curiosity, do you have the % of time in interrupt and sleep?
we do not :(

Re: Is stm32f4 the right chip?

Posted: Wed Apr 12, 2017 3:14 am
by marko
I got an email the other day that made me think of this thread.

Doesn't look like its fully on-line yet but there's a new MCU from freescale^W NXP.

"S32K" - Cortex M4F, 5V, automotive qualified, 112MHz, with 2MB flash and 256k ram. LQFP-176 with open tools supposedly.

http://www.nxp.com/products/automotive-products/microcontrollers-and-processors/arm-mcus-and-mpus/s32-processors-microcontrollers/32-bit-automotive-general-purpose-microcontrollers:S32K

I haven't looked much about it yet but ill try a demo board sometime.