Skip to content
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.

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

i2c: Add I2C Controller implementation #27

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,7 @@ embedded-hal = "1.0.0"
defmt = { version = "0.3.8", optional = true }
paste = "1.0.15"
log = { version = "0.4.20", optional = true}
nb = "1.1.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really would avoid using the nb crate nowadays. There's been talk of entirely deprecating it. It was intended to support embedded async before async was possible on embedded, but there's more modern approaches now with async frameworks targeting embedded.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thanks for this context. I'll look at embedded-hal-async

Copy link
Contributor Author

@astapleton astapleton Jan 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ryan-summers I looked at embedded-hal-async, but I'm not sure how it solves the same problem? It doesn't provide any tool to manage repeatedly trying a blocking call. Is the suggestion to remove non-blocking calls entirely? Wouldn't they be useful in interrupts, or for creating a Future implementation for async?

Is it embedded-hal-nb that might be deprecated rather than the nb crate? That wasn't actually at 1.0 when I originally created this driver, so I didn't implement those APIs.
Turns out I did implement this for the SPI driver.

Copy link
Contributor Author

@astapleton astapleton Feb 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ryan-summers Coming back to this, is the recommendation to declare non-blocking/async methods that return a Future instead of using the nb crate? Or have non-blocking methods that just check a status and return bool/ Result<bool> instead of returning an nb::Error::WouldBlock and then have methods that can't be easily decomposed to a bool return a Future? If you're not using an async runtime, how would one implement interrupt based operations? Just manually invoking poll on a future?


[dev-dependencies]
log = { version = "0.4.20"}
Expand All @@ -87,3 +88,7 @@ opt-level = "s" # optimize for binary size
[[example]]
name = "blinky"
required-features = ["stm32h503"]

[[example]]
name = "i2c"
required-features = ["stm32h503"]
64 changes: 64 additions & 0 deletions examples/i2c.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
#![deny(warnings)]
#![no_main]
#![no_std]

#[macro_use]
mod utilities;
use embedded_hal::{delay::DelayNs, i2c::I2c};
use fugit::SecsDurationU32;
use stm32h5xx_hal::{delay::Delay, pac, prelude::*};

use cortex_m_rt::entry;

use log::info;

#[entry]
fn main() -> ! {
utilities::logger::init();
log::set_max_level(log::LevelFilter::Debug);
let cp = cortex_m::Peripherals::take().unwrap();
let dp = pac::Peripherals::take().unwrap();

// Constrain and Freeze power
info!("Setup PWR... ");
let pwr = dp.PWR.constrain();
let pwrcfg = pwr.freeze();

// Constrain and Freeze clock
info!("Setup RCC... ");
let rcc = dp.RCC.constrain();
let ccdr = rcc.sys_ck(100.MHz()).freeze(pwrcfg, &dp.SBS);

let gpiob = dp.GPIOB.split(ccdr.peripheral.GPIOB);

let mut delay = Delay::new(cp.SYST, &ccdr.clocks);
let duration = SecsDurationU32::secs(1).to_millis();

// Configure the SCL and the SDA pin for our I2C bus
let scl = gpiob.pb5.into_alternate_open_drain();
let sda = gpiob.pb3.into_alternate_open_drain();

info!("");
info!("stm32h5xx-hal example - I2C");
info!("");

let mut i2c =
dp.I2C2
.i2c((scl, sda), 100.kHz(), ccdr.peripheral.I2C2, &ccdr.clocks);

// The STM32H503 NUCLEO board does not have any I2C peripherals, so put in the address of
// whatever peripheral you connect
let device_addr: u8 = 0x18;
// This implements a typical 8-bit register read operation, writing the register address and
// then issuing a repeat start to read the register value. Tweak these settings to read the
// desired amount of bytes from the register address.
let register_addr = 0x02;
let write = &[register_addr];
let mut read = [0u8; 1];

loop {
i2c.write_read(device_addr, write, &mut read).unwrap();
info!("Read reg {register_addr}: {read:X?}");
delay.delay_ms(duration);
}
}
Loading