PDA

View Full Version : How instant are Instant Interupts?



jmgelba
- 30th March 2009, 19:50
New project, in the "Is this even possible?" stage.
Hardware is open to sugestion.

I need to send out a pulse of any of the following durations depending upon settings: 1, 3, 5, 10, 30, 50, 100, 1000, 3000, 5000, 10000uS.

I need a delay before the pulse is sent out of any of the following: 0, 20, 50, 100uS.

Trigger input is TTL 5V rising or falling edge, selectable.

I want to have a 2x8 LCD display and a few buttons to set up a menu to change and set all these options. On completion of saving the settings, a button can be preesed to activate and wait for an incoming pulse. That would be the main program.

I need high accuracy on the o/p pulse delay and duration as this is a strobe light application for high speed cameras running 10,000 plus frame rates per second.

Are Instant Interupts up to the task?

Darrel Taylor
- 30th March 2009, 20:58
Everything but the 0 delay before the pulse.
It would take external hardware for that.

Assuming an 18F with high priority ASM type interrupts at high OSC speed.
The rest should be possible.

So the next question will be ...
What is the exact interrupt latency?

And the best way to answer that is to have you set up a timer with 1:1 prescaler triggering an interrupt.
When the timer rolls over to 0, an interrupt is generated and the timer continues counting.

When it reaches the handler, immediately turn the timer off.
The value in the timer now has the exact number of instructions it took to get there (+1).
It should be around 30-40 instructions. @ 40Mhz, that's 3-4 uS.
<br>

jmgelba
- 30th March 2009, 21:40
Yeah, the 0 delay is going to be fun.

I'd thought about something along the lines of a 555 setup as a one shot with a couple of caps that can be switched in to the circuit to get the low uS delay and pulse width. Caps are switched in or out with FET's thus having control through the menu system.

Everything else is ran through the PIC timers.

Darrel Taylor
- 30th March 2009, 23:52
555? Eeewwwww!
I think the minimum monostable time is around 2uS.

Actually, for the 0 delay, I was thinking you could do it with some 74HC NAND gates. A little tricky though.

By creating a SET/RESET flip-flop that gets toggled immediately on the incoming pulse, it can "gate" the FOSC/4 out signal into Timer1.

With a CCP module in COMPARE mode, you can load the delay time in CCPRxL:H prior to the pulses, and when it sees a match, it will output a pulse on the CCP pin which will reset the flip-flop, turning off the final pulse with great precision, and no software delay.

Interrupts will probably still be needed to reset things for the next pulse, but the actual task is done by hardware.
<br>

jmgelba
- 31st March 2009, 03:22
No I'd never use a 555 timer but I though about something along the same lines. In the past, the way way past, I had a project that used some really high stability and acurate timing IC's. I think the part number began with Z.
Anyway, I do agree that hardware is the way to go for the 0 and 1uS delay.

I've never used a PIC timer or a ccp so this should be good for learning.

Darrel Taylor
- 31st March 2009, 05:41
... I've never used a PIC timer or a ccp ...

:eek: Then you won't want to do this.
But here's what I was thinking in post#4 ...

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3287&stc=1&d=1238476254" /><!-- 3287 -->

This would be for Zero delay only, just to show the concept.
But it only takes a couple changes to get full control (zero delay or interrupt timed, selectable).

Some PIC's have a Gated Timer1 built into the chip. That would make the OSC config easier, and it wouldn't need the lower NAND gate.

Zero Delay or Full Control, it still only takes one 74HC00, and the mode is selected by the PIC.

Purely theoretical.
<br>

jmgelba
- 31st March 2009, 13:37
Interesting. I had been looking at programmable and custom delay lines too. There are a couple out there that are mcu controllable but cost a fortune. 74HC00's do not!

And, DT, I gotta try my hand at this for a couple of reasons.

1. I'd like to pay next months mortgage.
2. I'd stop asking you about timers and ccp's.

Darrel Taylor
- 31st March 2009, 21:41
1. I'd like to pay next months mortgage.
I thought everyone quit paying those things. :)


2. I'd stop asking you about timers and ccp's.
Now I'm confused, cause this would definitely generate more Timer/CCP questions.

Or did you mean you'd try your hand at programmable and custom delay lines?
<br>

jmgelba
- 31st March 2009, 22:06
Still barely paying my mortgage.

If I figured out timers and ccp's, I would be one person less asking you questions (in the future.)

As for now, yep, there'd be several questions I'm sure!

Darrel Taylor
- 1st April 2009, 00:29
OK, then let me throw some fuel on the fire...

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3293&stc=1&d=1238537481" /><!-- 3293 -->

This is the "Full control" version.
I've connected the pulse input to the INT pin of the PIC, for the delayed pulses.

The second input of the first NAND goes to another PIC pin (Zero Delay Enable).
When that pin is HIGH, Zero Delay is selected and the output of the flip-flop will go high immediately on an incoming pulse.
R1 keeps it disabled till the PIC takes over.

Another pin is used to "Set from CPU".
This is used to Set the output Flip-Flop manually from the PIC so it can respond to Delayed pulses timed by the interrupts. Taking the pin LOW will set the flip-flop. This should be tri-stated when in Zero Delay mode.

Clearing the flip-flop (end of pulse width) is done with the CCP out pin. Whether it's actually the CCP doing it, or timed interrupts.

Again, Purely theoretical.
<br>

jmgelba
- 2nd April 2009, 21:28
OK, then let me throw some fuel on the fire...

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3293&stc=1&d=1238537481" /><!-- 3293 -->

This is the "Full control" version.
I've connected the pulse input to the INT pin of the PIC, for the delayed pulses.

The second input of the first NAND goes to another PIC pin (Zero Delay Enable).
When that pin is HIGH, Zero Delay is selected and the output of the flip-flop will go high immediately on an incoming pulse.
R1 keeps it disabled till the PIC takes over.

Another pin is used to "Set from CPU".
This is used to Set the output Flip-Flop manually from the PIC so it can respond to Delayed pulses timed by the interrupts. Taking the pin LOW will set the flip-flop. This should be tri-stated when in Zero Delay mode.

Clearing the flip-flop (end of pulse width) is done with the CCP out pin. Whether it's actually the CCP doing it, or timed interrupts.

Again, Purely theoretical.
<br>

Hmm, how would one use this for falling edge trigger? I'll be honest, I havent had time to study what you are doing here, but what I've looked at seems logical.
I just ordered a couple of quad nands and a few 40MHz resonators, and over the next week or so will have a chance to work with this.

Darrel Taylor
- 2nd April 2009, 22:37
Hmm, how would one use this for falling edge trigger?
Several possibilities there.

If using Option #1, the 4th NAND gate is available and can be used to invert the incoming signal. Selection of Normal/Inverted modes would then be with a Jumper or SPDT switch.

If you wanted it to be selectable by the PIC, you could add a 74HC86 quad XOR. With the extra gates, you could put an XOR on the output too if you wanted the option to invert it from the PIC.
<br>

Darrel Taylor
- 5th April 2009, 02:50
Here's an update for the last post.
Two 74HC86 XOR gates have been added to be able to invert the input and output polarities.

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3300&stc=1&d=1238895362" /><!-- 3300 -->

I see that you specified "Trigger input is TTL 5V rising or falling edge, selectable." in the first post.
I must have missed that part. :o

I could be diverging from what you want to do.
But the problem is intriguing, so I'm continuing onward ... thru the Fog. :)

I think the circuit above gives you all the capabilities you're looking for.

I did a quick pseudo-program to see what it would take for a simple test without interrupts, and it was surprisingly easy.

If you can settle on a PIC to use ... preferably 2-CCP's (1 for the FOSC4).
Could probably come up with something that's close.

I love shooting things ... with camera's.

jmgelba
- 6th April 2009, 16:59
Looks like 18F4220 at the moment. I only have v2.43 so I am limited in which devices I can use. I cant find my reciepts or proof of purchase anywhere to get the upgrade.

I need a decent amount of I/O's. 2x8 lcd, at least 4 or 5 switches, status led's, logic gates, fet drive, lcd back light, adc for capacitor charge level/status.

I'm not a coder or really much of a hardware guy, but I am a power supply and LED guy. If only I could show you some of the stuff going on here..... :)

Bruce
- 6th April 2009, 20:06
I cant find my reciepts or proof of purchase anywhere to get the upgrade
If you bought PBP from us, we can look it up for you, and send you a copy of your original
receipt.

Most other distributors should be able to do something similar to help you get the upgrade.

jmgelba
- 8th April 2009, 16:07
Part of this project is obviously timing.

Say I have a pulse coming in at between 50 and 200uS and I need to match this incoming pulse to an output. Not really a problem.

IF PORTA.0 = 1 THEN PORTA.1 = 1

But what if that incoming pulse is longer than the 200uS and the output must be shut off after a predetermined maximum, lets say 1000uS?

IF PORTA.0 = 1 THEN PORTA.1 = 1 no longer works. TMR0 has to be triggered at the same time as PORTA.1 goes high, then needs to count to a maximum of 1000uS and make PORTA.1 = 0.
PORTA.1 then must be kept low until PORTA.0 has gone low.
When PORTA.0 = 0 TMR0's flag can be reset and wait for PORTA.0 to go high again. If PORTA.0 has gone low before TMR0 has set the flag, it must be reset and ready to count to 1000uS.

Does this make sense?

Darrel Taylor
- 8th April 2009, 23:18
If you're doing it with software polling, timers don't add much value unless you plan on doing other things at the same time. But all that really makes things complicated.

So here's a simple example that does the same thing with pauseus instead of a timer.

Delay = 1000

Wait4Pulse:
IF !PORTA.0 THEN Wait4Pulse ; Wait for incoming pulse
PORTA.1 = 1 ; Start Output pulse
PAUSEUS Delay ; pause for pulse width
PORTA.1 = 0 ; End of Output pulse

Wait4PulseEnd: ; Make sure input pulse is finished
IF PORTA.0 THEN Wait4PulseEnd

GOTO Wait4Pulse

jmgelba
- 8th April 2009, 23:52
DT, that wont work. The output has to reflect the input up to a maximum on time then the output has to be turned off regardless of input state.



Delay = 1000

Wait4Pulse:
IF !PORTA.0 THEN Wait4Pulse ; Wait for incoming pulse
PORTA.1 = 1 ; Start Output pulse
PAUSEUS Delay ; pause for pulse width *** this will keep the output on for 1000uS, not for the duration of PORTA.0 = 1
PORTA.1 = 0 ; End of Output pulse

Wait4PulseEnd: ; Make sure input pulse is finished
IF PORTA.0 THEN Wait4PulseEnd

GOTO Wait4Pulse

Darrel Taylor
- 9th April 2009, 00:15
DT, that wont work. The output has to reflect the input up to a maximum on time then the output has to be turned off regardless of input state.
Now you tell me!
That wasn't part of the plan.

The schematics above don't apply then. Nor does the example. :o
<br>

jmgelba
- 9th April 2009, 00:49
2 different projects/ideas.

This last one has nothing to do with the first one. Its a pulse follower with a protective cut off.

jmgelba
- 9th April 2009, 00:52
I am still very interested in the first one and looking forward to taking a look at the code.

The second one was me trying to learn timers and how to manipulate them.

Darrel Taylor
- 9th April 2009, 01:54
And now for something Completely Different!

Main brains only got 1 track left.
Ya gotta tell me when to switch to track B ... :D

OK, back to the first problem.
I've got this code for the last schematic.
It hasn't even seen an electron yet, but I think it's close, although it's guaranteed to change.

I'm trying to make a breadboard for it.
But it's going slower than anticipated. (blame Half-Life).

Here's what I got ...
http://www.pbpgroup.com/files/ZeroDelay1.htm
<br>

jmgelba
- 9th April 2009, 14:56
Interesting peice of code - over my head for the moment.

Going back to the pulse following example, here is a piece of code I came up with at about 4am this morning.


OSCCON = $70 'set internal resonator to 8mhz
DEFINE OSC 8
ADCON0 = %00000001
ADCON1 = %01111100
ADCON2 = %10111110

PORTB = %00000111
TRISA = %11111111
TRISB = %11110000

loop:
IF PORTA.5 = 0 THEN flash
GOTO loop

FLASH:
PORTB = %00001100 'turns on fets
A = 0 'resets count to 0

while A <= 5 'follow status of i/p turn off fets if i/p goes away
PORTB = %00001100
A = A + 1
IF (PORTA.5 = 1) THen
PORTB = %00000111
WEND
if (A <=4) THEN
GOTO loop
if (A = 5) then 'if A=5 fets are still on
pauseus 1500 'set max time for fets to be on
PORTB = %00000111 'turn off fets
IF (PORTA.5 = 0) THEN 'if i/p is still on, wait 2ms then repeat loop
pause 2
return

Dave
- 9th April 2009, 16:00
jmgelba , These lines will never execute because of the value of "A" before hand.

if (A <=4) THEN <<<<<<<<<<<<<<<<<<<<<<<<< here A = 6
GOTO loop
if (A = 5) then 'if A=5 fets are still on <<<<<<<<<<<<<<<< here A = 6
pauseus 1500 'set max time for fets to be on
PORTB = %00000111 'turn off fets

Also wheres the ENDIF's?

Dave Purola,
N8NTA

jmgelba
- 9th April 2009, 16:13
Why would A = 6?

Before the goto, A is set to 0, then I'm counting up. If A becomes less than or equal to 4 something happens. If A = 5 then something else happens.

Dave
- 9th April 2009, 16:35
jmgelba, Because "While" it is the loop A is being incremented until it equals 6 right?

Dave Purola,
N8NTA

jmgelba
- 9th April 2009, 17:12
I thought I was incrementing it until it reached 5? If its equal or less than 4 (>=4) is does something, if it is =5 than it does something else. After it has reached either of those conditions it shouldnt increment again.

jmgelba
- 9th April 2009, 17:48
So could this be used?

Repeat
PORTB = %00000111
Until
PORTA.0 = 1

Dave
- 11th April 2009, 18:50
jmgelba, Yes it could... You understand why the counter = 6 dont you?

while A <= 5 'follow status of i/p turn off fets if i/p goes away
PORTB = %00001100
A = A + 1
IF (PORTA.5 = 1) THen
PORTB = %00000111
WEND

Because if A = 5 you still increment A. Right? So when you drop out of the loop A = 6..

Dave Purola,
N8NTA