Shop OBEX P1 Docs P2 Docs Learn Events
How fast can the P2 read PORTA and save it to the hub repeatedly ? — Parallax Forums

How fast can the P2 read PORTA and save it to the hub repeatedly ?

BeanBean Posts: 8,129
in Propeller 2
I am working on a project that needs to store the state of 32 pins as fast as possible.
Does anyone know how quickly this can be done on the P2 ?
Either with a loop or even straight line code ? Maybe the streamer ?

Thanks,
Bean

Comments

  • RaymanRayman Posts: 14,646
    Streamer would be the fastest way... Could be every clock or every other clock, I think...
  • BeanBean Posts: 8,129
    If it can do it every clock that would be amazing.

    Thanks Rayman.
  • RaymanRayman Posts: 14,646
    Looks like some discussion and link to logic analyzer here: https://forums.parallax.com/discussion/169219/streamer-for-digital-pin-sampling
  • evanhevanh Posts: 15,916
    edited 2020-04-17 20:54
    Yep, a single streamer can do that. For hubRAM accesses, it requires the FIFO to be setup first. The FIFO controls all addressing of hubRAM. So can't be in hubexec for the duration.

    Data rate is specified with SETXFRQ instruction. Transfer mode, data format and amount, and start timing controlled with XINIT/XCONT/XZERO instructions. The difference between them being only in the timing details.

  • cgraceycgracey Posts: 14,155
    SETXFRQ is initialized to $8000_0000, which is EVERY clock. Yes, the streamer can record 32 pins every clock. If you use two cogs, their streamers, together, can record all 64 pins every clock.
  • BeanBean Posts: 8,129
    Thanks Chip.

    Bean
  • TubularTubular Posts: 4,702
    OzPropDev's logic analyzer does this, every single clock...

    We are spoiled
  • BeanBean Posts: 8,129
    Does anyone know if there is a delay between different pins ?
    I mean, if I run the same digital signal to any two pins will they always read the same state ?
    I want to put a 125pSec delay between P0 thru P31 such that P0 is the input signal, P1 has 125pSec delay, P2 has 250pSec delay an so on.
    I am trying to get 125pSec pulse measurements.
    Will that work ?

    Thanks,
    Bean
  • cgraceycgracey Posts: 14,155
    Bean, I don't know if that will work. There are different delays between pins that are fixed in the silicon implementation, which are the result of place-and-route differences, where the timing goal was met, but tolerable mismatch resulted. I suppose if you could qualify what those differences are, you could exploit them.
  • BeanBean Posts: 8,129
    Thanks Chip.
    Any idea what the "worst case" difference would be ?

    Thanks,
    Bean
  • RaymanRayman Posts: 14,646
    What about this "clocked" mode? Does that work with streamer?
  • cgraceycgracey Posts: 14,155
    Bean wrote: »
    Thanks Chip.
    Any idea what the "worst case" difference would be ?

    Thanks,
    Bean

    I remember reading ~850ps. I've been trying to find that email, but haven't located it, yet. They had a delay for each of the 64 pins.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    Bean, you could always equalize the delays with short pieces of wire. 850ps requires less than a foot.

    -Phil
  • jmgjmg Posts: 15,173
    cgracey wrote: »
    Bean wrote: »
    Thanks Chip.
    Any idea what the "worst case" difference would be ?

    Thanks,
    Bean

    I remember reading ~850ps. I've been trying to find that email, but haven't located it, yet. They had a delay for each of the 64 pins.

    That would be useful, as then a combination of native pin-delays and external delays could get Bean closer to a nominally even step size.
    The P2 may need thermal regulation if you wanted to reduce ambient variations, but maybe Bean is ok with a calibrate pass ?
  • BeanBean Posts: 8,129
    Thermal regulation is okay. And calibration is okay.
    Just so that each step is about the same and they all "trip" in order.

    I am trying to measure 1ppb frequency change of each cycle of a 1MHz oscillator over a 100uSec shock pulse (100 cycles).
    This won't get us there, but it is as least a start.

    Bean
  • TubularTubular Posts: 4,702
    I think this is a similar thing that I'm interested in for Time of Flight measurements.

    Do you know the rise time on the oscillator? There is also a different trigger threshold level for each pin
  • BeanBean Posts: 8,129
    Tubular wrote: »
    I think this is a similar thing that I'm interested in for Time of Flight measurements.

    Do you know the rise time on the oscillator? There is also a different trigger threshold level for each pin

    I'm not sure about the rise time, but that is a good point.

    The advantage you have with time-of-flight is that you can repeat the measurement many times to "build-up" more resolution. I can't do that here because it is a one-shot event.

    Bean
  • RaymanRayman Posts: 14,646
    edited 2020-04-20 23:46
    If you have several free pins, maybe one could use digital delay lines to send the same signal to multiple pins with a slightly different delay?

    I've thought about using this type of thing before but haven't yet:
    https://www.digikey.com/product-detail/en/rochester-electronics-llc/DS1021S-50/2156-DS1021S-50-MA-ND/11509952

    There are tap increments down to 3 ps...

  • TubularTubular Posts: 4,702
    We can just make a pcb with serpentine trace lengths to give the right kind of delays. This could just be a plug in accessory board for the P2ES, to try it with 8 delays

    We could accurately work out the switching thresholds potentially using two DAC outputs to combine their signals (aiming for 16 bits theoretical). I think I worked out you need a 31k external resistor to create a 16 bit static dac by combining two dac outputs. Its a pity we lost physical pin B connection option, but then perhaps we can still do this with the Rev B silicon chips we have right now

    The other problem is the internal delays will likely vary from cog to cog. I wonder whether it is possible to get those final synthesis propagation delay values from Wendy




Sign In or Register to comment.