Anyone to waste time on DIY engine control unit? (Page 2 of 5)

Those look like Hall senders in the distributor in the first post. If they are magnetic that's a good hint.

I don't think you want an operating system  in between your coding and the ecu. Any os hiccup means possibly bad things for the engine, a dead engine or a car that won't start. Make sure whatever stuff you use can handle voltage spikes of 80v (starter solenoid collapse spike)

Or I am.    So I guess I should study up a bit more before posting.  Google tells me that the BMW CPS sender I called a hall effect, is actually a variable reluctance as you guys seem to already know.   And, I have no idea what yours is, only that it looks quite different than the BMW CPS.

The RTOS you are using is associated with the board you are using?  Any pointers to info on it?

Thanks.

Russian,
I have lots of experience with the discovery board.
Our car (The Flying Lumberjacks) has a digital dash backed by one.
You can't make out anything but the fuel gauge on video.  http://www.youtube.com/watch?v=KwcOhuL-yRU
What we're currently monitoring is:
  Battery voltage
  Oil temp
  Oil pressure (switch only, no actual sensor)
  Water temp
  Fuel level

There's lots of inputs left on the board I made.  The board has seven analog ins + battery voltage montitor and 10 digital ins.  the display is a 240x64 pixel graphic LCD, it's not great but you can see it in the car pretty OK.  Future upgrades will include data logging to a USB thumb drive.

Looking at your schematic for the input in post #2, your pull up resistor should be going to 3.3v not 5v.  Most of the inputs onthe STM32F4 are tolerant of 5V but not all of them.  There should also be diode clamps to protect the CPU from voltage spikes.  A unidirectional 3.3v transorb is better still.

Once you start using the A/D converters you should note that the reference voltage on the board is 3.0v, the only way to find that is to look at the schematic of the board.  It took me a little bit to find that when all of my sensor inputs were off by 10%.

For something as simple as an ECU I wouldn't bother with an OS, it doesn't supply solutions for any problems you have.  The ST supplied peripheral driver libraries handle setup of the hardware just fine.

Cannot agree with you. It's way easier to program if you have threads, and by using the OS api not the ST api I hope to modify less code when I would need to port my code from f4 to f5 f6 or whatever happens next. I just to not want to hard-code any particular microprocessor.

There is absolutely no use for threads in a ECU.
EVERYTHING will be triggered by interrupts, and the vast majority of output (injectors & spark) by timers.
An ECU is a hard real time problem.  Programming solutions for hard real time systems are controlled by the worst case performance of all operations.  ChibiOS is a 'soft' RTOS, it has no methods for guaranteeing anything, it simply makes a 'best effort'.  Like I said, it doesn't have solutions for any of your problems. 

I understand why you want the OS.  I also know that you will not succeed unless you understand the hardware and know how to make it dance to your tune.   Looking at the ChibiOS section on timers, it doesn't even have the concept of the timer output going to a pin.  Either you need to set that up yourself (straight to the hardware) or a more complicated solution with callbacks triggered by timers to toggle outputs which will also be less accurate.

Granted, the amount of code required to run an engine is tiny and will present no hard real time issues so long as you don't write it in perl :-)

One thing you will need is a better A/D converter for the mass airflow sensor.  They run square law output for linear airflow so light thottle at low rpms will have very little output change.  I'd look for something with at least 16 bits of data.

I've always been partial to Analog Devices and Burr Brown (now TI) data converters.  Good luck finding anything good in DIP, I have a hard time finding anything good these days in anything as large as SOIC.

PWM outputs aren't good for much beyond idle solenoid control.  You need one shots.  Lots of one shots.  Most of the outputs you need to generate are specific length pulses that end at a specified time.  For spark you need an N ms pulse (dwell time) that ends exactly when you want the coil to fire.  For fuel you want a precise length pulse that ends in a specific relation to the valve close event.  PWM outputs generally don't have that kind of control.

If I was building my own ECU, I'd build in ion knock sensing, it's the right way of monitoring peak cylinder pressure and all the cool kids are doing it.  With ion sensing you can even auto tune the ignition timing.  Find out where your engine makes peak power and move the spark around until it lines up.

Very cool. I run an Autronic SM4 in my jetski.

I've signed up on your forum.  I'll pollute that space instead of here :-)

Yea, that would be much more practical for the mower compared to what I did to the jetski.

I'm interested, I'll pm you my email. Of if you want u can create a thread of rusefi.com/forum

This is exactly what I started from, I was using an EEC-IV to look at what strategies are being used and figure out how bare bones I can get.  Which in the end I decided to slim it down as much as possible, then try to add things in later as I run into limits with that plan.

Anyone who wants to look through my code, it's available on Russian's forum and I'd love to hear peoples suggestions and critiques.  My timing strategy is what a poster on here was describing I believe, which offloads all of the timing responsibility to hardware and leaves the processor to do very little work.

I don't know much about tuning, but I know a lot about coding. From what I have seen, it really seems to me that most of the existing things were done by tuners and/or wrenches who have forces themselves to code.

Back in the days of 8 bit 12MHz cpus, it was one thing. Now with 168MHz things I think approaches should be different.

You see, engine size or engine output has not changed much over the last 50 years. What do we have, a 50% gain? a 100% gain in output per cubic inch per gallon? In the CPU universe, the gain is 4000% between the hardware of MS1 and now. The change is much larger and that should not be ignored as it is ignored now.