A light-level program may work perfectly until a motor is added. The motor needs current that a logic pin is not meant to supply, and its behavior depends on the power path as well as the command.
This is an integration issue, not an advanced programming topic. In an Arduino forum thread about a board losing power with a servo, the board dropped out when the breadboard arrangement was connected, and the replies focused on the physical connections. On our bench we drove three kinds of load, a small fan module, a relay switching a geared motor and a MOSFET motor driver, from a Raspberry Pi Pico running MicroPython programs built in BIPES. In each case the GPIO only sends a control signal; a driver and a separate supply carry the load current.
A fan command is not a cooling result
The fan module has its own switching stage. Our program drove its control input on GPIO6 with 1 kHz PWM, raised the duty value in steps of 200 up to 8000, and waited three seconds at each step. On the duty_u16 scale, 8000 is about 12.2% high time. Our notes had described the end of the ramp as maximum speed; neither the command nor any measurement supports that, since we did not measure RPM.
The experiment establishes a control sequence for the driver. Whether a product stays cool is a different question. It needs the actual heat source, the enclosure airflow and temperature measurements. A spinning fan on the bench cannot answer it.
Use a relay for a defined switching task
The relay test set GPIO6 high for five seconds, then low. The relay switched a small geared motor powered from a low-voltage battery pack through a converter module. That low-voltage arrangement is all this test covers. It says nothing about switching household mains equipment, and should not be read as instructions for it.
A relay provides an on-off path. It is not a substitute for a PWM motor driver. Contact ratings, how the load behaves when switched, and how the module is actually built all matter if the setup is reused, and we did not verify those limits or any isolation clearances for another application.
PWM gives a command, not a controlled speed
The MOSFET driver program ran GPIO6 at 1 kHz with a duty value of 50000 for five seconds, then set it to zero. That is roughly 76% of the 16-bit range. Our notes called the result a middle speed, but we recorded no speed feedback and did not compare loads.
Motor speed can change with supply voltage and load at the same command. If a mechanism needs a repeatable speed or motion, decide what must be measured, add the sensor, and close the loop. Otherwise the same code will behave differently as the battery drains or the mechanism wears.
The driver module is described as optocoupler-isolated. That does not prove the complete wired system is isolated. If the controller and motor supplies share a ground or a converter, the isolation is bypassed. Trace every connection between the two sides before relying on it.
Document the command, driver, supply and load as one assembly
For each driven load in a prototype, write down:
- the control pin, PWM frequency and the duty range actually used;
- the driver module or circuit, and what it is rated for;
- the supply for the load, and how its ground connects to the controller's;
- the load itself, with its current at start-up and under the expected mechanical load;
- what the output does at power-up and if the controller resets.
That record is what turns a working bench demo into something a board designer can build. It is also where most early failures hide: a supply that sags when the motor starts, a shared ground that couples noise into a sensor, or a driver that runs hot only in the closed enclosure.
For a first integration trial, keep that whole chain connected the way the product will be, run the load through its real duty cycle, and measure supply voltage at the controller while the motor starts and stops.