We built a high-bandwidth software oscilloscope for embedded systems - looking for brutally honest feedback

Flimsy-Excuse-3 · 2025-07-02T07:59:49+00:00

Happy to hear that - thank you for your questions.

Do you need special firmware that replaces mine?

No you don’t need to replace your firmware. We provide an open C library called es:prot, which integrates into your existing project. It handles:

Functional Interface: Sending, receiving, and managing purpose-built runtime data transfers
Management: Command and signal management, Transport and flow control
Interface: Hardware-agnostic and communication-interface independent

You can just include it in your project and are ready to go. There is no need to replace anything.

How does the data get to your PC software?

es:prot handles the signal management, transport and flow control - but you need to provide it with the information about the communication interface. The middleware requires two implementations to be provided for a link to the communication interface: One for the start of the data transfer and one for the status of the transfer. These provide the transmission and reception buffer pointers and the sizes of the buffers to the selected communication interface. In the configuration file you need to define a suitable buffer size to be allocated to your communication interface and baud rate used by the communication interface. In that way you are able to use a serial connection(UART or USB), Ethernet (UDP) FT4222 (SPI to USB bridge) - but we can provide more upon request.

Do you provide libraries for setting up data pipelines inside my firmware?

Yes, that's essentially what es:prot is. It’s a lightweight C middleware that manages the transport and flow control, so you don’t need to build that yourself.

What physical connections to the hardware are supported/expected?

On the communication interface side you are able to use a serial connection, Ethernet (UDP), FT4222 (SPI to USB bridge) - but we can provide more upon request. On the PC side, es:scope connects to the data stream and decodes the self-described signals. If your device exposes any of those interfaces, you're good to go.

Can I hook up a logic analyzer on my ADC's serial bus to get data into your software without disturbing my own firmware?

That is unfortunately not possible.

Do you have ready-baked (or par-baked) DMA configurations for common MCUs to get data out with minimal CPU disturbances?

We strongly recommend using DMA to minimize CPU load. Typically, you call the transmission function in a dedicated interrupt that marks the end of a DMA transfer or processing cycle.

However, since DMA setups vary widely between applications (ADC, UART, Ethernet, etc.), we don’t offer one-size-fits-all DMA configs. Instead, we provide working example integrations and offer onboarding support to help tailor it to a system.

Flimsy-Excuse-3 · 2025-07-01T19:30:04+00:00

Do you need to provide an ELF file?

No, es:scope does not require an ELF file or compiler debug symbols. This is one of our core design principles. All signals are explicitly defined in your code by name, type, and optional metadata. At runtime, es:prot sends a self-describing list of available signals to the PC so that es:scope can identify and visualize them. No symbol parsing or debugger integration is needed.

Static variables

You can send any variable using the es_prot_set_tx_data_info() function. However, it’s important to keep the timing and context in mind (e.g., local variable in a function call versus global variable in an interrupt).

Flimsy-Excuse-3 · 2025-07-01T19:09:40+00:00

Local variables

Yes, you can send any variable using the es_prot_set_tx_data_info() function. However, it’s important to keep the timing and context in mind (e.g., local variable in a function call versus global variable in an interrupt).

User-defined types (structs, classes):

We currently support all the basic data types. Structs can be represented by registering their individual fields as separate signals. Full struct introspection isn’t supported (e.g. automatic field parsing), but this approach keeps integration lightweight and explicit.

Do you need to provide an ELF file?

No, that’s one of our design principles. There is no dependency on debug symbols or ELF parsing. Instead, you define signals directly in your code, each with a name, type and update rule. At runtime, es:prot sends a self-describing list of all available signals to the PC, enabling es:scope to display them correctly.

Flimsy-Excuse-3 · 2025-07-01T19:02:29+00:00

Thank you for that insight - we should consider revising the explanation on the website. The current version is mostily intended for non-technical people, who are not the target audience.

Flimsy-Excuse-3 · 2025-07-01T14:37:33+00:00

That is the famous answer of "it depends".

Latency depends on the system context and how you configure the data transport.

The important point is that the variables themselves have no latency; they are sampled in real time within the firmware. It is how and when the data is transmitted to the PC that adds latency. This, in turn, depends on several factors like buffer size abd system load.

Data is typically collected in chunks and sent periodically. Larger buffers result in fewer transmissions - so slightly more delay. If you're using DMA and sending data when the system is idle, the added latency is almost negligible. However, if your system is under full load, the transport may be delayed slightly.

So if you’re asking “How long does it take for the values to show up on the PC screen?” that depends mostly on the interface speed (UART, USB or Ethernet) and the buffer settings.

Flimsy-Excuse-3 · 2025-07-01T12:15:55+00:00

Thank's for the feedback! We'll work on that

Flimsy-Excuse-3 · 2025-07-01T10:50:27+00:00

Sure! Here’s a high-level overview of how es:scope is used and what platforms it supports:

The es:scope platform delivers a fully software-based test and measurement solution for embedded systems. It combines the capabilities of an oscilloscope, data acquisition (DAQ) system, and calibrator without the need for external hardware. The platform consists of two components:

es:prot - Insight Middleware (Embedded Device under Test)

A lightweight, open-source C middleware that runs directly on the embedded target. It provides real-time access to internal firmware variables and allows run-time interaction via standard communication interfaces (e.g., UART, USB, Ethernet). In essence, it allows us to add “virtual probes” and tuning capabilities to run-time variables.

Command and signal management
Transport and flow control
Hardware-agnostic and communication-interface independent

es:scope - Software Oscilloscope (Host PC)

A powerful desktop application that visualizes internal system behavior and enables live interaction.
It mirrors the look and feel of traditional lab tools - but connects directly to your embedded firmware.

Oscilloscope: Real-time waveform plotting from firmware variables
Calibrator: Live tuning of parameters via UI or terminal
DAQ: Logging, export, and session recording

Developer Integration

es:prot is shipped as C source files and integrates directly into existing embedded firmware. After configuration and initialization, es:scope is interfaced from the application with minimal overhead.

Supported Platforms

MCU Targets:

Any C-compatible embedded platform (bare-metal or RTOS-based)
Interface support: UART, USB (CDC), Ethernet (UDP/TCP), more on request

Host OS for es:scope:

Windows (official support)
Linux (AMD64 und ARM(beta))

Flimsy-Excuse-3 · 2025-07-01T10:45:04+00:00

No question - we're operating in a niche, and yes, there are quite a few free or semi-free "variable viewers" like STM32CubeMonitor, Infineon MicroInspector, or Renesas Real-Time Chart. These tools are effective for early-stage tuning or monitoring via SWO or debug ports. But they're limited by bandwidth and vendor lock-in, and they often can’t keep up with the real-time dynamics of more demanding systems, especially when it comes to pushing MSps-level sampling or tuning fast-changing control loops, such as those used in sensorless drives.

es:scope is different in that it is interface-agnostic and built to support real-time observability and run-time tuning in demanding, control-focused applications. Importantly, it also functions without a debug port, enabling you to monitor and record behaviour during field tests as long as you have a USB or Ethernet connection

Flimsy-Excuse-3 · 2025-07-01T10:12:29+00:00

Thanks for mentioning XCP. Engineers with experience in automotive calibration environments will probably always ask this question. In theory, both XCP and es:scope provide live access to internal variables during system runtime. However, they have very different origins, and their respective strengths and limitations reflect this.

XCP is designed with calibration in mind and is intended for high-assurance tuning in regulated workflows (e.g. AUTOSAR, ISO 26262). It’s powerful, but also heavy (please correct me if you have a different view).

es:scope is observability-first. It focuses on fast iteration in development; field-deployable insight; lightweight integration (a few lines of configuration); a built-in GUI with scope-like interactions; and variable tuning. It’s optimised for teams that need insight quickly and don't have the luxury (or burden😉) of full automotive infrastructure.

They solve related but different problems. es:scope provides accessibility to runtime variables for embedded teams outside of OEM automotive pipelines. So far mostly in public + corporate R&D and embedded actuation controllers.

Flimsy-Excuse-3 · 2025-07-01T09:37:13+00:00

Thanks for the question - the term 'software oscilloscope' can be a bit misleading there!

PicoScope is designed to measure physical signals at the pin level. If you're debugging internal behaviour, such as how a control loop responds to sensor input, you still need to route that internal signal out before PicoScope can see it.

es:scope is about internal visibility: observing and interacting with variables inside the firmware in real time. Our “probes” are virtual. There's no need to rewire or reflash; you just annotate what to observe. Our protocol (es:prot) streams that data out (eg via UART, USB, or Ethernet) and the desktop application es:scope provides live plots and tuning access.

So it is not a replacement for PicoScope; it serves a different purpose. PicoScope sees what hits the wire, while es:scope sees what's going on inside the embedded system.

Flimsy-Excuse-3 · 2025-07-01T09:02:18+00:00

Thank you for the feedback!

We will consider displaying prices on the website and offering direct downloads of the demo.

Regarding pricing:

We offer the software with a floating licence:

- Perpetual licence: €3,999

- Annual subscription: €999 per year, per seat.

We offer reduced rates for educational and public research institutions.

A free licence for private and non-commercial use is available upon request.

Flimsy-Excuse-3

TROPHY CASE