rusEfi car control unit: improved hardware, now we will write software for it
Two months ago, we settled on the fact that rusEfi became a full-featured control unit - only the hardware was like an explosion at a pasta factory. Let me remind you, rusEfi is an open source and iron car control unit on the stm32 platform.
We did not sit idly and focused just on the hardware side of the issue: the task was to make a step forward on the gland, and I think the progress on the face:
It was no name v3:
')
It became Frankenstein 0.1:
It is clear that this is still only an engineering platform, not an end product - but the main thing is that there is progress :)
The board naturally works:
10 boards “Frankenstein 0.1” have already been made, another 10 boards have been ordered. Now I need to collect two fees and send one to Canada, and the second to Slovakia - this is our international project. Source board by the way here.
The development of iron paused and go back to the software and implementation. From the point of view of the engine control itself, the firmware has not advanced - the firmware has advanced in terms of customization and debugging convenience: support for the HD44780 symbolic screen has appeared, the number of conditional compilations have decreased dramatically - a much larger percentage of settings can now be changed on the fly, through our debugging console or via the popular universal program settings ECU. SD slot appeared. There was a CAN bus - which, by and large, we do not need yet. The driver of a popular GPS module appeared - which at the moment is generally pure mischief :) In a word, we built the foundation - and I think we built it.
Now you can do the most delicious - now from all this you can make a convenient, versatile and simple automotive control unit.
Personally, first of all I am an experienced programmer, so we will write the firmware thoroughly:
Unit tests & continuous integration.
Three days ago, we switched from C to C + - there will be quite a bit of OOP, so for now we’ll assume only one plus in the word “C +”.
A week ago, it was possible to compile the basic logic of the firmware under Windows - this should soon result in automated functional testing.
You ask, so what is there is not enough while in the firmware? Much is not enough. Changes in some parameters require a reboot of the firmware so far - it is not able to switch from one mode to another while on the fly. Configuring online you need to finish carefully - some things are still set in the code.
So while programming neural networks is a bit early, as long as you need to program all the fundamental functionality. Yes, while the tasks are relatively boring - but interest is added by the requirements of crystal-clear purity codes and user convenience.
So if there are pedantic perfectionist programmers who want to learn something new, join.
Related Links:
http://rusefi.com/wiki/index.php?title=Main_Page/en
http://rusefi.com/forum/
PS: there was a request to specifically voice the challenges of programming.
So, the motor is already running - i.e. the control processes themselves in the prototype mode, with reference to a specific motor, are there. The parameterization of these processes needs to be improved. firstly, the configuration should be completely changed through the serial port, and secondly, the new parameters should apparently begin to be applied without restarting the program. This is the most important thing at the moment.
The next stage is the complication of control processes. For example, the input parameter 'load' should not be a slow analog sensor, but a fast analog sensor that needs to be polled only within a specific time window and averaged. The algorithm for maintaining idle is now more than naive - something needs to be done. The processing algorithm of the dual throttle position sensor, and so on, and so on. Electronic throttle control algorithm plus the electronics of this control. And at some point you need time variables from strange ticks in seconds / milliseconds. And so on.
I will start with automated functional testing - it is quieter for me to refactor something when it itself checks that external behavior does not change unexpectedly.
We did not sit idly and focused just on the hardware side of the issue: the task was to make a step forward on the gland, and I think the progress on the face:
It was no name v3:
')
It became Frankenstein 0.1:
It is clear that this is still only an engineering platform, not an end product - but the main thing is that there is progress :)
The board naturally works:
10 boards “Frankenstein 0.1” have already been made, another 10 boards have been ordered. Now I need to collect two fees and send one to Canada, and the second to Slovakia - this is our international project. Source board by the way here.
The development of iron paused and go back to the software and implementation. From the point of view of the engine control itself, the firmware has not advanced - the firmware has advanced in terms of customization and debugging convenience: support for the HD44780 symbolic screen has appeared, the number of conditional compilations have decreased dramatically - a much larger percentage of settings can now be changed on the fly, through our debugging console or via the popular universal program settings ECU. SD slot appeared. There was a CAN bus - which, by and large, we do not need yet. The driver of a popular GPS module appeared - which at the moment is generally pure mischief :) In a word, we built the foundation - and I think we built it.
Now you can do the most delicious - now from all this you can make a convenient, versatile and simple automotive control unit.
Personally, first of all I am an experienced programmer, so we will write the firmware thoroughly:
Unit tests & continuous integration.
Three days ago, we switched from C to C + - there will be quite a bit of OOP, so for now we’ll assume only one plus in the word “C +”.
A week ago, it was possible to compile the basic logic of the firmware under Windows - this should soon result in automated functional testing.
You ask, so what is there is not enough while in the firmware? Much is not enough. Changes in some parameters require a reboot of the firmware so far - it is not able to switch from one mode to another while on the fly. Configuring online you need to finish carefully - some things are still set in the code.
So while programming neural networks is a bit early, as long as you need to program all the fundamental functionality. Yes, while the tasks are relatively boring - but interest is added by the requirements of crystal-clear purity codes and user convenience.
So if there are pedantic perfectionist programmers who want to learn something new, join.
Related Links:
http://rusefi.com/wiki/index.php?title=Main_Page/en
http://rusefi.com/forum/
PS: there was a request to specifically voice the challenges of programming.
So, the motor is already running - i.e. the control processes themselves in the prototype mode, with reference to a specific motor, are there. The parameterization of these processes needs to be improved. firstly, the configuration should be completely changed through the serial port, and secondly, the new parameters should apparently begin to be applied without restarting the program. This is the most important thing at the moment.
The next stage is the complication of control processes. For example, the input parameter 'load' should not be a slow analog sensor, but a fast analog sensor that needs to be polled only within a specific time window and averaged. The algorithm for maintaining idle is now more than naive - something needs to be done. The processing algorithm of the dual throttle position sensor, and so on, and so on. Electronic throttle control algorithm plus the electronics of this control. And at some point you need time variables from strange ticks in seconds / milliseconds. And so on.
I will start with automated functional testing - it is quieter for me to refactor something when it itself checks that external behavior does not change unexpectedly.
Source: https://habr.com/ru/post/215081/
All Articles