Your prototype needs a clock signal, and a small module can generate one. You add buttons and a display, choose a frequency, and the screen shows the number you wanted. The next question is what actually reaches the circuit under test, especially when you change that number or press Stop.
We built a portable menu-controlled clock source on our bench: an Si5351 clock module, an SSD1306 OLED and a PCF8574 button pad on a GraftPort RP2040 board in an acrylic enclosure, running MicroPython 1.23. We operated the menu and measured one output on an oscilloscope at 12.0 MHz. The point of this note is to connect three things: the setting a person chooses, the command the software sends, and the waveform the connected circuit receives.
Start with the circuit you want to test
A clock source supplies a repeating timing signal. It can exercise a compatible digital input or show how a circuit behaves at different rates. Before choosing a module, write down the required frequency range, the input voltage limits, and whether the receiving circuit must keep running during a frequency change.
That last requirement can matter more than the maximum frequency on a product page. In an Arduino forum thread from October 2021, an audio developer reported clicks when varying an Si5351-derived clock for a delay circuit, and later resolved it by changing the library and scaler approach. Different system, same lesson: a steady-output test does not answer every integration question.
Our build is a menu-operated square-wave clock experiment. It is not an adjustable-amplitude sine source and not a calibrated frequency reference. If you need either, treat it as a different requirement, not an extra menu option.
Put the controls and the clock on their intended buses
The display and button pad sit on a connector expansion board attached to I2C0. The startup scan looks for the display at 0x3C or 0x3D and the buttons in the 0x20 to 0x27 range. An expansion board only adds connectors to the bus; it does not give two devices with the same address separate addresses.
The Si5351 sits on I2C1, where the scan checks for 0x60 or 0x61. In our log the scans found the clock at 0x60 and the control devices at 0x20 and 0x3C. Confirm the addresses on your actual modules. A scan that prints what it found is not the same as checking that the expected device was found.
Power comes from an SY7656 battery charge and discharge module. The two-wire cable we used is marked red for GND and black for VCC, the reverse of the usual convention, so verify polarity from the labels and with a continuity test while unpowered. Check the power indicators before assembly, and keep the signal output disconnected from the circuit under test until power and communication are confirmed and the output level has been checked against the receiving input's limits.
When mounting the parts, keep the clock connectors and the control buttons reachable. On this board, RUN switch 2 must be on when no external watchdog module is fitted; check that before troubleshooting a board that appears dead. We did not measure battery runtime or charging temperature inside the enclosure.
Understand what the four menu entries do
The firmware separates startup, a scheduler, menu handling and the device drivers. A control task reads the buttons every 200 ms, with a 50 ms scheduler tick. Those intervals govern menu handling, not the MHz waveform the clock chip produces.
The menu has four entries: freq, output, open and stop. Up and down choose an entry, SW1 enters or applies it and SW2 goes back. Left and right change the frequency in 1 MHz steps or select output 0, 1 or 2.
The order matters. Select the channel, apply its frequency, then enable it. Applying a frequency first disables the selected output and then programs it; the open action enables it. Changing the selected channel only changes the selection. It does not copy the displayed frequency into that channel's registers.
The menu allows a value of zero, but the fixed-PLL frequency routine in our driver does not treat zero as a stop command. Use stop. Before handing the fixture to someone else, remove or reject unsupported settings instead of expecting them to know which displayed values are valid.
There is a second trap. The board's own button pauses the menu task; it does not disable the clock outputs. And stop disables only the selected output, not all of them. A sensible next revision would show each channel's enabled state and add a deliberate all-outputs-off action. We have not built that yet.
Read the scope measurement for what it shows
The oscilloscope read 12.0 MHz with a period of 83.20 ns, and the trace showed clear overshoot and ringing at each transition. That is more useful than an ideal square-wave drawing, as long as you read it honestly.
It supports a frequency observation at one operating point. It does not record the probe connection, the load, the full measurement setup or calibration uncertainty, so it says nothing about accuracy across the menu range. We also cannot diagnose the ringing from this measurement alone. Tektronix's probe primer explains how a long probe ground connection can itself add ringing and change the observed edges. Check the measurement setup before blaming the source.
The menu log tells a separate story. It shows which addresses were found and which menu actions ran, which helps separate an addressing problem from an output-control problem. It does not show that the electrical output changed. (Our startup banner still carried the name of an earlier project, a reminder that logs need cleaning before anyone else relies on them.)
Check the frequency plan before reusing the firmware
Two configuration points need review before treating this firmware as a reusable clock source.
First, all three outputs share one PLL in our configuration, and the driver can reset that PLL when it changes a divider. Being able to pick channels independently in the menu is not evidence of independent, uninterrupted timing. If changing one output might disturb another, capture both signals during the change.
Second, the firmware combines a 25 MHz crystal setting with a multiplier of 15, which gives a calculated internal PLL frequency of 375 MHz. Skyworks' AN619 frequency-planning note specifies 600 to 900 MHz for the devices it covers. Confirm the exact chip revision and use a supported frequency plan. Our single 12 MHz measurement does not validate the existing configuration across settings or conditions.
Turn the demonstration into a test fixture
For the next test, record the selected channel and setting together with the probe, the ground connection, the receiving load and the measured waveform. Compare startup, steady operation, a frequency change and the explicit stop action.
Then add the missing clarity: list the settings you have verified, show which channel is enabled, label the output's electrical limits, and keep a repeatable measurement record. With that, a colleague can answer a better question than "does the screen say 12 MHz?" They can check whether the intended signal reaches the intended input, whether it survives the transitions the product needs, and whether Stop does what they expect.