Pin reading question

TonyB_

I'd like to read three pins in a single PASM instruction into register x, such that:

x[0] = ! pin N
x[1] = 1 if pin N+1 has gone from high-to-low, else 0
x[2] = ! pin N+2
where N can be multiple of four

Is this possible?

Rayman

Think addpins can do that for you

Oh, you might mean assembly?
Have to think about that one…

Rayman

Guess shr on ina with x as dest would work, right?

If no addpins magic

evanh

Far from a single instruction solution but if what you're trying to do is capture the level of all three pins upon N+1 rising then N+1's smartpin can detect the rise and software can wait on that with a WAITSE1. Follow this with a MOVE x,INA/INB to read all three pins. The smartpin then also requires rearming for next rise of N+1 with an AKPIN.

Edge detect requires a state memory to hold the knowledge of a past event, and requires rearming. It's not a simple combination to mix that with other pins without a specific application in mind.

TonyB_

Thanks for the replies. I've edited the first post to clarify that I'm aiming for one PASM instruction. There are in fact four pin inputs to read at the same time, say pins 0-3 for simplicity, all filtered the same with Tap = 0 and Length = 2 or 3. Pins 0, 2 and 3 are active-low level-sensitive and pin 1 is negative-edge triggered:

x[0] = ! pin 0
x[1] = 1 if pin 1 has gone from high-to-low, else 0
x[2] = ! pin 2
x[3] = ! pin 3

Note that polarity of x bits could be inverted. I'm thinking of GETNIB x,INA,#0 as the single instruction but is there a smart-pin or other mode that could handle pin 1? The need to rearm it would be an advantage, not a drawback.

Another question: what is input clock lag for JSEx if selected event is pin is low? This is not mentioned in I/O PIN TIMING section of the doc.

Ariba

@TonyB_ said:

... but is there a smart-pin or other mode that could handle pin 1? The need to rearm it would be an advantage, not a drawback.

I think this mode will raise IN if one neg edge occurs:

  pinstart(x+1, P_INVERT_A + P_EVENTS_TICKS, 1, 1)

Andy

TonyB_

@Ariba said:

@TonyB_ said:

... but is there a smart-pin or other mode that could handle pin 1? The need to rearm it would be an advantage, not a drawback.

I think this mode will raise IN if one neg edge occurs:

  pinstart(x+1, P_INVERT_A + P_EVENTS_TICKS, 1, 1)

Andy

Thanks, Andy. I don't use Spin so I'll need to convert this to PASM.

Ariba

Converted to PASM:

        dirl    #PINX1
        wrpin   ##P_INVERT_A + P_EVENTS_TICKS, #PINX1
        wxpin   #1, #PINX1
        wypin   #1, #PINX1
        dirh    #PINX1

To rearm for next neg-edge, use AKPIN #PINX1 or reset the smartpin with DIRL .. DIRH

evanh

Doh, I just realised SETSE1 does the edge detect - Don't have a smartpin involved. Which makes the rearming of the event automatic upon use of any event instruction.

Yep, GETNIB is great for piecemeal INx sampling.

As for the latency/lag effect, I have no proof but I would expect SETSE1 hardware to add one sysclock tick above a TESTP (I'll assume the event hardware will tap this same circuit). Which should make it the same as a TESTB INx (or GETNIB INx). See page 42 of "Hardware Manual".

Interestingly, a smartpin sees inputs a tick earlier than even TESTP. Ie: There is one incoming and one outgoing staging register each way between the physical pin (custom pad-ring circuit) and its smartpin. I derive this tidbit from how quickly the SPI modes can respond to an external clock.

evanh

@evanh said:
As for the latency/lag effect, I have no proof but I would expect SETSE1 hardware to add one sysclock tick above a TESTP (I'll assume the event hardware will tap this same circuit). Which should make it the same as a TESTB INx (or GETNIB INx). See page 42 of "Hardware Manual".

I'll reinforce the assumption here with a point of reason - I think the reason why TESTP is exceptional is because it doesn't have to mux in a memory array or any other SPRs. The data source is only from the pins. Therefore TESTP can directly examine the more distant routed (compared to INA/INB registers) second staging input registers which sit alongside the smartpins, outside the cogs.

The event hardware could do the same bypassing of the INx registers for the same reason. It's not examining a general memory map.