rusefi.com

I'm very happy to see that the time for Free and Open ECU is coming.

I came across this project util waiting for approval on my post in http://open5xxxecu.org forum.
This project way better structured and designed. Code is modular and well documented. This is the very first step to longevity of the code and entire project.
I'm embedded developer and I believe that the code is essential for any project. If you have the SW core running on STM32F4DISCOVERY it will be "piece of cake" to port it to another more powerful HW platform and push it further - more speed, more accuracy, more data and most important thing more supporters.

russian, thank you for all your efforts to bring rusefi project to live!

P.S. I'll go with https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware HW.

Thank you for the kind words!

This thread should have some info to get you started, including a link to our SW issue tracker if you are mostly on the software side of things.

As of today this firmware has only started one engine, but a couple more test vehicles are getting closer.

Feel free to poke me on skype or email me a .patch right away

Cool and welcome along. Jon is pro-using the o5e stuff, can I make a suggestion that you port the o5e code to chibios and make it run on an ARM? I'd like to see that happen, lots of work already done that can be reused.

kb1gtt wrote:Cool and welcome along. Jon is pro-using the o5e stuff, can I make a suggestion that you port the o5e code to chibios and make it run on an ARM? I'd like to see that happen, lots of work already done that can be reused.

Looking at what could be shared or reused is my plans, we just need to cover the fundamentals first. There is plenty of stuff to take care before you even start controlling the engine.

Good to hear. I know there is a copy of Jon's work out there, which you appear to have found. However his official work can be found here https://code.google.com/p/mpc5xxx-engine-control/ I'd recommend studying that code. I understand russian is not a fan of how the memory is used in that approach. I also understand that russian has a patch he's been looking to get integrated into that code base. That code base is based around the multi core processor approach, and transfers a bunch of information via memory. So a sub processor (ETPU) updates some RAM, then the primary processor reads the information from RAM. I mention it as I feel that having an underlying structure for a multi-core processor will be very helpful item for the long term. I see this http://olimex.wordpress.com/2013/10/09/a20-som-update/ is just around the corner. As well the beaglebone Black is multi core, lost of multi-core options out there and more will be coming at lower costs in the near future. I haven't looked at russians code lately, it's matured quite a bit sense the last time I looked at it, a couple months ago. He's been doing great work with it. I tend to think that smashing his code and Jon's code together is an optimal approach, as Jon already has lots of things like tables that get updated via TunerStudio (TS) and task priority. What is missing from Jon's is that we were using the FreeScale provided ETPU code, which sucks and simply didn't work on real world engines. The ETPU crank angle decoder simply won't keep a reliable sync on a real world crank signal. Even it it did work, the premade ETPU code was very limited. With no ETPU compiler, it's next to impossible to make changes to the ETPU code. So it never got working correctly. So if russian's crank angle and fuel pulse code was smashed together with Jon's multicore table adjustable code, I think we'd have a great setup.

I also know that russian has ticket numbers on SF.net. If you are looking to get involved, I think those tickets could be a good way to get involved. If you are looking to get something working in short order, I'd recommend using the STM F4 discovery board that russian is using. We are spinning a couple boards to get AN input, fuel outputs, ect. Those boards will make it much easier and reasonably low cost for most people to get involved.

If you go the olimex route, and plan to make a bunch of changes I might suggest an A20 and lots of work, or the OLIMEXINO-STM32 as it offers an automotive qualified voltage regulator, and several components that are automotive environment friendly. All for low $.

Hardware wise, what are your skills? I'm looking to make a device I've dubbed a play recorder. Basically I want to make a device where someone can record an engine, the developers can play back those signals, and develop on engines they don't have access to. Any interest in such a concept? I'm curious what your goals are.

Here's hoping you do some cool stuff.

Short term goals: Get build environment for STM32F4, get board, start coding and resolving tickets.
Long term goals: Stable running ECU, new features (turbo support, anti-lag, water jets, multi-stage injectors, multiple modes (at least stock and god modes), Africa Twin with direct injection (at least injection), support for different fuels, wide band O2 support, knock sensor support, processing the sound coming from engine, record all data available and repeat engine/ECU work away from the car, etc.
I'm not good with the soldering iron, but I can read schematics.
A20 is not better for what we are doing, in year or two maybe, but not now.
Sharing ideas and "competing" with other Free and Open ECU(and not only) projects is the best way to polish your "product", but everyone should follow his own way. This project have the potential to make engine control logic independent from underlying hardware. I'll test that with the board made by Olimex.
Please, excuse me if I'm missing something

dobrin wrote:Short term goals: Get build environment for STM32F4, get board, start coding and resolving tickets.

http://rusefi.com/forum/viewtopic.php?f=5&t=294 is pretty amazing.