Is stm32f4 the right chip?

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 »

mck1117 wrote:
Thu Jan 09, 2020 7:02 pm
If we're going to go after "ultra scheduling precision",
By the way, this comment is not a recommendation that we do something different. There are still significant improvements to be made within the existing "fully software scheduled" world.

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 »

mck1117 wrote:
Thu Jan 09, 2020 7:02 pm

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.
I was thinking more of using the FPGA as a monitor that can measure the timing accuracy of the stock system on a running engine. It's probably overkill, but might be a good first usecase after duct taping the two together.

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 »

mck1117 wrote:
Thu Jan 09, 2020 7:04 pm
mck1117 wrote:
Thu Jan 09, 2020 7:02 pm
If we're going to go after "ultra scheduling precision",
By the way, this comment is not a recommendation that we do something different. There are still significant improvements to be made within the existing "fully software scheduled" world.
Yeah, my iCE40 diversion isn't a full endorsement of the idea as THE way forward. I do think it is an interesting idea and probably the best way forward if "ultra scheduling precision" is actually desired.

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

Re: Is stm32f4 the right chip?

Post by puff »

infinityedge wrote:
Thu Jan 09, 2020 7:25 pm
It's probably overkill, but might be a good first usecase after duct taping the two together.
like a separate fpga-based device to detect misfire events? whoa!

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

Re: Is stm32f4 the right chip?

Post by mk e »

mck1117 wrote:
Thu Jan 09, 2020 1:57 am
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.
Modern spec are all about statistical distributions minimum cost to achieve system goals.

You're absolutely right that at MBT the slope is 0, but that is a point and the slope can change quickly as you move from the point. I mentioned earlier that on the engines I'e seen the most data for (H-D stuff) 1 degree error is 2-5%, but to your point 0.5 errors is about 1/3 that....so 1/4 degree or so is probably fine for that application with the setup tuned.

and Its that last little piece that places a big role in OEM spec as far as I know. They need to bolt everything together and have it meet output spec.
Combustion chambers, piston height, airflow, and everything else all have tolerances and they need to find settling that work all the time on every combination that rolls off the assembly line. The way testing usually goes they need worst-case examples to validate the spec ranges....the tighter ALL the specs are the closer they can walk to the limits, like the increasing compression which increases efficiency to be pretty close to the detonation limit which means they get to claim better mileage and more power. Then the call goes out to the design teams to provide options with pricing, they plug all the options into the simulation and optimize for a system performance spec at the lowest cost.....and from there out put pops 0.1 degree timing requirement.

Its not that any 1 spec is a make or break for the system performance, it just about where is the best return from tightening specs. The iron head H-Ds there was typically 10-15% less flow on the rear head than the front....so 10-15% less cylinder pressure. I always thought tat was way to big a difference to be an accident and they were trying to make less heat in the cylinder with less air flow, but my point is the first few EFI installs didn't just well. that was before cylinder trim tables, but that is an extreme example although I owned a ford contour that burned the middle pistons and later year models had colder plugs on the center cylinders to help so they pretty clearly had flow issues. The ferrari stuff I've had on my flow bench is typically =/-1% cylinder to cylinder but they are hand finished, most production stuff is more like +/-2or3% and stuff I port is +/- 0.5% at the worst, .025% is more typical. same with compression ration....a couple tenths variation is typical.

So there is no SCREAMING need for high precision in any 1 component...but them more control you have the closer you can creep to the limits and the more hp you can make....as a system. Just switching out the ECU from something that is +/-0.3 deg to something +/- 0.1 is not going to make a measurable difference the vast majority of the time. I remember the old MS1 days when the MS guys were claiming sequential injection was a waste of time and money even as all the OEMs were making the switch.....and they were kind of right in a way in that if you didn't have a good setup to start with just replacing the ecu probably wasn't going to help a lot but I think at this point pretty much everyone understands why the oems made that change....its like that but to a lesser degree.

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

Re: Is stm32f4 the right chip?

Post by mk e »

mck1117 wrote:
Thu Jan 09, 2020 7:02 pm
infinityedge wrote:
Thu Jan 09, 2020 5:07 pm
A iCE40 FPGA coprocessor is ~$10
It's not quite that cheap. ...
that always seem to be the thing of it in open source world. If it adds $100 to what was a say $200 project then 90% less people seem to want it from my limited experience. I think, for what like that is worth, that you guys have a great project as is that meets the needs of most DIY types and it doesn't need anything that will make it more expensive, the cost should drop over time not increase and the following will grow.

That said, there is probably a case to be made that like the V12 demo a demonstration or "big brother" system that is a spec match for anything out there may also attract more follower in that is shows you know how to make a system as good as anything out there but also know how to scale back and save money for people who don't need the fastest most powerful. It can't be allowed to distract from the low cost and good performing system you already have...but if an fpga board or similar type co-processor could be plugged on to a lower cost "starter kit" you might have another winner.

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 »

mck1117 wrote:
Wed Jan 08, 2020 10:12 pm
I agree, this seems like a solution in search of a problem.
The problem this might solve is one of motivation. I think we are all hear because we are motivated to do something cool and interesting. I drive the practical solution to the problem. FPGA's check off a box in the cool and interesting category.
Welcome to the friendlier side of internet crazy :)

essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: Is stm32f4 the right chip?

Post by essess »

Hi guys - I heard you're considering ARM+FPGA? Maybe this can be some inspiration: https://github.com/essess/agen I think it's a great idea, and the way forward. I too tried the 570 and it led to this 'interpretation of the HWAG' (which was undocumented at the time).

You may also want to look into the Infineon Aurix parts for their GTM -- 100$ devkit in an arduino form factor can get you started. I have one if you want it. For various reasons I'm done with Infineon though.

I'm terribly busy at the moment and I'll try to catch up on posts in the next few days. Andrey+crew, I love your tenacity; you're doing gods work here. Keep pushing.

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 »

Long time no speak. Good to hear from you. Hmmmm, Gods work you say. ARM+FPGA --> Jesus ECU?

That looks interesting. Some questions.
-- What hardware is needed to do this? I'm assuming hall or some kind of VR interface circuit to generate the pulses. However what FPGA can that run on?
-- What software is needed? Seems every FPGA has it's own software. What one does that one use to compile and program it?
-- What is the output of agen? Could the STM32 get a SPI data stream or similar? How could it potentially be used?
-- Could agen work with the Papilio pro? I have one of these in hand.
http://papilio.cc/index.php?n=Papilio.PapilioPro

Looks like the Papilio pro costs $75 as noted in the below link.
http://store.gadgetfactory.net/papilio-pro-spartan-6-fpga-dev-board-with-sdram/

A feature I like about the ARM+FPGA is that when you make a small change to the the software it does not effect the FPGA software. AKA a small bug in a minor feature like a check engine light, does not kill the engine unintentionally. It allows for the timing critical stuff to be on timing critical hardware, then the management stuff is handled separately and not interwoven into the timing critical stuff.
Welcome to the friendlier side of internet crazy :)

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 »

FYI all, I've been investigating current scheduling performance on stm32 (and improving it by an order of magnitude): https://rusefi.com/forum/viewtopic.php?f=5&t=1657&p=35269

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

Re: Is stm32f4 the right chip?

Post by mk e »

excellent

The way the freescale eTPU code worked some things were most important like:

the duration of the fuel pulse is critical but but if start it end bounces around a couple degrees it doesn't much matter.

The ignition end angle is critical but charge start and total duration can float a bit

Then the time between every crank tooth of course.

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

Re: Is stm32f4 the right chip?

Post by mk e »

My other question would be what happens to stuff ot on the due list like the fuel pulse and ignition timing as the number of time critical events goes up? As a general rule they should be done every 10msec or so......can you add something to track this to you project? If this is also good the you're done I think.

essess
Posts: 13
Joined: Thu Aug 10, 2017 7:12 pm

Re: Is stm32f4 the right chip?

Post by essess »

kb1gtt wrote:
Fri Jan 10, 2020 6:09 pm
Long time no speak. Good to hear from you. Hmmmm, Gods work you say. ARM+FPGA --> Jesus ECU?
yaaaas! I'm not one for religion, but those were the best words I could come up with. You guys just keep chipping away and keeping it free for others. That's fricken god's work right there --- we need more people/communities out there that build things and shares that information. That's some hippie talk right there, but it's how it should be. The world can be a better place with that kind of effort.
kb1gtt wrote: That looks interesting. Some questions.
-- What hardware is needed to do this? I'm assuming hall or some kind of VR interface circuit to generate the pulses. However what FPGA can that run on?
It just takes a digital input. You'd need to condition whatever it is to whatever it is at your fpga pin. There are some reg's in there that allow polarity inversion and digital filtering/debounce.
kb1gtt wrote: -- What software is needed? Seems every FPGA has it's own software. What one does that one use to compile and program it?
yep. I started this on a spartan6 and moved over to a lattice xo3. You can put this on anything. It's all generic VHDL that doesn't use any manufacturer specific macros.
kb1gtt wrote: -- What is the output of agen? Could the STM32 get a SPI data stream or similar? How could it potentially be used?
right now, it drives an angle clock as the output ... like time .. but angle...
so, SPI is not going to work for you ... this was designed to be 'more tightly bound' to a softcore on chip and the angle clock can be routed to all kinds of things like a hardware scheduler.
kb1gtt wrote: -- Could agen work with the Papilio pro? I have one of these in hand.
http://papilio.cc/index.php?n=Papilio.PapilioPro

Looks like the Papilio pro costs $75 as noted in the below link.
http://store.gadgetfactory.net/papilio-pro-spartan-6-fpga-dev-board-with-sdram/
that'll work. But you would need to use the Xilinix ISE software for 6-series devices .. this software was abandoned many years ago and they suggest upgrading to series-7 devices and using Vivado.

kb1gtt wrote: A feature I like about the ARM+FPGA is that when you make a small change to the the software it does not effect the FPGA software. AKA a small bug in a minor feature like a check engine light, does not kill the engine unintentionally. It allows for the timing critical stuff to be on timing critical hardware, then the management stuff is handled separately and not interwoven into the timing critical stuff.
fpga is hardware. full stop.
I understand what you're saying, but you can't pollute your view of fpga work as software work. When you do fpga work you're using words that look a lot like the standard software words, but you're really describing hardware.

That said, fpga's are a hard long road to get decent at and an even longer road to get good at.

For anyone else looking at this, I've got some updated code around here somewhere that simulates everything in GHDL and generates .vcd's that can be used w/gtkwave. I'll get around to updating the repo soonish. Everything that ends in _tb are testbenches which verify each part of the whole. I don't have an all-up test ready yet. I probably never will though. I was going to do it 'real world' but ran out of time. A move & job change stalled everything. Maybe someone else can pick it apart for ideas. Right now my work takes everything out of me (in a good way).

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:
Fri Jan 10, 2020 8:55 pm
My other question would be what happens to stuff ot on the due list like the fuel pulse and ignition timing as the number of time critical events goes up? As a general rule they should be done every 10msec or so......can you add something to track this to you project? If this is also good the you're done I think.
I'm not sure quite what you're asking for here, do you want a counter of how deep that queue is on average?

For example, the testing I did was scheduling around 65 events per revolution (8x injectors, 8x ignition, 8x map window, 8x knock window, etc), but everything is scheduled at the last tooth before it occurs, so the queue never actually ends up very long. With a 60-2 wheel, the queue might never end up longer than 3-5 items.

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 »

essess wrote:
Fri Jan 10, 2020 9:32 pm
right now, it drives an angle clock as the output ... like time .. but angle...
so, SPI is not going to work for you ... this was designed to be 'more tightly bound' to a softcore on chip and the angle clock can be routed to all kinds of things like a hardware scheduler.
Angle clock? I'm not following this. Do you mean an angle register that ticks between 0 and 3599? Then the software sets a 5mS injector timer to go off when the clock angle is something like 1800. When you say clock angle do you mean it's just a register which has some representation of the crank angle?

Hmmm, I'm not sure how you would get the clock angle to the STM32 for useful things like data logging. Seems like you would need many digital lines to echo this clock angle thing digitally to the STM32. I'm also not sure how the STM32 would interface timers or configure when / how long the timer should run for. I suspect the mentioned softcore would work well for this. Do they make ARM softcores that you can use these days? If so how hard would it be to port ChibioS stuff to it?

I understand software vs hardware. Well sort of. If I really understood hardware, I'd just look at your code and stop asking questions about what a clock angle is :)
essess wrote:
Fri Jan 10, 2020 9:32 pm
yaaaas! I'm not one for religion, but those were the best words I could come up with.
I'm medium religious. It has a large probability of being the most important thing you do in life, so it's important. However I also don't have blind faith in anything. Seems every time you think you know something, then some anomaly comes along and blows it all to heck. Without repeatable results, religion is a difficult nut to crack. Any how, religion is OT for this thread. I'm willing to talk philosophically, but probably not the proper thread here.

Speaking of OT, should we break the FPGA talk into a different thread?
Welcome to the friendlier side of internet crazy :)

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 »

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 »

ChibiOS http://www.chibios.com/forum/viewtopic.php?f=3&t=5107 is promising us support of six Arm Cortex-R52 cores clocked at 400MHz ST Stellar MCUs. No idea if they will have flying lead packages or just BGA.

https://www.st.com/content/st_com/en/about/media-center/press-item.html/p4141.html
https://www.st.com/content/st_com/en/landing-page/stellar-32-bit-automotive-mcus.html
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

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 »

https://www.cypress.com/products/cypress-traveo-ii-body-cyt4bf-series

350-MHz Arm® Cortex® -M7F dual core
8 MB code flash, 256 KB work flash and 1024 KB SRAM and Arm® Cortex® -M0+
176 TEQFP, 272 BGA, 320 BGA

Totally not available anywhere so far.

By the way
Munich, Germany, and San Jose, California – 16 April 2020 – Infineon Technologies AG (FSE: IFX / OTCQX: IFNNY) announced today the Closing of the acquisition of Cypress Semiconductor Corporation. The San Jose-based company has become part of Infineon effective as of the Closing.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

Post Reply