Two channels of a prototype work separately. Put them together, and a light changes before its partner, or a second measurement starts while the first is still finishing. Both channels may be running at the rate you asked for. What is missing is an agreement about their timing relative to each other.
Before asking for "synchronized outputs," decide what the product needs: the same repetition rate, a shared starting edge, or a new round that begins only when every channel is ready. Those are different requirements. A visual installation may tolerate a delay that would make a measurement trigger useless.
On the RP2040, PIO state machines can run independently and coordinate through flags. This note is a planning reference for that: what the hardware can help with, and what still has to be demonstrated on your prototype. It is not a record of a measured multi-channel synchronization test.
Give "together" an observable meaning
Take a proposed display with two separately controlled light groups. "Both update 50 times a second" describes a rate. "Both begin their next update on the same trigger" describes coordination. "The visible changes happen within an agreed interval" describes a result a tester can measure. Do not substitute one statement for another.
A Raspberry Pi forum discussion from late 2021 shows the distinction in another setting. The author used four ultrasonic measurement channels and found that differing measurement durations complicated the next round. The thread explored synchronization strategies, and the author reported that an initial suggestion did not work for their setup. It shows the integration question, not a validated recipe for triggering several acoustic sensors together.
For your project, write down which edges or actions matter, the allowed difference between them, and what should happen if one channel cannot finish. If the receiving module has its own processing delay, a simultaneous electrical trigger does not prove simultaneous physical output either. Pick the observation point to match what the user or the measurement actually depends on.
PIO can run tasks in parallel without making them identical
Each RP2040 PIO block contains four state machines: small hardware engines that run short I/O programs. They can run the same program on several channels, run different programs, or split one interface into parts. The RP2040 datasheet, section 3.2.7, documents this independent execution and the use of IRQ flags for coordination.
Independence is useful: one channel can handle a signal while another does different work. It also means a channel can take a different program path, or wait for an input or for data. Sharing a clock source does not remove those differences.
So an aligned start is only part of the design. If one program later waits while the other continues, their output events drift apart even though the clock dividers stay aligned.
Choose a mechanism for the requirement you actually have
The Pico C SDK has a helper, pio_enable_sm_mask_in_sync. According to its documented implementation, it enables selected state machines in one PIO instance while restarting their clock dividers on the same cycle, so with equal divisors their divided clocks stay in step. Program state and later execution still have to be arranged to produce the intended output relationship.
That is a C SDK facility, not a MicroPython method. MicroPython's StateMachine documentation describes active() as controlling one machine at a time. Calling sm_a.active(1) and then sm_b.active(1) does not express a simultaneous start. If the timing requirement needs one, make the start mechanism an explicit firmware integration task.
PIO IRQ flags let one program wait for another's progress, which suits a requirement like "do not proceed until this event." A repeated coordination scheme has to say who sets and clears each flag, what counts as ready, and what happens when a participant stops. A short set-and-wait sketch is not a reusable barrier. Match the design question to the requirement:
- Matching repetition rates: do both programs produce the intended period, including branches and waits?
- Aligned first output events: are start conditions, clock phases and instruction paths arranged together?
- Repeated coordinated rounds: is there an explicit ready and release arrangement, with clear flag ownership?
- Recovery when one channel stops: does the system stop, skip a round or restart the group, and can that be observed?
Test relative timing across the whole operation
Capture the relevant outputs together on a suitable logic analyzer or oscilloscope. Compare the edges at startup, after several rounds and after a restart. A frequency counter, or two captures taken at different times, cannot establish the relative timing you agreed to measure.
Then exercise the conditions that could make one path wait: a delayed input, a temporary lack of outgoing data, or the application's normal background work. The right cases depend on the program. Record the board, firmware, clock settings, capture configuration and the permitted timing difference. We have no such captures yet; this is the proposed validation work.
It also gives a project owner something concrete to review with the engineer. Instead of asking whether PIO is "fast enough," ask whether the required outputs stay within their agreed timing relationship during normal operation and recovery. That answer is much closer to deciding whether the prototype is ready for its next use.