Shop OBEX P1 Docs P2 Docs Learn Events
CtrMode %01110; for detecting negative edges? — Parallax Forums

CtrMode %01110; for detecting negative edges?

HarleyHarley Posts: 997
edited 2007-07-19 20:51 in Propeller 1
I have a need to detect a very narrow pulse. It looks like the subject mode might be useful for a 'glitch catcher'.

I searched the Prop manual and the 'search Parallax' for info on this and it seems Graham's tutorial just touched on it without much details.

Would a very short negative pulse be detected if the duration were less than one clock period (1/80 MHz = 6.25 nsec)?

Is there a document which fully describes the edge detection limits? And where is the result held?

It would be nice (Oh, really?) if the edge detection works and could act like an interrupt. Or would a separate cog be required to implement such and 'bang' on another cog to signal the edge event? Hope not, there aren't many cogs left.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn

Comments

  • mirrormirror Posts: 322
    edited 2007-07-16 23:19
    If you need genuine edge triggering, then I'd think about using something like the MCP23S08. It's cheap, others have already written some code to interface to it, and it can do interrupt on pin change.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Paul BakerPaul Baker Posts: 6,351
    edited 2007-07-16 23:33
    Harley, the value for all inputs including the counter are obtained on the clock cycle, so sub clock pulses that don't traverse a clock boundry are not witnessed.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.

    Post Edited (Paul Baker (Parallax)) : 7/16/2007 11:42:04 PM GMT
  • HarleyHarley Posts: 997
    edited 2007-07-16 23:49
    mirror said...
    If you need genuine edge triggering, then I'd think about using something like the MCP23S08. It's cheap, others have already written some code to interface to it, and it can do interrupt on pin change.

    Thanks for the MCP23S08 reference. But really I'd to NOT use any additional hardware. Well, not if the Prop can hack it, and find a way to 'promptly' respond on an edge.

    Guess I'm going to have to do some deep digging on the counters. Hadn't though I'd need them, but looks possible.

    Amazing how much the Prop offers. Wish the documentation was complete. But realize that is one large task to really get deep. Already the manual is 438 pages. Just remembered, I've also the Hydra manual; time to do some reading on Counters this evening.

    Thanks also Paul. Just saw your comments as I was about to preview this.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Harley Shanko
    h.a.s. designn
  • rokickirokicki Posts: 1,000
    edited 2007-07-16 23:58
    I have to admit, I find the propeller manual to be quite complete. Sure, there's some tricky
    details that may be omitted, but the information you asked for is already pretty much in there.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2007-07-17 00:21
    Harley, there is an application note (see downloads) and an education kit lab on the counters.

    Graham
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2007-07-17 00:26
    The MCP23S08 was mentioned as a solution but even if you did want to use it you can't. It won't work as the glitch filter is around 150ns and it won't catch those really fast glitches, just the slower ones.

    *Peter*
  • mirrormirror Posts: 322
    edited 2007-07-17 01:04
    Peter Jakacki said...
    The MCP23S08 was mentioned as a solution but even if you did want to use it you can't. It won't work as the glitch filter is around 150ns and it won't catch those really fast glitches, just the slower ones.

    *Peter*
    Oooh, I didn't know that! Well, another alternative is to use a 7400 quad NAND gate, make a Set/Reset latch, and use a pin on the propeller to do the reset. It does involve another chip, but the Propeller programming is easier. If you want fast edge detection, then use a 74ACT00, or something like that.
    ·
  • HarleyHarley Posts: 997
    edited 2007-07-17 22:41
    Thanks to Paul, Graham,

    Looking at AN001, pg 18 and 19, this appears like it is getting quite close to what I have in mind. Except....

    1. The example code was for a frequency counter. I would like to be able to detect a single event pulse (width would have to be greater than clock period of 80 MHz. It appears that one would set frqa to #1 and phsa to 0 and test for phsa being non-zero. Is this correct?____

    2. Would the 'glitch catcher' code have to run in a separate cog?____ I would like to have it in the same assembly cog as what will make use of 'glitch caught' event.

    3. In the freq counter example, how does 'freq' value get transferred into the Spin code to be displayed?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Harley Shanko
    h.a.s. designn
  • rokickirokicki Posts: 1,000
    edited 2007-07-17 22:45
    1. Yes.
    2. No, best in the same cog; each cog can only access its own counter registers.
    3. You can access the cog registers directly from spin just like you can from assembly.
  • HarleyHarley Posts: 997
    edited 2007-07-17 23:14
    rokicki,

    Thank you for questions 1. and 2. response. But the example doesn't use 'freq' in the assembly portion, only in the Spin. Hence question 3.

    But, what I don't understand is the 'hooks' between the two. Unless there is a correction/update to AN001 I'm not aware of.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Harley Shanko
    h.a.s. designn
  • Mike GreenMike Green Posts: 23,101
    edited 2007-07-18 01:07
    I'm not sure, but I suspect that the edge detection modes would be the most useful in that they would detect any 0 to 1 (or 1 to 0) transition that's at least one clock in width. They would skip any pulses less than one clock cycle in width and would count the number of such pulses seen. You could use a 6MHz crystal to get a 96MHz clock which would get you a minimum pulse width of slightly more than 10ns. That clock speed isn't officially approved, but the FTDI DIP version of the Prop runs with a 6MHz input clock.
  • AribaAriba Posts: 2,690
    edited 2007-07-18 01:16
    About your question 3:
    In Spin at COGNEW the PAR register gets the address of the freq variable.
    But I think the example is not correct. Right would be: COGNEW(@entry, @freq).
    In the Assembly section the measured frequency is written with WRLONG new,par into the freq variable.

    The freq is a variable in MainRAM and the new, old, temp ... are variables in the CogRAM of the Assembly cog.
    The frequency is measured in the cog with local Cog-variables and is then written in the MainRam, so that Spin can access it.

    Andy
  • ErNaErNa Posts: 1,752
    edited 2007-07-19 14:10
    The following could work: Connect a very small capacitor to the Input and and a diode to the signal. Charge the capacitor by outputting "H", change to input mode. A glitch will discharge the C below threshold and release the "waitpeq". Retrigger by charging the C.
  • HarleyHarley Posts: 997
    edited 2007-07-19 16:41
    Mike Green said...
    I'm not sure, but I suspect that the edge detection modes would be the most useful in that they would detect any 0 to 1 (or 1 to 0) transition that's at least one clock in width. They would skip any pulses less than one clock cycle in width and would count the number of such pulses seen. You could use a 6MHz crystal to get a 96MHz clock which would get you a minimum pulse width of slightly more than 10ns. That clock speed isn't officially approved, but the FTDI DIP version of the Prop runs with a 6MHz input clock.

    Sorry, my original post mentioned 6.25 µsec; I was thinking of Prop gen#2. Such anticipation!!! Should have been 12.5 µsec.

    On studying AN001 and thinking about the counters a lot, it appears that the 'transition' modes (%0101x and 0111x) don't really detect the actual transition. But if the change of state exists for more than a system clock duration, then the PHSx value is incremented. Right? If so, then there could be a variable delay of up to 12.5µsec on detecting the transition. Just something to keep in mind if response is critical. Anything wrong in this thinking?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Harley Shanko
    h.a.s. designn
  • AribaAriba Posts: 2,690
    edited 2007-07-19 20:51
    No, you're right.
    The Input Pin is sampled with 80 MHz and the sampled state is compared to the state of the last sample. If they are not equal, a transition is detected, and the FRQx is added to PHSx.
    If the Pulse is smaller then 12.5ns it can be detected, if it occures exactly at the sampling position, but this is an exeption.
Sign In or Register to comment.