Decoding Nissan style Mitsi Electric 360 slot cam sensors

For discussing and developing different RPM/Position decoders using our superior modular architecture! One thread per pattern, please.
Locked
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by Fred »

Have fun :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by SleepyKeys »

Started to write code and it seems I should move the 360x to the PrimaryISR. The secondaryISR isn't really needed because the primaryISR can/should handle the state of PT1. Suggestions/comments always welcome.

-sean
You snooze, you lose!
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by Fred »

You could do it that way by just polling pins, but as you know, just polling pins doesn't give you a result that is timed the same as the one that you got from the timer register and interrupt. I feel it would be nice to at least log the edge times of the other pulses too. Up to you though, just mess around till you have something/anything working :-)

Fred
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by SleepyKeys »

Yeah, thats the problem I thought of too. Maybe just a global boolean var for on or off state that is switched by a secondaryISR. Like you said, more tinkering needed. :) Thanks!
You snooze, you lose!
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by Fred »

I'm not sure that actually gains you anything. You can't do much in the 360 isr if anything as there is no time, so you have to do whatever calcs and logic in the other one where there is time. I'm sure you'll sort something out :-)

I'd start by having the isr simply echo the output to those same pins they already do and attach a piezo so you can listen for irregularity and try it out with real signals. Then I'd add more logic to the slower ISR and something simple in the fast one to trigger if/when the count is correct.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Half Baked Code

Post by SleepyKeys »

I thought I would throw this up before my drive home. Comments/suggestions welcome as always.

Code: Select all

/*********************** LT1-OPTI CODE*****************************************
 *
 *         This code will emulate 45 tooth cam trigger(360/8)
 *
 *
 *        Could also add #hi while low low for additional sync checks
 *        Not sure how out of hand I am at this point
 */


unsigned char PT1High = 0 ;  /* the 8x track will flag this 1 on rising and 0 on falling */

void PrimaryRPMISR(void)       //TODO  Make this as tight as possible
{
	if (PT1High)
	{
		Counters.optiHiWhileLoHi++;
	}
	if((coreStatusA & PRIMARY_SYNC) & is on 8th tooth)  //TODO Figure out best expression for this
	{
		void PrimaryRPMISRBranch(void);
	}
	Counters.optiHiResCounter++;
}
void SecondaryRPMISR(void)
{
	if (risingedge)
	{

		Counters.optiHiWhileLoHi = 0; /* clear HiLo counter */
		PT1High = 1 ;
	}

	if (fallingedge)
	{
		PT1High = 0 ;
		if (!(coreStatusA & PRIMARY_SYNC))
		{
			setPosition();
		} else
		{
			checkPosition();
		}
	}

}

void setPosition()
{
	switch (Counters.optiHiWhileLoHi)
			{
//TODO Physically count the number of highs in a low window
//			case  1 : TDC Reference    //not sure if this will be of much use right now
			case 10 : Counters.optiHiResCounter = 60;
					break ;
			case 20 : Counters.optiHiResCounter = 120;
					break;
			case 30 : Counters.optiHiResCounter = 180;
					break;
			case 40 : Counters.optiHiResCounter = 240;
			}
//	set system synced
}

void checkPosition()
{
	switch (Counters.optiHiWhileLoHi)
				{
				case 10 : Counters.optiHiExpected = 60;
						break ;
				case 20 : Counters.optiHiExpected = 120;
						break;
				case 30 : Counters.optiHiExpected = 180;
						break;
				case 40 : Counters.optiHiExpected = 240;
				}
    if (Counters.optiHiExpected != Counters.optiHiResCounter)
    {
    	set system to not synced
    	Counters.optiHiResCounter = 0 ;
    }
}
Last edited by Fred on Mon Oct 20, 2008 11:24 pm, edited 1 time in total.
Reason: wrapped in code block
You snooze, you lose!
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by Fred »

Sean, I'm not sure about the logic etc, but I have a couple of comments :

1) Don't use functions. It should be a simple linear and procedural setup that runs from start to finish in it's natural order. Functions have a not insignificant overhead that is best avoided especially for you with your 360 count :-)
2) Probably don't use the counter struct either as that *may* lead to an extra level of indirection and speed penalty. I'm not 100% sure on that though, so feel free to continue to do whatever you want at the end of the day :-)

For just getting it up and going you'll be fine with both, but for a final solution you'll want to not do those things. As far as counters, we should define some generic ones and use them for all decoders. If you want a more readable name you can start your file with something like :

#define nameYouWant genericName

Keep up the good work.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
deviousKA
QFP80 - Contributor
Posts: 43
Joined: Tue Apr 01, 2008 10:36 pm
Location: Id, USA
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by deviousKA »

SeanK, are you just wanting to divide the 360/1 (or 720/2 however you want to look at it), or are you also looking to have it synced properly?

If you want to have it "synced" to an exact engine angle (for use as primary signal to ems), you will have to decode the inner slots of the CAS as well and use that to sync up your divided output (or use an additional external cam sensor/signal)

Also, you can use output compare mode to shift your divide logic over to mostly hardware instead. Setup compare mode on your CAS signal input pin and have it fire an interrupt after X number of counts (how ever many you need to divide between event, which you could do a variety of diff ways depending on how you manage the synchronization).

Why are you needing to do this though? You can probably find some simpler mazda/mitsu, or subaru CAS disk that can be swapped in?
deviousKA
QFP80 - Contributor
Posts: 43
Joined: Tue Apr 01, 2008 10:36 pm
Location: Id, USA
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by deviousKA »

Firing any sort of software event for each pulse coming from the 360 signal on the nissan CAS is a big no no, imho. The original ecu only uses it for various hardware based counters and compare matches also.
User avatar
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors

Post by SleepyKeys »

This is a sequential system so yes it must be synced. If you look though the code you can see the switch/case, that sets the position after it figures out where it is.

"Also, you can use output compare mode to shift your divide logic over to mostly hardware instead..............." That would be SWEET I'll investigate thanks for the info. Links????

The original ECU had hardware decoding, we don't so I have to do something with every tick of the 360 track. Thats why I figured executing the main loop ever 8 ticks would be acceptable. In the mean time there are very few instructions that get executed 7/8s of the time.


My idea is to emulate a reasonable crank/cam trigger. This will allow minimal changes to be made to freds code.

"Why are you needing to do this though? You can probably find some simpler mazda/mitsu, or subaru CAS disk that can be swapped in?"
I want a PNP system, plus I have had too many people tell me I cant do it.

Thanks,
Sean
You snooze, you lose!
Locked