Decoding Nissan style Mitsi Electric 360 slot cam sensors
Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors
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!
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!
- 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
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
-sean
You snooze, you lose!
Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors
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
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!
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!
- 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
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!
Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors
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.
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!
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!
- SleepyKeys
- LQFP144 - On Top Of The Game
- Posts: 549
- Joined: Mon Feb 11, 2008 10:52 pm
- Location: Arizona
- Contact:
Half Baked Code
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
Reason: wrapped in code block
You snooze, you lose!
Re: Decoding Nissan style Mitsi Electric 360 slot cam sensors
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.
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!
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!
-
- 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
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?
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?
-
- 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
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.
- 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
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
"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!