If I wanted to take an Arduino ARM (for some serious power), this is the board I would use :) the NETduino is not great for embedded development, I certainly wouldn't go near C# for this type of work. I already consider the C++ subset the arduino uses a little too high-level ;)

My current ARM platform is the lovely mBED, but that is another project ;)

I've not used CPLDs, but I did think about using an FPGA... Bit really once you go down that route, the project needs more advanced soldering and multilayer technology.

Ideally the custom electronics should be no more than a simple board with a few discrete components that sit between the miata ECU plug (engine side) and the Arduino :)

I totally agree than we need to move the project to GITHub, but as I'm currently Job Hunting I'm not able to spend any time on this project. Also I want to freeze the current code base, as I think I've come up with a much better way to implement it. My current timing model is a little too complex, and I think we could actually use a much simpler one freeing up a lot of CPU time :)

I local garage had a '93 MX5 write-off in and I picked up the ECU for £20. My car is a '91 but I think the computers are compatible... This ECU is a B63H... I figured that even if the board was not compatible I would at least have an ECU Plug that I could use to make an Arduino->MX5 Loom adaptor.

But opening it up, it seems I lucked out! Someone has socket mounted the CPU (and mounted a Turbo daughterboard- Help identifying this would be good)... So If I could figure out the Pinout of the MX5's CPU I could interface the ECU with the Arduino much more simply and get some real world testing done.

I am aware that the CPU is some custom 6800 (Marked MP5270 in my attached photo)... but trying to find details of it is hard.

-Edit- All the chips on the daughter board have had their markings blacked out, I have tried to remove the ink, but to no avail :(
-Edit2- Googling around suggests the CPU might be a MC68HC908AP64... reading the datasheet now...

Screw this, mannnnnnnn, swap in a 4and1 disk instead of the DSM style disk and you can run FreeEMS RIGHT NOW :-) On a 4 cyl you can run wasted spark and sequential OR COP/CNP and semi sequential/bank injection. In a few weeks I'll have added the DSM/Miata decoder and you'll be able to run them like that without the disk swap. On any hardware you want. Without restriction. Free. Libre. Gratis.

Fred.

If they really wanted to run something off the shelf or somewhat ready, they would have installed a PNP Megasquirt or assembled a DIY V3 board and they would be golden by now. The point of this thread is that they want to do something completely on their own.

Urr, which drugs are you smoking dude? Next time I'm having a bad day I'd like to be that far away from the truth. There is nothing off-the-shelf about FreeEMS, what-so-ever, it's 100% DIY... to the core, to the grave.

Do you have to write the code for it? Is it *THAT* DIY?

I'm not asking if you can, for free, unrestricted. I'm asking if you *have* to. As Reverant said, it wasn't about installing someone else's work on their cars. This is about building something completely from the ground up 100% on their own.

Now take your shitty attitude and go fuck yourself with it.

You know, I was going to tear you a new arsehole, because you need it, BUT, then I saw your sig and decided you can't be that bad after all, do pull your head in, though, before it gets knocked off ;-)

Fred.

PS, you may have mistaken me for a noob, think again.

:laugh:

E-thug is thuggish.

Well now, I'm sorry I injured your sensibilities. I know who you are. I've been following the DIYEFI thing passively for a while now because I'm interested in seeing where it goes and I may yet give it a run some day if and when megasquirt stops being interesting to me. Don't make the mistake of thinking that I'm insulting your abilities. You made a dick comment, you got a dick response.

No, not at all.

Thanks for that, I quoted you elsewhere, I hope you don't mind. I need to document the process that you're at the beginning of for the benefit of others. I find MegaSquirt* incredibly dull, because I understand it on every level. You'll have your epiphany eventually, don't worry :-)

No, not sensibilities, nor abilities, nothing injured or insulted.

Bingo, here is the part that IS confusing, I didn't! I'm not sure what you read or thought you understood. Whatever it is, though, it's irrelevant.

The only "mistake" I made here is believing that this behaviour from you both has anything to do with forum social pecking order, which can't be argued, because it is purely subjective.

Fred.

Oooh, that's interesting. I've never seen that daughtercard before. The only one I've seen before this one is the board from Grid in Japan (http://www.grid.co.jp/direct/direct150.htm).

The only other thing I can tell you about that ECU is that it's not a USDM one. There's no barometric sensor. I know the Japanese ECU's don't have barometric sensors, but I don't know about the European units.

AllData may have the stuff you looking for. Next time I get a chance to play with one (during this week) I will search for it.

After reading the datasheet, it looks like the 68HC9 is a pretty standard 6800 in a 42pin package with a bunch of GPIO and 8 analogue inputs.

Now a question for the hardware guys, if I remove the CPU (and the daughterboard), then test the signal between a pin on the ECU plug and a pin on the CPU socket, will I be able to see what is connected to what... Given the very small amount of logic on the mainboard and the high IO count of the CPU, I am going to assume that for many pins there will be a 1:1 relationship between at least some of the signals on the CPU plug and the ECU plug... Can I assume this? Really, I would prefer if someone had a schematic for the ECU... Any joy?

Its not really that easy to determine by simple probing: EG inputs might have common pullups, which means simple probing would find they are all sort of connected together. Output drivers are not going to have a testable connection between the uC pin and the connector pin.

The best way is to slowly work backwards from the ECU connector and reverse engineer the complete schematic.

I actually was planning to do this for the whole ECU anyway, mainly because I am interested in comparing the hardware input / output circuits and components we use in megasquirts to what was chosen for the OEM design. (And compare design margins etc...)

Should receive an ECU any day now hopefully and I will start, ill will take a photo of the PCB when I get it, I wonder how many variants of ECU there might be and how much they will differ internally?

I've spent a little while reverse engineering some of the circuits. You do have to be careful "copying" circuits from the OEM ECU to the megasquirt. You have to take the entire MS as a whole, and realize that there's more to it than just a bunch of individual circuits.

For instance, the OEM ECU uses a 10k resistor along with two caps to filter the AFM signal. The megasquirt suggested circuit for a MAF is a 2.2k resistor and two caps. If you compare the circuits you'll see that the OEM circuit has quite a bit more smoothing, which makes sense. However, if you look at the datasheet for the megasquirt's CPU, you'll see that they warn against using any resistor 10k or higher on the analog inputs, otherwise it could affect the timing of the readings.

Yeah... I kinda figured as much...

I have no experience with hardware reverse engineering :(

You could well be the saviour of my project then :) As long as your ECU uses the same CPU, I'm gonna guess the IO is going to be the same (or similar enough for me to have a good starting point) as my ECU.

If I can help in any way then let me know.

If I can use my spare ECU as an interface between the Engine and the Arduino, I can do some real testing of my software :)

I removed the Daughterboard to see what was underneath. Here is a photo of the main board, the socket is where the CPU goes... and where I want to attach a new Microcontroller, probably on a new daughterboard ;)

Havn't forgotten about this, just waiting for my OEM ECU to arrive!

Cool! I'm busy with real life so no rush yet ;)

I'm rather keen to rewrite my code using a simpler timing model!

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

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

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.

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 :)

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 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.

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.

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 :)

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.

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.

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.

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.

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....

Yeah it does, total pain in the arse... 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 :)

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.

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.

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

Looks very similar to my unit, a few different transistors but all the major components the same.

Those Denso part numbers threw me off too, firstly trying to indetify the CPU... I'm guessing the Denso ICs are probably standard components but from special batches that meet the Automotive spec... As r26det has alluded to above, the ECU doesn't "bit bang" the signals... So these are probably just simple, counters, shifters and buffers etc... If you can detail a schematic, I reckon their function could be determined by logical deduction (if you excuse the pun) :)

make sure to figure out the alternator circuit, or car will never have any charging capability.

Only relevant on a MK2. MK1 alternators internally regulate.

just a question of simplicity and curiosity.

i was wondering if the audrino unit is outright limited with all of it's process function. maybe it would be a better idea to make it do a little bit less as well. the biggest and obvious reason why audrino is considered is simply it's price and adjust-ability.

everybody and their mother pray to the heavens for a way to upgrade their injectors and get rid of the afm with some kind of fuel control.

wouldn't it be easier to hook up a Map, IAT and an RPM Source to create and emulate the AFM signal source outright. in essence copying what the E-manage Ultimate can do.

the AFM Voltage reference has also been documented as well right?

couldn't we just create a voltage table graph based of the AFM to modulate our injectors? i mean just a suggestion as to keep the cost down and keep the coding simple.

Just my perspective here:

But I think the point of the Arduino ECU is that it is a project in itself, not really intended to compete with the really well established existing solutions on a 1 to 1. More about the journey than the end.

It's like the "hello world" of engine ECU's the code will be an interesting and hopefully easy read for people who want to learn more about how an ECU works.

Maybe something that deserves its own thread, but I was shown an article in a magazine where the a MAP sensor and a simple inverting op amp circuit was used to substitute the AFM for a carburettor converted MX5. (so the standard ignition system would still work)

I didn't believe it could be that simple so I wired the OEM AFM to a spare ADC on the megasquirt, did some drives and used the collected data to make a curve. This is what it looks like: (I think with some averaging / smoothing applied. I need to search for the origional files.)

http://www.tincannetwork.com/files/MAPvsAFMloads.png

http://www.tincannetwork.com/files/M...0AFM%20ADC.JPG

It is almost a simple curve to match, except for the hump.

I made it so long ago I can't remember the conditions which caused the hump at below idle MAP and zero air flow.

I think the issue was around 30kpa you could not tell the overrun condition from idle or similar. Maybe this could be fixed with an RPM input as well.

If there was interest and with some more research could be definitely worthy of a (seperate) project. A box which connects to the AFM plug, with a map and air temp sensor going in for a plug and play AFM deletion.

i found a link where someone had previously attempted a conversion for Afm to map through this link

http://www.my-acoustic.com/Car/ECU/a...afm_to_map.htm

he got for the most part the voltage inversion correct however. through his design wasn't able to solve the main problem with part throttle acceleration. he was literally trying to match voltage range with no other support that's it.

His design didn't have any algorithm correction, rpm input or the hardware to support voltage adjust-ability.

if a "PNPAdurino AFM Eliminator" is to be created there is going to have to be some standardization to be put into place in order to proceed before we even bother trying to attempt to write code.

the first pieces that we need to know are what aftermarket parts we would use. i would assume we would use the MEGA Squirt MPX4250 2.5 Bar MAP Sensor $28 and the replacement IAT sensor and bun MSPNP and DIYPNP IAT Sensor Kit $29.

would bring total costs to $113 + whatever a AFM harness adapter would cost to buy. if if you really did need it plug and play.

also data-logging will be required to map the Voltage curves (which apprantly fieldeffectdave already did) a mathematical conversion Algorithm must be created in which audrino has to convert on the fly.

then last but not least after we have a stable unit working on an Naturally aspirated vehicle. a tuning program must be created so that bigger injectors or boosted applications can be supported.

then it's cake.

(btw if PNPAdurino AFM Eliminator is made let everybody know i coined the term)

Something will need to be done about acceleration enrichment too. I don't know that the ECU itself does AE... I think it's built into the AFM. Look at the brief spike in the graph right after tip in. This is the flapper overshooting the target, and then settling back down... it's a purposeful part of the design.

FYI, I have the AFM attached directly to my megasquirt instead of a MAP sensor, and no AE is required.

the rpm enrichment is probably a mechanical design. the wind that is passes through the afm will kick back the plate initially further then the air that is passing through was suppose to be at. it's all inertia i would assume. because it levels out real quick

i'm mean we are talking about a small albeit minor flac that the afm

also a question for whoever had made this graph... did you swap into a full range tps? also can you get us a read out of what it looks like to be 3 k rpm 5th gear cruising down the freeway. i think that's the most important thing about our cars.

ugh.. i just spent the last 3 hours trying to figure out how we could get "ideal gas law" to work with adurino

i was also looking into how map-ecu does it with their setup and it requires tps, rpm, iat and map sensor for it to take over. obviously without the mathematics i couldn't know how they came up with their solution to do the afm crossover.

does anybody in collage and has free time to solve and plug in this equation

"PV= nRT"

P = Absolute pressure
V = Volume of gas
N = particles in the gas
R = 8.314 J·K−1·mol−1 (<------ yea baby no idea what this means.)
T = Absolute Temperature Measured in Kelvin Scale

anyways the way i look at it. if we have a way where we could plug in our motors displacement (1.6 or 1.8) multiplied by the rpm and let it be adjusted by the manifold absolute pressure.

we would get a Volume constant. this could be in turned converted over a voltage reference to which we can apply as our afm signal.

at least i think this is how it works.. my brain hurts anybody good at math. again i know im not taking into account heat, nodes and density but fuck i can't math nor do i think anybody here would want to write a code to handle gas law outright upfront.

we just need to find a volume constant and graph the correlation accordingly. hopefully by then we could get a way to include other sensors to get a much better resolution.

plz anybody else help fill in.

Hi blade8r,

Yes, FieldEffectDave is bang on! The idea of the Arduino ECU is an attempt to get a basic, low cost, easy to understand ECU design working. I want the source code to be easily adaptable to other micro controllers... And indeed I have ported it to the mbed micro controller board and with the mbed (100mhz 32bit) we can do more exciting things... Like mathematically modeled fuel and timing control, rather than precalculated look up tables! As you have alluded to in your posts, this also seems to interest you!

Have fun,

Matt

Hey blade8r,

Your "R" term is more commonly written as k, it's the Boltzmann constant. And yes my degree was in chemistry so I do know how to use these laws :) but going this way is probably not a great idea... My preferred method is to base my mathematical models on real world measurements...

We would run the car up on a dyno, then measure airflow, engine temp, air temp, fuel amount, power output, speed, etc... and adjust the variables and plot the results against each other, wean then use this data to determine the ideal settings for the desired output... Eg performance vs fuel consumption. A "best fit regression analysis" would then be used to determine the equation of the graph! With a nice powerful CPU (ie the mbed), we can use that equation rather than a table... A table is a good trade off, but it's not as much fun ;)

An easier method is to not worry about MAF, and use a MAP, can get those for under 20 dollars. But, worry about individual cylinders and then worry about system in total.
Anyways use density fraction and then apply that to calculating the mass of air that goes into 1 cylinder of the engine, from there you get how much fuel needed and with some other simple math you figure out the pulse duration. From there you assume that each cylinder is the same, and go from there.

Tip in enrichment, you can get from engine acceleration, if you apply another equation, linear, to the standard equation of fuel calculations, you will get that spike. It is multi-variable, and should be looked in 3d instead of 2d. You wont get the spike if engine is spinning high rpm and its accelerating up a bit, but you will get it if engine is at idle and its spinning up rapidly. Also time decaying enrichment can work. Instead of time I apply engine cycles, it makes sense to me, not sure about anyone else.

Arduino is plenty powerful to do what ECU needs, it requires ingenuity and cunning to get the code compatible with arduino. Think how they did it long ago with EFI.

Dear Blood Line

you should of just mentioned that you got the audrino code ported already into mbed or LPCmini. it would of saved me a few hours outright instead of trying to pull my hair out trying to think of a way to come up with a conversion table.

i honestly didn't want to do a afm to maf conversion. however i figured the adurino side of things is dead and i thought you wanted the mbed project to be something that was your own. i just want simplicity in a box for everybody in the miata community or any other community that is plagued by an afm. i think we all want that.

but seeing as i can't code at all. there is little help i can provide other then real world testing. so i can outright buy an lpcmini or mbed i think it's the only bet i can go with the project. but at least you guys will need to come up with a good working code.

i have completely stock car and i have some time and i can solder. lets do this.

You haven't wasted any time, always start with the Arduino, since that is where I want the base to be... Once programmed the ATMega328 (the microcontroller at the heart of the Arduino) can be bought for £2! That is the key to producing a low-cost Miata ECU replacement :)

While I love the mbed, I always try to start with an Arduino... Then move to the mbed if I need more power.


Well, let's see how FieldEffectDave gets on... If he can put together some good schematics I hope to be able to do some real world testing. I won't drop the Arduino as the base platform, but I want to offer more advanced features with the mbed. :)

Everyone

Thanks for your investment in time and skills. I'm building a hill climb race car with 1/4 of the motivation being racing the car and 3/4 being the fun of the build experience, and hope to use an ECU like the one described here. The idea of using an arduino with the appropriate "shield" on top of it is just wonderful.

Does anyone know why do so many race engines use a single, relatively fine toothed crank angle sensor with only one channel (a missing tooth indicating the "home" position)? Racing engines can achieve terrifying rotational accelerations and I fear a Miata with a very light flywheel can too. Thoughts or comments?

Also, any plans for wide-band O2 feedback into the algorithm?

Watching the progression of this thread has motivated me to attempt to undertake my own pet project:

https://www.miataturbo.net/attachmen...ine=1319249129

I don't expect to accomplish anything huge, but I've always wanted to play with one of these.

hey guys i'm glad this has spawned such interest.. I'm still arduino-less, though i'm one step closer, having just ordered a Pololu servo controller for an unrelated hardware project i'm undertaking.

In the meantime i've read a lot more about Arduinos and learned a bit about its capabilities as well as the numerous shields, components, and kits out there..

That, combined with the large install / user base, I'm sure there's a real opportunity to create something big here.

good luck guys

A 40 pin DIP whose marking cannot be read due to the blurriness of the photo?

Looked good on the phone :facepalm:.

Its a propeller.

There were two existing propeller ECU projects, but one found out about the other and stopped. Such is the hazard of doing something because it's cool/unique to do, I guess. The other is functional and available afaik.