PIO question

[jean-claudeF]

Hi,
can somebody explain what's wrong in this simple test program?

from rp2 import asm_pio
import machine

@asm_pio()
def test():
    mov(isr, 1234)  # Load a test value
    push()          # Push to FIFO

sm = rp2.StateMachine(7, test, freq=1_000_000)
sm.active(1)

import time
time.sleep(0.1)  # Give time to execute

if sm.rx_fifo() > 0:
    print( sm.get())  # Expecting: 1234

[Josverl]

you are trying to create/run an instruction that is not possible in the PIO

so your source 1234 or 010011010010 is actually interpeted as mov( isr, y )

AFAIK there is no direct way to load a 32 bit number from code into one of the fifos

you can provide a number, and have the pio echo that back ( or do something more interesting )

import time
import machine
from rp2 import PIO, StateMachine, asm_pio

# Define a PIO program
@asm_pio()
def test():
    pull()            # Pull a value from the TX FIFO into OSR
    mov(isr, osr)     # Move the value from OSR to ISR
    push()            # Push ISR to RX FIFO

# Initialize StateMachine with the PIO program
sm = StateMachine(0, test, freq=1_000_000)

# Load a value into the TX FIFO
input_value = 1234
sm.put(input_value)

# Activate the StateMachine
sm.active(1)


time.sleep(0.1)  # Give time to execute

# Check if there is data in the RX FIFO and print it
if sm.rx_fifo() > 0:
    output_value = sm.get()
    print(f"Input: {input_value}, Output: {output_value}")

The documentation for the pio.mov instruction is :

        Copy data from Source to Destination.

        Destination:
            - 000: PINS (Uses same pin mapping as OUT)
            - 001: X (Scratch register X)
            - 010: Y (Scratch register Y)
            - 011: Reserved
            - 100: EXEC (Execute data as instruction)
            - 101: PC
            - 110: ISR (Input shift counter is reset to 0 by this operation, i.e. empty)
            - 111: OSR (Output shift counter is reset to 0 by this operation, i.e. full)

        Operation:
            - 00: None
            - 01: Invert (bitwise complement)
            - 10: Bit-reverse
            - 11: Reserved

        Source:
            - 000: PINS (Uses same pin mapping as IN)
            - 001: X
            - 010: Y
            - 011: NULL
            - 100: Reserved
            - 101: STATUS
            - 110: ISR
            - 111: OSR

        MOV PC causes an unconditional jump. MOV EXEC has the same behaviour as OUT EXEC (Section 3.4.5), and allows register
        contents to be executed as an instruction. The MOV itself executes in 1 cycle, and the instruction in Source on the next
        cycle. Delay cycles on MOV EXEC are ignored, but the executee may insert delay cycles as normal.
        The STATUS source has a value of all-ones or all-zeroes, depending on some state machine status such as FIFO
        full/empty, configured by EXECCTRL_STATUS_SEL.

        MOV can manipulate the transferred data in limited ways, specified by the Operation argument. Invert sets each bit in
        Destination to the logical NOT of the corresponding bit in Source, i.e. 1 bits become 0 bits, and vice versa. Bit reverse sets
        each bit n in Destination to bit 31 - n in Source, assuming the bits are numbered 0 to 31.
        MOV dst, PINS reads pins using the IN pin mapping, and writes the full 32-bit value to the destination without masking.
        The LSB of the read value is the pin indicated by PINCTRL_IN_BASE, and each successive bit comes from a higher numbered pin, wrapping after 31.

[jean-claudeF]

Yes, that's what I was looking for!
Not astonishingly, it is very accurate for low frequencies, and less for high ones.
For a frequency counter I could alternatively use this idea:
count low to high transitions by decrementing the X register, and after e.g. 1 second read X to get the frequency.

[scruss]

Similarly, there's this very simple PIO pulse counting code: upy-examples/pico/pio_pulse_counter.py at master · dhylands/upy-examples

[jean-claudeF]

@peterhinch :
Is there any reason for the 1 clock delay
jmp(x_dec, 'next') [1]
you are using?
If I understand well, it would work without this with an increased resolution of 16ns?

[peterhinch]

The reason is in the period measurement. The period SM measures the high time and the low time, summing the results. The delay in the high time measurement is to equalise the number of states required by the low time measurement. The latter uses three cycles because of the

jmp(pin, 'done')

instruction.

The mark SM uses the same delay purely to enable the same scaling to be used for each SM. If you only need the mark SM you could indeed remove the [1] and adjust the scaling accordingly, with a gain in resolution.

[jean-claudeF]

Thank you Peter,
I was just about to draw this conclusion myself.