rusefi.com

http://www.st.com/web/en/press/p3606s
http://www.st.com/stm32f7

STM32 F7 series is pin-to-pin compatible to the STM32 F4 series. They promise twice the performance of F4.

https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html

The STM32H7 single-core and value lines are pin-to-pin compatible with the STM32F7 series of very high-performance MCUs and STM32F4 series of high-performance MCUs for the most common packages (*).

(*): see datasheet for the specific case of 100-pin packages

Available in Q2/2015, LQFP100 -144 -176 packages, pretty sweet! I have to pat myself on the back for the processor-independent approach

Looks like ChibiOS support is pretty possible: http://forum.chibios.org/phpbb/viewtopic.php?f=16&t=2331

Just placed an order for NUCLEO-F746ZG based on STM32F746ZGT6

I am mostly curious about

SRAM: 320KB (including 64KB of data TCM RAM for critical real-time data) + 16KB of instruction TCM RAM (for critical real-time routines)

looks like faster RAM regions for most important methods and overall 462 Million Instructions per Second vs 210 DMIPS on our current stm32f407vg. All this for just $23.

Taller and a bit wider then stm32f4discovery.

Looking good!

How are out chances looking for a quick and easy Chibios port?

Hi, Everyone!

I happen to have a Nucleo STM32F767ZI and have plans to test it with the Frankenso board and see what we can come up with.

My name is Troy (also known as Dj Wind), I live in Springfield, MO USA.

I am a disabled database programmer. (I have been looking at the code and could certainly help with it or even documentation)

I have a lot of experience in computers and cars (all my life, working on both).

I would like to know if the Frankenstein or the Frankenso would be better based on the following.

Here is my setup:
1999 Mazda 626 ES V6
KLD4 motor (Same motor in ford probe and a lot of other mazda's)
This motor is compatible with KLDE/KLZE parts.
It is a v6 2.5 liter.
The 1999 mazda 626 uses the ford eec-v ECU.

vacuum diagram


the cam sensor pic from rockauto (best parts site IMO)


the crank sensor from rockauto

From the ford EEC Wiki:
Additional performance needs drove Ford Electronics to develop an enhanced microprocessor named the 8065 building on EEC-IV technology. Memory was expanded from 64K to 1 megabyte, speed tripled, and I/O more than doubled. Additional interrupts and improved time controlled I/O allowed continued use of EEC-IV code and extended the family lifetime to almost 20 years in production.

The KLD4 use VRIS (Actually 2 system VRIS)
The system uses the ford edis coil system.

Here is the full specs on my 1999 Mazda 626 ES V6 (got to love VIN lookups)

Vehicle Name Mazda 626, Mazda 626
Body Style 4 Door Sedan
Drivetrain Front Wheel Drive
EPA Classification Midsize
Passenger Capacity 5 5.0 min 5.0 max
Passenger Volume 97.1 ft³ 97.1 min 97.1 max
Base Curb Weight 3065 lbs 2988.0 min 3065.0 max
EPA Fuel Economy Est - City 20 MPG 20.0 min 21.0 max
EPA Fuel Economy Est - Hwy 26 MPG 26.0 min 27.0 max
Engine Type Gas V6
Displacement 2.5L/152
Fuel System EMPI
SAE Net Horsepower @ RPM 170 @ 6000
SAE Net Torque @ RPM 163 @ 5000
Trans Type 4 4.0 min 5.0 max
Trans Description Cont. Automatic
Trans Description Cont. Again Electronic
First Gear Ratio (:1) 2.80 2.8 min 3.31 max
Second Gear Ratio (:1) 1.54 1.54 min 1.83 max
Third Gear Ratio (:1) 1.00 1.0 min 1.31 max
Fourth Gear Ratio (:1) 0.70 0.7 min 1.03 max
Reverse Ratio (:1) 2.33 2.33 min 3.17 max
Final Drive Axle Ratio (:1) 4.16 4.1 min 4.16 max
Cold Cranking Amps @ 0° F (Primary) 582 582.0 min 582.0 max
Maximum Alternator Capacity (amps) 90 90.0 min 90.0 max
Total Cooling System Capacity 7.9 qts 7.9 min 7.9 max
Suspension Type - Front Independent struts
Suspension Type - Rear Independent struts
Suspension Type - Front (Cont.) w/lower A-arms
Suspension Type - Rear (Cont.) w/twin links
Shock Absorber Diameter - Front 32 mm 32.0 min 32.0 max
Shock Absorber Diameter - Rear 32 mm 32.0 min 32.0 max
Stabilizer Bar Diameter - Front 1.07 in 1.07 min 1.07 max
Stabilizer Bar Diameter - Rear 0.55 in 0.55 min 0.55 max
Front Tire Size P205/60HR15
Rear Tire Size P205/60HR15
Spare Tire Size T125/70D15
Front Wheel Size 15 x 6 in
Rear Wheel Size 15 x 6 in
Spare Wheel Size 15 x 4 in
Front Wheel Material Aluminum
Rear Wheel Material Aluminum
Spare Wheel Material Steel
Steering Type Pwr Rack & Pinion
Steering Ratio (:1), Overall 17.0 17.0 min 17.0 max
Lock to Lock Turns (Steering) 2.9 2.9 min 2.9 max
Turning Diameter - Curb to Curb 35.4 ft 35.4 min 35.4 max
Brake Type Power
Brake ABS System Yes
Disc - Front (Yes or ) Yes
Disc - Rear (Yes or ) Yes
Front Brake Rotor Diam x Thickness 10.8 x 0.94 in
Rear Brake Rotor Diam x Thickness 11.0 x 0.39 in
Fuel Tank Capacity, Approx 16.9 gal 16.9 min 16.9 max
Front Head Room 38.4 in 38.4 min 39.2 max
Front Leg Room 43.6 in 43.6 min 43.6 max
Front Shoulder Room 56.3 in 56.3 min 56.3 max
Front Hip Room -TBD- in
Second Head Room 37.0 in 37.0 min 37.0 max
Second Leg Room 34.6 in 34.6 min 34.6 max
Second Shoulder Room 55.9 in 55.9 min 55.9 max
Second Hip Room -TBD- in
Wheelbase 105.1 in 105.1 min 105.1 max
Length, Overall 186.8 in 186.8 min 186.8 max
Width, Max w/o mirrors 69.3 in 69.3 min 69.3 max
Height, Overall 55.1 in 55.1 min 55.1 max
Track Width, Front 59.8 in 59.8 min 59.8 max
Track Width, Rear 59.8 in 59.8 min 59.8 max
Trunk Volume 14.2 ft³ 14.2 min 14.2 max

Do you plan to try the nucleo f767? If so, how could i help?

Djwind wrote: ↑

Tue Jan 30, 2018 7:54 pm

Do you plan to try the nucleo f767? If so, how could i help?

It's unclear why would we need it. Why would we need it?

but you can always help, I can see at least three ways
1) donate $
2) KiCad an adapter board from nucleo f767 to stm32f4discovery pinout - that case we would be able to use existing Frankenso boards
3) fork source code and create the board-specific folders so that we can build rusefi frankenso for stm32f7 - even if we start without some features having a way to compile even with just serial port would be a step forward

It's not needed, it would just be a faster version of the discovery (i.e. F769-disco0). Forking the code would not be difficult considering the F679-disco0 is backwards compatible, according to the documentation. Please don't get me wrong, speed is not the issue, its upgrade, compatibility (i.e. Cortex-M7). I will now start a fork of the code and test using the F769-disco0, the libraries are already finished for the M7 including all interfaces on the board.
The timing is what will need tinkering with .

Are you proposing that we consider putting in a larger more powerful heart into the project just for the sake of having more power. Why would you think we might be interested in doing such a thing... The OEM setup is just fine for us here, we don't see any need to make things faster just for the sake of making them faster....

Sarcasm aside, I like the idea. We have been focusing our limited resources on other features, and I wonder if this is one you might have interest in helping with. I can see how some day we'll run out of resources and our other efforts will run into resource issues. If we had a path to having more resources available, I'm fairly sure we'll have that need some day.

I think a PCB adapter board would be helpful in getting this kind of board usable. I also agree that porting shouldn't be to hard. Have you checked if this chip is ChibiOS friendly? I would think it is. As well what other resources would it provide? I'm guessing more RAM, perhaps more timers, does it provide more IO? Could you do a little write up about how it compare against the STM32F4?

I know in the past there was some effort to use a RAM chip such that we could do some auto-tuning stuff. Currently auto tune is done via TS and a PC, and it would be difficult to get auto tuning into the existing chip because it has a lack of RAM. I've also been making some progress with the LCD display board. That board has an accelerometer. I could see how we might start doing auto tuning via acceleration data.

this one is even better?
https://www.terraelectronica.ru/product/2584140
https://www.compel.ru/lib/ne/2018/1/3-stm32-semeystva-h7-s-novyimi-vozmozhnostyami-k-novyim-vershinam

puff wrote: ↑

Thu May 10, 2018 2:55 pm

this one is even better?
https://www.terraelectronica.ru/product/2584140
https://www.compel.ru/lib/ne/2018/1/3-stm32-semeystva-h7-s-novyimi-vozmozhnostyami-k-novyim-vershinam

Лучше чем что ? И чем именно ?

чем субж, разумеется. а прочитать по ссылке не асилил? только написать?

Added initial support for STM32 Nucleo144-F767ZI board:
https://github.com/rusefi/rusefi/pull/620

New series of chips - STM32H7 - https://www.st.com/en/microcontrollers/stm32h7-series.html

400 MHz
1 Mbyte of SRAM

STM32H7 series is pin-to-pin compatible with the STM32F7 series for common packages, and compatible with the STM32F4 series for most of the common packages *

STM32H7 about 4 times faster that STM32F4 but I am mostly interested in 4 times more RAM.

STM32F407/417 – 168 MHz CPU/210 DMIPS
STM32F469/479 - 180 MHz CPU/225 DMIPS
STM32F7 - 216 MHz/462 DMIPS
STM32H7 - 400 MHz/856 DMIPS

russian wrote: ↑

Mon Jan 28, 2019 12:57 am

STM32H7 about 4 times faster that STM32F4 but I am mostly interested in 4 times more RAM.

STM32F407/417 – 168 MHz CPU/210 DMIPS
STM32F469/479 - 180 MHz CPU/225 DMIPS
STM32F7 - 216 MHz/462 DMIPS
STM32H7 - 400 MHz/856 DMIPS

I have a Nucleo H7 here I am trying to compile for, but I dont understand enough of the firmware part.

The board are supported in Chibios.

Can you add it easily?

960 wrote: ↑

Mon Jan 28, 2019 4:08 am

Can you add it easily?

I am afraid you are missing a lot of context here First of all, as of today we are using ChibiOS17 - so, first step would probably be to migrate to ChiboOS18 - that's https://github.com/rusefi/rusefi/issues/631

Before we migrate to ChibiOS18 would be nice to figure out https://github.com/rusefi/rusefi/issues/685

All this would require some software developers and at the moment we have very few of those.

About STM32H7, how does the IRQ latency compare? A fast bit pump doesn't necessarily mean accurate timing. However faster clock XTAL's often do mean less IRQ delay and less jitter.

russian wrote: ↑

Mon Jan 28, 2019 4:22 am

960 wrote: ↑

Mon Jan 28, 2019 4:08 am

Can you add it easily?

I am afraid you are missing a lot of context here First of all, as of today we are using ChibiOS17 - so, first step would probably be to migrate to ChiboOS18 - that's https://github.com/rusefi/rusefi/issues/631

Before we migrate to ChibiOS18 would be nice to figure out https://github.com/rusefi/rusefi/issues/685

All this would require some software developers and at the moment we have very few of those.

I dont know so much about this stuff, but I have compiled it all working for F767 with latest ChibiOS.

Whats the difference from others like FreeRtos, Erika etc.?

960 wrote: ↑

Mon Jan 28, 2019 2:31 pm

ChibiOS... Whats the difference from others like FreeRtos, Erika etc.?

ChibiOS has a great (best open source?) HAL = Hardware Abstraction Layer in addition to just kernel - http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:hal:start

Unfortunately making HAL is a lot of effort so ChibiOS is 987% focused on stm32

See how people use ChibiOS HAL with FreeRTOS v10 http://www.chibios.com/forum/viewtopic.php?f=8&t=4419
See switch from something else to ChibiOS because of HAL http://www.chibios.com/forum/viewtopic.php?f=8&t=4521

I have one unpopulated https://github.com/rusefi/rusefi/tree/master/hardware/brain_board and two unpopulated https://github.com/rusefi/rusefi/tree/master/hardware/brain_board_176-pin

Do we know if there are any 100% pin compatible F7 or H7 chips which would work on these boards?

Nucleo F7 boards are different from F4 discovery: F7 nucleo has St-Link generating 8MHz frequency MCO wave while 8MHz oscillator is not connected

F4 discovery St-Link is NOT providing 8MHz to stm32f4, the oscillator does. This hardware difference is important because software has to be compiled with options accounting for the setup.

https://rusefi.com/build_server/ now has two different versions of F767 firmware for different hardware configurations

https://github.com/rusefi/rusefi/issues/708

@andreika makes a lot of cool things, look at what this chip is

Mini-F407 vs Mini-Monster-H743:

andreika wrote: ↑

Fri Mar 22, 2019 4:02 pm

Mini-Monster-H743

My nuckeo-H743 has arrived. At this point there is zero reason to try rusEfi on H7 but it does not mean we should not try anyway

That's a sweet little board.

Our worst F7 major issue! Kudos to @mck1117 and @960

https://github.com/rusefi/rusefi/issues/854 This makes me see how we are probably not ready to H7 drama with even more caching magic on H7?

@AndreyB - I just watched this video from one of your other links and because I used to work with drones.



I understood a lot more that I expected just not quite as much as I would have ultimately liked

You should be congratulated on your choice of ChibiOS, very clearly well researched.

One thing which did intrigue me was the use of the HW_DEFS.DAT and the hardware definitions extracted from the datasheets with the python script.

That seemed incredibly efficient and functional.

I was actually in the process of researching which Nucleo board to choose and buy, but got distracted.

STM32H743xI has

2× ultra-low-power comparators
• 2× operational amplifiers (8 MHz bandwidth)
• 1× digital filters for sigma delta modulator
(DFSDM) with 8 channels/4 filters

Does this make STM32H7 more than just faster STM32F4 by adding more of analog peripheral we've looked at in F3?

AN4936 Application note
Migration of microcontroller applications from STM32F7 Series to STM32H743/753 line