PULSOUT emulating phase shift

[lwindridge]

As part of my project to build a timing controller for my car (taking reading from a crank angle sensor, then delaying the pulses using the pic) I'm now working on getting the pulses out.

I'm taking my reading and know the rpm and therefore the pulse high and low that I should be generating so that's not a problem.
I seem to be having a couple of issues at the minute though.

I'm trying to emulate and approx 800rpm pulse (2 pulses per rev at about a 45% duty cycle - 26 pulses per second).

This is working fine using the pulsout command and using pauseus to work on the dwell of the pulse.
What I can't quite get my head around is how to delay the phase of the pulse - if I put a delay in each cycle it will alter the pulse time not the phase.

Should I be doing this another way (ie using PWM) or do I just need to restructure the code a bit more?

Here's a simple graphic representation of what I'm trying to achieve...

Pulse in - ____###____###____###_
Pulse out - _____###____###____###_

So say I want to delay the pulse train by 22uS I need to alter the pulse start time by the appropriate amount.
This needs to be done on the fly and adjust the phase according to variables taken by my other code which reads the RPM and other engine factors so the higher the airflow and RPM then the more the phase will be delayed.
I've generated a table to look this up and that is working fine, I just need to convert the looked up level to the phase delay.

Hope that makes sense anyway.

Leigh

[Melanie]

You have a slight problem here.

In it's simplest for this will delay (Phase-Shift) the output for a period in mS equal to the variable PortDelay

PortDelay var Byte
PortFlag var Bit
PortStatus var Bit

PortDelay=50
PortFlag=0

loop:
PortStatus=InputPin
If PortStatus < > PortFlag then
PortFlag=PortStatus
Pause PortDelay
OutputPin=PortFlag
endif
Goto Loop

Now this is fine for slow delays in mS, but switching to uS, you'll find that your accuracy is hampered by your own PIC's processing speed adding a few uS here and there. There's no way that the same PIC that is doing your number-cruching and LCD Displays will have time to perform a background task that needs to accurately time-delay a Pulse in low uS counts. To do this digitally in uS without introducing processing delay errors looks like a job for a dedicated Programmable Delay Line....

[Darrel Taylor]

Hi again Leigh,

Sorry, my other project took me longer than expected. Now, back to yours.

Not to worry, this is very doable. But, it has to be done with a little assembly language and some interrupts. The main reason I took you in the "Capture" direction for the RPM in <a href ="http://www.picbasic.co.uk/forum/showthread.php?s=&threadid=366">the previous thread</a> was to keep the interrupts free for this phase of it, and also to keep the PIC from wasting time on Pulsin measuments that don't allow anything else to happen at the same time.

Essentially, you just need to take the signal that is currently going to the CCP (RC2) and also connect it to the INT pin (RB0).

Then we'll first set INTEDG to 1 so that it creates an interrupt on the rising edge. In the interrupt, we'll start TMR0 with a preloaded value that gives the required delay. This value may need to be adjusted from what your table gives in order to account for the interrupt delay, but should be easy enough. Then when TMR0 overflows, another interrupt is generated. This time it turns ON the output and sets INTEDG to 0 to catch the falling edge of the pulse. On the next interrupt it starts TMR0 again for the "Post Delay", and when the TMR0 overflows again, it turns the output off, sets INTEDG back to 1 in prep for the next pulse.

There are a few other things to account for, one being, not interferring with the RPM reading since an interrupt will occur exactly when you have to start the capture process, but this is also doable.

But, for now I'd like to see your table, so I can get a feel for the minumum and maximum delays. Since I know Squat about engines, I can't even guess at what they might be.

Of course, if you wanted to show the whole program, it would be helpfull too. Apparently, you've made some progress (changes) in other areas as well.

Best regards,
&nbsp;&nbsp;&nbsp;Darrel

[lwindridge]

Thanks for coming on board Darrel. I'll get the program back into a working form today and post it back up.
Or if you like I could send it straight over on email for you if it would be easier?

One major change that is going to take place soon is I'll be going from a 4mhz crystal to a 20mhz - should improve the resolution loads!

Will get thing working later then and then drop you a line.

Cheers

Leigh

[Darrel Taylor]

Switching to 20Mhz was going to be my first suggestion too. Of course, now the Capture and RPM calculation needs to be changed also. Oh well, the price of progress :)

Email's fine if you want. darrel at pbpgroup.com

Later,
&nbsp;&nbsp;&nbsp; Darrel