Is stm32f4 the right chip?

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: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.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post 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....
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 »

@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?
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 »

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.
Last edited by abecedarian on Tue Feb 10, 2015 4:59 am, edited 1 time in total.
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 »

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.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post 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.
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 »

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
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 »

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.
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 »

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 ;)
Attachments
oc_ic_10us.png
oc_ic_10us.png (65.26 KiB) Viewed 52815 times
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post 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.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

After some thought, I should correct myself and say "4-6 interrupt sources".
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 »

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.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post by abecedarian »

I'd like to see things represented as a state diagram / machine.
You can lead the horticulture but you can't make them think.
DaWaN
Posts: 51
Joined: Sat Sep 20, 2014 6:54 pm
Location: Benschop, Netherlands

Re: Is stm32f4 the right chip?

Post 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.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Is stm32f4 the right chip?

Post 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.
You can lead the horticulture but you can't make them think.
Sync
Posts: 7
Joined: Wed Jan 07, 2015 10:11 pm

Re: Is stm32f4 the right chip?

Post 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.
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 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.
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 »

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*
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 »

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.
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 »

@kb1gtt - Find the "safety" compliance docs for STM32F4 yet?
Their suggestions for how to meet stuff and such are an interesting read.
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 »

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 »

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?
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 »

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.
Welcome to the friendlier side of internet crazy :)
Simon
Posts: 3
Joined: Thu Mar 26, 2015 5:14 pm

Re: Is stm32f4 the right chip?

Post 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 )
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 »

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
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 »

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?
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 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.
Simon
Posts: 3
Joined: Thu Mar 26, 2015 5:14 pm

Re: Is stm32f4 the right chip?

Post 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?
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 »

Simon wrote:Out of curiosity, do you have the % of time in interrupt and sleep?
we do not :(
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
marko
Posts: 8
Joined: Sat Mar 25, 2017 5:20 pm

Re: Is stm32f4 the right chip?

Post 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.
Post Reply