Skip to content

Serial API #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
japaric opened this issue Jun 9, 2017 · 6 comments
Closed

Serial API #3

japaric opened this issue Jun 9, 2017 · 6 comments
Labels
RFC

Comments

@japaric
Copy link
Member

japaric commented Jun 9, 2017

  • What is missing in this API?
  • Can this API be implemented for different devices?
@japaric japaric added the RFC label Jun 9, 2017
@japaric
Copy link
Member Author

japaric commented Jun 9, 2017

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.

@japaric japaric mentioned this issue Jun 9, 2017
Closed
@adamgreig
Copy link
Member

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
Copy link
Member Author

japaric commented Jun 11, 2017

@adamgreig Sounds good.

@hannobraun
Copy link
Member

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
Copy link
Member Author

japaric commented Sep 21, 2017

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

@hannobraun hannobraun mentioned this issue Oct 24, 2017
Merged
japaric pushed a commit that referenced this issue Dec 20, 2017
@homunkulus
Auto merge of #22 - hannobraun:write-flush, r=japaric
db91212 
Add `flush` method to `serial::Write`

As suggested previously here: #3 (comment)
@japaric
Copy link
Member Author

japaric commented Jan 20, 2018 •
edited
Loading

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!

@japaric japaric closed this as completed Jan 20, 2018
peckpeck pushed a commit to peckpeck/embedded-hal that referenced this issue Nov 10, 2022
@homunkulus
Auto merge of rust-embedded#3 - wose:feature/i2c, r=japaric
9dda466 
embedded-hal i2c traits implementation using i2cdev

I tested this on a Raspberry Pi 2 with an SDD1306 OLED display and a Si7021 humidity/temperature sensor (driver crates will follow soon).

However, I'm not quite sure about the address parameter. The i2cdev crate will use the address when creating the LinuxI2CDevice, the embedded-hal traits expect the device address as parameter. I just ignore this parameter in this implementation. Is this the right way to do it?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
RFC
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@adamgreig @hannobraun @japaric