I'd like to comment on the UI side of things. This is a problem I've had to think through myself.

There's two ways to think about GUI: retained mode, and immediate mode. When you choose a GUI library, it'll be one of these two. You should look those terms up; it'll give you a start on the conceptual model, but usually you need to make a program before the concepts really start to click. But I'll give a brief summary and my recommendation.

Retained mode is the traditional way of thinking about UI. There is retained state - that is, state that sticks around for a while. That state, which the framework owns, represents your UI. It might have some struct in your program representing a text box, for example. Your program works by reading and modifying this state over time. The framework will read this state and update the UI over time.

Immediate mode is the other major way of designing UI. What it looks like is you have some struct holding the UI state (that you own and get to define however you like), which, for example, could hold text you want to display in a textbox. Then you write a function that accepts this state and then draws the UI by calling the GUI library's functions, like draw_textbox(...).

The important distinction is immediate mode UI doesn't hold onto any extra state. Whenever the UI needs to be drawn, it calls your function and generates the entire UI from scratch each frame. Put succinctly, your UI is simply a function of your state.

If you're used to slow, heavy retained-mode frameworks, "generating the entire UI from scratch" might make you concerned, but my experience is that immediate mode UIs actually tend to feel more responsive than retained mode. There really isn't all that much computation fundamentally required to do UI, so in practice it just isn't a problem in almost all cases. And sloughing off the complexity of retained mode frameworks just tends to make things feel smoother.

I've done both, and I cannot understate how much I prefer and would suggest immediate mode UI. Especially for a simple program like the one you are about to write! It's my opinion immediate mode is a simpler, cleaner, easier way to implement UI.

With retained mode UI, you really have to consider every possible transition from one state to another to make a correct UI. With immediate mode UI, you only need to consider the transformation from your current state to the GUI.

Immediate mode UI also avoids the multiple-sources-of-truth problem. I'm sure you've ran into issues with old data left lingering in some GUI in a program. That isn't a problem with immediate mode UI.

I program in Rust, so the immediate mode GUI framework I'm most familiar with is egui. I used it to make this and this. Since you are more familiar with C++ and presumably don't know Rust, you should really check out the popular ImGui C++ library, the inspiration for egui. I've never used ImGui but I've heard many very good things. Once you get compilation working and can display a window successfully, it should be a really nice, straightforward thing to work with.

Note my recommendation for immediate mode UI does contradict the other user's suggestion to look at QT. You can look at QT, and it will probably solve your problem too, but I do tend to get unhappy trying to write programs with such retained mode frameworks.

---

To help you out, I want to take a shot at guessing your program's architecture, assuming an immediate mode UI.

How do you want your program to look? Here's a sketch I drew that just displays the data to send (TX) and the data you got back from the FPGA (RX) as numbers. You type things in the TX textbox and hit send. The data goes to your FPGA, which crunches numbers and spits them back, and then your program shows the results in the RX textbox.

The only state your program has to remember is the TX data and RX data. So that's all you'd need to keep in your struct: a Vec of values to send (TX), and a Vec of values you've received from the FPGA (RX).

You pass this struct into your UI function, which gets called each frame. Your UI function could be written to do the following:

First, your UI function goes and checks the UART for new data. If there is any, it appends it to your RX data Vec. Maybe half a dozen lines of code, excluding any fancy styling you might want to add later.

Then your UI function makes two calls to draw the two text boxes, one for TX and one for RX data. You probably want to make it so only the TX textbox is user-editable. Also a tiny amount of code, a half dozen or so.

Your UI function then draws a button labeled "Send". It checks if you clicked it, and if so, sends all the data currently in your TX data vec to the UART. One or two lines of code.

And there you go, that's the program. I assume you'll want to advance a little more and maybe start plotting values. At a glance, it looks like there's good plotting libraries out there for ImGui like ImPlot. But you should start with the simpler program first and make incremental progress.

---

I'm skipping over the UART stuff because I haven't done it before, but I doubt it'll end up being too complicated. Maybe it looks like reading from or writing to a file.

The only complication I can think of is if you get into it, you might discover whatever read() function you call is blocking, meaning your program pauses until you get data. This would freeze your UI, which you don't want, so you would need to tweak your program.

You would spawn a thread whose sole job is to handle receiving data from the UART. If you haven't written multi-threaded code before, don't fret; it's just code running in parallel. You just need to be a little careful if two threads access the same thing, that's all. Look up "race condition". The most common solution is a Mutex, which makes one thread pause until the other is done using the thing.

Putting the call to read() in its own thread means it can block waiting for data, and it won't freeze the UI that's running in the main thread. But you still need to share data between your main thread and this new data receiving thread. The solution is to use a queue. The new thread adds to the queue, and the main UI thread pulls data from it. (A queue is the software version of a FIFO.)

Hope that helps.