A different approach.

It's all about the code!
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

A different approach.

Post by roflcopter »

First, let me explain a bit of background and who I am...

My name is roflcopter, and I like to race cars. A friend and I decided to make a effort at racing in the LeMons series and managed to get a car and team together for one race in the 2013 season, we also planned to make it to the Gator-O-Rama in MSR Houston but we sadly couldn't get a team together in time. After running our first race and having some troubleshooting issues due to the inadequacy of the engine management system in our car, especially the fuel injection side of things, I decided to tackle coming up with a quick and dirty EFI system to drive our injectors. This systems goal was to reduce the complexity to it's absolute simplest form and thus eliminate the engine management guesswork from our troubleshooting efforts in the future, as well as provide for some form of tuning to take place since we are planning some pretty major changes to the engine over this next season.

The system I've been developing is quite basic in scope compared to the one being hosted here, but Russian prompted me to post up my goals and current state of things to see what input can be gleaned from my approach. The system is based off of a similar board to the one used in rusEFI, it is the STM32F103 chip which is being used on the LeafLabs Maple R5, which can be found at http://leaflabs.com/devices/. My choice to use this board was made because I am fairly competent with the Arduino platform, but I needed something more robust to handle this project, and I like the peripherals available to the ARM platform. This board seemed to be a good idea for the project but actually ended up barely holding up to the final product, more hardware timers and a built-in SPI framework would help with my approach, but I worked around it. I may consider a different board in the future, Silicon Labs has a few that might prove to be better.

I currently have the code in a finished enough form that I was planning on purchasing the rest of the circuit components to make the actual hardware driver for the injectors, as well as the power management for the board. Now that I know that there is an effort such as this out there, I'm almost convinced to just try and help with development on this project. After more thought I think I will go ahead and throw the proof on concept together for my project, just to see if my assumptions are correct and see if it works.

Keep in mind that my system is much more basic than the current forms of rusEFI, although my goal was simplicity. The system in its current form is an Alpha-N based fueling system, which was a choice I made due to the lack of accurate air metering in the intake system that will soon be on our car. It uses only the cam position and throttle position to read from a look up table and establish the correct injector pulse width. I handled all of the timing, including artificial pulse width modulation through the use of 4(because this is a 4cyl) cascaded hardware counters and 3 compare interrupts per timer to handle when to turn injectors on, off, and start the next counter. Quite basic really.

For the future...

-I was planning on expanding the project to handle ignition timing as well, which wouldn't be hard to adapt from the existing injector timing I have.

-A speed-density setup would allow for more precise fueling in cars that can meter air either through a MAF or MAP system, and it's only writing more more module to handle that instead of just using a lookup table(or possibly have both open/closed loop in one system?)

-I had considered having multiple maps for startup, idle, load conditions(much like a 'traditional' ECU)

-Find another board to use that would allow for handling more cylinders, ignition on the same board, etc.

-I still need to add some sort of debugging as well as a way to datalog.

I have attached the source code I have at this point(one file, just the actual firmware that has been flashed to the board, colors and spacing won't copy correctly) and anyone is free to ask questions or offer suggestions. You guys have made a lot of progress in areas I haven't even looks at yet, but from what I have seen there may be some improvement possible in other areas and I'd love to see how I can help out this project. Thanks for taking a look!
MapleEMS.rtf
(5.55 KiB) Downloaded 642 times
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: A different approach.

Post by AndreyB »

Personally I do not have enough experience to say if anything would be wrong with such an implementation. The only thing which comes to mind would be that this way to a bit less precise just because it would factor less variables like outside air temperature - which on the one hand does play a role but on the other hand it stays more or less the same for some regions. Especially for our endurance racing application - the air temperature would chance over the course of a 9 hour race, especially over the course of a true 24 hour race.

I'd say do it and let's see what happens :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

I am slightly concerned about that aspect of things, but this is basically an electronic carburetor at this point, which those are known to get finicky when temperature and pressure start changing, although I'd rather alter a tune than swap jets...

All of those variables can be added in later though, even with only having one lookup table. I don't know how much database experience you have but making a 5-6 dimensional array to store the values in and look them up based off of more sensors shouldn't pose an issue.

One of the easiest implementations of adding in other variables is just to use multipliers... air density changes in very predictable ways in respect to both pressure and temperature.

I was reading through some of your thread on the forum and I must agree with the person who was saying that the joys of the ST architecture is that you have all these fun peripherals to play with, so why waste cycles doing stuff that can be offloaded to hardware and then never have to worry about it again? The system really is not complicated enough to warrant a complete OS to run it. I can definitely tell you are software guy from the tendency to look for abstraction layers through either the OS or threading, which is kind of counter productive with a microcontroller, they're made to do one thing, and do it well.

We really need to talk about all of this, hopefully I'll have some truly free time here soon, just started a new job and am a full time student, so time get's scarce.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: A different approach.

Post by AndreyB »

roflcopter wrote:5-6 dimensional array to store the values in and look them up based off of more sensors shouldn't pose an issue.
A five dimensional array like 16x16x16x16x16 would have 1048576 elements, if each value is a byte that's a megabyte.

A 6 dimensional array of integers would be 64 megabytes. That's all I know about databases :)

And that would also mean you need to dyno 1048576 scenarios of outside temp and atmospherics pressure, that could take a while.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

russian wrote: A five dimensional array like 16x16x16x16x16 would have 1048576 elements, if each value is a byte that's a megabyte.

A 6 dimensional array of integers would be 64 megabytes. That's all I know about databases :)

And that would also mean you need to dyno 1048576 scenarios of outside temp and atmospherics pressure, that could take a while.
Who needs RAM anyways??? The method involving multipliers is much more correct and would be less resource intensive... How much tuning have you done? Because there are easy ways to not have to dyno nearly that many scenarios to come up with the tables, it's all in the math, yo!
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Actually, multipliers would be incredibly easy to implement because dry air can be modeled by the ideal gas law, which means that we could just plug in the values for temperature and barometric pressure and come to a resulting density. Since this is all algebra, it would be fine to have this task as part of the usual fueling calculations.

I do not think that these factors will make a huge difference in the functionality of the ECU though, the actual intake charge temperature doesn't change much once the car is up to temp from my experience, barometric pressure would play a larger role, density and mass are linearly, directly, which means that a 5% change in density, be it from temperature or pressure, will translate into a 5% change in mass of air, which is almost 1 whole AFR point in the wrong direction, so maybe it will cause more issues than I think. 7% is a pretty typical change of pressure from location to location and due to storms and things, so something in that ball park is what we're looking at.
erich
Posts: 21
Joined: Tue Sep 03, 2013 4:55 am

Re: A different approach.

Post by erich »

If you want to keep it as simple as possible how about this:
A simple alpha N table to get it close (+-5% or so)
A WB O2 sensor.
A second table with a multiplier based on a single target AFR from the WB O2 that's the same size as the main alpha N table.
A clamped feedback loop that ticks fuel correction up or down at 0.5% per second with a clamp at 15%.
A warning light that says a trim values has hit a clamp.

There could be some issues with the filtering needing the selected table entry to be a constant for long enought for things to settle but I'll leave that as an exercize for the reader.
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

I had the idea to a constantly closed loop system to begin with, and actually had all the code written to do it, although I wasn't using a separate table for it and that shouldn't be needed. The issue I started to run into when thinking that through was that if the engine is running at high rpm, it takes time for the O2 to actually see the change that is made and report it to the board. I wasn't sure this method would be fast enough or consistent enough for me to run a car at WOT to redline.

Most 'real' ECUs use open loop above a certain rpm/load/throttle demand for a reason, and I am pretty sure that is the reason they do that. Once I get the system together and able to control injectors, then the fueling strategy can get looked at and revised.
erich
Posts: 21
Joined: Tue Sep 03, 2013 4:55 am

Re: A different approach.

Post by erich »

Cars used to run open loop at WOT but they don't any more. Most modern ECUs use a WBO2 because WOT is a tested parameter for the EPA and they can't get away without it.
That's why you can get a Bosch WBO2 sensor for cheap now.

I'd use a separate table for the correction so you can wipe it without worring about your base tune.
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Interesting... the newest thing I've ever looked into tuning is the 2003-2008 Mazda RX-8's and I know that they still use a MAF based open-loop table at WOT above ~4500rpm.

I was worried about the response times between the WBO2 and the injectors, but I guess if that's not an issue, then that's not an issue. I'd love to have a completely closed loop setup, essentially eliminates tuning, just gotta get your algorithms right. I'd be worried about it wandering pretty quickly between lean/rich conditions though, it'd be essentially chasing its tail constantly...

Getting the car running to begin with will definitely be an Alpha-N setup since that's the easiest. I liked the idea of not having to meter air, which a WBO2 based feedback loop would still accomplish to allow us freedom of intake design. I actually have a spare RX8 Bosch WBO2 sitting in the garage, and an RX8 with raw voltage logging capabilities, should be easy enough to map and get working once I get the system working well enough to run a car.
Mr. Wednesday
Posts: 1
Joined: Wed Oct 30, 2013 2:07 am

Re: A different approach.

Post by Mr. Wednesday »

roflcopter wrote:I'd love to have a completely closed loop setup, essentially eliminates tuning, just gotta get your algorithms right. I'd be worried about it wandering pretty quickly between lean/rich conditions though, it'd be essentially chasing its tail constantly...
The theory for doing closed-loop process control right to avoid your "wandering pretty quickly" is reasonably straightforward. It's typical material for an undergraduate chemical engineering course, though the typical chemical engineer may never use it again after school.
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Mr. Wednesday wrote:
roflcopter wrote:I'd love to have a completely closed loop setup, essentially eliminates tuning, just gotta get your algorithms right. I'd be worried about it wandering pretty quickly between lean/rich conditions though, it'd be essentially chasing its tail constantly...
The theory for doing closed-loop process control right to avoid your "wandering pretty quickly" is reasonably straightforward. It's typical material for an undergraduate chemical engineering course, though the typical chemical engineer may never use it again after school.
Im sure it's doable... It'll definitely be something I'll look into once I have it successfully running open loop. What're your thought on the delay between the WBO2 reporting changes and what's actually happening inside the engine? Do you think the feedback loop will be quick enough to accomplish that type of system reliably?
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Not particularly software related, but... ordered the parts to build my injector drivers and power supply just now.

Here's a shot of the schematic, poorly drawn of course...

Image
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: A different approach.

Post by kb1gtt »

I'm not sure the exact intentions of that above posted circuit, it's kind of hard to read. I see some potential issues. It appears you are using a "push" only 5V regulator, and it appears you are using shunt diodes to limit the voltage on the MCU pins. I think your intent is that if you over voltage the MCU pin, it will dump the excess into the 5V rail, the rail you have will then exceed 5V as the linear regulator will only push you up to 5V. To prevent issues you need to make sure your regulator will also pull down to 5V, such that this extra dumped energy doesn't blow the 5V components.

For low side drive using an external TVS diode to limit can be problematic. Using Protected MOSFET's is often better as they are well thermally coupled with the over temperure circuits and such. Also 100V is likely a bit high and doesn't really get you very much. I did a QUCS simulation that helps show some of the stuff that happens with these voltage limiting designs, I created a poorly constructed wiki page found here https://code.google.com/p/daecu/wiki/Injector_driver_theory I would suggest using a 40V OVP MOSFET instead of trying to create that yourself. Also beware the GND voltage lifting, as the GND currents from having several injectors turned on can bring your GND up to the point where you'll have trouble driving the gate. If you have a larger amount of current on the common conductor, it might be good to verify it won't fail when all injectors are around 90% on. As it looks now, you have good drive to the MOSFET, however the MCU pin could still list and create problems if your common is bouncing around.

The MIC4429YN is nice, especially if driving external ignitor's as many ignitors need a push and pull style signal. Injectors are pull only.
Welcome to the friendlier side of internet crazy :)
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Let me preface this with the fact that I know essentially nothing about circuits... but I think I can explain a few choices that were made in this one. The guy who has been helping me on the hardware side of things has been doing hardware design longer than I have been alive, and while I'm more than willing to take advice and criticism, he's never steered me wrong before.

This circuit is designed to control a single injector, from the low side, while completely protecting the MCU from any ill-effects and provide the FET driver with enough current when it needs it. The diodes you are talking about between the pin itself and the FET driver are in fact there to keep the voltage within the 5-0V range that the pin can handle. I believe his intention(if memory serves me well) was that if there was any sort of kickback from the driver, it would essentially get fed back into the current going to the MCU, not back through the pin, and the onboard voltage regulators on the board I am using are supposed to be able to handle up to 12V, so it should be able to handle it? I also know that the voltage regulator that we are using to power the board is taking the 12-13V unregulated current and dropping it to 5V so that the onboard voltage regulators can handle it, and it's rated to 18V for the input side, does that mean that it is pulling it down? Now for the TVS diode being used to limit the MOSFET, I believe he said that the particular MOSFET we are using is internally protected, and he just drew the diode there to demonstrate to me that there was actually some sort of protection going on. The fact that they are 100V was a choice he made, since we had no real data on what the injectors will be using/doing,to go big on that one, and he apparently has used those particular pieces with success before and likes them. The push/pull comment on the FET driver kind of confuses me because it is just driving a FET, not the injector itself, but yet again, I don't know enough to really comment on it.

Thanks for the input, and if you have time I'd love to hear a more in depth(and possible easy to understand) take on what is going on. I'll voice the concerns to my friend and let you know what he has to say as well. I currently have all the components on my desk and will be putting one together tomorrow, I'll keep everyone posted on how that goes and we'll see how it works. I was thinking of writing quick program to just run an injector at 50% duty cycle, at 7500rpm(more than our car will ever see) for a good 10-15 minutes and see if anything has heat issues or whatnot, think that is a good trial by fire?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: A different approach.

Post by kb1gtt »

I'm a bit short on time now, so I can't comment very much. You might find this schematic handy as a reference. https://daecu.googlecode.com/svn/Hardware/trunk/KICAD_Project_TRK-MPC5634_P3-P4-ETPU_IO_proto/TRK-MPC5634_ETPU_IO-board-sch_RA.pdf

Look for U26B on page 3. This op-amp allows me to create a push/pull rail regulator, for up to like 20 to 60mA. This allows the rail stay put if the analog inputs in the top left of that page are shorted to 12V. I also don't like the linear regulators, as they dump a bunch of heat in the ECU which you have to deal with, and they are often not automotive qualified. These switching regulators are dirt cheap these days and far more efficient, so less heat to deal with in the ECU. I'd recommend using an off the shelf switching supply.
Welcome to the friendlier side of internet crazy :)
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

I looked at that circuit, which is if I am reading it correctly... for power regulation to the board?

I really need to learn more about the circuitry side of things... I'm going to test the one I already have built and see if it works, then go from there.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: A different approach.

Post by AndreyB »

roflcopter wrote:I really need to learn more about the circuitry side of things... I'm going to test the one I already have built and see if it works, then go from there.
Do you want to post a picture of your board when you finish it?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Image

*Artist's rendition of my wiring job(note the breadboard it's on!)

Joking aside, I'll post up once I get it hooked up to the board and consolidate my wiring a bit.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: A different approach.

Post by AndreyB »

ROFL :lol: :lol: :lol: :lol: :lol: :lol:
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: A different approach.

Post by kb1gtt »

That artists rendition looks very similar to some proto boards I've made :)

I forgot to mention. In my schematic, the op-amp is powered by U19 on page 1. However any 5V supply would work. The op-amps reference is select-able via P20. I wasn't sure if I was going to want to use a reference diode like ADR5041BKSZ, or if I was going to be OK with a more generic 5V reference. So I used P20 which allowed me connect a wire that I could move around from Vref to Vref. I was fine with using a generic 5V.

The above pencil sketch circuit looks fine, until you get some kind of transient spike. That's when the diodes will dump electrons to the 5V rail, causing the 5V rail to go higher than 5V. Most MCU's are only spec'ed for a max 5.3V some times as high as 5.7V. After that bad things happen.
Welcome to the friendlier side of internet crazy :)
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

kb1gtt wrote:The above pencil sketch circuit looks fine, until you get some kind of transient spike. That's when the diodes will dump electrons to the 5V rail, causing the 5V rail to go higher than 5V. Most MCU's are only spec'ed for a max 5.3V some times as high as 5.7V. After that bad things happen.
By this you mean the actual voltage the chip itself is seeing on the board(after the onboard regulators get to it)? Because the board I'm using is rated to handle up to 12V on the barrel jack.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: A different approach.

Post by kb1gtt »

Correct, the diodes will dump energy directly to the MCU pin, below the 5V regulator. The 5V regulator will pull up up to 5V, however it will not prevent something external from pulling the 5V higher than 5V. When the diodes conduct, the 5V rail will raise higher than 5V regardless of you barrel connector.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: A different approach.

Post by AndreyB »

roflcopter, I think it's about the whatever magic which happens when you turn an injector off.

An injector itself is a coil, and in very plain and probably wrong words - you put energy in to charge the coil to open the injector. When you turn it off, the coil dumps the energy back into the wires so you will get something back into the mosfet and the question is how far this extra voltage would go. That's how I understand the whole issue.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Okay, that makes more sense... but the way he did the circuit, the MCU pin isn't connected to the injector, or the mosfet, it's connected to a mosfet driver that's supposed to 'shield' the board, right? By no means am I saying that's wrong, actually the more I read it definitely points to that being correct, but what're the chances of overvolting the pin when it's only controlling a driver?
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

Or could I alter the circuit so that the diode in question dumps to the 5V regulated rail, not back to the 3.3V of the board, then the 5V regulator would take care of anything going above that, and as long as I made sure to use a 5V tolerant pin(which my board has) then everything would be fine right? It would stay at 3.3V unless something funky happened to the MOSFET driver and it kicked back, then at most it would go to 5V.
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

TTTriple PPPost PPPower!!!

So I have the circuit all laid out and consolidated as much as possible... I can hook an injector up to it and see if it makes it click on and off... but what should I really be testing for? Just run it a while and see if it overheats? Watch voltage with a multimeter on the GPIO pin that it's hooked to? See how fast I can actually get it to actuate consistently? Where is the first issue I'm going to need to watch for?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: A different approach.

Post by AndreyB »

roflcopter wrote:TTTriple PPPost PPPower!!!

So I have the circuit all laid out and consolidated as much as possible... I can hook an injector up to it and see if it makes it click on and off... but what should I really be testing for? Just run it a while and see if it overheats? Watch voltage with a multimeter on the GPIO pin that it's hooked to? See how fast I can actually get it to actuate consistently? Where is the first issue I'm going to need to watch for?
Check if it clicks and check if the MOSFET is hot and check if your boards survives :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: A different approach.

Post by roflcopter »

russian wrote:
roflcopter wrote:TTTriple PPPost PPPower!!!

So I have the circuit all laid out and consolidated as much as possible... I can hook an injector up to it and see if it makes it click on and off... but what should I really be testing for? Just run it a while and see if it overheats? Watch voltage with a multimeter on the GPIO pin that it's hooked to? See how fast I can actually get it to actuate consistently? Where is the first issue I'm going to need to watch for?
Check if it clicks and check if the MOSFET is hot and check if your boards survives :)
Sounds good to me. Hopefully those will all be obvious.

I'm also going to look at current draw from the injector, and the voltage inbetween each component and make sure it's not doing weird things, I think.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: A different approach.

Post by AndreyB »

roflcopter wrote:I'm also going to look at current draw from the injector, and the voltage inbetween each component and make sure it's not doing weird things, I think.
If you would do some PWM your multimeter would get crazy anyway and show something weird in between everything. But I have no clue anyway :( Are you going to stimulate your program with a fake signal & check rpm? in case of noise you would maybe see that your rpm values got f-up.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply