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

api: add i2c master/slave support | examples: add i2c master/slave samples #523

Merged
merged 2 commits into from
Dec 6, 2023

Conversation

twilfredo
Copy link
Contributor

@twilfredo twilfredo commented Nov 22, 2023

Overview

Adds new I2C master/slave api to libtock-rs. The changes were tested using the samples running on 2x Particle Boron boards. Where one was a master and the other was a slave device, that would ping-pong data across. Additional testing was performed by communicating with an MCP9808 device as an I2C bus Master.

Building and Testing

The samples can be built by running the below from the top-dir:

$ make nrf52840 EXAMPLE=i2c_slave_send_recv
$ make nrf52840 EXAMPLE=i2c_master_write_read

After flashing each sample to the respective master and slave device. The following serial output can be observed. Note you may have to reset the devices after flashing.

Master Log (i2c_master_write_read.rs)

i2c-master: write-read operation 1
2 bytes read from slave | data received (0h): [c1, c5]

i2c-master: write-read operation 2
2 bytes read from slave | data received (0h): [c2, ca]

i2c-master: write-read operation 3
2 bytes read from slave | data received (0h): [c3, cf]

Slave Log (i2c_slave_send_recv.rs)

i2c-slave: operation 1
4 bytes received from master | buf: [5e, bc, 1a, 78, 0, 0, 0, 0]
2 bytes read by master | data sent: [2, a, 0, 0, 0, 0, 0, 0]
i2c-slave: operation 2
4 bytes received from master | buf: [60, c0, 20, 80, 0, 0, 0, 0]
2 bytes read by master | data sent: [3, f, 0, 0, 0, 0, 0, 0]
i2c-slave: operation 3
4 bytes received from master | buf: [62, c4, 26, 88, 0, 0, 0, 0]
2 bytes read by master | data sent: [4, 14, 0, 0, 0, 0, 0, 0]
i2c-slave: operation 4
4 bytes received from master | buf: [64, c8, 2c, 90, 0, 0, 0, 0]
2 bytes read by master | data sent: [5, 19, 0, 0, 0, 0, 0, 0]
i2c-slave: operation 5
4 bytes received from master | buf: [66, cc, 32, 98, 0, 0, 0, 0]
2 bytes read by master | data sent: [6, 1e, 0, 0, 0, 0, 0, 0]

NOTE: These are two different logs, so the bytes aren't matched... I only have one UART converter >,>

TODO/Help

This api is all synchronous, we need to look at adding async support. It looks like we need to improve the kernel i2c_master_slave_driver.rs for this, as it seems to support only a single subscriber currently. What's a good place to get started? Or is there something I missed here?

Cheers

@twilfredo
Copy link
Contributor Author

@alistair23

@twilfredo twilfredo force-pushed the wilfred/add-i2c-api-upstream branch from 48e19c8 to 188def0 Compare November 22, 2023 03:33
@twilfredo
Copy link
Contributor Author

ping!

bradjc
bradjc previously approved these changes Nov 29, 2023
@jrvanwhy jrvanwhy added the upkeep Indicates a PR is upkeep as defined by the code review policy. label Nov 30, 2023
Adds support to the i2c master slave sycall api for libtock-rs. The
current implementation implements all the functionality synchronously.

This api was testing using 2 Particle Boron boards (nrf52840 based)
setup as a master and slave device. Additionally, this api was also tested by
communicating with an MCP9808 sensor as an I2C master, again using the
Particle Boron.

Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Adds a master/slave sample that can be used to communicate with
eachother.

These two samples were verified using 2x Particle Borons (nrf52840 based).
With one sample running on one board, the other on the 2nd board.

Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
@jrvanwhy jrvanwhy added this pull request to the merge queue Dec 6, 2023
Merged via the queue into tock:master with commit 4b94b4c Dec 6, 2023
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upkeep Indicates a PR is upkeep as defined by the code review policy.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants