rp2.StateMachine: state machine fails when I2S protocol is used
A rp2 state machine instance can be made to fail when the I2S protocol is used.
Minimal test to reproduce
The code below uses a PIO state machine to flash the onboard LED on a Raspberry Pi Pico development board.
- Working case: Onboard LED will flash for STATEMACHINE_INSTANCE = 1...7
- Failure case: Onboard LED will NOT flash for STATEMACHINE_INSTANCE = 0 (shows the Issue)
import time
from machine import Pin, I2S
import rp2
STATEMACHINE_INSTANCE = 0
@rp2.asm_pio(set_init=rp2.PIO.OUT_LOW)
def prog():
pass
sm = rp2.StateMachine(STATEMACHINE_INSTANCE, prog, set_base=Pin(25))
i2s = I2S(0, sck=Pin(16), ws=Pin(17), sd=Pin(18), mode=I2S.TX, bits=16, format=I2S.STEREO, rate=22_050, ibuf=10000)
while True:
sm.exec("set(pins, 1)")
time.sleep(0.5)
sm.exec("set(pins, 0)")
time.sleep(0.5)
In the failure case (STATEMACHINE_INSTANCE = 0) , both the rp2.StateMachine instance and the machine.I2S instance try to use state machine 0. Because I2S instantiation follows the rp2.StateMachine instantiation, the state machine configuration used by rp2.StateMachine is overwritten by I2S initialization. This causes a failure in the rp2.StateMachine instance (LED does not flash).
The root cause of this Issue seems to emerge from the rp2.StateMachine implementation. rp2.StateMachine does not make use of the functions for cooperative claiming of hardware that are provided by the Pico SDK. e.g. pio_sm_is_claimed(), pio_sm_unclaim(), pio_claim_unused_sm(). This does not allow any other MicroPython entities (such as I2S) to detect state machine configuration conflicts.
Suggestions for a fix to rp2.StateMachine implementation:
Enhance the rp2.StateMachine implementation to use the Pico SDK functions for cooperative claiming of PIO hardware. The I2S class implementation shows one way to use these functions, in the functions pio_configure() and pio_deinit().
rp2: Problem when creating more than 4 state machines [solved'ish]
I ran into a problem when I wanted to create more than 4 state machines. Five in may case. It seems that creating the fifth state machine interferes with the previous ones. Using the number sequence:
0 1 2 3 4 get trouble, even when SM 4 is not activated, just created.
The sequence 4 0 1 2 3 lets me at least state machines 0 - 3. It looks as if the creating SM 4 the instruction memory of PIO0 is used instead of that of PIO1
A quick glance at the code did not reveal an obvious place, and I do not have a simple test case yet. I will try to make one.
The actual case which fails does not use too many instructions. Like 22 in total. All but one SM consist of only two instructions. It is used for a 8080 type bus, and four of the variants just write to the bus using different data widths and control signals. They are separate to avoid the time needed to re-init.