richyvrlimited

iTrader: (1)

The ignitors provide the voltage/current for the coilpacks to create a spark, but the ECU controls when this happens.

So you need to control the ignition timing.

bloodline

Many thanks all! So the ECU does actually decide the spark time

Also the AVR provides microsecond timers, I think this is high enough resolution for an ECU. I assume that the time between the TDC of consecutive cylinders is 1875 micro seconds (at 8000 RPM, the top of the Miata's engine range), this is enough time to determine the injector time and spark time.

Have I forgotten something?

SlowRider

Have you seen diydrone.com ?

They use Arduinos - and gps and lots of other cool stuff. Check it out. No affiliation, blah, blah. Pretty cheap boards available there.

Actually kind of scary - wouldn't take a lot more effort to make something lethal out of it...

Joe Perez

iTrader: (8)

Over the course of the various mainstream aftermarket ECU projects, the Miata's I/O have been extremely well documented. Some of it I've done myself. There's not exactly one single place to go for all of it, but it's around. What year engine will you be working with? I may be able to point you in the correct direction.


Nope. The ECU asserts a logic high to the ignitor to start the dwell period, and then pulls the signal low again when it's time to fire the plugs. So far as I know, pretty much every modern ignition system works this way. Well, except for EDIS, but that's about as modern as a horse in my book.



So far as I am aware, the MS1e and MS2e aren't even using hardware timers for ignition triggering- they're just doing it in software and bit-banging the outputs. Good enough for a claimed 10us accuracy. Not saying this is the best way of doing it- in the case of the MS, they're reserving the hardware timers for fuel pulsewidth calculation. If your CPU has enough hardware resources to do both fuel and spark with timer interrupts, more power to you.


Analog inputs, PWM outputs, high-precision timers, sounds like the lot of it. When you toss out all the emissions and body-control stuff, it takes surprisingly little to make an engine run. Two crank/cam position inputs, a MAP or MAF input, O2, maybe TPS if you're feeling exotic. Two or four outputs for spark and fuel (dealer's choice), a PWM output for idle control, a couple of relay drivers to control the fuel pump and the fans... Not a lot, really.

I still think you're nuts, but in a reverent sort of way.

sacmiata

I could hardly get my boe-bot (basic stamp I think) to follow the black line....I cant imagine the development time you would need to run a FI motor!

I did one of the MPGuino's for the beater civic to track mileage...pretty cool little toy - but I wouldnt try to make it into a EMS considering my MS-2 was retardidly simple in comparison to doing something like what your considering...but more power to ya if you do

bloodline

My Engine is a stock '91, 1.6 engine. some timing charts would be nice, so I can see when the injectors (and for how long) and coils fire with respect to the CAS. As I understand it, the MX5 CAS has a Single Cylinder 1 TDC pulse and 4 timing pulses for each came revolution. A higher resolution CAS would be nice, but as I said, the AVR (CPU as used on the Duemilanove) microsecond timers so it won't be a problem to get precise timings.

Ah, OK... I think I need a better ECU pinout diagram....

Lol!

The AVR has a nice set of external interrupts, so that is my preferred method. The MS2 is using a variant of the 68HC12, which is a bit stone age compared to the AVR. the MS3 seem to be using a much nicer CPU...

Actually, the project I'm working on grew out of my investigation to replace the throttle cable with a servo... By using a servo to control the throttle, we don't need a TPS (or rather the TPS would be on the Accelerator peddle), the need for an ISC valve is removed also (as the micro-controller can simply open/close the throttle itself, if it needs to.


So far I have identified:

5 Analogue inputs:
1. Airflow
2. Throttle Position
3. Coolant Temp
4. O2 Sensor
5. Oil Pressure (I have a real sender on my car... so might as well use it at some future date).

5 Analogue outputs (PWM):
1. Throttle Servo (which would be the ISC valve on a stock engine).
4. Injectors (though I plan to handle these in a special way, for better accuracy)

2 Digital inputs:
1. CamA (1 pulse per revolution)
2. CamB (4 pulses per revolution)

4 Digital outputs:
1. IgnitorA
2. IgnitorB
3. Coolant fan
4. Coolant valve (not sure if the MX5 has this and instead uses a mechanical thermostat).

The Arduino also includes a USB data link, so you can monitor the system in real time and adjust settings all via a laptop

Well, right now it's just a bit of fun... but if we can make it work, I'm sure we would all appreciate a fully adjustable ECU that could be had for about $60 in total ( the Microcontroller board alone only costs $21 (http://www.dhgate.com/arduino-duemil...9b7174810.html)

Joe Perez

iTrader: (8)

Close.

The first signal gives four evenly-spaced pulses per cam revolution, where each pulse corresponds to one spark event. I refer to this as the CKP (Crankshaft Position) signal, which is also called "Ne" by some people. It's the white wire, which goes to pin 2E of the ECU.

The second signal gives not one but two pulses per cam rotation, of unequal length. I call this one CMP (Camshaft position) and it's also referred to as the "G" signal. Yellow or yellow/blue at pin 2G of the ECU. The leading edges of these pulses are the same, but the trailing edges are different. The rising edge of CMP always occurs while CKP is low. But one falling edge occurs while CKP is still high, the other after CKP has gone low.

Forgive the crudity of this sketch, I took these measurements while the floppy drive on my old scope was broken. It's not perfectly to scale, but the times I've penciled in are accurate:



Traces 3 and 4 are the two spark outputs. I honestly can't remember which one is cyls 1/4 vs. 2/3, but they're labeled "B" (brown wire) and "B/Y" (brown/yellow wire). more discussion here: https://www.miataturbo.net/megasquirt-18/sanity-check-inverted-primary-trigger-required-jimstim-29726/





This is for a US-spec '92:












I would definitely use a hardware IRQ for the CKP trigger. It's probably not necessary for anything else. You can just state-detect the CMP.

Speaking of which, just FYI, the stock CAS is a load of rubbish. Not only that, but since it's belt-driven, it tends to jump around at high RPM relative to the crank. You'll be much better off installing a wheel and sensor directly on the crank pulley.



Intake Air Temp. And if it were me, I'd always choose MAP over MAF/VAF.




Analog? These would all be straight PWM (assuming you use a standard hobby-style servo for throttle, rather than a proper DBW throttle body off something like a Subaru.)




Plus clutch / neutral (if you want it for flatshift / launch control), Aircon (if you have it), and any other zany ideas like table switching.




Coolant valve? I have never seen an automotive engine which used an electronic thermostat. Yes, the MX-5 has a mechanical thermostat.

Also, fuel pump, aircon again, boost control (if that's your thing), etc.



For an apples-to-apples comparison, you could build a Megasquirt 1 for that if you were willing to overlook B&Gs copyright claim and source all the parts individually. I honestly don't think the world needs yet another homebrew ECU project, but more power to you.

JasonC SBB

Yes you do, to complete the feedback loop, unless you use a stepper motor drive.

Will you use it to linearize throttle response or to do traction control?

JasonC SBB

You'll need to implement crank position detection based on constant angular acceleration, or how the MS does it, the alpha/beta/gamma algorithm.

You'll have to think about this scenario:

Say you have a crank tooth at 20* BTDC. YOu know when that tooth passes, you're at 20*BTDC. Let's say at some condition you need to spark at 22*. The previous tooth passed (say at 80*BTDC), and you set a timer interrupt with the predicted time it takes for 58* to pass. Then before the calculated time for 58* passes, here comes the 20* BTDC tooth, because the engine is accelerating faster than you assumed. If the 20* tooth arrives before when you think the 22* time comes, you need to override the wait and spark it.

BTW I think the Parallax Propeller is better suited for this. Multiple interrupts are messy things for real time control. The Propeller is an 8-core uP, which is very fast. It is better to dedicate one of the cores for crank angle prediction duty, one for ignition, one for fuel, and you have 5 more .. than to take a single core uP and make it do all that. It's better to dedicate uP's for single tasks, and to do timing with continuous polling than to use interrupts.

Search for propeller on diyefi.org, there's a guy who's enamored with it, and has written extensively about it.

Joe Perez

iTrader: (8)

If he uses the stock NA CAS, this will never be a problem. There's only one CKP pulse per spark event, and the leading edge of that pulse will always be somewhere in the vicinity of 75° BTDC. So regardless of whether he chooses to assume crankshaft angular velocity to be a constant or actually implements some kind of deceleration factor, there will never be a situation where the ignition countdown starts on one tooth vs. another.


Indeed, the Prop looks like a massively awesome device. Sadly, I've had one sitting here on my shelf for over a year, and haven't gotten around to doing anything useful with it.

One thing I've never been clear on is whether the timing of the hub rotation is completely deterministic. IOW, is it possible for one cog to "seize" the hub, like in the old days of Token Ring networking, when a host failed to pass the token?

On the plus side, you'd have the advantage of being able to code only the "interrupt cog" in assembly, while doing everything else in SPIN.

JasonC SBB

This may answer your Q

http://electronicdesign.com/article/...ller13329.aspx

Joe Perez

iTrader: (8)

No, nothing I've ever read actually seems to describe the mechanism by which the hub services the cogs. At least, I think I'm interpreting the design correctly. My perception is that any given cog can only access main memory and I/O when the hub is pointing at that particular cog, and if this is true (and I'm not saying it is) then I'd love to know exactly what controls the rotation of the hub and whether it's possible for a cog to "foul" the hub.

JasonC SBB

If I understand your Q correctly, AFAIK the cogs can read shared mem any time, but can only write to em when the hub is pointing at it. And, the hub runs independently of the cogs. The cogs have "private" memory.

re IO:

"Unlike many multicore CPUs, this is a microcontroller. The bus doesn't connect to the part's pins so memory cannot be expanded. In fact, other than power and a couple of housekeeping pins, the device has just 32 I/O connections to the outside world. And herein lies another bit of clever quirkiness: each of those I/O lines goes to all of the cogs. If configured as outputs, the result is the logical OR of all of the cog's assertions. If cog 0 sets pin 23 to a zero, and cog 5 drives it high, the output will be high. Odd, huh? But this is a part meant for control applications. If a pin were tied to a warning light, any cog can easily, and without any complex interprocessor communications code, turn the light on."

neogenesis2004

iTrader: (12)

My interpretation of the logical chip diagram is that each cpu has an output register and an output select. The hub connects to all cpu's output register and select. Essentially the hub is just RAM with a built in multiplexer. According to the datasheet, memory collisions on write operations can occur and need to be accounted for in software design. Reads however are trivial and any of the cpus can read whatever is in RAM at any time. Even simultaneously as long as they both want the same data. That was my interpretation at least.

Their high level drawing looks misleading to me. They picture it as a spinning wheel that just goes clockwise giving each cpu a write operation every 8 cycles. In fact an cpu can write any time as long as none of the others write at the same time. So a cpu could in fact just continue to write as long as the others don't need to.

I also noticed that there are no true hardware interrupts built in to the CPU at all. Their reasoning is that interrupts were built for a single core world where you couldn't waste precious cpu cycles constantly monitoring an input. I don't fully buy that excuse, there are many times when a hardware interrupt would be usefull no matter how many cores you have.

As for memory expandability, there is 0 reason you could not hook up an external sram or flash to an i/o pin and just use it as an spi interface. Thats is pretty standard fair for any mcu. Their 32Kb max system ram is kind of a huge joke to me though for a modern 32bit multi core mcu. I also think they are wasting significant resources including a graphics architecture into the chip. Any small modern lcd will have a driver built into it that just communicates serially. Its pretty easy to do and has much higher resolution and color support that way. I'd trade the graphics stuff for more onboard ram any day.

Joe Perez

iTrader: (8)

Ok, did some further reading...

All cogs have shared access to all I/O pins. For pins configured as outputs, the state of the pin is a logical OR of all states being written to it. So if one cog is writing a 0 to a given pin and another is writing a 1, the pin will be high.

It appears that all access to shared memory is controlled by the hub, both read and write, and that the hub rotates continuously, taking 16 clock cycles to complete a full revolution. Here's a note from the Propeller Assembly Instruction Master Table:
So, while there doesn't seem to be the possibility of any given cog delaying other cogs from hub access, there's also no determinism in how long it will take to initiate a shared memory access operation. Shouldn't matter for these purposes.

The lack of an interrupt is kind of weird. Looks like you pretty much have to dedicate a cog to either polling one or more pins in round-robin fashion, or if you need faster performance, leave a cog sitting idle waiting for a state-change on one particular pin. That'd probably be the best thing here. Let a cog sit and wait for a CKP rising edge. When it happens, start a timer, then wait for the falling edge, and when you see that, look at CMP to see whether it's still high or not in order to determine absolute engine phase.

JasonC SBB

"There is no concept of yielding with Spin or cog code. In fact, there are no interrupts. Everything is designed to be polled although it is possible for cog code to wait for a change on the IO lines."

"There are no interrupts: just assign a cog to the activity. It makes you think about a very different paradigm when processors are abundant."

neogenesis2004

iTrader: (12)

I agree with Joe on the lack of interrupts. To me it sounds like they are saying, "since you have 8 cores, there is no need for interrupts because you have so much more resources to waste polling inputs!"

It looks liek I must misunderstand how the hub works. I do not like that it is "spinning" all the time at all. I want complete control over what core can access memory at any given time in my code execution. Multi cores for computing, and memory with a simple memory controller that can handle memory requests so that there are no collisions. A simple request for access and a yes or no response would work. Just seems more efficient. I doubt I would ever choose the Propeller for any projects for myself. Based on the stuff we have discussed and also because there is a distinct lack of low level information on it, even in is datasheet. Not a fan...

Joe Perez

iTrader: (8)

Since we've now dreailed this thread properly, I will share an amusing observation.

Am I the only one who thinks that this business of timing instructions to fit between hub access cycles sounds a lot like some of the old optimization techniques that folks used to pull in the days of drum memory?

The Story of Mel, in particular, springs to mind.

bloodline

Lol... The propeller is a very interesting chip, but things like lack of interupts and other design decisions put me off trying it out... I hope other manufactured try a more traditional approach to multicore MCUs...

Anyway... If I could get back on topic (if only for a bit )... The pinouts and timing diagrams are good stuff Joe, many thanks! I didn't realise the standard engine used a batch injection, I assumed it was sequential

In terms of sensors, I think for the time being it is best to just stick with what came with the engine... though I am fascinated by the MAP sensor, it seems like a vastly superior way to determine the mass of air, but is computationally more expensive (or will require a large lookup table).

I was lead to believe that the CAS worked differently to how your timing diagram would suggest... I was expecting a standard industrial rotary encoder. "Signal A" giving a single pulse for a complete revolution, and "Signal B" giving 4 equal pulses for a single revolution.

This woulds allow me to use "Signal A", to synchronise the MCU with the engine valve positions, and use "Signal B" for timing.

With this assumption, I built a simple mathematical model for Cylinder 1 running at 8000rpm(the fastest the engine can run). In this model I assume the first stroke from TDC is an induction stroke. Also the time taken to complete all four strokes of the engine cycle is 7500 microseconds (1875 microseconds per stroke).

The "Piston Position" curve is displacement from BDC in mm (The 1.6 Miata stroke is 83.6mm).
The injector for this cylinder is held open 1200 microseconds (just as an example, the real time would obviously be determined by the amount of air in the manifold).
The ignitor fires on the timing pulse for the 3rd stroke (just as an example, the real time of ignition would be determined by the RPM).
The other cylinders would follow the same cycle, offset by their respective positions in the cycle



I will attempt to adjust my model to fit with the real Miata CAS sensor :(

Joe Perez

iTrader: (8)

I can only speak with absolute authority on US-spec cars, however I assume UK-spec cars to follow a roughly similar timeline.

From 1989 through 1993, the ECU has only two injector channels and thus uses batch-injection. Injectors 1 & 3 are on one channel, with 2 & 4 on the other. From 1994 onwards, there are four injector channels and injection is fully sequential. (California-spec cars got this in 1993.)

Ignition is wasted-spark in all MX5s from 1989 through 2005, with cylinders 1&4 paired on channel 1, and 2 & 3 on channel 2.



While I understand the general concept of model-based fuel computation, all of the OEM Miata ECUs, as well as all aftermarket ECUs that I am aware of, use lookup tables (with interpolation) regardless of whether you are running Alpha-N, MAF, VAF, or speed-density (MAP). Typical table sizes range from 8x8 to 16x16, so it's not all that large.

To me, this seems much easier to implement (both computationally and from a design standpoint) than trying to model the engine's airflow characteristics into a formula. It's certainly been done, but it's not exactly mainstream.



Nope.

There are some CASs which do work that way- with four pulses per rev on CKP and one pulse per rev on CMP. But all 1989-1997 MX5s use the 4/2 pattern, which is an old Mitsubishi standard, commonly used on the 4G63 engine family. This pattern allows for quicker engine starting, as you only have to wait a maximum of 1/2 cam revolution before you can sync up and start firing the ignition (assuming wasted-spark), whereas with a 4/1 pattern you'd have to wait up to 1 full cam revolution.


In 1999, it got even more complex. The NBs have a cam signal which gives a total of three pulses per rev, and four unevenly-spaced teeth on the crankshaft. Decoding that thing is such a pain in the **** that on the MS1, for instance, the developers simply gave up.

Here's a diagram which shows roughly 1.5 cycles' worth of NA and NB sensor signals, without the ignition signals:




I thought I'd taken one of the injector phasing relative to CMP, but I can't seem to find it at the moment.



Regardless of year, these are all open-collector outputs, normally pulled up to +5. Be aware that they are notoriously noisy and flaky; debounce is of critical importance. The best which I've found for the job is the MAX9924 / 9926.


You can still do this, you just have to look at the relationship between the two signals. Since the two CMP pulses are of unequal length, of the four CKP pulses per revolution, only one of them is going to have a falling edge while CMP is still high. That one is your phase reference. There looks to be about 55° (at the cam) of overlap, so that's plenty of time to poll those events even if you're sampling them at a fairly low rate.