rb26dett

Where can I grab a checkout of the code? And what is the license?

bloodline

http://sourceforge.net/projects/miatabrain/files/

This release is GPL, but I'm open to a different licence if your project needs it.

rb26dett

Hi, GPL is fine, but I just had a quick flick through, and there is nothing I would want to use in there, however, I have a question and a few comments:

You're bit banging the outputs from loop code, not using hw pin change + interrupts, right?

You're doing 32 bit unsigned math in real time, this is an 8 bit cpu, right? If so, SUPER slow, but possibly unavoidable.

And worse, you're doing floating point math in real time, even slower, and probably completely unnecessary.

Good luck! :-)

Fred.

bloodline

No, I'm using interrupts.

I'm sure I commented the code, but the timing code in v0.6 is just temporary, I used a log curve (Keeping the spark a set distance from TDC for any given RPM, regardless of load), as I didn't have any timing maps available. This is slow, but all the 0.6 code needs to do is hold the engine at idle, also the Arduino runs at 16Mhz with a single cycle hardware multiply... so it's not as slow as you might imagine

I have plans for a 100Mhz ARM based ECU, that won't use maps, but instead will algorithmically determine timing and fuelling...

Many thanks, I have learned a lot since I released this code... my next rewrite will use a much simpler event model and I now have a real RPM/Load map to use

rb26dett

I see an input ISR handler for half of the CAS, and a timer over flow ISR handler that appears to bit bang ignition pins. IE, I think you're wrong, or at least, misunderstood my question, which admittedly wasn't all that clear.

I don't see any handling of noise on the input ISR, though I didn't study it for long. You need that to protect the engine from damage on a real application.

As for the 32 bit math, it was a divide, so it'll definitely be slow. And the floating point, same goes. I was aware of your lack of tables when I made my comments...

<leading/trolling question>How will you allow users to tune such a thing?</>

With respect simpler events, you should abstract your log calcs out to an output number, then the source of it, and the way it's used are independent.

I've got to pack for a flight. I'm out of this thread for a while at least.

Fred.

bloodline

I can see where it looks like that, the 16us timer decrements the countdowns then checks to see if the countdown is < 0, if it is then it alters the state of the ignition pins. But the countdown is set by the CKP falling interrupt (and again checked on the rising interrupt, which I realise now is being too cautious), so it is event based rather than just banging the hardware... V0.1 busy waited for the CKP... and was really quite horrible.

I would condition the signals in hardware... Unless that's inadvisable? I'm new to the noisy high current environment of a real engine, any advice would be welcome.

I totaly agree, that part of the code does suck for an 8bit CPU, but at 1000RPM, the CPU had plenty of cycles to spare... and my only concern with my V0.x code is to hold the engine at idle... and maybe accel to a few 000 RPM

It's all just proof of concept pre V1.0... this is were we clean up the design.

Not sure, I'm totally ignorant of engine tuning. Studying the standard 1.6 OEM Miata timing map, show that for any given load the spark must be ignited at a specific time before the piston reaches TDC (or after in the case of very heavy, low RPM loads)... My theory is that a good mathematical model of the combustion process would provide the most efficient burn resulting in the most amount of power for any given amount of fuel under any condition... I realise the real world doesn't work quite like theory... and that is why I'm here, to learn from the people who do work in the real world

I look forward to any future contributions you can make.

rb26dett

That IS bit banging... in FreeEMS the hardware changes the state of the pin itself, and then you get an ISR so you can do any housekeeping after that fact. IE, your errors are much larger than your expected 16us as that code could be running quite late depending upon what else ran recently. IE, I'm right. :-)

You have to do both. You'll figure it out. It's more a matter of just saying "no thanks" when things aren't right.

I see tables in your future.

bloodline

I see what you mean, I assume with the FreeEMS, you simply star the dwell and then the hardware fires the ignition. That makes sense if you know the dwell time, your software can account for it. I prefer to control it in software, as for the error in my timings, I have run the output on an O-Scope and I'm not getting any timing errors greater than 16us... That is at 1000RPM... The ATMega is a fast CPU!

-edit- just want to add that the timer interrupt has priority, so it doesn't miss its deadline. The ATMega is much more modern than the 6800!

"Debouncing" the signal in software is easy if needed

Well, I have a starting table now, that I fully intend to be user updatable via serial/USB

rb26dett

HW starts the dwell too.

Which you must, because you're controlling it.

You might, but it will always be inferior.

You have only a fixed number of reference frames and you get no further information that would influence your decision in between them and the output event, whether it be dwell start or firing. Thus you can't do any better by watching and pouncing just as the hw would do for you, only worse due to latencies. For reference, FreeEMS has 0.8us granularity. MS2 is 0.6666. You're >=20 times worse than FreeEMS at output accuracy, before you start. Does it matter? Not at idle, no :-p :-)

Get back to me when you're turning 10000rpm with full noise checking and other functions, then we'll talk about what is and isn't fast.

We'll see about that.

rb26dett

Great, but can it do nested interrupts? If not, it will still miss its deadlines sometimes. The FreeEMS MCU CAN do nested interrupts but I have it off because you can easily run into concurrency issues if you do that. We'll be using our 80MHz co-processor to do bit bang on fuel with circa 1us accuracy.

bloodline

Does the freeEMS require the use of a better (higher resolution) CAS than the stock Mazda one? As that is the only way I can think you would be able to get the accuracy you are claiming? I'm working with an event model that gives me one falling and one rising int per half a rev...

I agree with your points, and I do need to do some real world testing, keep in mind I'm not trying to make a high performance ECU yet... I just want to get something that works (hopefully as good, if not better than the OEM unit) so I have a known good starting point.

rb26dett

I'm not claiming accuracy of output events relative to when you command them, angle wise, I'm claiming accuracy of input readings, and accuracy of output events relative to when you command them, time wise. Without the latter, you can not have the former. IE, such resolution is important no matter what the input style. You might want to think in percentages more.

http://www.google.com/search?hl=en&q...&aqi=&aql=&oq=

your angle error minimum at 8000 rpm, which is a very attainable number for a miata...

As it happens the FreeEMS architecture does not force any input pattern, it is a plugin architecture, there is one for the 4and1 CAS that I used on my 400hp truck, and I've got a 90% completed Miata/MX5/DSM/Mitsi 4and2 one in the wings ready to roll.

bloodline

Hey Dave, any update on this?

I managed to get another job, so I was able to turn my attention to this project again... Since I can't take the Arduino any futher at the moment, I decided to work on my Mbed (http://mbed.org/) port.

The MCU is vastly superior to the Arduino and the low cost version (the LPCMini - identical except has no ethernet) is about the same cost as an Arduino.

As this is a 32bit 100MHz MCU, my ECU design is much cleaner and has none of the very tight timing limitations of the Arduino. It's really a fun little board.

FieldEffectDave

I think there was some postage difficulties and I am still without an ECU.

I might just buy one from a wrecker in the UK.

bloodline

No worries, I'm having a lot of fun with the Mbed version of my ECU. I am having no problems meeting the timing deadlines with this platform... I might consider the mbed my primary platform for this project.

Edit: found this... any use?

http://www.filemount.com/pdf/image/l...iagrams-p1.gif

JustinHoMi

Does mbed still require the use of their web-based IDE? I couldn't deal with that....

bloodline

Yeah it does, total pain in the ****... but it is quite easy to set up a gcc build chain using their precompiled mbed library... I'm quite comfortable with it now as the ARM guys are very active on the forum and often offer low level advice

JustinHoMi

That's the other thing -- you can't view their forum unless you've purchased an mbed controller! Phhh.

Sorry for the complaints, but those are two very stupid things.

bloodline

I agree these seem restrictive to those of us used to the openness of the Arduino (and believe me, I'm still very much an Arduino fan!)... But keep your eyes open for the LPCmini, it's an opensource Mbed clone (it lack the mbed's built in ethernet interface, so it quite a bit cheaper), and that coupled with the gcc build chain make an interesting and very competitive alternative to the Arduino. I should note that the LPCmini can be flashed with Mbed binaries and works fine.

FieldEffectDave

It's only a 2 layer board which makes it very easy to follow tracks, but there are alot of components on the board which I cannot find datasheets for.

I started with the injector drivers, I can trace them back to the "MP493". I think this is an ASIC (a chip NipponDenso designed for themselves), so it might be very difficult to get a datasheet to understand what it is doing.

I could only guess that maybe there is some current sensing / diagnostic circuits which is why there is so much hardware between the uC port pin and the injector driver.

Maybe with a full bench setup running the ECU you could probe with an oscilloscope and intuitively try and figure out what this chip does and what the pinout is.

Definitely not as straightforward to reverse engineer as I was hoping.