[info] ATLAB X5- MX5 PNP

[atntpt]

Hello, I have recently been gaining interest in the creation and development of ecus. my first project was based on speeduino- an ecu pnp for the mx5 mk2.
Everything became functional but some software limitations led me to want to do the same but based on rusefi!
I'll probably need some help
Anyway, I'm posting updates of what I'm doing.

[kb1gtt]

Sweet and feel free to ask questions.

If you post your schematics and such, I can offer my comments from a hardware level review.

Do you plan to do a re-spin of the board which includes the STM32 components? It appears you have some kind of brain board area. Do you plan to spin a board with includes the STM32 chip used by rusEFI, then place it in that area?

[AndreyB]

Mk2 or nb2?

[atntpt]

Sweet and feel free to ask questions.

If you post your schematics and such, I can offer my comments from a hardware level review.

Do you plan to do a re-spin of the board which includes the STM32 components? It appears you have some kind of brain board area. Do you plan to spin a board with includes the STM32 chip used by rusEFI, then place it in that area?

hello, thanks for the availability!
I'm doing it all over again and I want it to be as clean as possible. When I have something more composed I share so you can comment!

Regarding the hardware I have a few questions, I used tc4427 to control the mosfets on my board. I noticed that in the frankenso scheme they are linked directly to the stm output. but in the name of the links it refers to "5v" the stm only has 3.3v outputs right?
- any special care with the pinout outputs / inputs that have to be specific for certain functions?
-I'm using the lib from stmf407 but being able to use the 469 pinout is equal right? both lqfp100 obviously
- What is the purpose of the 32mhz crystal? programming?


- about software .. being that the pinout can be all configured will the firmware will work without any changes? in Prometheus git there is an .oic file that seems to me to be some kind of configuration

[atntpt]

Mk2 or nb2?

the idea is to make both bit i own a mk2 not mk2.5 so i will do it first

[kb1gtt]

I recall the STM32 was 5V compatible, but can only drive 3.3V. My labels are perhaps less than clear. When I made the labels I did not know it was 3.3V drive. I saw the 5V compatible note, and made my labels. With how flexible this has ended up being, it's probably best because if my labels did not reference voltages.

I understand the use of a small MOSFET driver to drive a larger MOSFET, as it helps prevent the channel energy from holding the gate on. However I don't understand the use of a small MOSFET driving a small MOSFET. You are still driving a MOFET and it still has the ability to self latch. Also I have not found any OEM ECU's which use a MOSFET driver for 1A loads. To me the TC4427 seems like it's just extra components. I'm not sure it's providing the benefits you might think it's providing.

I recall CAM / CRANK are fairly specific. I recall those have limited IO that they can be attached to. I think everything else is fairly universal / obvious. This would be better known by @.

I think you are referencing X2, the 32.768kHz. I recall that's a low energy slow clock for sleeping cycles. Or perhaps it was a RTC thing. I forget. I don't think we are using it yet, but if we end up doing sleep stuff some day, then it would likely be useful.

[andreika]

-I'm using the lib from stmf407 but being able to use the 469 pinout is equal right? both lqfp100 obviously

These are NOT compatible pinouts, beware!

being that the pinout can be all configured will the firmware will work without any changes? in Prometheus git there is an .oic file that seems to me to be some kind of configuration

There are several pinout configurations available inside the firmware. But you need to clean-and-rebuild the firmware (and reset flash config) to switch them. See /rusefi/firmware/config/boards/ folder for more details.
1) The default is a ST_STM32F4 "Discovery" config pinout which is compatible with Frankenso/Frankenstein boards on 407 chip.
2) Another is "Prometheus" config which contains two pinouts for 469 chip (in 64 and 100-pin packages) for the Prometheus board (rev 0.1 and 0.2).
And also there are plenty of "engine" configurations on top of them.

[atntpt]

These are NOT compatible pinouts, beware!

I mean hardware wise - I didn't confirm them all but did put both sheats side by side and looked similar ! Will double check every pin! Don't you happened to have eagle lib ?

There are several pinout configurations available inside the firmware. But you need to clean-and-rebuild the firmware (and reset flash config) to switch them. See /rusefi/firmware/config/boards/ folder for more details.
1) The default is a ST_STM32F4 "Discovery" config pinout which is compatible with Frankenso/Frankenstein boards on 407 chip.
2) Another is "Prometheus" config which contains two pinouts for 469 chip (in 64 and 100-pin packages) for the Prometheus board (rev 0.1 and 0.2).
And also there are plenty of "engine" configurations on top of them.

About being a custom board, I saw the file board_configuration.cpp contains most of the pin assignment. Is this the only modification I need to make if I use same processor ? If don't how hard is it and if Im able to finish the board could someone help me ?

[andreika]

Don't you happened to have eagle lib ?

No, I didn't use eagle, sorry...

board_configuration.cpp contains most of the pin assignment. Is this the only modification I need to make if I use same processor ? If don't how hard is it and if Im able to finish the board could someone help me ?

If you're using different UART/SPI channels, you might also want to modify mcuconf.h (see rusefi/firmware/config/boards/Prometheus/mcuconf.h as example -- just use #undef+#define scheme to override non-default values). Alse look into efifeatures.h - to disable unused hardware ("#define EFI_HD44780_LCD FALSE" etc.) and setup some internal non-configurable channels and interfaces ("#define ADC_CHANNEL_VREF ADC_CHANNEL_IN14")...
We've already put some effort to make multiple HAL-configs possible, so basically it should work.

[atntpt]

litle update