Need advice for creating nS time delay

[sayzer]

At 4Mhz and at 20Mhz, how do we create a time delay for 200nS or 300nS?

Clever ideas?

[Acetronics2]

Hi, Sayzer

How are you ???

let's see ...

@ 20 Mhz ... a NOP is ... 1/ 5 Mhz = 200 ns ...

so, just insert, in your PbP program :

@ NOP ... and you get a 200 ns delay ...

You can try to Boost a 16F PIC @ 30 Mhz ... ( I've read about 32 Mhz ...)


With 18F series @ 40 Mhz , you will get 100 ns per NOP ... and it is a PbP DEFINE OSC ...

so, 2 or 3 NOP's will do it !

regards

Alain

PS : No PIC solution @ 4Mhz ( minimum instruction time is 1µs ... )

But you can play with external logic gates ( if possible ...) and use their propagation time : time can easily fall to 10 nS ...

[sayzer]

Thanks Alain.

I was playing with that calculation but I made it wrong.
Actually, jumping from one line to another is also around 200nS ~ 300nS at 20Mhz.
Just do A = B and get this delay.

But I am unable to use 20Mhz, so I must find another way of getting at least 300nS at 4Mhz.

[mister_e]

a single instruction @4Mhz is 1uSec, this will be impossible to be faster for this frequency.

[sayzer]

...
...you can play with external logic gates ( if possible ...) and use their propagation time : time can easily fall to 10 nS ...


a single instruction @4Mhz is 1uSec, this will be impossible to be faster for this frequency.

I was thinking to charge a 10pF capacitor and wait for its discharge.
But before spending hours on its tests, should I keep thinking on this?
Don't we have a cap on our input pins already? that is another issue.

[Acetronics2]

Hi, Sayzer

Depends on the Pic you want to use ... but, if an internal oscillator could be used ( 16F88 i.e. ) ...

you could think to change the osc. frequ by soft !!! ( 8Mhz maxi gives 500 ns ...)

but depends if you could "boost" your osc frequ. for some instructions ...

see 16F88 ( i.e.) datasheet $ 4.6.2 for further infos ...

Alain

[mister_e]

or... eh eh, a 18F and enable/disable the internal PLL on the fly...

[Darrel Taylor]

This won't help Sayzer, but it's another example of why NOT to say RTFD all the time.

I was looking at the timing of a 628A. Trying to see if there was something that might work.
Looked at the capacitor discharge idea using a on-board comparator. But the response time was up to 600ns.
Hmmm, didn't expect them to be that slow.

Then was looking farther and came across this ...
Apparently, you can run a 16F628A at 4Ghz.
A 1ns delay would just be a NOP.

:D

[skimask]

??????????
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2195&d=1197319528

[Darrel Taylor]

I guess it should be RTFCD. (current datasheet) :)

P.S. Hello skimask.

[Ioannis]

Hi skimask! Where have you been? Its been a long time...

Well about the pin capacitance, I don't think it is a good idea in respect of the difference between chips. The delay won't be standard. If precision is needed don't think about it.

Can you provide more info about your project Sayzer?

Ioannis

[sayzer]

Ioannis,

I am interfacing with PYD1998 (digital output pyrodetector) and the communication requires a pause min.200nS.

I am using 12F675 (intosc) and the min. delay is 1uS.

1uS does not give precise results.
Since, a delay faster then 1uS at 4Mhz is not possible, now I have no choice but use a chip with 8Mhz intosc ( based on Alain's calculation I can get 500nS).

This time, the unit cost will be on table.



...
Then was looking farther and came across this ...
Apparently, you can run a 16F628A at 4Ghz.
A 1ns delay would just be a NOP.
:D

Anyone can show me a practical application of this?


P.S. - Welcome back Skimask! Howzit?

[Ioannis]

Although I have not made anything on FPGA's I see them now as an approrpiate solution.

They can be really fast!

Now about the device, I could not find a detailed pdf. Only a 2-page short datasheet. Do you have a complete copy? From the short one I think it is not as fast as you have stated.

Ioannis

[sayzer]

Although I have not made anything on FPGA's I see them now as an approrpiate solution.

They can be really fast!

Now about the device, I could not find a detailed pdf. Only a 2-page short datasheet. Do you have a complete copy? From the short one I think it is not as fast as you have stated.

Ioannis

Here are the detailed data sheets.

Unfortunately, application note file is 224KB, forum limit is 200KB.

[Acetronics2]

Hi, Sayzer

Hmmmm, 10 µm center bandpass ... that's a human motion detector !!!

Did you ask for the application Kit from Perkin-Elmer ???

http://optoelectronics.perkinelmer.com/content/manuals/man_digipyroappkit.pdf


By the way ...

having a closer look to your datasheet ... it appears ( to me ... LOL )

1) you must wait for the sensor's output HIGH level ( PIC as input : Hi Z state ...)

2) When pic ready, generate a LOW 200ns MINIMUM pulse, then a HIGH 200 ns MINIMUM pulse

3) Pic as Input for 1µS MINIMUM ( Hi - Z ! ) then reads level


4) generate 200ns MINI low pulse , then 200 ns MINI high pulse ... etc, etc : we're back to step 2)

that repeated for the 15 bits ...

No "hyper high speed" processor required here as 200ns and 1µs are MINIMA ... ( the data is read at the speed given by the low to high transitions sent by the processor

so, try 24µs instead of 200ns and 24µS instead of 1µs waiting ... ( it's the pauseus minimum @ 4 Mhz ...)
after that you will be able to speed it up a bit using @nop !!!




Alain

[sayzer]

Hi, Sayzer

Hmmmm, 10 µm center bandpass ... that's a human motion detector !!!

Did you ask for the application Kit from Perkin-Elmer ???

http://optoelectronics.perkinelmer.com/content/manuals/man_digipyroappkit.pdf

Alain

When I run the circuit on F877 with 20Mhz, I get very good results.
So I have no problem with the circuit; communication etc.

[Acetronics2]

Haaaaaa,

good news !!! you've got it working ...

now, from the datasheet it appears the sensor outputs a new "ready" signal every 2.84 ms ...

do you use polling or interrupting to initiate your reading sequence ???

Alain

[sayzer]

Alain,

I already got it working weeks ago.

The issue is that I need to make it work at 4Mhz.

For new sampling, I am giving it more then it needs. (it needs 3.7mS, I give it 10mS).

BTW; I added Application note; sampling example to my post above.

[Ioannis]

Hi Sayzer.

As Alain said and after looking at the datasheets, there is no need for hyper speed controller. What the DS states, are the minimum pulse width that you are allowed to apply. So, in case you have an extra-super-duper-high-speed controller capable to output 1ps pulses the sensor won't be able to follow.

You can just apply the pulses as fast as possible for the unique reason, to get your data soon. Otherwise there is no need to hurry.

As I understood the procedure:

1. MCU applies a high pulse for at least 200ns

2. MCU enter Z-state and sensor understands that MCU will read now the data

3. Sensor outputs the data bit

4. MCU reads the data bit

5. MCU outputs new high pulse

etc...

All you have to do is repeat the cycle as fast as possible if you want "real time" surveilance.

Ioannis


Ioannis

[sayzer]

Ok;

Thanks Alain and Ioannis.

Since the circuit worked very well at 20Mhz, I thought I was holding the sensor too long at 4Mhz. I must be having some other simple issue based on what you two have said.

I will work on this direction.

[Acetronics2]

Hi, Ioannis

The problem here is the sensor "1" level lasts only 1µS ....

the only solution I see here is use an asm part to generate the high state and test the pin as soon as end of high state .

If i remember ... it's the trick used to test if a pin is low, high or Hi-Z ... !!!

( thanks for the last picture, Sayzer ...)

Alain

[Ioannis]

Where is this 1µs? Did I missed it?

As I understood, the sensor will respond only when the MC enters Z-state.

Ioannis

P.S. Oh I got it. But Alain, this is settling time, not bit width time.

[Ingvar]

My guess is that this code will work......



@ device pic12F675, protect_off, mclr_off

define OSC 4
DEFINE OSCCAL_1K 1 'Set OSCCAL for 1K device

DataPin VAR GPIO.0 'DOCI on the PIR
PIRdata VAR WORD
i VAR BYTE

ANSEL = 0 'No AD on 12F675
CMCON = %00010111 'Digital pins - no comparator
WPU = 0 'No pullups

WHILE 1 'Do forever
HIGH GPIO.1 'Set a pin to time the reading
GOSUB ReadPIR 'Call the Sub
LOW GPIO.1 'Reset a pin to time the reading
PAUSE 10 'Just something to sync the scope
WEND


ReadPIR:
INPUT DataPin 'Let PIR control the Datapin
PIRdata = 0 'Use this time to let Datapin settle
WHILE DataPin = 0 : WEND 'Wait for PIR to indicate "new data"
PAUSEUS 25 'Wait for PIR to fiddle with the data
FOR i = 14 to 0 STEP -1 'Loop to get 15bits
LOW DataPin 'Force Datapin Low
HIGH Datapin 'Force Datapin High
INPUT Datapin 'Let PIR control the Datapin
' You may need a short pause here if you have long wires to the PIR
PIRdata.0(i) = Datapin 'Sample the datapin
NEXT
LOW DataPin 'Force Datapin Low
INPUT Datapin 'Let PIR control the Datapin
RETURN

END


... it compiles and runs as expected. Only problem is that i don't have a PIR to verify it with, it does however look OK on a scope. If i have interpreted the datasheet correctly you should be flying.

/Ingvar

[sayzer]

Ingvar,

I tested your code a minute ago; with some additions;

Congratulations! It works flawlessly.

My code is almost the same as yours.

What I see here is that, when we set the pin HIGH and then LOW, the time it takes to set the pins is already good enough for the sensor reading.

[Ingvar]

Good to know that we have working code ... if i ever buy one of theese PIRs.

[Acetronics2]

P.S. Oh I got it. But Alain, this is settling time, not bit width time.

Hi, Ioannis

looks the sensor output is seen by the PIC like a small capacitor ...and this capacitor is discharged by the low state of the pic pin ... not by the sensor itself.

this is a little confusing in the datasheet as the settling time is called as bitwidth time !!!

That explains why Ingvar's program works well ...

INPUT Datapin 'Let PIR control the Datapin

PIRdata.0(i) = Datapin 'Sample the datapin

surely need more than 1µs to be done !!! ...


Thanks, Ingvar ... we've learnt something !

Alain

[Ingvar]

Alain, surely that was obvious ....... ;) Nah, must admit that it wasn't all that clear in the datasheet.

I figure the PIR must be driving the output with resistors since there would otherwise often be a collision when the MCU drives the pin. No good. Driving via resistors will always be sensitive to capacitance on the lead and therefore a settlingtime will be needed. I figured it had to be this way since they specified tbit as "Data bit settling time" with a 10pF load.

[Ioannis]

It is kind like the 1-wire of Dallas devices. They are active low with pull up resistors, so that collisions can be avoided.

Ioannis

[sayzer]

Actually, I had to use 10K resistor to GND.

Without it, PIR's internal resistor is not good enough (at least for my circuit), and pin takes a free walk.