Catching a short spike / event?

I need to catch an event lasting on average, about 20 to 30 nanoseconds and I'm not sure the best way to do it.

The device is 16F677

I think I can use Interrupt On Change, or possibly the Capture / Compare / PWM module.

The 677 doesn't have the CCP1 function, and use of the CCP also requires use of Timer1, which in my application will be busy with another task. It could be reconfigured, but I'd really like to avoid using this route if at all possible.

I'd like to use the IOC route but I've got questions...

- It sounds as if the change event happens during an active pin read cycle in the execution. As the duration is so short compared to the clock cycle time (I'm running at 20Mhz, external resonator) - the event could easily be missed between reads.... or is this setting of the interrupt flag something that happens almost "analog" - where a sort of switch is tripped which will be discovered on the next read - so in theory, an exceptionally short event - maybe 1nS even would still trip the IOC. Is this true, or do we need to assume the change lasts for multiple clock cycles?

- The same with the comparator - I do have all those pins open to use, and I know a change in the state of the comparator can trigger interrupts or set other flags.... as the comparator runs essentially free of the clock timing... could I just compare it to the internal voltage, which would cause the comparator to read opposite during the transient spike event?


... or is there another method that's better?

Thanks!!

Microchip had an AN I think it was AN592. In this AN a frequency counter was implemented with an old PIC at 4MHz measuring up to 50MHz!

May be this could help you.

Ioannis

Hi,Kevj

That's quite simple : the datas from µChip give a minimum transition time the PIC can see on its inputs ... whether the clock frequency.

Ioannis gave you the link to AN592 that uses this feature of their chips; I cant tell you it works well, and 50Mhz input frequency is a minimum ... ( If PCB is well designed ... LOL !!! )

Now, understand you won't READ the spike length, but only "FLAG" it

if you want to catch much shorter events, You probably can use some Very High speed TTL ( or CMOS ? ) monostable to lengthen the spike ... once more, it will only be a spike "flagging" ....

Alain

Quote:

---

Originally Posted by Acetronics

the datas from µChip give a minimum transition time the PIC can see on its inputs

---

Thank you - where would I find this info? I looked over the data sheet and didn't see it - maybe I missed it someplace? Is it in one of the errata publications for the chip? Seems like it would have been an obvious spec to publish - thus I was surprised not to find it.

Thank you.

I scanned the PIC 18F4620 data sheet to see what they say about Interrupt-On-Change timing issues. Nothing except this in section 10.2.

.....The input pins (of RB7:RB4) are compared with the old value latched on the last read of PORTB. The “mismatch” outputs of RB7:RB4 are ORed together to generate the RB Port Change Interrupt with Flag bit, RBIF (INTCON<0>)......

This is vague but I interpret it as saying that the interrupt event must remain present on the pin until the processor gets around to reading the port a second time as directed by some of your instructions.

The comparator is 'analog' with a response time between 150 and 600 nSecs according to table 26.2. The comparator signal would be volatile unless you wired the comparator to have significant hysteresis.

HTH
Brian

I wonder if a simple 7555 timer would work? (the lower power and supposidly faster version of the 555). I looked for a "high speed" monostable but didn't find much.

As I understand it, the 7555 has no "clock", it's just an internal network of transistors and it would seem that if the circuit were "tripped" by anything, it would transition - I don't see any time spec on minimum trasnient duration required to cause a transition. Anyone have an idea on that?

If it were too short (say a fraction of a nanosecond), you'd think it would trip on its own from time to time just from radio spike hits and what not.

With everything on the planet running at multiples of gigahertz these days, I didn't think this would pose any real challenge but it is indeed complicating things. :(



BrianT - thanks man. I found the very same thing in my own data sheet. Didn't exactly make it perfectly clear did it. I got the same read - that the event must last long enough for the program to execute a read and register that the pin has indeed changed state.

Quote:

---

Originally Posted by kevj

Thank you - where would I find this info? I looked over the data sheet and didn't see it - maybe I missed it someplace? Is it in one of the errata publications for the chip? Seems like it would have been an obvious spec to publish - thus I was surprised not to find it.

Thank you.

---

Hi, Kevj

No secret ... Midrange ref. Manual, Section 30+ ...

Alain

Quote:

---

Originally Posted by Acetronics

Hi, Kevj

No secret ... Midrange ref. Manual, Section 30+ ...

Alain

---

Was that comment supposed to come off as sarcastic and demeaning?



Anyway.....


I assume you were referring to this manual (which was a secret to me - I had no idea this manual or the others in this list existed until you pointed out my ignorance for me).

http://ww1.microchip.com/downloads/e...Doc/33023a.pdf

A bunch more manuals:

http://www.microchip.com/stellent/id...GE&nodeId=1956


Section 30 of the noted manual is Electrical Specifications. I didn't see the measurement I needed specifically spelled out. Page 591 does note what appears to be a CCP low input time (by the graphic I assume this means the minimum time the pulse can be low and still be counted) as ".5Tcy +20" with no prescailer, but I don't know what Tcy is - but notes 10ns with the 16Cxxx when using a prescaler - does a prescailer of "1" still count? And why would that be shorter than with no prescailer and while we're there.... where are the measurements for the 16F - these are for the C.



At any rate, I'm going to try and catch this pulse with a 555 / 7555. I'm not aware of any specific monostables that are faster - if someone's got a part number, I'd much appreciate it. Any other ideas on flagging this event - I'm all about listening and experimenting if pointed in the right direction.

[QUOTE=kevj;46506]Was that comment supposed to come off as sarcastic and demeaning?



Hi,

Was just to show you there's no hidden info, but we have a lot of datas to read ... only needs years of practice to remember all these little (! ) details.

it's Everyone's pain !!! not only yours ...

Alain