RP2 PIO StateMachine.exec() function

[D-Paesani]

Hello,

this a general question about the inner workings of the rp2.StateMachine.exec() function. If I execute this function on a SM which is already running, how does it impact or interfere with the normal operation of the SM? Are instructions run using "exec" injected at specific points in the SM program?

In particular, I am building a rate-meter using an RP2040, based around the (https://github.com/dhylands/upy-examples/blob/master/pico/pio_pulse_counter.py) pulse_counter() which continuously accumulates pulses in a PIO SM:

@rp2.asm_pio()
def pulse_counter():
label("loop")
wait(0, pin, 0)
wait(1, pin, 0)
jmp(x_dec, "loop")

Every fixed time interval (10 to 1000 ms) the main program retrieves the pulse count for that specific time interval (it subtracts the previous value and handles overflows), by executing

sm.exec("mov(isr, x)")
sm.exec("push()”)
sm.get()

I was wondering if, with the PIO SM continuously running, executing the code above at fixed intervals could affect or interfere with the normal SM operation, resulting in pulse count loss.

How are the instructions run with “exec” inserted in the normal SM operation?

would it be wiser to have the SM written as:

def pulse_counter():
wait(0, pin, 0)
wait(1, pin, 0)
jmp(x_dec, "loop")
label("loop")
mov(isr,x)
push()

so that the main program will only act on ISR FIFO via sm.get() ?

Thank you!
Best regards,
DP

[mendenm]

It might actually work pretty well to set your program up with autopush at 32 bits, and then just every so often do

grab_it = rp2.asm_pio_encode("mov(isr,x)") #precompile instruction
... start sm ...
while 1:
    if (some timing statement):
        sm.exec(grab_it)
        count = sm.get()

this effectively peeks asynchronously at the x register.

I haven't tried it, but it should work.

[D-Paesani]

Dear mendemn,
thank you for your prompt answer.

I like the idea of precompiling into grab_it and using autopush.
My only concern left is whether sm.exec(grab_it) will interfere or not with the operation of the SM.

Since every clock cycle is taken by an instruction and the only way to execute an instruction seems to be via the instruction memory, how are exec() instructions handled asynchronously?

Sction 3.5.7. "Forced and EXEC’d Instructions" of the PICO data sheet (https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf) should clarify what is happening:

"
Besides the instruction memory, state machines can execute instructions from 3 other sources:
• MOV EXEC which executes an instruction from some register Source
• OUT EXEC which executes data shifted out from the OSR
• The SMx_INSTR control registers, to which the system can write instructions for immediate execution

[...]

When an instruction is written to the INSTR register, the state machine immediately decodes and executes that instruction, rather than the instruction it would have fetched from the PIO’s instruction memory. The program counter does not advance, so on the next cycle (assuming the instruction forced into the INSTR interface did not stall) the state machine continues to execute its current program from the point where it left off, unless the written instruction itself
3.5. Functional Details 342
RP2040 Datasheet
manipulated PC.
"

i am not sure about how all this is implemented in the micro python "exec" command.

thank you again!

[mendenm]

What you were planning is pretty much exactly the way this can be used. Since the instructions you are exec-ing don't create any race conditions (they don't depend on where the program is executing), except for the exact snapshot time you capture 'x' in the ISR, it should do just what you want. All the 'exec' command does to the SM is (after compiling the instruction, if needed), writes the word to the appropriate register in the PIO register block. The hardwired SM logic handles how it gets put into the instruction stream.

[D-Paesani]

great, after a bit of digging around, it seems like StateMachine.exec(instr) relies on pio_sm_exec in hardware/pio.h, which in turn relies on the INSTR register:

inline static void pio_sm_exec(PIO pio, uint sm, uint instr) {
check_pio_param(pio);
check_sm_param(sm);
pio->sm[sm].instr = instr;
}

A final comment:

If, as suggested, I want to use the autopush feature, should grab it rely on in_ as follows?

grab_it = rp2.asm_pio_encode("in_(x,32)")

Thank you and best regards

[D-Paesani]

1. I was wondering wheter implementing everything (pulse count and timer to report data) in the same SM could be beneficial.
   I was thinking about something like this: (i still have to figure how to add some NOP()s to compensate delays...)

SM:
jmp(pin, "is_high")

label("is_low")

jmp(y_dec, "nopush1") 
in_(x, 32)
irq(nolbock, rel(0))
mov(y, osr)                #(re)load push timer on Y
label("nopush1")

jmp(pin, "rising_edge")    #low to high edge found
jmp("is_low")

label ("rising_edge")      #found rising edge
# jmp(x_dec, "is_high")    #do smth with rising edge
label("is_high")

jmp(x_dec, "nopush2")     
in_(x, 32)
irq(nolbock, rel(0))
mov(y, osr)               
label("nopush2")

jmp(pin, "is_high")
jmp(x_dec, "is_low")      #high to low edge found, decrement edge counter X
jmp("is_low")             #in case of overflows

2. For smaller counting gates time-bases (1 microsecond or so), i think the best approach would be to implement two SMs follows:

SM2:
issues a timer
when the timer overflows, raises irq(7)
set(pins, 1)
nop() [5]
set(pins, 0)

SM1:
counts edges on input pin
pushes data if triggered by irq(7) or if pins is HIGH

3. If, as I suspect, SM1 will have to use wait(1, irq, 7) as the only way to sync, meaning it must necessarily block (not being able to count pulses) waiting for SM2, a "push trigger" signal could be issued by sharing a PIN bewteen SMs.
   If, checking for the "push trigger" will be too complicated or compromise the pulse counting performance, SM1 could push the new count value every time a new count is registered:

SM1:
wait(0, pin, 0)
wait(1, pin, 0)
jmp(x_dec, "loop")
label("loop")
in_(isr,x) #with autopush at 32

and SM2, via DMA (piped from SM1 to SM2) would always access the updated count value, finally pushing it to the main program whenever needed.