Pinscope beyond the ESP32: Zephyr, Raspberry Pi Pico, Linux and ESP8266
Pinscope started on the ESP32 because that is where we needed it. The device side was written in portable C from the start, and today the same remote access, logs, metrics, crash reports and firmware updates run on Zephyr, the Raspberry Pi Pico 2 W, Linux and the ESP8266.
What is the same everywhere
One outbound connection from the device to Pinscope, over the Noise protocol instead of TLS, so nothing is opened on the router and no VPN is needed. Over it:
- the device's own web server gets an HTTPS address, behind your login, a share link or an API token;
- its log output is streamed and stored;
- health numbers arrive without code: memory, stack, signal, uptime, restarts;
- a crash survives the reboot and is decoded with the ELF of that build;
- new firmware goes from the dashboard to the device, with the platform's own way of falling back.
The dashboard, the alerts, the share links and the API are the ones you know from the ESP32. A project can hold devices of every kind.
Each platform, the way it is used there
| Adding it | Updates | RAM | |
|---|---|---|---|
| Zephyr | A west module and two lines in prj.conf; no code | MCUboot, zephyr.signed.bin | about 8.6 KB with a 4 KB thread stack |
| Raspberry Pi Pico 2 W | One CMake include and one call | UF2 into the other A/B partition, with try-before-you-buy | about 9 KB |
| Linux | One command installs the agent as a service | Your file, handed to your install command | a small process |
| ESP8266 | An SDK component, the key in menuconfig, one call | The SDK's two OTA slots | about 7 KB |
| ESP32 | One line, on ESP-IDF, Arduino or PlatformIO | Two slots with rollback | 9.4 KB |
Zephyr
Pinscope is a Zephyr module. Add it to west.yml, then:
CONFIG_PINSCOPE=y CONFIG_PINSCOPE_PROJECT_KEY="psk_..."
That is the whole integration. The module turns on what it needs (sockets, DNS, DHCP, settings storage) as defaults your configuration can still override, starts at boot, and stops the build with the fix in the message when something is missing, such as a storage partition or a random number source. LOG_* and printk output is sent to the dashboard. A fatal error is kept across the reboot; with the ELF uploaded, the dashboard shows the function and line. With MCUboot, updates work from the dashboard. It runs on WiFi, Ethernet and anything else Zephyr gives sockets on. The Zephyr guide.
Raspberry Pi Pico 2 W
One include in CMakeLists.txt and pinscope_start() once WiFi is up. Everything printed with printf becomes the log. Updates use the RP2350's A/B partitions: the new image boots on trial and is kept only when it reaches Pinscope; otherwise the bootrom goes back. The Pico guide.
Linux
A small agent, installed as a service with one command, puts a Raspberry Pi or a gateway in the same dashboard as its microcontrollers: its web interface from anywhere, its journal, memory, load, temperature and disk. An update is a file you upload and a command you choose, so it can be a .deb, a container image or a script. Reaching a Raspberry Pi behind NAT.
ESP8266
For the ESP8266 boards still in the field: the same component as on the ESP32, in the ESP8266 RTOS SDK, in about 7 KB of RAM, where a TLS session would take a large share of the free heap.
New free tools
Like the ESP32 tools, they run in the browser and send nothing anywhere:
- Zephyr fatal error decoder: the fault, the reason, every CFSR bit explained, and the call trace with functions and lines.
- Cortex-M HardFault decoder: CFSR, HFSR, MMFAR and BFAR from any source.
- MCUboot image inspector: version, TLVs, the hash checked, and a warning when an image is signed with MCUboot's published development key.
- UF2 converter: .bin to UF2 and back, for the RP2040, RP2350, ESP32-S2/S3, SAMD, nRF52840 and STM32.
- ESP8266 exception decoder:
Exception (28)and the stack dump, decoded with the ELF.
Beta
The ESP32 component is the one most devices run today; the other platforms are new. They are in beta while we test them on more boards. If yours is not covered, or something does not work, write to hello@pinscope.dev: we answer, and we fix it.
Try it
Three devices are free, and no card is needed. Create an account, or read the guide for your platform: ESP32, Zephyr, Raspberry Pi Pico, Linux, ESP8266.
More
- Remote access to an ESP32 without TLS: what it measured and what it costs
- Reaching an ESP32 web server from outside its network
- Updating ESP32 firmware over the internet, with rollback
- Guru Meditation Error: decoding the backtrace, and crashes from the field
- Remote logging: ESP_LOG without a serial cable
- Heap and stack monitoring in the field
- An ESP32 behind CGNAT, 4G or Starlink
- TLS memory usage on the ESP32, and how to reduce it
- Sharing an ESP32 sensor page with anyone, without port forwarding
- ArduinoOTA over the internet, with a rollback
- ESP32 remote access compared: port forwarding, ngrok, Cloudflare Tunnel, Tailscale
- esp_http_server slow? The 250 ms delay and the fix
- Before the first ESP32 ships: a field support checklist
- ESP32 exception decoder: a Guru Meditation backtrace to lines, in the browser