Introduction
During hardware bring-up and firmware development, our desks usually end up covered in a mess of USB cables. Testing a new sensor or bringing up a custom board often requires a dedicated USB-to-UART bridge, a separate dongle for I²C/SPI, a CAN bus adapter, and a logic analyzer to verify timing. Worse, each of these tools requires its own desktop software and specific driver environments.
We wanted to eliminate this fragmentation and physical clutter. Our goal was to consolidate protocol-level interaction (SPI, I²C, UART, CAN) and signal-level visibility (GPIO, ADC, DAC) into a single wireless platform.
The result of this effort is bUniProbe. Instead of relying on a USB tether and desktop applications, we moved the entire control interface to the local network. The device hosts its own web server, allowing us to debug buses and monitor signals directly from a web browser. Here is a look at the architecture and some of the engineering challenges we had to solve to make it work.
The Hardware Architecture: Handling Multiple Logic Levels
One of the most persistent annoyances in hardware debugging is dealing with logic levels and floating lines. Typically, moving between a 3.3V and a 5V system requires wiring up external level shifters. Similarly, if an I²C line is floating, you have to dig through your parts bin for a 4.7kΩ resistor and stick it on a breadboard.
To handle this entirely within the hardware, we designed the front-end to be dynamically configurable via the UI.
We implemented adjustable level-shifting circuitry that allows the user to switch the entire system voltage between 3.3V and 5V on the fly. For line stability, we added a controllable resistor network. Instead of hardwiring pull-ups, the MCU can selectively switch in a 10kΩ pull-up, a 10kΩ pull-down, or disable them entirely on a per-GPIO basis across all interfaces. For the I²C bus specifically, we added dedicated, switchable 4.7kΩ pull-ups to meet the standard spec.
Serving the UI and Real-Time Data over Wi-Fi
Moving from a hardwired USB connection to Wi-Fi introduces constraints around latency and throughput, particularly when dealing with high-speed buses or continuous streams of data like UART logs, ADC readings and CAN messages.
To handle this, we split the communication strategy into two distinct paths:
- REST API for State & Configuration: For discrete actions such as i2c/spi transmissions, toggling a GPIO state, controlling analog outputs, changing the logic level, or configuring the Wi-Fi credentials, we use standard REST endpoints. This makes the system predictable and allows users to easily write Python or bash scripts for automated testing without needing to use the web GUI.
- WebSockets for Real-Time Traffic: Polling a REST endpoint is a little slow for protocol traffic. To stream live CAN bus messages, UART logs, continuous ADC readings, and more such traffic to the browser, we implemented WebSockets. This maintains a persistent, low-latency connection.
Waveform Rendering in the Browser
A major part of bringing up hardware is simply seeing the signal. While bUniProbe isn’t a 100MHz oscilloscope, we needed a way to visualize digital GPIO states and analog voltage levels (via the 4-channel, 10 KSPS ADC and 2-channel DAC) in real-time.
The browser parses these frames and pushes them directly to the rendering pipeline, resulting in a smooth, continuous oscilloscope-style view without spinning up the user’s laptop fans.
What’s Next
Moving the debugger to the local network has fundamentally changed how we do hardware bring-up. It allows multiple engineers to open the same IP address and view the bus traffic simultaneously, and it completely removes driver installation from the equation.
We are open-sourcing this project (both hardware and firmware) and launching it soon on Crowd Supply.
If you are interested in the hardware files, the REST API documentation, or grabbing a board for your own lab, you can check it out here: https://www.crowdsupply.com/bitmerse/buniprobe