Should setting baud rate for serial communication be part of this hal?

[kjetilkjeka]

I believe some way to set baud rate for the serial traits is needed.

Relevant problem

Dynamixel servos comes with two different RS-485 protocols that have some difference in support of baud rate. And even if every servo on your RS-485 bus uses the same protocol there should be nothing stopping you from configuring them with different baud rates. This require setting baud rate before communicating with a servo.

This is currently the biggest blocker for having the dynamixel library work for every embedded-hal implementation out of the box (as it currently does with adapters supporing serialport)

[kjetilkjeka]

One possible solution could be to introduce a serial::Serial trait that implements the set_baud_rate(&mut self) -> Result<(), Self::Error>.

Then i could auto implement the dynamixel interface for Serial + Write + Read types

[therealprof]

Hm, so you're using the Serial trait for RS-485 communication? Interesting. Is this application relying on the fact that a RS-232 to RS-485 adapter is available?

I do agree that there're some uses for on-the-fly configuration changes, so I'd be very much in favour for adding this; however we'd need to check for implementation feasibility. There might be chips which only allow such changes through full re-initialisation which may require resources which are not owned but only borrowed.

[kjetilkjeka]

Hm, so you're using the Serial trait for RS-485 communication? Interesting. Is this application relying on the fact that a RS-232 to RS-485 adapter is available?

currently I've only implemented it for this serial trait. I've tested it with an ftdi like rs485 usb dongle.

You could use a RS-485 transceiver directly connected to some uart, meaning it's no need for converting to RS-232. Since this is SW and we don't really care about things as differential-lines and voltage levels the only real difference is that with RS-485 you cannot read and write at the same time.

[therealprof]

@kjetilkjeka That only works with dedicated hardware. When using a MCU and a RS485 transceiver you will need a "Driver Enable" signal. Expecting the user to manage that manually is not very user friendly and some chips, e.g. STM32 MCUs have hardware support for it which is especially handy if one wants to use async IO.

[kjetilkjeka]

The simple way is to connect tx together with the enable line. Then you will get dominant 1s and recessive 0s. That is if the mcu doesn't drive the enable line for you.

I would expect the write/read implementation to handle this. If they don't they're pretty much useless. I'm not suggesting such a thing.

Edit: i dont expect the hal to assume what kind of hw you've connected to the uart. This mist be handled in hw or at the initialization.

[therealprof]

My point is that you'll need specific setup for that case. You can't just use the regular serial impl and it'll work out automagically for RS-485 as well.

[kjetilkjeka]

Is this simply an observation, an argument against adding the set baud method or an argument against using the serial traits for RS485?

Perhaps I'm wrong, but i see the serial traits as a generic serial protocol. Much like the stdlib Read/Write traits can be used on network sockets, files, rs485, etc. I expect the serial traits to work on uart, usart, RS232, RS485, etc. Even for the simple uart case you will need "specific setup" as voltage levels might not be the same for the commuinicating units.

[therealprof]

It's a somewhat unrelated observation that the serial trait may be lacking more details than just the baudrate selection to be useful for various serial protocols.

[austinglaser]

I'm in favor of keeping the base Read and Write traits as simple as possible -- they should have to do with transmitting and receiving bytes on the bus, and basically nothing else.

However, I can also see the need for changing the baud rate (and possibly other parameters) at runtime. I'm going to make the same suggestion we've talked about elsewhere: Add a separate, but composable trait (maybe serial::Configure). Something like:

trait Configure {
    type Freq;

    fn set_baud_rate<T>(&mut self, baud_rate: T) where T: Into<self::Freq>;
}

This doesn't break existing implementations, and leaves it to implementers to decide whether such configuration makes sense for their use-case.

[kjetilkjeka]

In favor of what @austinglaser suggests with the following additions.

• To make the trait useable we must create a way to construct it. What about requiring a fallible conversion from u32 to Freq.
• I'm generally in favor of making functions infallible by only allowing legal arguments to be allowed. I think if we want to support weird baudrates (which we do) we must allow the set_baud_rate to fail.

pub trait ConfigureBaud {
    type BaudRate: TryFrom<u32>;
    type Error;

    fn set_baud_rate(&mut self, baud_rate: Self::BaudRate) -> Result<(), Self::Error>;
}

Another alternative could be to distinguish between interfaces supporting weird and non-weird bauds:

pub enum StandardBaudRate {
    B1200,
    B2400,
    B4800,
    B9600,
    B19200,
    B38400,
    B57600,
    B115200,
}

pub trait ConfigureBaud {
    type BaudRate: From<StandardBaudRate> + TryFrom<u32>;

    fn set_baud_rate(&mut self, baud_rate: Self::BaudRate);
}

pub trait TryConfigureBaud: ConfigureBaud {
    type Error;

    fn try_set_baud_rate(&mut self, baud_rate: u32) -> Result<(), Self::Error>;
}

[therealprof]

This is a rather messy topic and I don't have good solutions in my head at this time. Your "standard" baud rates are ending far too low, 115200 is rather pedestrian nowadays. Also even "standard" baud rates can very often not be represented exactly and also often this depends on the clock the UART or even the whole system is running at.

For me this means it either should be fallible or there must be a way to determine whether a baud rate can be supported or what the next closest supported value would be.

[kjetilkjeka]

This is a rather messy topic and I don't have good solutions in my head at this time. Your "standard" baud rates are ending far too low, 115200 is rather pedestrian nowadays.

These are BaudRates that every unit conforming to the embedded-hal needs to support. And it looks like Rust is going to work on 8-bit avr in the future. Perhaps this is a good argument for dropping the infallible set_baud.

Also even "standard" baud rates can very often not be represented exactly

How big of a problem is this? I would be happy with the "best effort" and "you should probably have your impl fail if it's to far away (2-3% or something)"

and also often this depends on the clock the UART or even the whole system is running at.

I guess the solution here is, If the implementation don't know what kind of freq the uart clock runs at this Trait should (read: can) not be implemented.

---

This alternative would supporting getting an indication of how much off the BaudRate is. But would allow scary things like. interface.set_baud_rate(BaudRate.closest(9999999999)) (the naming is ad-hoc)

#[derive(Debug)]
pub struct UnrepresentableBaud;

pub trait BaudRate: Into<f32>{
    //// Try to crate a `BaudRate` with less than 2% error.
    fn create_approximately(baud_rate: u32) -> Reult<(), UnrepresentableBaud>; 

    //// Create the closest `BaudRate` possible to `baud_rate`.
    fn closest(baud_rate: u32) -> Self;

}

pub trait ConfigureBaud {
    type BaudRate: BaudRate;

    fn set_baud_rate(&mut self, baud_rate: Self::BaudRate);
}

[therealprof]

These are BaudRates that every unit conforming to the embedded-hal needs to support.

Huh?

And it looks like Rust is going to work on 8-bit avr in the future.

Even the ominous ATMega328 officially supports 2 MBaud...

How big of a problem is this? I would be happy with the "best effort" and "you should probably have your impl fail if it's to far away (2-3% or something)"

It's a big problem. I've seen people clock their MCUs specifically for proper serial communication and if this is all automagic then it will cause all sorts of surprises.

I guess the solution here is, If the implementation don't know what kind of freq the uart clock runs at this Trait should (read: can) not be implemented.

Well, often you pass in the relevant clocks when initialising the UART, e.g. from the stm32f103xx-hal:

            impl<PINS> Serial<$USARTX, PINS> {
                pub fn $usartX(
                    usart: $USARTX,
                    pins: PINS,
                    mapr: &mut MAPR,
                    baud_rate: Bps,
                    clocks: Clocks,
                    apb: &mut $APB,
                ) -> Self

So the application sets up the clocks and passes it in so there's no way of knowing whether the baud rate is compatible with the current clocks and now coming back to this topic and my previous concern: If you reconfigure the baud rate on the fly you will most likely have to pass in the very same information again that was used during construction to make the proper calculation (and some chips actually require that you turn the peripheral off again to make such a change) but this is all implementation dependant...

[kjetilkjeka]

So it looks like the temporary spec sheet currently looks:

• Cannot be mandatory to implement just to use Write/Read. (must live in its own trait)
• Support weird baud rates.
• Give an indication of how far away from the desired baud the actual baud is.
• Be explicit whether you need an "exact" baud or approximate baud.
• Be explicit of when the baud rate change occurs (can this affect bytes already called transmit on?)
• Must not require passing any "init" information like uart clock frequency etc.
• Of course, be easy to use correctly and hard to use wrongly.

and some chips actually require that you turn the peripheral off again to make such a change

If this is the case, the reconfigurable baud rate should probably not be implemented (or handle these special concerns in software)

So the application sets up the clocks and passes it in so there's no way of knowing whether the baud rate is compatible with the current clocks and now coming back to this topic and my previous concern: If you reconfigure the baud rate on the fly you will most likely have to pass in the very same information again that was used during construction to make the proper calculation

I guess what you mean is "no way of knowing statically"? As the interface could remember its clock frequency. Then you could simply ask the interface whether the new clock freuquency is compatible or not. For instance with:

#[derive(Debug)]
pub struct UnrepresentableBaud;

pub trait ConfigureBaud {
     fn set_baud_rate(&mut self, baud_rate: u32) -> Result<(), UnrepresentableBaud>;
}

[therealprof]

I guess what you mean is "no way of knowing statically"? As the interface could remember its clock frequency.

The problem with "remembering" is, that the clock might actually change...

At the moment, the most compatible and safest way to change the baud rate would be to drop and reinitialise the serial interface.