Mitch_1979

I do have some ideas regarding ways to better generalize my project and roll pieces of it into this one... maybe this could evolve into an Arduino shield providing standalone or piggyback ECU in the same package (to be honest, my interest will be limited if this is standalone only).

Some early decisions though: bloodline you said you wanted the code to be 100% standard Arduino. Is this firm? I'm not sure this will be possible in the long-haul, and I'll suggest you've already strayed from it by tweaking the Timer2 registers. Consider maybe what could be built is an unreadable complicated core [ ], but then a user-configurable header simple enough to allow this to easily port to other vehicles.

2nd pt.; ECU selection. I went right to the Arduino Mega for the additional features. Joe P listed out earlier in this thread all the potential inputs necessary. I haven't gone through a design but I'm skeptical that an Arduino 168 has enough stuff.

3rd pt.; JasonC are you onboard at least as electrical consultant? I managed to come up with circuits that work but I'm not an electrical engineer. What I built works for the 2JZ but I know there are problems I solved in s/w that would be better solved with a better schematic (specifically my lack of signal conditioning on the crank sensor). I think the next challenge will be breadboarding a circuit to hookup with a Miata engine.

...

Shift in topic; you're earlier questions about fuel injectors. Were they answered?
I *think* the Miata has a Peak & Hold injector, which are about 1-2 Ohm. The alternate is a saturated-type (12 Ohm). There are different requirements for the driver circuit for each type... maybe there is a design that works with both (???).

-Mitch

bloodline

The software needs to be capable of standalone operation, and as piggy-backing simply a subset of the total functionality I see no conflict of interest between the two

I am quite keen to add A code path for your 34 tooth CAS, with a simple
Compile time switch.

Yes, the need to modify the ADC and the timer has blown away that goal... I suggest we simply wrap any non standard functionality into a set of clearly documented functions, they can be adapted if need be. It is really the only option, the arduino library does not provide enough realtime functionality.

My code is already at 8k complied, so the 328 is the smallest chip I would recommend (all official arduino boards use at lease that chip so we are good)... The UNO board which I use does have a limited amount of IO, but it dies just about have enough to function (writing a multiplexer Is not difficult if I need more IO), my code will of course work on the mega, that is te advantage to using the standard library over custom functions

I'm a software developer by trade, and hardware is just a hobby... We do need a hardware guy

I think the miata is saturated, and is high impedance so won't burn up if you hold it open for long periods I think Joe posted about this earlier in this thread.

Mitch_1979

Long-time since any progress has been reported on this thread. Any updates worth posting? I've thought a few times on working out a function to read analog data but hesitated because I figured I'd be working with a fairly obsolete .pde.

ctxspy

iTrader: (3)

Hey Mitch, I've been busy with work & family lately, no progress from me I'm planning on getting an arduino sometime early next year.

bloodline

Hey there,

The project is still alive, but I've had to focus on my real life job for a bit as the economy here in the UK has gone belly up. I am having to get everything ready to look for a new job etc... Anybody want to employ me full time on this project? hahahahah

On a brighter note, the last release does work from a theoretical point of view. That is to say that it should hold an engine @1000 RPM, and while it would be lumpy it should handle up to 7000 RPM.

In order to push this project on any further, really we need to interface with a real engine. I have compared my output on an O-scope with that of the engine and it "seems" to be ok.

I'm looking forward to ctxspy getting an Arduino so we can share ideas a bit more, and should allow us to develop the ECU<->Laptop interface to something very useful!

I also hope we can start to build an Arduino/Engine interface... but we can worry about that later

sketchman

Subscribed.
I just thought of this a couple days ago. Glad to see it's already happening.

JustinHoMi

I wish I had time to help with this. When you get to the point where you need baseline fuel and spark maps (afm volts vs rpm), let me know.

rb26dett

OK, guys, bloodline, and mitch 1979, please for the love of god, get these code bases into version control, and get them licensed appropriately! GPL or MIT or Apache or BSD or something good.

www.github.com - post link when done, thanks!

Also, move this into the public domain and out of this purely miata forum, potentially gaining more assistance! Post it on:

http://forum.diyefi.org

no ads, rare moderation, correct target audience, that forum is exactly for projects just like this one.

Here is an example of some aduino based stuff on github:

https://github.com/quan-time/dynofirmware

Fred.

sketchman

^X2
This thing needs to go places.

flyrdm

https://github.com/flyrdm/EngineControlShield

Made for Arduino Mega in shield/stack format. I have two prototypes built
and will send to people if convinced they might do something with it. I put a lot of time and expense into it so far. Sensor reading works. Crank/cam decoding works. Not much else tested or developed. I put this out there to hedge my bets with Fred@FreeEMS and to keep the opensource fires lit.
Cheers,
flyrdm

rb26dett

Ye of little faith! ;-)

That repo isn't much good to anyone but you without a license declaration of some sort in it, you might want to fix that.

Fred.

ctxspy

iTrader: (3)

for the lay-people -- what exactly does it do? offloads some of the lower level stuff into a shield so the main arduino can concentrate on calculations related to fuel, spark, etc?

tomaj

ctxspy

iTrader: (3)

I'm still interested in the project, but my vote is to keep it miata specific for now.. I've seen many projects languish and die in the early stages because people want it to be everything for everyone.

IMHO if you get it to a decent stage running on a miata, people will become excited and intrigued and make whatever changes they feel are necessary to run on THEIR car.. enough of that happens, then you can come together and abstract the differences so that it becomes interchangeable based on some settings vs being hardcoded..

Some people prefer the top-down approach but without a real motivator ($$) and proper staffing it rarely gets out of the planning stages.

Tomaj

flyrdm

The piggyback boards do all the conditioning and driving.
For the the injectors and coils it uses dual (MC33810s?). These are just smart drive chips that can sense over-current, over-dwell, etc. The
NCVXXX is a VR conditioner (cam/crank). I also have a need to sense 6 EGTS so they are in there. Signal conditioning for the 0-5V analog inputs is also included (IAT, MAP, TPS, Coolant, etc). It has the capability to drive 8 coils and 8 injectors or if using less cylinders, you can use as higher current aux digital outs. I need to look at the external DB connector pinouts and make a sheet that describes capability. I haven't played with this in months so I am a little rusty.

ctxspy

iTrader: (3)

When using this shield, what features would the main arduino implement?

In other words, does the shield expose an API and things like fuel & ignition are triggered from a main loop on the arduino, or does it run the execution loop on the shield itself but parameters can be tweaked via API?

flyrdm

The arduino implements everything. Arduino digital and analog I/Os are used to interface with the shields which in turn interface with the outside world. Think buffering/conditioning layer when you think of the shields.

FieldEffectDave

Is it possible to build fast accurate hardware timers in a CPLD device?

http://hackaday.com/2008/12/11/how-t...-devices-cpld/

I am wondering would it be possible if you built something like the above and have the CPLD do the time critical tasks of ignition and injection timing and leave the arduino to read A2Ds perform the calculations for injection time and ignition advance and transfer this to the CPLD. (Maybe with a parallel bus?)

Where I am getting at is you abstract all the timing critical tasks out of the Arduino and leave the "fun" stuff for a larger spectrum of enthusiasts to play with, within the Arduino development environment?

ctxspy

iTrader: (3)

based on the prior pages it seems like maybe the arduino is not the ideal platform for ECU development due to the limited CPU power available.

I've read about the 'netduino' which has a more powerful CPU, more memory, onboard ethernet and SD card. Supports .NET micro framework, event based programming etc, costs $60.

Do you think .NET is too high level to be reliable as a real-time system? I'd be much more likely to contribute to a .net based system as i'm proficient in C#.

JustinHoMi

I think you'd lose developers if you switched to C#. Check out this arm-based arduino clone:

http://leaflabs.com/

kakarot

iTrader: (1)

Its not a bad idea to split the task, but to calculate the injection/ignition takes a bit of processing. Arduino has plenty of HP to take on engine management. My Audi has 8Mhz cpu and fraction of memory that arduino.

It may be a good idea to copy the ArduPilot style of coding. http://diydrones.com/

They do it by splitting the task onto fast, medium and slow. So crank position and ignition is tracked in the fast loop, injection tracked in the medium loop, ignition advance, injector pulse width, MAF/MAP, etc in slow loop.

many tricks can be used to reduce cpu loading, like parallel injection (all at once), combining ignition coils, fire 1&4 and 3&2 for 4 cyl for example.

Also, a friend of mine is doing multitasking on arduino platform, so that is possible as well.

PS, going to read the thread from start ones again.