hacknus / serial-monitor-rust Goto Github PK

I found out by talking to the maintainer that the added benefit of using serial2 crate is its better support for Windows: https://docs.rs/serial2/latest/serial2/. So taking this into use would make serial monitor more cross-platform enabled than it is today.

When build with -r flag, the plot is displayed wrong.

This is how it looks like in debug build:

When you connect device A which transmits 5 columns and then later one reconnect device A but now it transmits 6 columns, the sixth label is hidden. A "reset labels" is required, but then we need to re-enter all previous 5 labels.

Desired behavior: keep old labels and add a new one "Column 6".

once this issue is fixed, we can bump the project up to version 1.0.0

When logging for a long time ( 3 hours with 8 columns, 1 new value per second) the application gets laggy until I clear the data.

Based on my understanding, MyApp's plotting_range is used to limit the number of PlotPoint displayed on the screen. However, the default value of -1_isize is not very intuitive since it doesn't clearly indicate what it does. From the code, it appears that -1 means to display all the PlotPoints. Would not it be better to use usize::MAX as the default value?

Hi just want to race awareness that I've started work on a new ZMODEM crate recently: https://github.com/jarkkojs/zmodem2. It is progressing rapidly as can be witnessed from the Git log. I've also listed issues that I want to reach for my personal uses and purposes for this: https://github.com/jarkkojs/zmodem2/issues.

Would be interesting to see how this could eventually integrated to the serial monitor. Most likely at least https://github.com/jarkkojs/zmodem2/issues/5 and https://github.com/jarkkojs/zmodem2/issues/1 need to be completed before this is doable.

fn serial_write(port: &mut BufReader<Box<dyn SerialPort>>, cmd: &[u8]) -> bool {
    let write_port = port.get_mut();
    match write_port.write(cmd) {
        Ok(_) => {
            let mut response = "".to_string();
            serial_read(port, &mut response);
            println!("sent a command!");
            if response.contains("OK") {
                true
            } else {
                println!("cmd not acknowledged!!!");
                false
            }
        }
        Err(_) => false,
    }
}

The code expects a connected device to send back a string that contains "OK" each time it receives a command. I am not sure if this is a reliable way to handle a response, as the device on the other end may not have processed the command yet or may take some time to send a response.

Also, even if a device can respond quickly enough, I am not sure if the app can always read a "OK". Doesn't the app read whatever data in the RX buffer? Let's say a device sends "0.1" 100 times a second. The device sends back "OK" when it receives a command. When the app calls serial_read, does it always read "OK"? Or sometimes it reads "0.1"?

cargo build --release doesn't work because the https://github.com/hacknus/serialport-rs repository does not exist.

Hello there,

I came across your project and noticed that the codebase could benefit from some improvements to its quality. Specifically, I think running Clippy would help identify and fix many of the issues in the code.

I am interested in contributing to this project, and I believe improving the code quality would be a good first step. I would like to ask if you would be open to me submitting pull requests or working with you to make the changes.

Please add an option to reconnect device automatically when replugging

On macOS 14.1 (Apple Silicon) the menu item is no longer displaying "Serial Monitor" but it shows the system default "NSMenuItem".

When \r\n (or \n for that matter) is entered as the EOL char, the monitor litteraly sends a '\' followed by a 'n' instead of interpreting it as the correct control character.

It would be nice to associate timeseries to graphs and have the opportunity to display multiple graphs at the same time.

For example, by assuming to receive data streams from three sensors, one should be able to plot sensorValues1 and sensorValues2 on the first graph and sensorValues3 on the second graph.

could also be useful for other stuff..

It would be nice to have support for things like defmt and/or probe-run/probe-rs or similar. I imagine defmt would make a lot of sense for fast and efficient logging of lots of datapoints to build graphs. Also things like probe-run to allow communication using debugger instead of serial.

Not sure how or even if this would fit into this project, but as a user, it would be nice :)

Perhaps the easiest and most flexible would be something like adding stdin under "Devices" so the user can pipe the output of any external tool to serial monitor?

me@box:~/my-embedded-project$ cargo run | serial-monitor-rust

It would be quite useful if there were a graphical way to see what text line corresponds to what point on the x axis.

For example mousover the text line could show a horizontal line in the graph. In the same way hovering in the graph could light up the closest text line in the console.

The print_to_console and update_in_console functions in gui.rs do not currently handle errors that can occur when acquiring the write lock on the provided print_lock.

pub fn print_to_console(print_lock: &Arc<RwLock<Vec<Print>>>, message: Print) -> usize {
    let mut length: usize = 0;
    if let Ok(mut write_guard) = print_lock.write() {
        write_guard.push(message);
        length = write_guard.len() - 1;
    }
    length
}

pub fn update_in_console(print_lock: &Arc<RwLock<Vec<Print>>>, message: Print, index: usize) {
    if let Ok(mut write_guard) = print_lock.write() {
        write_guard[index] = message;
    }
}

Should we add error handling and improve the code's reliability and robustness? We can modify them to return a Result that indicates whether the lock was successfully acquired or not.

When transferring large amounts of data continuously, the transfer rate of serial-monitor-rust is much slower than other serial port software (e.g. serialplot). Comparisons as following:


The serial-monitor-rust receives a line every 0.025s, indicating the transfer rate of 25 sps. But the serialplot achieves 359 sps.

the command line should only send the contents when it is focused. Now it is always sensitive to the enter keystroke - even when one is adjusting another parameter in the side panel and pressing enter to save it. This will always send whatever is in the command line too (also just empty string + EOL).

When data columns are in very different ranges it is impossible to view.

It would be very useful if the user could create multiple plots and select which data columns goes where.
Multiple Y-axis' would also be a great addition.

Not able to select and scroll the raw traffic. We should find a way to allow similar behavior as in a text editor.
Also CTRL+A should be implemented.

A workaround to retrieve the data is to use the "save raw traffic" option and save a file.

Hi,
I have a device where the output data is as so
[RECV] t + 210.359s: #,00:00:00 00/00/0000, , , .0862, ,N.m, VCX000002, 1
A feature for a custom separator would be pretty awesome

When having different values with completely different scales, the smaller ones turns in to flat lines close to zero

It would be useful to have individual scaling per channel like on an oscilloscope. Not shure how that would work with y-ranges etc.

Some (linux) Systems don't run a screensaver service which makes the serial monitor thread crash on a connect attempt. Either test if a screensaver is present or provide a feature to be able to remove it at compile time.

It would be good to have a quick introduction window popping up on first launch to show all the features. For example:

• double clicking the plot to center it
• keyboard shortcuts
• ...

The latest code crashes because we get an out of bounds error in ./src/gui.rs:690:66:

self.serial_devices.number_of_plots[self.device_idx]

we need to make sure that number_of_plots is extended/updated when a new device is connected.

Workaround:
use the latest release