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.
Is stm32f4 the right chip?
-
- Posts: 17
- Joined: Fri Dec 27, 2019 4:43 pm
Re: Is stm32f4 the right chip?
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.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.
-
- Posts: 17
- Joined: Fri Dec 27, 2019 4:43 pm
Re: Is stm32f4 the right chip?
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.
Re: Is stm32f4 the right chip?
like a separate fpga-based device to detect misfire events? whoa!infinityedge wrote: ↑Thu Jan 09, 2020 7:25 pmIt's probably overkill, but might be a good first usecase after duct taping the two together.
Re: Is stm32f4 the right chip?
Modern spec are all about statistical distributions minimum cost to achieve system goals.mck1117 wrote: ↑Thu Jan 09, 2020 1:57 amIs 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.
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.
Re: Is stm32f4 the right chip?
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.
Re: Is stm32f4 the right chip?
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
Re: Is stm32f4 the right chip?
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.
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.
Re: Is stm32f4 the right chip?
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.
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
-
- running engine in first post
- Posts: 1494
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Is stm32f4 the right chip?
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
Re: Is stm32f4 the right chip?
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.
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.
Re: Is stm32f4 the right chip?
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.
Re: Is stm32f4 the right chip?
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.
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: 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?
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 software is needed? Seems every FPGA has it's own software. What one does that one use to compile and program it?
right now, it drives an angle clock as the output ... like time .. but angle...kb1gtt wrote: -- What is the output of agen? Could the STM32 get a SPI data stream or similar? How could it potentially be used?
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.
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: -- 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/
fpga is hardware. full stop.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.
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).
-
- running engine in first post
- Posts: 1494
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: Is stm32f4 the right chip?
I'm not sure quite what you're asking for here, do you want a counter of how deep that queue is on average?mk e wrote: ↑Fri Jan 10, 2020 8:55 pmMy 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.
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.
Re: Is stm32f4 the right chip?
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?essess wrote: ↑Fri Jan 10, 2020 9:32 pmright 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.
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
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
Re: Is stm32f4 the right chip?
Lets migrate FPGA talks to here.
https://rusefi.com/forum/viewtopic.php?f=13&t=803&p=26478
https://rusefi.com/forum/viewtopic.php?f=13&t=803&p=26478
Welcome to the friendlier side of internet crazy
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
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://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
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
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
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.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
https://www.globenewswire.com/news-release/2020/10/20/2110984/0/en/STMicroelectronics-Unveils-Features-of-Multi-Application-Deterministic-Automotive-Microcontrollers-to-Maximize-Safety-and-Security-in-Next-Generation-Domain-Zone-Architectures.htmlAndreyB wrote: ↑Sun Jan 26, 2020 4:27 pmChibiOS 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
A year layer still only a bit of new no part numbers so farST jointly developed with Bosch...
To date, ST has delivered more than 3000 samples to customers and samples have been running in vehicles for about a year. For additional information, please contact ST sales.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
FS32K148UJT0VLUT is available now but at this point we already have Cypress working if anyone really needs a 5v rusEFI.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
targeting 2024AndreyB wrote: ↑Sun Jan 26, 2020 4:27 pmhttps://www.st.com/content/st_com/en/landing-page/stellar-32-bit-automotive-mcus.html
https://www.globenewswire.com/news-release/2021/06/16/2248274/0/en/STMicroelectronics-Delivers-First-Stellar-Advanced-Automotive-Microcontrollers-for-New-Road-Car-Projects.html
https://www.st.com/en/automotive-microcontrollers/sr6p7c7.html
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
Kind of speaking of which what about STM32F723 STM32F723ZET6 any reason why we cannot use it on rusEFI?
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- contributor
- Posts: 413
- Joined: Tue Jul 24, 2018 8:55 pm
- Github Username: Orchardperformance
- Slack: Orchardperformance
Re: Is stm32f4 the right chip?
Doesn't this just come under D?
Isn't any discussion of new hardware forbidden?
Isn't any discussion of new hardware forbidden?
Now keeping MRE in stock in the UK - https://www.FutureProofPerformance.com
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
STM32F723 is just another stm32F7 which could be soldered on Proteus or Hellen. At the moment I am asking for help clarifying if for any reason STM32F723 would not replace for instance STM32F767. I do not suggest a new platform.OrchardPerformance wrote: ↑Sun Jan 16, 2022 9:14 pmDoesn't this just come under D?
Isn't any discussion of new hardware forbidden?
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- contributor
- Posts: 413
- Joined: Tue Jul 24, 2018 8:55 pm
- Github Username: Orchardperformance
- Slack: Orchardperformance
Re: Is stm32f4 the right chip?
You are correct, it requires investigation of a new chip and possible modification to an existing platform which requires human time and input.
This is near exactly what was proposed previously and was met with immediate hostility. A new platform was never suggested.
Regardless I will leave that there.
Is there any actual use case for another option for Proteus or Hellen? We already have about 4 options for these boards as it is is.
If we migrate to a total H7 line up and then take advantage of the extra performance of the chips where does that leave MRE as there is no H7 option there without major rework of the pinouts.
This is near exactly what was proposed previously and was met with immediate hostility. A new platform was never suggested.
Regardless I will leave that there.
Is there any actual use case for another option for Proteus or Hellen? We already have about 4 options for these boards as it is is.
If we migrate to a total H7 line up and then take advantage of the extra performance of the chips where does that leave MRE as there is no H7 option there without major rework of the pinouts.
Now keeping MRE in stock in the UK - https://www.FutureProofPerformance.com
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
One word: chip shortage.OrchardPerformance wrote: ↑Sun Jan 16, 2022 9:29 pmIs there any actual use case for another option for Proteus or Hellen?
At the moment STM32F723ZET6 is the only 144 pin F7 in stock at JLCPCB.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- Posts: 1
- Joined: Sat Sep 10, 2022 6:20 pm
Re: Is stm32f4 the right chip?
hi forumers!
Wanted to know if there are people still working on the 5V automotive graded MCU's?
Wanted to know if there are people still working on the 5V automotive graded MCU's?
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
People are definitely not making progress on Kinetis and Cypress.Kperformance wrote: ↑Wed Sep 14, 2022 8:09 pmhi forumers!
Wanted to know if there are people still working on the 5V automotive graded MCU's?
It still builds so firmware is up to date but there are maybe two Kinetis units in existence and maybe zero or one Cypress on this planet.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Is stm32f4 the right chip?
There are other versions available now. CYT2B7 and CYT2B9 are at Mouser and Rochester Electronics in 100 and 176 pin versions (only Roc Elec has the -9 in 176 pin). But you then you'd have to solder it yourself.AndreyB wrote: ↑Mon May 04, 2020 5:23 pmhttps://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.
Interesting stats: 1M flash, 128k RAM (double both for the -9 version). 5V. No USB. I think it's programmable over CAN or LIN, at least once. May require some odd RSA stuff for application signing. For the 176 pin, 64 ADC channels divided among three 1Msps units (24/32/8), 8 serial channels (UART/SPI/I2C), 6 CAN FD, and something like 75 16-bit counter/PWM/capture units! Dual core 160MHz M4F and 100MHz M0+ so you could theoretically dedicate the M0+ to the PWM timer loop (instead of interrupt) but with 75 separate counters I'm not sure you'd need it (maybe useful for injection/ignition events).
IMO it has a lot of interesting features to take advantage of but it may be hard to use in RusEFI as you're trying to make your code more CPU agnostic. For example the lack of USB may bother you but I'd just hook up an MCP2221A and use some of it's GPIO to control the reset and bootloader on the ECU to allow reloading the firmware no matter what state the ECU is in without needing to open the case and push a button or hook up a JTAG programmer.
EDIT: CYT2BL8CAAQ0AZEGS available at Mouser is 176 pin, 4MB flash, 512kB RAM. Even more CAN for some reason.
- AndreyB
- Site Admin
- Posts: 14358
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Is stm32f4 the right chip?
Nice stuff!
We've since started liking OpenBLT but do not see this as supported platform - having OpenBLT for CAN programming same as we have on stm32 would be one of the building blocks. We have ISO-TP connector wrapping TunerStudio protocol etc etc etc it all seems _theoretically_ doable just no resource to make it happen for real.
We've since started liking OpenBLT but do not see this as supported platform - having OpenBLT for CAN programming same as we have on stm32 would be one of the building blocks. We have ISO-TP connector wrapping TunerStudio protocol etc etc etc it all seems _theoretically_ doable just no resource to make it happen for real.
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute