Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
We have heaps of timers now. We are requesting suggested usages.
#1
Thanks to the new Xgate code, we have 8 free timers of which an engine typically only needs 1 for crank and 1 for cam position(some use more). The rest are fair game for capturing other vital data. Below is a skeleton of potential functions that need precision timing in order to be of any use. If anyone would like something added just post it here.

So far we have:

*
* General purpose capture ISR
*/
void gpcT7isr0() {

//TODO use a configurable function pointer so that a user may execute more than one desired capture function

return;
}

void readFlexFuelSensor() {

}

/* Return vehicle speed */
void readVehicleSpeed() {

}

/* Capture the angle at which a rising or falling edge occurred. Useful for copying OEM timing tables etc */
void captureAngle() {

}
Reply
#2
(10-13-2014, 09:08 PM)seank Wrote: Thanks to the new Xgate code, we have 5 free timers(out of 8) for an engine that only needs 1 for crank and 1 for cam position(some use more). The rest are fair game for capturing other vital data. Below is a skeleton of potential functions that need precision timing in order to be of any use. If anyone would like something added just post it here.

So far we have:

*
* General purpose capture ISR
*/
void gpcT7isr0() {

//TODO use a configurable function pointer so that a user may execute more than one desired capture function

return;
}

void readFlexFuelSensor() {

}

/* Return vehicle speed */
void readVehicleSpeed() {

}

/* Capture the angle at which a rising or falling edge occurred. Useful for copying OEM timing tables etc */
void captureAngle() {

}

What are the intended constraints? i.e. is this only for high frequency or high precision stuff, that the regular s12x core can't or shouldn't do?. Can these timers do only input capture or output compare or PWM? How many timers are available on the s12x core, can both be used simultaneously?

Some things I can think of are VSS (vehicle speed sensor(s)), ABS Tone rings, old ford MAF's (PWM output versus analog)

Whacko idea: Could they be used for a parallel install (i.e. piggyback) to measure oem drive signals (i.e. Logic Analyzer mode) for things like injector PW, ignition drive signals, dashboard drive signals, etc, as a way to capture a datastream in order to reverse engineer a running system?
-- David
Reply
#3
I vote for a <=10Khz capable freq input. Hitachi MAF's are a dime a dozen from Denso systems.
Reply
#4
You should take a look at the timer function block to see what it can and can't do, in the end it's pretty capable.

The constraints/requirements are anything that's not a slow moving input(toggle switch or similar) or an analog voltage(we have plenty of ADC channels). When you mention cores it sounds like you are referring to pin polling, which is an option, but I think it's best to stick to using the hardware, until the resource is exhausted. Nevertheless, we still need to handle the ISR that the hardware generates. I suppose depending on the application, we should consider using Xgate for certain GPC routines.

Good ideas:
VSS = S12 almost certainly
ABS Tone = S12, Xgate and/or PulseAccumulator, I think those are high-res but slow reving.
MAF = Xgate and/or PulseAccumulator, thanks essess for providing a target.

I don't think those ideas too Whacko. OEMs have put a lot of resources into their data, sometimes it's nice to take a peek.

Depending on the application we can utilize the PulseAccumulator function of the timer to remove the need to fire an ISR on every edge.
Reply
#5
essess, any chance you can drop a couple links about the frequency range of those MAF sensors?
Reply
#6
No links, 10khz is the limit from memory. They're also used in a lot of GM's too.
Reply
#7
   

It seems that your memory is pretty accurate:

I think it would be wise to try to utilize the PA for this. Using the PA will have an averaging effect, that's likely a good thing.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)