Allow configuring whether to care about the CTS line

[meithecatte]

Resolves #65.

I have chosen to make "ignore CTS" the default, as that is the choice that is more likely to simply work for the user, as the aforementioned issue demonstrates.

Since the PR adds a new field to the Config struct, it would probably need to be a semver bump. Perhaps that's a good opportunity to mark the Config struct as #[non_exhaustive], but I'll leave that call up to you.

[phip1611]

thanks for bringing this up! I just returned from vacation and will take a look into that in the following days (hopefully)

[phip1611]

Thanks for your contribution:

Please:

• change the commit title to: config: allow disabling CTS check
• Add a why comment to the commit message body: Why is this necessary (Real hardware, which one) and why is this a good default
• add a changelog entry like this **Breaking:** ready_to_send()` doesn't check `MSR::CTS` anymore by default because <insert concise reason>. For manual checks, users can check `if device.msr().contains(MSR::CTS) {}`. This field is configurable in the `Config`.

[phip1611]

Please rename to check_cts_before_sending.

And please extend the rustdoc like this:

    /// Whether to wait for CTS before sending.
    ///
    /// Only activate this if.. keep it off if ...
    pub check_cts_before_sending: bool,

something concise yet helpful.

[phip1611]

I think this is not correct or at least difficult to read. How about we slightly rewrite it to keep it readable:

if mcr.contains(MCR::LOOP_BACK) {
    return Ok(());
}
if self.config.check_cts_before_sending {
    let mcr = self.mcr();

    if !mcr.contains(MCR::LOOP_BACK) {
        let msr = self.msr();

        if !msr.contains(MSR::CTS) {
            return Err(ByteSendError::RemoteNotClearToSend);
        }
    }
}
Ok(());

WDYT? It is a little nested and ugly but I prefer it over smart collapsed statements.

ping @mkroening

[meithecatte]

I've applied the changes you requested, although I instead renamed the Config field to flow_control – I think that's a better name than either of our first attempts at naming the option ;3

[phip1611]

Lovely, thanks :)

[makubacki]

Is this a stale comment?

[meithecatte]

Now that you mention it, possibly so? I previously assumed that "software flow control" meant "we're driving the flow control lines manually instead of configuring the UART to do it for us", but now that I've looked it up, it appears that software flow control usually refers to using the ASCII XON/XOFF characters for in-band signaling.

[phip1611]

I'm also not 100 percent sure about software and hardware flow control. I tried my best by reading the spec and experimenting on real hardware. Any improvement to the (likely unnecessary?) comment is highly appreciated

We might also just remove that comment. WDYT @meithecatte?

[makubacki]

Thanks! This resolved the issue I was having with v0.6.0.