Where can I grab a checkout of the code? And what is the license?
|
Originally Posted by rb26dett
(Post 713074)
Where can I grab a checkout of the code? And what is the license?
This release is GPL, but I'm open to a different licence if your project needs it. |
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. |
Originally Posted by rb26dett
(Post 713136)
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. 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. |
Originally Posted by bloodline
(Post 713139)
No, I'm using interrupts.
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. |
Originally Posted by rb26dett
(Post 713141)
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... 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. |
Originally Posted by bloodline
(Post 713150)
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.
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. |
Originally Posted by rb26dett
(Post 713153)
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. |
Originally Posted by bloodline
(Post 713160)
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 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 ;) |
Originally Posted by bloodline
(Post 713160)
-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!
|
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'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. |
Originally Posted by FieldEffectDave
(Post 712573)
Havn't forgotten about this, just waiting for my OEM ECU to arrive!
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. |
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. |
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 |
Does mbed still require the use of their web-based IDE? I couldn't deal with that....
|
Originally Posted by JustinHoMi
(Post 736185)
Does mbed still require the use of their web-based IDE? I couldn't deal with that....
|
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. |
Originally Posted by JustinHoMi
(Post 736188)
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. |
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. http://www.tincannetwork.com/files/OEMPCM.png |
All times are GMT -4. The time now is 02:16 AM. |
© 2024 MH Sub I, LLC dba Internet Brands