XGATE PIT based bit bang fuel injection

[SleepyKeys]

thx for the fast reply. May I pry a bit more with A2. Does that seem like a sound way to handle it in your mind?

Not sure about the overlapping pin changes though, as in can it happen with proper use and if it does happen how to handle it?

[Fred]

Yep, that's perfectly fine!

Another thing:

At some point we need the ability to update the end of a pulse by bringing it back or forward. This could be done with "if start time is before current end, respect new end even if new end is earlier than old end was" logic.

Useful for improving PW up-to-date-ness and increasing spark accuracy.

Fred.

[SleepyKeys]

100% DC tested and looks good on the scope

Now for events that share the same pin. How do you want PIN respect logic to work?

[Fred]

Cool! But I don't understand your question.

[SleepyKeys]

"At some point we need the ability to update the end of a pulse by bringing it back or forward." -done

What I was saying is that if you have two events that share the same pin you get what each event commands. In other words it does not care what the other event is doing to the same pin. See what I'm saying now?

[Fred]

"At some point we need the ability to update the end of a pulse by bringing it back or forward." -done

What I was saying is that if you have two events that share the same pin you get what each event commands. In other words it does not care what the other event is doing to the same pin. See what I'm saying now?

The two parts of your post seem to be mutually exclusive. The second part says that if you ask for a pulse starting at 1 and ending at 3 and another starting at 2 and ending at 4, then you will just get one pulse that starts at 1 and ends at 4. great. However the second part also says that if you have one pulse that starts at 1 and ends at 4 and another that starts at 2 and ends at 3.5 you'll get one pulse that starts at 1 and ends at 4. Or will it realise that it's internal to the pulse and trim it on that basis? Or, most likely, each pulse has some ID and if you send an update to the same ID, it will reset that ID's end point, I bet that's right. if so, sounds good.

Is it taking into account the input edge stamp yet? If yes, perhaps we should have a call later today so I can grill you and you can shoot me down in flames :-)

Fred.

[SleepyKeys]

1-3,2-4 will yeild 1-4 if 1-3 started running when the request for 2-4 came in otherwise you will get just 2-4. Will that work?

[Fred]

No, I don't think so. It's fine if the only ones that can replace a schedule are ones on the same virtual event. If other ones on the same pin can replace it, then that's no good. Imagine an input event at 1 and a pair of output events at 2-4 and 3-5, scheduled at the same time, or close to it, before both. Both pulses on the pin should remain good and overlap, as their ID's are say 0 and 1. On the other hand if both IDs were 1 and you scheduled it, and in the mean time it changed and you try again, it's correct to replace it entirely updating both ends to be either sooner or farther. And if the ID is 1 and 1 and the first one starts before the second one is scheduled then just updating the end to some new value that is earlier or later is sufficient.

The point is to be able to start a pulse at 1 from an input point at say 0.5 with the intent for it to end at 4 or with duration 3, either, then take more readings and update that pulse for more accurate timing (if it was a dwell) or afr (if it was a pw) close to the end time from a nearer tooth at say 3.5 making the final end point 3.9 or 4.1 for timing or duration 2.9 or 3.1 for fueling. You'll say "yes, that should work" but I don't know if it started yet or not, and as such you need a way of distinguishing between the events on an ID basis as above.

I feel like a phone call is in order. I'm sick, though, and this weekend is meet the parents in Madrid, so I don't know if there will be time before next week. And next week will probably be my funeral! :-o :-)

Fred.

[SleepyKeys]

Yeah time for a call indeed. You should be able to reach me at 100 in about 2 hours.

[SleepyKeys]

DC testing using a POT on an ADC channel.

http://powerefi.com/files/video-2011-09-17-17-01-00.3gp