Allow using stdio as a 'Device' #86
Conversation
| split_data | ||
| .iter() | ||
| payload | ||
| .split(&[':', ',', '=', ' ', '\t']) |
There was a problem hiding this comment.
This was just to get the output of ping to look nice in the screenshot. I am happy to revert this if you want
src/stdio.rs
Outdated
|
|
||
| pub struct Stdio; | ||
|
|
||
| impl serialport::SerialPort for Stdio { |
There was a problem hiding this comment.
A successful SerialPortBuilder::open returns Box<dyn SerialPort> however from what I have seen so far (might have missed something), we only seem to need io::Read and io::Write, if we could get a trait object of that instead of SerialPort for normal serial ports, we would not have to implement SerialPort for Stdio. Not sure if that is doable though...
There was a problem hiding this comment.
implementing SerialPort for Stdio seems to be a bit hacky indeed. Could we create a new struct called Interface that implements io::Read and io::Write and then two builder functions: from_serial() and from_read() ?
Not sure how to handle the configuration of the serial port then (baud, parity etc)..
|
Hi, first of all: thanks a lot for the contribution to this project! Regarding this:
I'm aware of some bugs in the current release, specifically concerning the named lines in the plot and grouping etc. (see issue #80 ) |
| use std::io; | ||
|
|
||
| pub enum Interface { | ||
| SerialPort(Box<dyn serialport::SerialPort>), | ||
| Stdio, | ||
| } | ||
|
|
||
| impl io::Write for Interface { | ||
| fn write(&mut self, buf: &[u8]) -> io::Result<usize> { | ||
| match self { | ||
| Interface::SerialPort(s) => s.write(buf), | ||
| Interface::Stdio => io::stdout().write(buf), | ||
| } | ||
| } | ||
|
|
||
| fn flush(&mut self) -> io::Result<()> { | ||
| match self { | ||
| Interface::SerialPort(s) => s.flush(), | ||
| Interface::Stdio => io::stdout().flush(), | ||
| } | ||
| } | ||
| } | ||
|
|
||
| impl io::Read for Interface { | ||
| fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { | ||
| match self { | ||
| Interface::SerialPort(s) => s.read(buf), | ||
| Interface::Stdio => io::stdin().read(buf), | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
implementing SerialPort for Stdio seems to be a bit hacky indeed. Could we create a new struct called Interface that implements io::Read and io::Write and then two builder functions: from_serial() and from_read() ?
Not sure how to handle the configuration of the serial port then (baud, parity etc)..
Something like this?
There was a problem hiding this comment.
Serial settings are ignored. From ui point of view perhaps it would make most sense if the serial related things were greyed out once "stdio" is selected? However I am not sure how I would accomplish something like that..
There was a problem hiding this comment.
I was thinking more like this:
/// STDIO interface
#[derive(Debug)]
pub struct StdioInterface<stdio> {
pub(crate) stdio: stdio,
}
/// Serial interface
#[derive(Debug)]
pub struct SerialInterface<SerialPort> {
pub(crate) serial: SerialPort,
}
/// Write data
pub trait WriteData: private::Sealed {
/// Error type
type Error;
/// Write data.
fn write(&mut self, payload: &str) -> Result<(), Self::Error>;
/// Flush data.
fn flush(&mut self, payload: &str) -> Result<(), Self::Error>;
}
/// Read data
pub trait ReadData: private::Sealed {
/// Error type
type Error;
/// Read some data.
fn read(&mut self) -> Result<String, Self::Error>;
}
impl<SerialPort, E> ReadData for SerialInterface<SerialPort >
where
SerialPort: // traits
{
type Error = Error<E>;
// ...
}
impl<stdio, E> ReadData for StdioInterface<stdio>
where
stdio: // traits
{
type Error = Error<E>;
// ...
}
impl<SerialPort, E> WriteData for SerialInterface<SerialPort >
where
SerialPort: // traits
{
type Error = Error<E>;
// ...
}
impl<stdio, E> WriteData for StdioInterface<stdio>
where
stdio: // traits
{
type Error = Error<E>;
// ...
}
But not sure, if this works...
greying out the serial settings should be possible in the GUI.
There was a problem hiding this comment.
Unless I misunderstand, that would require casting oh...Box<dyn SerialPort> into Box<dyn WriteData> which as far as I know is not possible.
There is however also serialport::new_native which returns different things depending on OS. At that point we would no longer need the Box<dyn ...> and just #[cfg] into the right enum variant.
There was a problem hiding this comment.
Unless I misunderstand, that would require casting Box into Box which as far as I know is not possible.oh...
Oh I think maybe I understand now(?). Since the type is wrapped in a newtype it would be the newtype that could then be turned into a Box which would be fine. However that would be double boxing...
There was a problem hiding this comment.
I see, this is not as straight forward as I expected...
|
hello! is there an update on this PR? |
A semi hacky POC for #85
(Yes, I have a low res screen :) )
[albin@macen serial-monitor-rust]$ ping 1.1.1.1 | cargo rBTW, any ideas as to why the data does not show up until "number of plots" is increased to 2?