Is stm32f4 the right chip?

User avatar
AndreyB
Site Admin
Posts: 10486
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Is stm32f4 the right chip?

Post by AndreyB »

Yes, that's definitely an approach. I believe this is close to what @andreika did to support his 5v kinetis chip at https://rusefi.com/forum/viewtopic.php?f=4&t=1516
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

mck1117
running engine in first post
running engine in first post
Posts: 446
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by mck1117 »

The tricore and GTM can do some cool stuff. However, I don't think it's worth our time to port rusefi to TriCore. There isn't a real problem with the stm32. The GTM is pretty cool, but we don't really need it-our existing software scheduler works just fine. Likewise, 5v I/O would be pretty neat, but we seem to be getting along just fine.

The other trouble is the cost of TriCore. The development boards, compiler, debugger, and other tooling cost an order of magnitude (or more) more than that for the stm32.

Ultimately, I think ports to new architectures are net a distraction from real improvements that are needed in the firmware that are architecture-agnostic.

User avatar
AndreyB
Site Admin
Posts: 10486
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Is stm32f4 the right chip?

Post by AndreyB »

@andreika has just introduced me to my new true love:

Cypress Semiconductor S6E2GH8J0AGV2000A at stock on mouser! It has everything - 5v supply, RAM, M4F kernel, a lot of ADC...

S6E2CCAL0AGL2000A is also available and it has even MORE!

I believe these two chips are BEST we've seen so far for rusEfi. So if anyone is interested to port ChibiOS...
Attachments
S6E2GH8J0AGV2000A.png
S6E2GH8J0AGV2000A.png (64.3 KiB) Viewed 8336 times
S6E2CCAL0AGL2000A.png
S6E2CCAL0AGL2000A.png (64.08 KiB) Viewed 8336 times
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

Have you guys though about maybe using a FPGA to handle all time critical stuff? This was on the table at the end of the o5e project an seemed to have the most support....but not enough to actually make it happen. I know that is how the high $$ cosworth (petel) ecus are done, I think just an old mpc555+fpga and the newer motec M1 have an fpga (=mpc5565??? don't recall) but I think they use it for the crazy logging rates they get....just seems like it would give you more options.

Did I read somewhere here there is some question about the timing accuracy of fuel/spark/crank stuff as rpm/processor load goes up? stuff like this becomes a non-issue with a dedicated time processor like a fpga could be.

Just a thought.

960
contributor
contributor
Posts: 333
Joined: Mon Dec 10, 2018 1:22 am
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by 960 »

These looks promising :-)

User avatar
AndreyB
Site Admin
Posts: 10486
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Is stm32f4 the right chip?

Post by AndreyB »

mk e wrote:
Tue Jan 07, 2020 8:37 pm
Have you guys though about maybe using a FPGA to handle all time critical stuff?
We do not have that much issues with scheduling - for instance we have a successful test at https://github.com/rusefi/rusefi/issues/557

As is, we cannot run ETB at 20KHz unless we start using a HW timer which we currently do not do. So technically 20KHz PWM would be the only need for extra timing capability. I believe there is a topic for FPGA but I am not aware of anyone stepping forward and work on a solution :( Pretty low priority at this point.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

russian wrote:
Tue Jan 07, 2020 9:24 pm
mk e wrote:
Tue Jan 07, 2020 8:37 pm
Have you guys though about maybe using a FPGA to handle all time critical stuff?
We do not have that much issues with scheduling - for instance we have a successful test at https://github.com/rusefi/rusefi/issues/557
I see errors of like 5 to nearly 10us...if we did some stats the system capability would probably flush out closer to +/- 15us. Not too bad but not also OEM which i believe is a 1us spec. Unless I'm reading wrong it looks like a single pin test? Does it change when you run all the pins at once with the processor busy crunching numbers to simulate the normal system load? I thought I read you were having an issue with that?

To your point though, its working fine for the applications using it so maybe a non-issue....but a fpga would probably make it as near perfect as can be :)

For PWM I know the ecu I'm using does that in the driver chip not the CPU.

DonaldBecker
Posts: 32
Joined: Mon Aug 19, 2019 10:40 pm
Location: Los Gatos CA USA
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by DonaldBecker »

Using the existing hardware timers on the STM32 would make the output timing very precise.
The drawback is limiting pin assignment.

But step back and do some approximations.

How precise and accurate do you need your ignition timing to be? Getting it within 1 degree is almost perfect. Being off by a degree or two is only going to have a trivial effect on power and emissions -- probably below your measurement capability. And it's certainly far below the accuracy of your tuning map. A precision of 0.1 degree is often the target, but that is really arbitrary -- it's way better than it needs to be. Really it's more of a "our hardware can do this, so we'll market the capability as a vital feature".

How accurate does you need your injector timing to be? That's actually more of a challenge. Selecting high flow injectors (me make big HP!) means that the injectors need to run at really low duty cycle most of the time. That seems to indicate that you want high precision short pulses, but you run into the problems of mechanical inconsistency and injector matching. Those are two orders of magnitude more significant than microcontroller interrupt latency.

I'll argue that the primary place you really need precision is on one input: crank position sensing with a high tooth count crank wheel. If it is precise enough you can calculate instantaneous acceleration, which call tell you cylinder performance balance and engine output.

mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

A 1 degree ignition timing error is like 2-5% hp loss on modern engines and often detonation on a high boost engine. 0.1 degree should be considered a requirement for a performance system and is the requirement for OEM systems I believe. An older 2 valve engine with a big slow combustion chamber running 40 degree timing is more forgiving for sure and 0.5 or maybe even 1 degree is probably ok...but tight chambers running 20 degree or less total timing....the desired spec is 0.1 and 0.2-3 is about all you can live with I think.

The oem type chips have a LOT of timers....64 or 96 in the timing co-processor and another 16 or 32 in the main processor plus more in the driver chips. That is what's needed control modern performance engines and all the stuff attached to them.

But if the goal is fun more than ultimate performance then the spec can be relaxed a bit and timers can be shared and most engines will run just fine most of the time.....and that's not a bad thing.

User avatar
kb1gtt
contributor
contributor
Posts: 3645
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Re: Is stm32f4 the right chip?

Post by kb1gtt »

Some direct injection applications fire the injector 12 or so times during combustion. Small timing is an issue for those applications. I once looked at fpga, but that is another set of programming skills that I don't have. The below makes fpga programming much easier. I believe there has been zero progress on this.

http://papilio.cc/
Welcome to the friendlier side of internet crazy :)

puff
contributor
contributor
Posts: 2809
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Is stm32f4 the right chip?

Post by puff »


mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

puff wrote:
Wed Jan 08, 2020 8:49 am
just a reminder. check this out
https://rusefi.com/forum/viewtopic.php?f=10&t=1191
not a real helpful for the non-russian speakers ;)

Reading with google translate it looks like the plan was to use the fpga AS the ecu which is not at all what I was asking about....that's hard and a bit pointless I think. The thought I was asking about was using it as a time co-processor with an ARM to do everything else effectively adding as many timers as your heart desires without making all the rest of it brutally difficult.

...but if timing isn't a issue then its a solution in search of a problem.

puff
contributor
contributor
Posts: 2809
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Is stm32f4 the right chip?

Post by puff »

not sure about the original topic-starter of that thread, but in the later posts by peredelkin (dated novermber 2019) he uses fpga to calculate some angles and dwell times.

"a solution in search of a problem" - still no clear understanding if there is such a problem. according to russian, there is no problem so far. ;)

mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

puff wrote:
Wed Jan 08, 2020 2:00 pm
not sure about the original topic-starter of that thread, but in the later posts by peredelkin (dated novermber 2019) he uses fpga to calculate some angles and dwell times.
Ahh, it wasn't clear to me what exactly was being discussed towards the end.

puff wrote:
Wed Jan 08, 2020 2:00 pm
"a solution in search of a problem" - still no clear understanding if there is such a problem. according to russian, there is no problem so far. ;)
If the purpose is to make an engine run then there is absolutely no issue.

Way back in the o5e days I bought a crank wheel and sensor from diy autotune and set it up to do a live HW test.....we couldn't read it. back to the bench and everything was fine, back to the HW and no sync. The problem was that the wheel and more importantly the sensor had more error than the OEM spec eTPU code (used by several F1 teams pre spec ecu days so there was no question it worked - its a dedicated processor running its own code for time stuff embedded in the main chip) would accept. It all worked just fine on MS products but on a system designed not to tolerate over 0.1 degree error did not work. Replaced the sensor with a high quality commercial grade unit and with the error bands opened up to near max it worked fine...OEM auto grade stuff the error bands could be set to about the mid-point. This was a 36-1 setup, it might have worked on a 60-2. Anyway....lot of MS ECUs running lots of engines and DIY sold lots of those sensors (I called and talked to them about it, they never had an issue with them but the 2 I tested were both a problem).

My point is with design its easy to end up in not the place you thing you are going. System specs are the map and should include things like required accuracy...whether or not there is a problem depends on what the system spec is. The data posted suggests its not OEM or motec, etc grade accurate but it may be every bit as good as an MS, I just don't know but its certainly good enough to make engines run.

puff
contributor
contributor
Posts: 2809
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Is stm32f4 the right chip?

Post by puff »

MS - megasquirt? - as the key rivals in terms of timing accuracy?
why not OEM ecus? anyway, according to Jared, newer gdi systems would require more timers with better accuracy (if i'm not mistaken) - wouldn't this bring us to limitations of the current mcu?

just my recent thoughts: to my knowledge, so far there is no feature in rusefi that would allow to calculate mis-fire events in setups with trigger wheels with large number of teeth. it seemed that one of the reasons was the lack of high-accuracy timers?

mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

Yes, MS as in megasquirt but not as an example of perfection, just as an example of a whole lot of people are living very happily with stuff that can't possibly be meeting OEM type specs so clearly OEM accuracy is not required on many (most?) applications. I don't want it to sound like I'm saying anything bad this or another ECU because I'm not., there are dozens of engines running, it works.

I guess the question is more about where is the project heading? GDI is harder than port injection. Stuff like misfire detection requires confidence in each and every tooth trigger not just a running average. A chip with 16 timers can probably handle this stuff on a 4 cyl engine...the freescale 5634 I was playing with is sold as a 4cyl ecu processor and it had I think 40 timers with 32 running dedicated code in a kind of stand-alone mode, the OEMs put everything on its own timer....but I'm a mechanical guy not an electronics guy so I don't know if all that is actually needed....but actual ECU chips have lots of timers these days.

DonaldBecker
Posts: 32
Joined: Mon Aug 19, 2019 10:40 pm
Location: Los Gatos CA USA
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by DonaldBecker »

mk e wrote:
Wed Jan 08, 2020 4:52 pm
the freescale 5634 I was playing with is sold as a 4cyl ecu processor and it had I think 40 timers with 32 running dedicated code in a kind of stand-alone mode, the OEMs put everything on its own timer....but I'm a mechanical guy not an electronics guy so I don't know if all that is actually needed....but actual ECU chips have lots of timers these days.
Once designed, timers are small, cheap and easy blocks to put on the chip. Connecting the timer channels to pins requires chip-specific layout and lots of area. So the trend is toward many feature-filled timers, even if they can't all be used.

The STM32F407 has "up to 17 timers". Timers can have up to four channels, and some channels support two output pins (inverted outputs with deadtime, used for H-bridge and motor control to avoid both high and low sides from being on simultaneously). So there are *way* more total timer channels than most applications would need, but somehow there is still lots of design required to fit the constraints.

Some applications, especially power-sensitive ones, use timers as logic to minimize waking the main processor up. For instance, a timer input might trigger DMA to write the setup registers for another timer, which sequences the DMA to write the registers of another peripheral, wait a bit, then output data to that peripheral. It's easy to chew up lots of timers and DMA channels this way, but that' ends up using less power than having the main processor do the same thing when reacting to an interrupt.

mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

DonaldBecker wrote:
Wed Jan 08, 2020 6:44 pm

The STM32F407 has "up to 17 timers". Timers can have up to four channels,.....

..... a timer input might trigger DMA to write the setup registers for another timer, .....but that' ends up using less power than having the main processor do the same thing when reacting to an interrupt.
Those are the problems not the solutions.

The MPC5xxx chips have 6 more timers dedicated to the DMA, 3 or which can run off the angle clock and are configure normally as slow, med, fast to read sensors , convert the input and and store the results without the main processors being involved.

Over in the TPU (time processing unit) the 32, 64 or 96 timers are all running their own micro-code and decoding the crank, creating an 0-720 degree angle clock (that any of the other channels or the DMA can read) and firing coils and injectors.....there are no interrupts to wait for other than memory access. A freescale engineer told me that once the engine is running you can and he has shut the main processor down and the engine keeps running....there is no waiting for anything.

That is how ECU chips are designed, they are very specialized. But chips are a lot faster now and you can get away without dedicated timers and letting the main processor get involved managing stuff...but stuff like misfire detection means only tolerating maybe 100nanosec error which is still near impossible and GDI a real challenge without something like a TPU or fpga, hence the original question.

puff
contributor
contributor
Posts: 2809
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Is stm32f4 the right chip?

Post by puff »

In a recent thread there is another guy who wants to port rusefi to some oem ecus used in audi. Probably those ecus use chips that are more suitable for such tasks? But then again what's the need to port rusefi? Lack of flexibility of the original firmware?

mck1117
running engine in first post
running engine in first post
Posts: 446
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by mck1117 »

I agree, this seems like a solution in search of a problem.

At 6000 RPM, 1 degree is 46 microseconds. We're better than 15us jitter and absolute accuracy, so we can certainly do better than 1/3 of a degree under all real conditions. There are software improvements I know of in this domain that we could make. Improvements here would likely get us well below 5us accuracy.

As for fueling, let's suppose you'd like to be within 1% of the desired pulse width. My car with 440cc/min injectors hits a minimum pulse width (base - excluding compensation) of around 0.6ms. That's during overrun at high RPM. Idle is around 1.5ms base. 1% at idle is 15us, which we already do with ease.
puff wrote:
Wed Jan 08, 2020 4:04 pm
newer gdi systems would require more timers with better accuracy (if i'm not mistaken)
No. GDI requires slightly better timing precision (but not much - most cars run injections in the 1-4ms range. Because you can control the fuel pressure, you can keep the injection time reasonable, even at idle), but not more events. GDI has no need to do more than one injection per cycle.
puff wrote:
Wed Jan 08, 2020 4:04 pm
just my recent thoughts: to my knowledge, so far there is no feature in rusefi that would allow to calculate mis-fire events in setups with trigger wheels with large number of teeth. it seemed that one of the reasons was the lack of high-accuracy timers?
We don't have that feature yet, no. I don't think we need more timing precision than is currently available for that to work. Our trigger decode interrupt is the highest priority interrupt in the system, which means there should be little-to-no jitter in its firing. Our master timer runs at the same speed as the CPU, so 168 or 216MHz (precision in the single digit nanoseconds). There are of course optimizations to help the software here, but there is no fundamental reason the existing system can't do per-cycle misfire detection with a high tooth count wheel.

Let's do some napkin math:
A 60-2 wheel running at 6000 RPM has a tooth rate of 6000 hz, or a period of 166.6us. If we end up with 100 timer cycles of jitter, that's only 600ns, which still gives us better than 0.3% precision on the tooth period.

Until I can see a convincing argument about a REAL problem with doing software scheduling, we don't need a fancy MCU with more timers or an FPGA.

mk e
Posts: 147
Joined: Tue Dec 06, 2016 7:32 pm

Re: Is stm32f4 the right chip?

Post by mk e »

mck1117 wrote:
Wed Jan 08, 2020 10:12 pm
I agree, this seems like a solution in search of a problem.

At 6000 RPM, 1 degree is 46 microseconds. We're better than 15us jitter and absolute accuracy,
The first place I worked as a young engineer the QA manager has a sign over his desk that read "In God we trust, all other bring data".

Do you have data this? Does it change with RPM or as the the number of cylinders increases? I'm not saying it isn't correct but the data I saw looked like a simple single channel test on an unloaded system and the result stuff in the +/- 5-8 usec range.....which would be the 15 you mention at any reasonable confidence interval. I would very honestly be surprised if the error doesn't increase was you add channels.....but its certainly possible that it doesn't....and 1/3 degree is already triple OEM specs.

mck1117
running engine in first post
running engine in first post
Posts: 446
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by mck1117 »

mk e wrote:
Wed Jan 08, 2020 11:02 pm
The first place I worked as a young engineer the QA manager has a sign over his desk that read "In God we trust, all other bring data".

Do you have data this? Does it change with RPM or as the the number of cylinders increases?
I've wanted to measure this in a scientific way for a long time. I made some moderately unscientific measurements many months ago, and don't remember what the conclusions were other than "I don't see anything particularly offensive".
mk e wrote:
Wed Jan 08, 2020 11:02 pm
I would very honestly be surprised if the error doesn't increase was you add channels.....but its certainly possible that it doesn't....
It probably doesn't increase with more channels, as the logic never actually iterates over all channels. The list of all future events is maintained in sorted order, so that to actually fire the event that's due, you can consult the head of the list (constant-time operation).
mk e wrote:
Wed Jan 08, 2020 11:02 pm
and 1/3 degree is already triple OEM specs.
Is there data to support that 0.1 degree is desired or required? The definition of MBT is that dTorque/dTiming is equal to zero, so small timing changes will have small resulting torque changes. Of course this doesn't apply when an engine is severely knock limited far away from MBT where the slope of that derivative isn't flat.

infinityedge
Posts: 17
Joined: Fri Dec 27, 2019 4:43 pm
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by infinityedge »

If anyone is interested in adding an FPGA co-processor, might I suggest the iCE40 line from LatticeSemi:

http://www.latticesemi.com/en/Products/FPGAandCPLD/iCE40

They aren't huge as far as FPGAs go but do have up to 7680 logic cells. The main benefit is that they are one of the few FPGAs with a fully open source toolchain. It's also nice that they're cheap, small, and can even be had in extended temperature ranges. The BGA format kinda sucks though.

https://www.mouser.com/Semiconductors/Programmable-Logic-ICs/FPGA-Field-Programmable-Gate-Array/_/N-3oh9p?Keyword=ICE40&FS=True&Ns=Number%20of%20Logic%20Elements|1

SVeilleux9
Posts: 13
Joined: Sun Jan 05, 2020 3:06 am
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by SVeilleux9 »

I have played around with a tinyFPGA a little bit which uses the ice40 chip
https://tinyfpga.com/

It was overall easy to setup and use. I wanted to use MATLAB to auto generate the Verilog code since I'm not the best with Verilog. I did not get that far though.

As far as achieving .1 degree accuracy for the crank shaft keep in mind that the crank sensor itself can have up to .05 degrees of jitter.

User avatar
AndreyB
Site Admin
Posts: 10486
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Is stm32f4 the right chip?

Post by AndreyB »

lets not discuss fpga here. please find existing topic or create a new one.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

infinityedge
Posts: 17
Joined: Fri Dec 27, 2019 4:43 pm
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by infinityedge »

russian wrote:
Thu Jan 09, 2020 1:58 pm
lets not discuss fpga here. please find existing topic or create a new one.
The FPGA stuff was already broached a while back.

Isn't this thread about changing hardware architectures from STM32F4 in order to get a more accurate timing response?

An alternative to finding a faster chip with more timers would be a co-processor to handle timing critical tasks, which is where an FPGA would shine. Granted hardware and software design complexity would increase. But that would be true of trying to port to an automotive ECU with minimal public documentation, or rewriting the timing routines to run closer to bare hardware. Plus getting a microprocessor that is significantly more powerful (speed/ram/timers) than the STM32 line tends to come with significantly more cost if Mouser is anything to go by. A iCE40 FPGA coprocessor is ~$10 and extremely flexible in its capabilities. I think it is as worthy as the other options for consideration. Hell, it might be worth making a board with one just to get an extremely accurate timing of what the current chip does since that is still a bit of an unknown.

User avatar
kb1gtt
contributor
contributor
Posts: 3645
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Re: Is stm32f4 the right chip?

Post by kb1gtt »

What is needed for the brain in terms of timing resolution? I know many often jump to 0.1 or 0.2 degree's of angular accuracy, but that's not really applicable to the MCU. The MCU has jitter and signal delays. Can we pick some parameters like RPM, dynamic RPM changes, and boil that down into parameters like jitter and signal delay? I know some technologies can do 5nS signal delays, but what we need is more like 1uS. What do we need then we can use that as a baseline when selecting the brain's abilities.
Welcome to the friendlier side of internet crazy :)

User avatar
AndreyB
Site Admin
Posts: 10486
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Is stm32f4 the right chip?

Post by AndreyB »

Infinityedge can you recommend a dev board for this fpga platform? Can you implement a hello world LED blinking controlled via SPI?
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239


mck1117
running engine in first post
running engine in first post
Posts: 446
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish
Soldering skill: yes
Coding skill?: yes

Re: Is stm32f4 the right chip?

Post by mck1117 »

infinityedge wrote:
Thu Jan 09, 2020 5:07 pm
Isn't this thread about changing hardware architectures from STM32F4 in order to get a more accurate timing response?
I have a PR out that improves ignition timing precision by an order of magnitude. More on that later.
infinityedge wrote:
Thu Jan 09, 2020 5:07 pm
Granted hardware and software design complexity would increase. But that would be true of trying to port to an automotive ECU with minimal public documentation, or rewriting the timing routines to run closer to bare hardware. Plus getting a microprocessor that is significantly more powerful (speed/ram/timers) than the STM32 line tends to come with significantly more cost if Mouser is anything to go by.
Yes, I agree. If we're going to go after "ultra scheduling precision", an fpga is the way to go. A few years ago I prototyped trigger decode and ignition timing generation on an FPGA, and it seemed to work pretty well on the bench, though it never ran a real engine.
infinityedge wrote:
Thu Jan 09, 2020 5:07 pm
A iCE40 FPGA coprocessor is ~$10
It's not quite that cheap. FPGAs are significantly more power-supply sensitive than a normal microcontroller. They need 2-5 power supplies (looks like the ice40 is 2 supplies: 3.3v and 1.2v), and really don't appreciate noise. There's also the board area cost, which has potential to make the board larger/not fit in the case/etc.
infinityedge wrote:
Thu Jan 09, 2020 5:07 pm
I think it is as worthy as the other options for consideration. Hell, it might be worth making a board with one just to get an extremely accurate timing of what the current chip does since that is still a bit of an unknown.
You don't even need to measure the timing performance of an FPGA with real hardware. You can accurately simulate the whole thing beforehand, and something designed properly will be able to have hard timing guarantees about when edges will arrive. The prototype I wrote a few years ago was accurate to within 2 clock cycles, and the clock was running at something like 50 or 100 MHz, so something on the order of 20ns.

Post Reply