rusEfi: opensource DIY injector project
I would like to continue the topic of the fuel injection unit based on stm32 and talk about the current status of the rusEfi project.
rusEfi is a opensource project to create a universal control unit for an internal combustion engine. Universal means support for a wide range of configurations, sensors, and actuators. This means that this unit can be installed on any engine and get complete control, without closed firmware, undocumented features and everything else. If you are a programmer, then the possibilities are even wider - you can edit the algorithms yourself, and not just the available maps and settings. RusEfi differs from other similar projects in its emphasis on powerful, but inexpensive hardware, and due to this the ability to write the most transparent and portable code.
Four years ago, I accidentally became interested in very amateur endurance ring races. Time passed, I wanted faster and better, but there was no desire to go the banal path of buying a BMW e30 - so there were thoughts to install a turbine on the engine. Reliability in this configuration is possible only with proper injection and ignition control, and according to the rules of my races, all this should also be very cheap. An analysis of existing solutions showed that the prices are still high, and not always justified, but the possibilities are limited. A makeshift block clearly comes at a price cheaper than existing custom blocks.
After reading the available sources (and by profession I’m just a programmer), I decided to write code from scratch. The initial task was to write clear, extensible, and minimally hardware-related code.
Currently, there are a large number of powerful and inexpensive microcontrollers, whose performance is enough not to care about each clock cycle, concentrate on high-quality code and a high level of abstraction. All this will allow you to get high-quality and portable code, extensibility and lack of binding to a specific hardware. All this promises the possibility of switching to other hardware platforms when it comes to a test. As a result, STM32 was chosen - inexpensive, but powerful.
For several reasons, I believe that at the current stage, and possibly forever, iron should be modular. Currently, the STM32F4DISCOVERY debug board and two modules are used - the power driver module and the analog input module.
The dimensions of the development board allow connecting at least four small modules to it from different angles. Now we have an analog input
module, a solenoid control module (the fuel nozzle is just a solenoid)
and a wiring connector module. The
boards are drawn in KiCad - again, an open and free package. But taking into account the rather flexible configuration of the pinout, everyone can use their I / O cards, compatibility is not required.
With drawing boards now is probably the bottleneck - several people are already involved in writing the code, but with iron it's getting harder. There is a list of tasks, but no people. And already I want to try from the Chinese to order not only the board, but also order the assembly of at least all the resistances.
For better modularity, the system uses a small RTOS ChibiOS / RT , which is also valuable due to the level of abstraction from the equipment. ChibiOS gives us, firstly, threads and blocking primitives - this is the functionality of the RTOS kernel, and secondly - hardware drivers with a convenient and uniform API for different MKs. Due to this, one does not have to go deep into buses and registers and there is hope for portability. At the same time, there is no great connection specifically with this RTOS, if necessary, it will be possible to move to another.
The main principle of this project: the most readable source code. Everything that can be done is as modular and straightforward as possible: I really want to not hack anything anywhere, but simply to honestly implement it. With minimal involvement with the selected hardware platform, switching to another platform in the future should be quite simple.
As you know, to configure the control unit requires some software that allows you to write logs, analyze and edit all kinds of tables, calibrations and settings. This software often costs money and its purchase for a single setting is not always relevant.
To control us, we use the popular TunerStudio, integration is already working. TunerStudio is quite flexible and allows you to edit the settings on the fly, create any tables, edit maps and so on. Everything works online. It should also be noted that integration with TunerStudio also promises integration with MegaLogViewer, which allows you to analyze logs and automatically adjust the fuel map based on the log. Also from the same line there is Shadow Dash MS - an android application from the creators of Tuner Studio, which allows everything the same as Tuner Studio, but from an android device via bluetooth.
All these software products implement the necessary mechanisms; they will not have to be written from scratch. Right now, fuel and temperature adjustment cards are working in TunerStudio, the mechanisms are in place, and further development in this direction does not pose a problem.
Now the controller controls the fuel supply, based on the shaft position sensors and the air flow sensor. From a simple table, the pulse lengths are obtained depending on the current speed and air flow, with additional corrections for the temperature of the coolant and air. This is a primitive and far from ideal algorithm that is used more for debugging.
There is no ignition control right now. At some point there was an ignition control, then it was temporarily removed - now ignition control will be the main area of work on firmware.
If you touch on the topic of analogues - the first one usually mentioned is Megaskirt, which is "ajar" - the source code is open, but requires the use of their official hardware, another use is a violation of the license. Megasquirt costs quite tangible money. Only FreeEMS can be called a truly open and living project - about twenty cars already drive this control unit, but this project is tied to a very specific hardware and the source code just disturbs my sense of beauty.
How much does it all cost? The project is open, the source code does not cost anything. Iron is open - iron costs as much as you spend on its manufacture. The approximate minimum control unit should be around $ 100. By the way, a separately interesting direction for the future is to implant a new MK into the board of the original ECU. For old blocks of the DIP era, this will be the most economical version - such an upgrade will cost only $ 20, while it will be fully compatible with rusEfi.
Now you just need to debug the foundation - carefully process all the options for position sensors, carefully arrange the hardware modules in a single style for a wide range of car configurations.
At the moment, the project needs your support. You need to write code, work on electronics and do other exciting and useful things. Everyone can help!
The project code is located on Sourceforge - the tracker also lives there.
Schemes of the current version of iron
There is a forum
rusEfi is a opensource project to create a universal control unit for an internal combustion engine. Universal means support for a wide range of configurations, sensors, and actuators. This means that this unit can be installed on any engine and get complete control, without closed firmware, undocumented features and everything else. If you are a programmer, then the possibilities are even wider - you can edit the algorithms yourself, and not just the available maps and settings. RusEfi differs from other similar projects in its emphasis on powerful, but inexpensive hardware, and due to this the ability to write the most transparent and portable code.
A bit of history.
Four years ago, I accidentally became interested in very amateur endurance ring races. Time passed, I wanted faster and better, but there was no desire to go the banal path of buying a BMW e30 - so there were thoughts to install a turbine on the engine. Reliability in this configuration is possible only with proper injection and ignition control, and according to the rules of my races, all this should also be very cheap. An analysis of existing solutions showed that the prices are still high, and not always justified, but the possibilities are limited. A makeshift block clearly comes at a price cheaper than existing custom blocks.
After reading the available sources (and by profession I’m just a programmer), I decided to write code from scratch. The initial task was to write clear, extensible, and minimally hardware-related code.
Choosing a hardware platform.
Currently, there are a large number of powerful and inexpensive microcontrollers, whose performance is enough not to care about each clock cycle, concentrate on high-quality code and a high level of abstraction. All this will allow you to get high-quality and portable code, extensibility and lack of binding to a specific hardware. All this promises the possibility of switching to other hardware platforms when it comes to a test. As a result, STM32 was chosen - inexpensive, but powerful.
For several reasons, I believe that at the current stage, and possibly forever, iron should be modular. Currently, the STM32F4DISCOVERY debug board and two modules are used - the power driver module and the analog input module.
The dimensions of the development board allow connecting at least four small modules to it from different angles. Now we have an analog input
module, a solenoid control module (the fuel nozzle is just a solenoid)
and a wiring connector module. The
boards are drawn in KiCad - again, an open and free package. But taking into account the rather flexible configuration of the pinout, everyone can use their I / O cards, compatibility is not required.
With drawing boards now is probably the bottleneck - several people are already involved in writing the code, but with iron it's getting harder. There is a list of tasks, but no people. And already I want to try from the Chinese to order not only the board, but also order the assembly of at least all the resistances.
Software
For better modularity, the system uses a small RTOS ChibiOS / RT , which is also valuable due to the level of abstraction from the equipment. ChibiOS gives us, firstly, threads and blocking primitives - this is the functionality of the RTOS kernel, and secondly - hardware drivers with a convenient and uniform API for different MKs. Due to this, one does not have to go deep into buses and registers and there is hope for portability. At the same time, there is no great connection specifically with this RTOS, if necessary, it will be possible to move to another.
The main principle of this project: the most readable source code. Everything that can be done is as modular and straightforward as possible: I really want to not hack anything anywhere, but simply to honestly implement it. With minimal involvement with the selected hardware platform, switching to another platform in the future should be quite simple.
Integration with customization programs
As you know, to configure the control unit requires some software that allows you to write logs, analyze and edit all kinds of tables, calibrations and settings. This software often costs money and its purchase for a single setting is not always relevant.
To control us, we use the popular TunerStudio, integration is already working. TunerStudio is quite flexible and allows you to edit the settings on the fly, create any tables, edit maps and so on. Everything works online. It should also be noted that integration with TunerStudio also promises integration with MegaLogViewer, which allows you to analyze logs and automatically adjust the fuel map based on the log. Also from the same line there is Shadow Dash MS - an android application from the creators of Tuner Studio, which allows everything the same as Tuner Studio, but from an android device via bluetooth.
All these software products implement the necessary mechanisms; they will not have to be written from scratch. Right now, fuel and temperature adjustment cards are working in TunerStudio, the mechanisms are in place, and further development in this direction does not pose a problem.
Project Current Status
Now the controller controls the fuel supply, based on the shaft position sensors and the air flow sensor. From a simple table, the pulse lengths are obtained depending on the current speed and air flow, with additional corrections for the temperature of the coolant and air. This is a primitive and far from ideal algorithm that is used more for debugging.
There is no ignition control right now. At some point there was an ignition control, then it was temporarily removed - now ignition control will be the main area of work on firmware.
If you touch on the topic of analogues - the first one usually mentioned is Megaskirt, which is "ajar" - the source code is open, but requires the use of their official hardware, another use is a violation of the license. Megasquirt costs quite tangible money. Only FreeEMS can be called a truly open and living project - about twenty cars already drive this control unit, but this project is tied to a very specific hardware and the source code just disturbs my sense of beauty.
How much does it all cost? The project is open, the source code does not cost anything. Iron is open - iron costs as much as you spend on its manufacture. The approximate minimum control unit should be around $ 100. By the way, a separately interesting direction for the future is to implant a new MK into the board of the original ECU. For old blocks of the DIP era, this will be the most economical version - such an upgrade will cost only $ 20, while it will be fully compatible with rusEfi.
Now you just need to debug the foundation - carefully process all the options for position sensors, carefully arrange the hardware modules in a single style for a wide range of car configurations.
At the moment, the project needs your support. You need to write code, work on electronics and do other exciting and useful things. Everyone can help!
The project code is located on Sourceforge - the tracker also lives there.
Schemes of the current version of iron
There is a forum