Is stm32f4 the right chip?

klyttle
Posts: 19
Joined: Fri Jan 02, 2015 9:47 pm

Is stm32f4 the right chip?

Post by klyttle »

Jeez! This is more than enough techno babble bull@#$% to make your head spin! :o . Makes me wonder if switching to this Hercules from TI is worth the trouble... or is it? :?

Edit by @: https://github.com/rusefi/rusefi_documentation/blob/master/misc/selecting_open_source_ecu_microcontroller.md
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: Is stm32f4 the right chip?

Post by AndreyB »

We need a 5v automotive grade chip. Hercules from TI just seems like the best option for us :)
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
Sync
Posts: 7
Joined: Wed Jan 07, 2015 10:11 pm

Re: Is stm32f4 the right chip?

Post by Sync »

It might sound a bit rude as the first post, but why do you think that there is a need to switch to a 5V controller?

A lot of the currently deployed automotive controller platforms run on a single 3.3V supply mostly due to speed or cost considerations.
It is much cheaper to buy a already proven silicon IP core that runs on 3.3V than to run your own.

Look at the Freescale or Infineon lineup, most of them run on 3.3V or even lower.

You have to protect any input anyway and adding voltage deviders to ADC inputs costs basically nothing but board space.
Translating between voltage levels is a hassle, but I'd rather stay with a platform that has good community support and especially a free (as in gcc) compiler with
free libraries.

I'm currently designing a base board that tries to implement more automotive grade circuit protection and EMI considerations. So far the powersupply seems to
work fine with test pulses according to ISO7673-2.
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: Is stm32f4 the right chip?

Post by AndreyB »

I've mixed two separate issues when I said that we need "5v automotive" - one question is if we need 5v and another question is if we need automotive. I am pretty ignorant in both issues but just the PR side of it alone forces me to look at least into automotive. I guess if it's also 5v it would not hurt, but the bigger part is 'automotive', not '5v'.

At the moment TMS570 is the best automotive chip fulfilling all our needs
1) dev board
2) chip availability
3) free toolchain
4) free support

Spansion fm4 is lacking #4 but it's theoretically an option
Freescale/ST PowerPC is lacking #3

I believe Infineon is also lacking #3
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
Sync
Posts: 7
Joined: Wed Jan 07, 2015 10:11 pm

Re: Is stm32f4 the right chip?

Post by Sync »

Well, the toolchain might be free now with the implications of a code size of 16K max from what I can understand, that part is not clear.
But how does that change in the future? If at some point TI chooses to lock down the licensing development is suddenly impossible for people without the old tools.

The STM32F4 might not be officially be automotive qualified but it is plenty robust enough. All inputs can be appropiately secured against failure.
They are qualified from -40°C to 105°C, which is not entirely automotive, but lets face it, most users will run their ECUs in the cabin where temperature will not be an issue.
Also they are used in a lot of industrial control situations that are far more challenging than our cars. If it would be really such a big issue a lot of aftermarket ECUs would
die all the time.

You also get a lot of community support with the STM32, several truly free library sets, some RTOSses and a variety of compilers.
I don't think that it is worth to lock yourself with a "real" automotive MCU, too much effort would be lost.

The benefits do not outweigh the risks in the log run in my opinion.
Sure, you can always port code to some different architecture, but do you really want to go that route? A lot of work for no benefit, besides saying that the MCU is automotive
qualified. That does not help the rest of the deal, I think it would be better to find a common specification of inputs and outputs (looking at some other aftermarket ECUs ;)) and
design a solid base from there. It is not productive to keep looking for other/better/cooler/whatever MCU when there is no real need.

I'm sorry if my posts are a bit harsh, but I really want to see rusEFI to be a successful opensource project with a lot of users/developers. :)
It would be sad if all goes down the drain when TI decides to either pull the IC or clamp down on licensing.
klyttle
Posts: 19
Joined: Fri Jan 02, 2015 9:47 pm

Re: Is stm32f4 the right chip?

Post by klyttle »

This question of whether or not this STM32F4 MCU and its Discovery dev. board is the right one for rusEfi, I say yes... at least for the time being; It seems to be working quite well thus far, based on the YouTube videos I've seen.

Now, it's possible that development might reach a point where this MCU may no longer suffice (at which point, maybe you might want to consider going the TMS570 route). But I haven't seen any evidence of that as yet - unless I'm missing something.
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: Is stm32f4 the right chip?

Post by AndreyB »

Sync wrote:Well, the toolchain might be free now with the implications of a code size of 16K max from what I can understand, that part is not clear.
Not clear indeed, but looks like no code size limit - the only limitation is to only use XPS100 debug probe.

stm32f4 has a TON of benefits, stm32f7 is coming. At this point I doubt we would quit stm32 completely. Considering the fundamental idea of separating HAL code from logic code I thing it would be nice to have at least some version for another platform, who knows maybe support both versions. That would be pretty beneficial from the code quality prospective.

One way or another, hopefully rusEfi would keep the current practical approach.
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
DaWaN
Posts: 51
Joined: Sat Sep 20, 2014 6:54 pm
Location: Benschop, Netherlands

Re: Is stm32f4 the right chip?

Post by DaWaN »

I am in sync with Sync on this subject.

To me the switch to a different MCU is not very crucial.
The lack of a 5V ADC requires a bit of extra hardware and thus board space, but does not seem like a huge problem to me.
The price of the STM32 chips is very low and so is the price of general purpose resistors and amplifiers. The STM32 is also very easy to source and all tools and programmers are also cheap and available everywhere. Temperature range is also good enough for the bulk of applications.
Also the opportunity to upgrade to the ARM Cortex M7 very easily with the STM32 system is very nice.

There are quite a lot of ECU's that do not use specific automotive chips, but are fine ECU's. The older Honda PGM-FI systems do use simple MCUs with good hard- and software design. Rarely heard of one of these ECUs failing other than leaking electrolytic capacitors. Some goes for VEMS, those guys just use a jelly-bean AVR as their main MCU. Quality in the ECU is mainly in good hard- and software design. The hard- and software design is much more key to the quality of the ECU rather than the actual MCU used.

I think it is a good exercise to explore the automotive grade chips as they do offer some advantages over general purpose microcontrollers in terms of peripherals/speed/specification, but in my opinion a general purpose microcontroller can be the core of a successful ECU as long as its performance is sufficient and the hardware design is sound.

Another thing is portability. Why is Linux, Android, ChibiOS successful as an open-source project?? Simply because it can run on different hardware. Take FreeEMS / VEMS / Megasquirt as examples for open-source ECUs and you see they are not really portable. The ultimate goal for open-source ECU software in my mind would be portability. How cool would it be to target RusEFI to an OEM ECU and just refresh it with software written from scratch? That is my ultimate goal of open-source ECU software.
So this would be reason to retain STM32 support, to keep the firmware portable.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Is stm32f4 the right chip?

Post by kb1gtt »

Some key limitations of the STM chip is the IRQ latency. The automotive grade devices generally have latency's that can be down around 5 to 10nS. Which rivals FPGA logic. Granted you still have software delays after that with the point being, the latency can be lower. So how low does the latency need to be? Well that depends on your crank wheel, RPM, ect. The latency we currently get easily allows a 36-2 wheel at 6kRPM. However a bike at 12kRPM and 60 tooth wheel is beyond the abilities of the STM chip. Also a direct injection system with multiple fuel pulses during combustion can also be on the fringe edges of the IRQ latency.

Also beware the implication that automotive grade is better. While the specs generally include a variety regulations for safety and fail safe circuits, they also cover many manufacturing concerns. For example, why would a pin that will never be connected to an ESD source need an ESD diode to protect it. More importantly, why would a large automotive company pay for all those diodes? There are many specs that allow the removal of these diodes, especially on analog inputs where the ESD diodes capacitance and leakages warp the signals, or high speed digital signals with eye diagram. The only way I know to figure out if it has the ESD diodes with out purchasing the chip and measuring it, is to look at the IBIS simulations for chips. It's common that the only way you have to know if the pin has an ESD diode is to use the MFG supplied IBIS simulations then tune your transmission lines (PCB traces) to get a proper voltage levels. After a while, you'll start to notice that some pins have a certain amount of capacitance, while others don't. Then when you ESD the ones that don't have that capacitance, you'll notice they break easily. You'll also notice that the pins with out those ESD diodes are easier to get a proper PCB layout. AKA improper impedance matching on your SPI transmissions traces will result in higher Bit Error Rates (BER) Such issues can happen 1 in 100k bits or more if the PCB is not properly designed. An automotive grade chip, often controls the assembly process (mostly humidity) which will ensure the assembly PNP machine does not machine ESD. After assembled, the board will never see an ESD event, as the ESD should be captured at the connector, and chip to chip connections on a PCB will not see ESD. So those chips often do not have ESD diodes for the sake of reducing costs. Or at least it reduces cost in large qty, which is not so good for little guys like us, as it increases our costs and our failures, when we don't know these subtle differences. Can we guarantee that machine ESD does not happen to a SPI pin?

However an industrial grade chip could allow that SPI pin to be a GPIO, or other function. So an industrial chip will generally require the chip to have ESD diodes on all pins. This often requires a bit more PCB layout, but with some basic rules you can generally do this good enough, or your process often allows for an occasional bit error. For example, the EGT chips on Frankenso. If we get one bit that tells us a wrong temperature once every couple or hours or days, it's not a huge issue. I doubt we'd ever notice, and if we did, I doubt we'd care. We'd just pass it off as a small noise spike on the sensitive thermocouple lines, and add a smoothing filter to get ride of this noise and other noise.

Point being, you can't use automotive grade vs industrial grade as your measure of good vs bad. It's often a good starting point, but you have to dig into the underlying technologies and determine if they are appropriate for the task they are preforming.

That said, I feel that for after market DIY and track use, the STM is good enough for the applications it will be used for. The STM does have some limitations, like those high rev bike engines, so I can see how a faster chip could be needed. If we switch to a faster chip, I would generally suggest a chip that specifies engine control, as it will likely have the hardware that needed for engine control. AKA correct amount of ADC vs timer, vs CAN interfaces. If you can't get that then going with an automotive chip is often a good way to start a ball park guess if the chip is good, but you eventually need to do a low level analysis to make sure the IO have the protections you expect to be there. If you don't follow the assembly procedures specified in the automotive grading, you could cause more failures than you would get with an industrial, as industrial chips have more generic and more commonly know assembly requirements.

Any how, long story short, I agree, STM32 chip is good for most of what we are doing, but we should also keep an eye out and mindful ear for the future and evolving engine technologies.

I also like the STM's community for support, as well as the portability offered by the OS.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

If STM32F4 runs an engine, fine. Does that make it "right"?

Some of kb1gtt/Jared's comments do allude that with things as they stand, the chip is getting thin. He also gives good reasons for what considerations the alternatives require before jumping off to something else.
You can lead the horticulture but you can't make them think.
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Is stm32f4 the right chip?

Post by Sergey89 »

kb1gtt wrote:Some key limitations of the STM chip is the IRQ latency. The automotive grade devices generally have latency's that can be down around 5 to 10nS. Which rivals FPGA logic. Granted you still have software delays after that with the point being, the latency can be lower. So how low does the latency need to be? Well that depends on your crank wheel, RPM, ect. The latency we currently get easily allows a 36-2 wheel at 6kRPM. However a bike at 12kRPM and 60 tooth wheel is beyond the abilities of the STM chip. Also a direct injection system with multiple fuel pulses during combustion can also be on the fringe edges of the IRQ latency.
Cortex M4 require only 12 cycles to start IRQ handler (it will be cool to see Cortex R4 numbers). I think that the main problem of the current implementation is the software and OS latency. 12kRPM and 60 tooth wheel is not a problem for the slower MCUs and it should not be a problem for STM32F4.
Sync
Posts: 7
Joined: Wed Jan 07, 2015 10:11 pm

Re: Is stm32f4 the right chip?

Post by Sync »

I think the latency issue is rooted in the RTOS, for a position controller project I had to give up ChibiOS because I could not process ADC data in an interrupt over a few kSPS.

Maybe the discussion should be more in the direction of whether we should try to go to a more event driven framework than the RTOS. Keep in mind that 6811 driven ECUs with 2MHz core speed controlled F1 cars in the 80s...

To the ESD issue, I don't really think it is that big of a deal. ST specs it to 2000V HBM and 500V CDM, plenty strong for China manufacturing. I have not have one fail from manufacturing problems just yet...
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

I agree, to an extent, the system should be more event driven, but I find the comparison between this and F1 in the '80s a bit of a stretch. IIRC, many of the ignition systems at the time were magneto based, so there goes a bunch of current ECU requirement out the window. The fairly narrow RPM requirement of an F1 engine of the time, albeit high RPM, also precluded the fine injector pulse width required in a consumer vehicle as well. Again, IIRC, many of the FI systems used were also mechanical with electronic 'controls' over those mechanical operations, with Bosch K-Jetronic or similar types being used by many.

I could be wrong though. ;)


And since it was brought up earlier, Honda's first PGM-FI (consumer oriented) looked like this on the inside (note the grand total of 20 wires inter-connecting the boards):
DSC00006.JPG
DSC00006.JPG (3.85 MiB) Viewed 100672 times
The two, large chips in the middle of the right-side board are extended-temp (i.e. "automotive grade" since that really didn't exist at the time) 8xxx based, as best anyone willing to talk will tell. ;)
You can lead the horticulture but you can't make them think.
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Is stm32f4 the right chip?

Post by Sergey89 »

This is a result of the real latency measurement for STM32F4.

Code: Select all

void TIM2_IRQHandler(void)
{
    if (TIM2->SR & TIM_SR_CC3IF) {
        TIM2->SR = ~TIM_SR_CC3IF;
        GPIOD->BSRRL = GPIO_ODR_ODR_12;
        /* 265 ns latency before this line can be executed */
        GPIOD->BSRRH = GPIO_ODR_ODR_12;
    }
}
Attachments
oc_ic.png
oc_ic.png (61.1 KiB) Viewed 100662 times
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: Is stm32f4 the right chip?

Post by AndreyB »

Sync wrote:I think the latency issue is rooted in the RTOS, for a position controller project I had to give up ChibiOS because I could not process ADC data in an interrupt over a few kSPS.

Maybe the discussion should be more in the direction of whether we should try to go to a more event driven framework than the RTOS.
First of all, that's off-topic for the scope of this thread.

As a matter of fact, I am far from convinced that ChibiOS is part of our problem: it's not really involved with driving the engine, everything happens within the input capture interrupt handler. See updated post in the source code Q&A post: http://rusefi.com/forum/viewtopic.php?f=5&t=10&p=431#p431

I am curtain that current implementation with stm32 and ChibiOS could be improved significantly - it's all the question of human resources :( A bunch of tasks where rusEfi could use some help is marked with [help needed] in the Software sub-forum - http://rusefi.com/forum/viewforum.php?f=5
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
Sync
Posts: 7
Joined: Wed Jan 07, 2015 10:11 pm

Re: Is stm32f4 the right chip?

Post by Sync »

That would be 44 cycles when running at 168MHz. Are you sure that you are running at full speed?

@russian:

Yeah, that wasn't meant as a negative comment, just my experience with latency issues. I have to look deeper into the actual code to get a feeling for what is happening. I just had a quick glance and it seemed to about match my problem.

I just don't want to waste a lot of time developing on a platform that will be changed in the near future. :/
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Is stm32f4 the right chip?

Post by kb1gtt »

That's good news about the latency. I once predicted a min allowable latency of 694nS the thought process / math is documented here https://code.google.com/p/daecu/wiki/Minimum_processor_latency Your measured 265nS is well below this min requirement. So I need to take back my concerns of latency as a need for a different processor. Was that test done with the full speed STM? I seem to recall the Discovery board runs a much slower clock rate. What was the MCU XTAL rate for that test?
Welcome to the friendlier side of internet crazy :)
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: Is stm32f4 the right chip?

Post by AndreyB »

Sync wrote:I just don't want to waste a lot of time developing on a platform that will be changed in the near future. :/
The stm32 boards are out there already. There is just no chance stm32 would be dropped, at least not until we get a major issue caused stm non-automotive grade. And it does not look like one is coming?
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
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

*edit- nevermind.
You can lead the horticulture but you can't make them think.
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Is stm32f4 the right chip?

Post by Sergey89 »

Sync wrote:That would be 44 cycles when running at 168MHz. Are you sure that you are running at full speed?
kb1gtt wrote:Was that test done with the full speed STM? I seem to recall the Discovery board runs a much slower clock rate. What was the MCU XTAL rate for that test?
Yes, the MCU speed in this test is 168 MHz. But this is not only IRQ latency test it also GPIO latency test. Moreover IRQ handler contains some software stuff needed to be executed before the output pin will be toggled. For example, this code produces only 160 ns latency:

Code: Select all

void TIM2_IRQHandler(void)
{
    GPIOD->BSRRL = GPIO_ODR_ODR_12;
    ...
Attachments
oc_ic2.png
oc_ic2.png (59.42 KiB) Viewed 100631 times
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

~168MHz with 160ns latency?
That's like... 1000 cycles?

At 168MHz, 1 cycle is about 6.1 ns, so 160[ns latency] * 6.1 [ns per cycle] = 976 cycles

More interesting, 976 cycles * 6.1ns = 59536ns... almost 6 microseconds.

My math could be wrong though.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Is stm32f4 the right chip?

Post by kb1gtt »

TIM1,8 have a max clock of 168, and interface clock of 84MHz. However the test was for the more common timers including TIM2. Which has a max clock of 84MHz and interface of 42MHz. Looks like there are two options for how the IRQ is processed, one is over the DMA2, the other is through the normal bus's. Do we know if this was done via DMA or by AHB1 peripherals? Noted on PG21 found here http://datasheet.octopart.com/STM32F407VGT6-STMicroelectronics-datasheet-12357803.pdf If it was on AHB1, then there might be significant reduction in latency by going DMA.
Welcome to the friendlier side of internet crazy :)
User avatar
Sergey89
contributor
contributor
Posts: 839
Joined: Wed Sep 25, 2013 5:30 pm
Location: Russia, Velikiy Novgorod

Re: Is stm32f4 the right chip?

Post by Sergey89 »

abecedarian wrote:~168MHz with 160ns latency?
That's like... 1000 cycles?

At 168MHz, 1 cycle is about 6.1 ns, so 160[ns latency] * 6.1 [ns per cycle] = 976 cycles

More interesting, 976 cycles * 6.1ns = 59536ns... almost 6 microseconds.

My math could be wrong though.
I think calculations may look like this:

1/168000000 = 5.95 ns
160/5.95 = 27 cycles
kb1gtt wrote:TIM1,8 have a max clock of 168, and interface clock of 84MHz. However the test was for the more common timers including TIM2. Which has a max clock of 84MHz and interface of 42MHz. Looks like there are two options for how the IRQ is processed, one is over the DMA2, the other is through the normal bus's. Do we know if this was done via DMA or by AHB1 peripherals? Noted on PG21 found here http://datasheet.octopart.com/STM32F407VGT6-STMicroelectronics-datasheet-12357803.pdf If it was on AHB1, then there might be significant reduction in latency by going DMA.
TIM2 is also 32 bit timer and seems to be more suitable for capturing slow signals.

Although latency is not critical if the inputs and outputs controlled via "input capture" and "output compare" capability of the timers.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

@Sergey89 - yeah, your math looks better than mine. I did say I could be wrong, right? ;)
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Is stm32f4 the right chip?

Post by kb1gtt »

What is the worst precision IRQ pile up we can expect? I guess you could simultaneously spark pulse, fuel pulse, Crank pulse, and Cam pulse. So I would say the min latency needs to be 4X the measured latency. I would suggest rounding that up to 6X as there will be other overhead, and I guess at WOT and full load you could get multiple fuel injectors at one time. Also because we need to capture multiple IRQ events, part of the overall latency will be caused by the IRQ processing. So the IRQ will need to go atomic, log the crank angle pulses, then will need to fire fuel injectors and spark events, then will need to stop atomic operation. I fear this IRQ processing will add cycles to the IRQ latency, and after 4X to 6X multiplier will cause a less than preferred latency. I wonder what that latency could be, and how many RPM's it could handle. Also I fear that at full RPM there aren't any CPU cycles for other processing. AKA we can get the crank angle timing logged, but can't process the data, as well many IRQ's could cause memory issues with the stack. A TPU or some kind of secondary processor, would be really handy for simplifying this kind of administrative vs critical timing situation and would greatly amplify the abilities of the MCU.

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.

Lets consider this to be 27 cycles every 694nS, so 1/694nS * 27 = 38.8 million cycles per second. However if we end up with 4X IRQ events that's would be 27*4 which would be 155 million cycles per second, and 6X IRQ's is 233 million cycles. We only have 168M cpu cycles to work with. I would expect that we don't continuously have all 4 or 6 IRQ's happening at the same time. My concern would be that at fast RPM's, we might be approaching an average that is getting close to the 168M cpu cycle limit, and occasionally we would be exceeding this limit. When we exceed the limit, it simply means that for that period of time we have dropped from .1 degree accuracy, to something like 1.4 or 1.5 degree accuracy, and during that lower accuracy time, there has been no admin processing.

Any how, I wonder how fast of an RPM can the this STM chip handle, and what crank angle accuracy can it handle? I know we have much longer latency now, which is largely due to Chibios latency's, but what could it be if we hand optimized some assembly code for the IRQ's?
Welcome to the friendlier side of internet crazy :)
Sync
Posts: 7
Joined: Wed Jan 07, 2015 10:11 pm

Re: Is stm32f4 the right chip?

Post by Sync »

Here is a good reference on interrupt latency on the STM32: http://community.arm.com/docs/DOC-2607

Interrupt latency will be fairly predictable and you can prioritize them appropiately that spark holds good accuracy. Once you are synchronized, inter-rev speed is not going to change.

I don't see why you take half of the timing budget, Nyquist should not apply, as we are not sampling the triggerwheel actively, we get interrupts at the edge.
As long as we hit anywhere in the 1.38µs band we are good.

I guess with those triggers you could exploit the integrated counting and decoding functions of the timer to fire interrupts in the right places so that you don't need to worry about wasting cycles in the input capture. I wonder how much jitter it would produce just to run from the TDC notch after sync, as global advance should be calculatable and speed is known

I agree that having a dedicated resource to decode wheels would simplify the fuel and spark execution time budgets, maybe slap a cheap STM32F103 on there and have it generate a 0° and 180° signal? All other timing calculation could run from that. Also frees up time keeping track of the global state with some of the stranger triggers, like the Mitsubishi one.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Is stm32f4 the right chip?

Post by kb1gtt »

I did the 2X thing because I wanted .1 deg accuracy +/- .05 deg. If you go for .1 deg accuracy +/- .1 deg you could remove the 2X thing.
Welcome to the friendlier side of internet crazy :)
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: Is stm32f4 the right chip?

Post by AndreyB »

kb1gtt wrote:I did the 2X thing because I wanted .1 deg accuracy +/- .05 deg. If you go for .1 deg accuracy +/- .1 deg you could remove the 2X thing.
How many layers do we have between IRQ latency and actual ignition timing? 5? 10 layers maybe? I think focusing on just one part of the total data/event flow is a bit pointless.

There is RPM decoder, there is RPM decoder precision, there is even calculation precision - too many precisions between crank position signal rise and firing the injector.

“One accurate measurement is worth a thousand expert opinions.” quoting the smart lady.

We need software developers doing real tests, researching where the bottle neck is and addressing the bottlenecks. Until we know where the bottleneck is, we are “Did You Lose the Keys Here?” “No, But the Light Is Much Better Here” if you get my vague metaphor.
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
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Is stm32f4 the right chip?

Post by kb1gtt »

My interpretation was a bit different. I was separating from the current software as we are discussing if the chip is correct. I'm trying to figure out the MAX RPM and feature set we can expect form this chip. Once we know what it is capable of doing we can decide if that's good enough or not. As far as I can tell, this chip can handle fast RPM engines, and is physically good enough. However I'm not sure I've learned enough to make the claim. My lack of understanding has caused me to make some apparently incorrect claims, and I don't want to do that again.

I originally thought there was a non resolvable architecture latency issue, but it looks like that latency is just a software issue, which can be resolved given resources and time. I'm currently at a bit of a loss about why we might support a different chip, other than getting that automotive check box.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

The following are my opinions and/or interpretations of things as best I know.


With any real-time oriented system, interrupt latency has to be accounted / compensated for. It's worth noting an RTOS itself introduces latency and can exacerbate existing ones. This isn't necessarily a bad thing if the processor has the speed and resources to accommodate this.

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.

Which brings me to:
kb1gtt wrote:... I'm currently at a bit of a loss about why we might support a different chip, other than getting that automotive check box.
If you have available to you a processor which has modules that can do crank decoding and trigger events with other peripherals/modules autonomously using few, if any, main core processor facilities, would you use it?
You can lead the horticulture but you can't make them think.
Post Reply