`Serial` API

[japaric]

• What is missing in this API?
• Can this API be implemented for different devices?

[japaric]

What is missing in this API?

I'd say get_baud_rate and set_baud_rate but are those useful to build higher level abstractions? They feel more like configuration-style APIs that you are more likely to do once, specially in the case of set_baud_rate.

[adamgreig]

I think Serial should, like SPI, have a Word associated type rather than using u8. It's not at all uncommon to have 9-bit serial and that's supported by all the embedded UARTs I've seen.

On the other hand, if you did find a UART that didn't support 9-bit serial, you could just not impl for Word=u16, which I think neatly communicates to the user that you can't do 9-bit serial here.

[japaric]

@adamgreig Sounds good.

[hannobraun]

I'm not sure how generally applicable and useful this is, but in my own serial code I have a flush method that blocks until the transmitter has become idle. I'm currently converting my code into an implementation of embedded-hal, and since serial::Write doesn't have such a method, I've decided I don't actually need it. However, I thought I'd mention this here, as something that the hardware is capable of, that isn't represented in the serial traits.

[japaric]

@hannobraun Adding a flush method to write makes sense to me.

[japaric]

The serial::{Read,Write} traits are now part of a crates.io release so I'm going to close this. If you encounter any problem implementing / using those traits feel free to open a new issue!