Arduino as ECU?
#202
http://sourceforge.net/projects/miatabrain/files/
This release is GPL, but I'm open to a different licence if your project needs it.
This release is GPL, but I'm open to a different licence if your project needs it.
#203
Junior Member
Join Date: Feb 2007
Location: 11368 miles from where i would like to be
Posts: 269
Total Cats: 92
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.
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.
#204
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.
And worse, you're doing floating point math in real time, even slower, and probably completely unnecessary.
I have plans for a 100Mhz ARM based ECU, that won't use maps, but instead will algorithmically determine timing and fuelling...
Good luck! :-)
Fred.
Fred.
#205
Junior Member
Join Date: Feb 2007
Location: 11368 miles from where i would like to be
Posts: 269
Total Cats: 92
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.
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...
I have plans for a 100Mhz ARM based ECU, that won't use maps, but instead will algorithmically determine timing and fuelling...
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.
#206
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...
It's all just proof of concept pre V1.0... this is were we clean up the design.
<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.
I've got to pack for a flight. I'm out of this thread for a while at least.
Fred.
#207
Junior Member
Join Date: Feb 2007
Location: 11368 miles from where i would like to be
Posts: 269
Total Cats: 92
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.
Not sure, I'm totally ignorant of engine tuning.
#208
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. :-)
-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!
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.
Last edited by bloodline; 04-11-2011 at 08:28 PM.
#209
Junior Member
Join Date: Feb 2007
Location: 11368 miles from where i would like to be
Posts: 269
Total Cats: 92
That makes sense if you know the dwell time
I prefer to control it in software
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 :-)
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!
"Debouncing" the signal in software is easy if needed
#210
Junior Member
Join Date: Feb 2007
Location: 11368 miles from where i would like to be
Posts: 269
Total Cats: 92
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.
#211
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.
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.
#212
Junior Member
Join Date: Feb 2007
Location: 11368 miles from where i would like to be
Posts: 269
Total Cats: 92
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.
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.
#213
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.
#215
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
Edit: found this... any use?
http://www.filemount.com/pdf/image/l...iagrams-p1.gif
#219
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.
#220
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.
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.