DIYEFI.org Forum

Sean and I have been discussing implementing this for our final injection solution. I thought we may as well document the dev process here. Hopefully the slack bastard actually replies to this one, unlike the loader one ;-)

So, lets cut to the chase!

We need three pieces of software for this:

1. configure the timers and registers and data set for each event required
2. turn pins on at specific times based on timer events and data set provided
3. turn pins off at specific times based on timer events and data set provided

1) Sean is proposing that this run on the xgate, I like that idea. It will need some information passed to it, namely:

• pin number to fire (1 - 12)
• delay after input event to begin pulse (0 - 65535) in ticks
• duration of pulse (0 - 65535) in ticks
• ECT time stamp that the delay is based off (0 - 65535) absolute number - must handle roll over

This code will take the above info from registers populated from the s12 side in a function called by a decoder and setup the data and PIT registers to run the other two threads effectively.

2) fired by PIT timer - reads data set and switches pins ON as per setup done by 1)

3) fired by PIT timer - reads data set and switches pins OFF as per setup done by 1)

Sean, shoot holes in this! :-)

Fred.

My old PIT code did more or less this. The code for 1 can be found commented out in NipponDenso.c and the code for 2 and 3 can be found in igntionISR.c file. This code *almost* worked and worked for a short time perfectly until something went wrong. Something was a cumulative error that built up and then snowballed. I think.

Looking at this code could do one of two things:

A) poison your pure mind
B) help you see some ways of doing the job

It's up to you if you look at it or not :-)

Fred.

Fred wrote:This code *almost* worked and worked for a short time perfectly until something went wrong.

Ain't this always the truth mate!?!

Fred wrote:
Looking at this code could do one of two things:

A) poison your pure mind
B) help you see some ways of doing the job

It's up to you if you look at it or not

Fred.

I'm interested. I always wanted to be a poisoned programmer.

I'd prefer people didn't look and purely came up with their own shlt by themselves. But, feel free if you're not developing it :-)

Fred.

I'll look after I get stuck or fail In which case I will be able to combine info from both. Updating the debs right now.....

Sean0 wrote:I'll look after I get stuck or fail :) In which case I will be able to combine info from both. Updating the debs right now.....

Perfect!

viewtopic.php?f=8&t=57&p=16068#p16068 enjoy!

Edit: As discussed, let me know what interface stuff you need, do your commits, push them, and rebase on top of any minor firmware work that I do as required. Sweet? :-)

So far so good no measurable jitter.
sorry on a mobile phone ill resize later

Wait, what is the Camaro super duper ECU doing on the bench, man??!! LOL :-)

How is that triggered? Is it some how relative to the decoder? Is it just done with clock delays? Is it using the PIT timers? Tell us more :-)

Fred.

I was anxious to get started . It is super though isn't it lol.

This was just some testing I was doing with clock delays. I wanted to see how strong things were. Jitter seems to be pretty much non existent. I'll continue to more on. Keep up the good work on the SM/Cheetah stuff.