lucazulian / mcp23017

MCP23017 a 16-Bit I2C I/O Expander with Serial Interface module

👋 Ciao!

• 🌍 I'm a software craftsman living in Milan (Italy 🇮🇹)
• 💻 I've been programming for over half my life. I'm comfortable creating, developing, maintaining, and improving software written in C, C#, Python, and Elixir (most of my recent projects have been written in Elixir), but I'd like to work more on Haskell, Rust, Erlang, OCaml, Scheme, Agda and Elm
• 🗣️ My current interests revolve around functional programming, algorithms, compilers, interpreters, domain-specific languages, virtual machines and autonomous robot
• 💬 I blog fairly regularly on a journal

🙌 What I'm (currently) excited about

• Programming languages & PLT
• Distributed systems
• Robotics
• Functional programming
• Formal methods

🎮 When I am NOT at writing code, I enjoy to

• Read books 📚
• Walking 🚶, running 🏃, climbing 🧗 or sailing ⛵
• Make fresh pasta 🍝 or bread 🍞

📰 You can find me on twitter, LinkedIn or mastodon

mcp23017's Issues

Add minimum viable implementation as example

Should `init_hardware` be marked `pub`?

The readme example has u.init_hardware(). However, if I try to copy this example, rust complains with:

function `init_hardware` is private

Is this function meant to be pub or have I misunderstood how to use the example?

support MCP23008 or equivalently support IOCON.BANK=1

Hello :)
I am looking into using this driver for the MCP23008 wich, afaict, is exactly the same chip with just one IO bank.

The only thing that would need to change is to be able to use the addressing of IOCON.BANK=1 aka being able to change this field on the MCP23017 and then using the other addresses. Writing this field on the MCP23008 has no effect.

Then you could use the exact same driver with just the first IO bank for the MCP23008.

What do you think of this proposal? Would you accept a PR if I implement these (small) changes?

PinMode constants are mixed up

The PinMode constants are mixed up, i.e. INPUT should be 1, and OUTPUT should be 0.

This, in combination with the pm function results in not being able to properly use all_pin_mode. (i.e. casting 1 to u8 results in 0b00000001, not 0b11111111, which doesn't work with write_register.)

I forked your repository and fixed this, but I also changed a bunch of other things, so I'm not sure a PR of my fixing commit would be the best thing... your choice 😅 .

Add dependabot

read_gpioab()/write_gpioab() aren't congruent

Thanks for great and straightforward library to interface with the mcp23017.

I came across a bug when using read_gpioab() and write_gpioab(). The read half returns GPIOA in bits 8:15 while the write version expects GPIOA in the low bits 0:7. The write version make more sense to me and the change is simply:

 --- lib.rs.old	2022-01-09 13:04:33.000000000 -0600
+++ lib.rs	2022-01-09 13:04:25.000000000 -0600
@@ -148,7 +148,7 @@
     /// Reads all 16 pins (port A and B) into a single 16 bit variable.
     pub fn read_gpioab(&mut self) -> Result<u16, E> {
         let buffer = self.read_double_register(Register::GPIOA)?;
-        Ok((buffer[0] as u16) << 8 | (buffer[1] as u16))
+        Ok((buffer[1] as u16) << 8 | (buffer[0] as u16))
     }

     /// Reads a single port, A or B, and returns its current 8 bit value.

However, if someone was relying on it, it would be a breaking change.

Add github workflows

write_bit checks for >HIGH

The write_bit function checks for >1, which conflicts with the definition of HIGH=1.

(Same disclaimer as in the other issue)
I forked your repository and fixed this, but I also changed a bunch of other things, so I'm not sure a PR of my fixing commit would be the best thing... your choice 😅 .

Example with interrupts

I'm doing a hobby project to learn more about hardware. I've found this library very useful so far! My current challenge is to understand how to use it with interrupts. I suppose it depends what controller is used, but do you think it would be possible to provide or refer to a simple example on how to detect e.g. a button press with this library?