Set mappings are much more limited than out mappings. You can only address 5 pins, but also writing to those pins has to be done from immediate values, i.e. encoded directly into the instruction. That makes working with set pins a lot trickier if the desired output depends on run-time data, such as whatever you might've received through the FIFO.
Out mappings can't just address more pins, but they're also tied into the output shift register, making it easier to express certain things. For example, consider
Code: Select all
@asm_pio(out_init=(PIO.OUT_LOW,)*4, out_shiftdir=PIO.SHIFT_RIGHT)
def prog():
pull()
out(pins, 4)
Implementing that same functionality of controlling 4 output pins using 4 bits sent to the state machine with sm.put(0b0101) using a set mapping would be a lot more work and not very practical.
The pioasm syntax, as documented at
https://datasheets.raspberrypi.org/rp20 ... asheet.pdf, uses
PIN for the
WAIT and
JMP instructions when referring to an individual pin, but
PINS for the
MOV,
SET,
IN, and
OUT instructions when referencing a set of consecutive pins. I presume
pin and
pins exist to keep PIO programs generated with python looking pretty much the same as their PIO assembler equivalents, just like the
__getitem__ implementation that allows for delays to be expressed using
nop() [x].
IN_HIGH and
IN_LOW are still mysterious to me. They do actually set the pull-down enable and pull-up enable bits, but I'm not sure what the behaviour of those is when the input-enable bit is set. The datasheet doesn't really cover that, or what setting both the pull-up and the pull-down bits means, though the C SDK does mention a "bus keep" function that weakly pulls towards whatever the current pin state is.