drivers: add MCP23x17 I/O expander support #10688

gschorcht · 2019-01-02T02:22:04Z

Contribution description

This PR adds a driver for Microchip MCP23x17 I/O expanders which can be used to extend the number of GPIOs over I2C or SPI. It is a complete rework of the driver that was provided in PR #7652 and rewritten from scratch.

The following expander devices are supported:

Expander	Type	Interface	Pseudomodule
MCP23017	16-bit I/O expander	I2C	`mcp23017` or `mcp23x17_i2c`
MCP23S17	16-bit I/O expander	SPI	`mcp23s17` or `mcp23x17_spi`

The main features of the driver are:

Its interface is compatible with the peripheral GPIO interface. The only difference is that the functions have the prefix mcp23x17_ and require an additional parameter, the pointer to the expander device of type mcp23x17_
It supports the GPIO extension API as defined in PR periph_*: Allow extensions for external periph adapters #9582 and provided in PR periph/gpio: support for extension API #9860 and periph/gpio: support for extension API (part 2) #9958.
It supports the following GPIO modes
- GPIO_IN, GPIO_IN_PU and GPIO_OUT in hardware
- GPIO_OD and GPIO_OD_PU are emulated.
Optionally, the a low-active push-pull INT signal of MCP23x17 expanders can be used to provide external interrupt capabilities for all expander pins. The driver interface is compatible to module periph_gpio_irq
It supports direct GPIO mapping to SAUL which is compatible to the peripheral GPIO SAUL interface. Thus MCP23x17 I/O expander pins can be used with SAUL in the same way as peripheral GPIOS.
Multiple MCP23x17 expander modules and different variants can be used simultaneously.

Benchmarks

MCP23x17 driver run-time performance benchmark over SPI using 10 MHz clock speed:

                 nop loop:       634us  ---   0.063us per call  ---   15772870 calls per sec
                 gpio_set:    540009us  ---  54.000us per call  ---      18518 calls per sec
               gpio_clear:    540000us  ---  54.000us per call  ---      18518 calls per sec
              gpio_toggle:    811005us  ---  81.100us per call  ---      12330 calls per sec
                gpio_read:    271001us  ---  27.100us per call  ---      36900 calls per sec
               gpio_write:    539005us  ---  53.900us per call  ---      18552 calls per sec

MCP23x17 driver run-time performance benchmark over SPI using 1 MHz clock speed:

                 nop loop:       634us  ---   0.063us per call  ---   15772870 calls per sec
                 gpio_set:   1429044us  ---  142.904us per call  ---       6997 calls per sec
               gpio_clear:   1429005us  ---  142.900us per call  ---       6997 calls per sec
              gpio_toggle:   2144009us  ---  214.400us per call  ---       4664 calls per sec
                gpio_read:    715000us  ---  71.500us per call  ---      13986 calls per sec
               gpio_write:   1428004us  ---  142.800us per call  ---       7002 calls per sec

MCP23x17 driver run-time performance benchmark over I2C using 400 kHz clock speed:

                 nop loop:       639us  ---   0.063us per call  ---   15649452 calls per sec
                 gpio_set:   1965040us  ---  196.504us per call  ---       5088 calls per sec
               gpio_clear:   1960008us  ---  196.000us per call  ---       5102 calls per sec
              gpio_toggle:   3088493us  ---  308.849us per call  ---       3237 calls per sec
                gpio_read:   1127503us  ---  112.750us per call  ---       8869 calls per sec
               gpio_write:   1960004us  ---  196.000us per call  ---       5102 calls per sec

Reference board was an esp8266-esp-12x.

Testing procedure

The test application tests/driver_mcp23x17 can be used to test each MCP23x17 I/O expander pin with shell commands.

Compile the application. Dependent on the MCP23x17 expander module, compile it with at least one of the pseudomodules mcp23x17_i2c or mcp23x17_spi, e.g., for the I2C version MCP23017:
```
USEMODULE=mcp23x17_i2c make flash -C tests/driver_mcp23x17 BOARD=...
```
Add the interrupt functionality by enabling module mcp23x17_irq and override the default GPIO pin for the interrupt signal, e.g. for the I2C version MCP23017:
```
CFLAGS="-DMCP23X17_PARAM_I2C_INT=$GPIO\(0,6$\)" \
USEMODULE="mcp23x17_i2c mcp23x17_irq"  flash -C tests/driver_mcp23x17 BOARD=...
```
Connect the MCP23x17 I/O expander module using the interface and the GPIO for the interrupt signal as defined during compilation.
Connect a GPIO pin of the MCU, e.g. GPIO_PIN(0,4), and a MCP23x17 I/O expander pin, e.g. Port A (port 16 in test application) and Pin 6.

Execute some or all of the following commands (results in comment):

 > init_in 0 4
 > init_od_pu 16 6

 > set 0 4
 > read 0 4          # GPIO pin (port 0, pin 4)) is HIGH

 > clear 16 6
 > read 0 4          # GPIO pin (port 0, pin 4)) is LOW

 > init_od 16 6
 > init_in_pu 0 4

 > set 16 6
 > read 0 4          # GPIO pin (port 0, pin 4)) is HIGH

 > clear 16 6
 > read 0 4          # GPIO pin (port 0, pin 4)) is LOW

 > init_in 16 6
 > read 16 6         # MCP23x17 pin (dev 16, pin 6)) is HIGH
 > init_out 0 4 
 > read 16 6         # MCP23x17 pin (dev 16, pin 6)) is LOW

 > set 0 4 
 > read 16 6         # MCP23x17 pin (dev 16, pin 6)) is HIGH

 > init_int 16 6 0
 > clear 0 4         # INT: external interrupt from MCP23x17 pin 6
 > set 0 4

 > init_int 16 6 1
 > clear 0 4
 > set 0 4           # INT: external interrupt from MCP23x17 pin 6

 > init_int 16 6 2
 > clear 0 4         # INT: external interrupt from MCP23x17 pin 6
 > set 0 4           # INT: external interrupt from MCP23x17 pin 6 

 > disable_int 16 6
 > clear 0 4
 > enable_int 16 6
 > set 0 4           INT: external interrupt from MCP23x17 pin 6
 > clear 0 4         INT: external interrupt from MCP23x17 pin 6

 > init_int 16 5 2
 > disable_int 16 5
 > set 0 4           INT: external interrupt from MCP23x17 pin 6

Issues/PRs references

~~The driver is compatible with the GPIO extension API, PRs #9582, #9860 and #9958, but it does not depend on it.~~

gschorcht · 2019-01-02T02:23:11Z

@ZetaR60 Again a GPIO expander driver that is working perfect with your last version of the extension API.

stale · 2019-08-10T03:08:02Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

stale · 2020-03-10T12:38:11Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

jeandudey

This might be a little bit old but left some comments for a first pass, I hope it gets a rebase in the near future as the driver seems very complete.

jeandudey · 2021-02-27T12:57:17Z

drivers/mcp23x17/mcp23x17.c

+ return -MCP23X17_ERROR_NO_DEV;
+ }
+#endif
+ if (params->reset_pin != GPIO_UNDEF) {


Suggested change

if (params->reset_pin != GPIO_UNDEF) {

if (gpio_is_valid(params->reset_pin)) {

jeandudey · 2021-02-27T12:58:59Z

drivers/mcp23x17/mcp23x17.c

+ * If GPIO pin for interrupt signals INTA and INTB is defined in parameters,
+ * we use interrupts.
+ */
+ if (params->int_pin != GPIO_UNDEF) {


jeandudey · 2021-02-27T13:02:30Z

drivers/mcp23x17/mcp23x17.c

+ return MCP23X17_OK;
+}
+
+int mcp23x17_gpio_init(mcp23x17_t *dev, gpio_t pin, gpio_mode_t mode)


I'm bit unsure about using gpio_t in here as some CPUs could define it as an structure, I think it may be more suitable to add a proper mc23x17_gpio_t type, same could apply for mode as CPUs could define their own and probably the IO expander has it's modes defined independently of the host.

gpio_t and gpio_mode_t are used here intentionally. As a result of the review of the first driver provided in PR #7652, the goal of this PR was to implement an API that is compatible with the GPIO API in order to integrate the GPIO expanders transparently.

At the moment, gpio_t must be a scalar for all GPIO implementations because there are hundreds of comparisons in RIOT that use the == operator.

In PR #12877 and later in PR #14602 I tried to introduce a GPIO API using a structured gpio_t type more than a year ago, but I didn't succeed until now. So there is no reason not to use gpio_t at the moment. Once, the structured GPIO is introduced, the driver could easily be changed, as the example of the low-level GPIO API implementation of an expander driver in PR #14602 shows.

gschorcht · 2021-10-30T11:04:17Z

drivers/mcp23x17/Kconfig

@@ -0,0 +1,40 @@
+# Copyright (c) 2021 Gunar Schorcht


@leandrolanzieri How can I test the config for a new driver. Everytime I use menuconfig as make target, I only see LM75A/TMP1075 in Sensor Device Drivers and nothing else. When I use [A] Toggle show-all mode, I see all variables in red, but I can't change anything. Furthermore, I get the following message in red.

*** !! ERROR: There are conflicting modules active !! ***

I get this message also for other test applications in release branch.

@gschorcht to test the dependency modelling with Kconfig you should set a variable: env TEST_KCONFIG=1 make menuconfig.

Furthermore, I get the following message in red.
*** !! ERROR: There are conflicting modules active !! ***

Everything that is in red is not visible, so that message is actually hidden if I understood you correctly.

For this modelling I'd suggest the following change:

diff --git a/drivers/mcp23x17/Kconfig b/drivers/mcp23x17/Kconfig index ca79fcc382..705780263b 100644 --- a/drivers/mcp23x17/Kconfig +++ b/drivers/mcp23x17/Kconfig @@ -36,6 +36,8 @@ config MODULE_MCP23X17_IRQ depends on HAS_PERIPH_GPIO_IRQ depends on MODULE_MCP23X17 select MODULE_PERIPH_GPIO_IRQ - select MODULE_EVENT_THREAD_MEDIUM + depends on MODULE_EVENT_THREAD_MEDIUM + help + To use the IRQs the MODULE_EVENT_THREAD symbol should be set. endif # MODULE_MCP23X17 diff --git a/tests/driver_mcp23x17/app.config.test b/tests/driver_mcp23x17/app.config.test index 181cba5f04..9d5911c6bf 100644 --- a/tests/driver_mcp23x17/app.config.test +++ b/tests/driver_mcp23x17/app.config.test @@ -2,6 +2,10 @@ # application configuration. This is only needed during migration. CONFIG_MODULE_MCP23X17=y +# enable event thread to process IRQs +CONFIG_MODULE_EVENT=y +CONFIG_MODULE_EVENT_THREAD=y +CONFIG_MODULE_EVENT_THREAD_MEDIUM=y # enable interrupt support by default CONFIG_MODULE_MCP23X17_IRQ=y

You may also want to expose which thread priority to use on the driver, similar to the at driver (see here).

@leandrolanzieri Either I still don't understand how Kconfig is used correctly or there is something wrong with ESP8266 Kconfig. After making the changes according to your suggestions and running Kconfig, I get the following output for USEMODULE variable:

TEST_KCONFIG=1 make -C tests/driver_mcp23x17/ BOARD=esp8266-esp-12x menuconfig TEST_KCONFIG=1 make -C tests/driver_mcp23x17/ BOARD=esp8266-esp-12x info-debug-variable-USEMODULE ```suggestion benchmark tsrb core_init periph_init cpu periph_init_uart newlib stdin mcp23x17_irq event core_panic mcp23x17 periph_i2c periph_init_gpio periph_timer mcp23x17_i2c core periph_uart periph_init_pm event_thread periph_common event_thread_medium stdio_uart_rx shell periph_init_timer core_msg periph_gpio_irq newlib_syscalls_default auto_init core_thread_flags periph_gpio periph_pm div sys periph_init_i2c auto_init_xtimer stdio_uart isrpipe board xtimer core_idle_thread periph_init_gpio_irq mcp23x17_irq_medium

When I set USEMODULE as environment variable, I get the following output for USEMODULE variable:

USEMODULE='mcp23x17_i2c mcp23x17_irq' make -C tests/driver_mcp23x17 BOARD=esp8266-esp-12x info-debug-variable-USEMODULE auto_init auto_init_random auto_init_xtimer benchmark board boards_common_esp8266 core core_idle_thread core_init core_msg core_panic core_thread_flags cpp cpu div esp_common esp_common_periph esp_freertos esp_freertos_common esp_i2c_sw esp_idf esp_idf_esp8266 esp_idf_nvs_flash esp_idf_spi_flash esp_idf_util esp_idf_wpa_supplicant_crypto esp_sdk event event_thread event_thread_medium isrpipe log luid mcp23017 mcp23x17 mcp23x17_i2c mcp23x17_irq mtd newlib newlib_syscalls_default periph periph_common periph_cpuid periph_flash periph_gpio periph_gpio_irq periph_hwrng periph_i2c periph_i2c_sw periph_init periph_init_cpuid periph_init_flash periph_init_gpio periph_init_gpio_irq periph_init_hwrng periph_init_i2c periph_init_i2c_sw periph_init_pm periph_init_timer periph_init_uart periph_pm periph_timer periph_uart prng prng_tinymt32 ps random shell stdin stdio_uart stdio_uart_rx sys tinymt32 tsrb xtensa xtimer

That is, a number of specific esp_* modules are missing in Kconfig configuration for ESP8266 boards. The same happens for ESP32 boards.

We still did not make it to the esp for the Kconfig modelling of dependencies, that's why it's not tested yet in the CI

RIOT/.murdock

Lines 10 to 18 in 9256970

: ${TEST_KCONFIG_BOARDS_AVAILABLE:="

dwm1001

hifive1

native

nrf52840dk

nucleo-f103rb

remote-revb

samr21-xpro

seeedstudio-gd32

(help doing so is really welcome :). It should be working fine with the platforms that already have their modules in.

@leandrolanzieri Is there a more elegant way to map a possible choice to an enum than the following?

driver.h

typedef enum { DRIVER_MODE_1 = 0x10, DRIVER_MODE_2 = 0x20, DRIVER_MODE_3 = 0x30, } driver_mode_t;

driver_params.h

#ifdef CONFIG_DRIVER_MODE_1 #define CONFIG_DRIVER_MODE (DRIVER_MODE_1) #elif CONFIG_DRIVER_MODE_2 #define CONFIG_DRIVER_MODE (DRIVER_MODE_2) #elif CONFIG_DRIVER_MODE_3 #define CONFIG_DRIVER_MODE (DRIVER_MODE_3) #endif

Kconfig:

choice bool "Select right mode default DRIVER_MODE_1 config DRIVER_MODE_1 bool "Mode 1" config DRIVER_MODE_2 bool "Mode 2" config DRIVER_MODE_3 bool "Mode 3" endchoice

When migrating default configuration parameters to Kconfig, a further question arose. What are the rules when a define in driver_params.h should be called CONFIG_DRIVER_PARAM_<NAME> and when a parameter should simply be called DRIVER_PARAM_<NAME>? I have seen a mixture which doesn't seem to be consistent.

Would be a mapping

#define DRIVER_PARAM_<NAME> (CONFIG_DRIVER_PARAM_<NAME>`

OK to keep the compatibility with existing documentation where the default parameters could be changed by overriding them by CFLAGS at the make command line?

@leandrolanzieri Is there a more elegant way to map a possible choice to an enum than the following?

What about the following:

choice bool "Select right mode" default DRIVER_MODE_1 config DRIVER_MODE_1 bool "Mode 1" config DRIVER_MODE_2 bool "Mode 2" config DRIVER_MODE_3 bool "Mode 3" endchoice config DRIVER_MODE hex default DRIVER_MODE_1_VAL if DRIVER_MODE_1 default DRIVER_MODE_2_VAL if DRIVER_MODE_2 default DRIVER_MODE_3_VAL if DRIVER_MODE_3 config DRIVER_MODE_1_VAL hex default 0x10 config DRIVER_MODE_2_VAL hex default 0x20 config DRIVER_MODE_3_VAL hex default 0x30

Then you can also have:

typedef enum { DRIVER_MODE_1 = CONFIG_DRIVER_MODE_1_VAL, // not actually configurable, just not to duplicate DRIVER_MODE_2 = CONFIG_DRIVER_MODE_2_VAL, DRIVER_MODE_3 = CONFIG_DRIVER_MODE_3_VAL, } driver_mode_t;

Note that this last part would only work in the case Kconfig is actually run.

What are the rules when a define in driver_params.h should be called CONFIG_DRIVER_PARAM_<NAME> and when a parameter should simply be called DRIVER_PARAM_<NAME>? I have seen a mixture which doesn't seem to be consistent.

Personally I think many of those parameters are more a hardware configuration rather than a configuration of the driver itself, and would be better off left for other tools (e.g. the current driver_params.h or Device Tree). Nevertheless there are some drivers that expose these default values for their first instance as Kconfig symbols.

Would be a mapping

#define DRIVER_PARAM_<NAME> (CONFIG_DRIVER_PARAM_<NAME>`

OK to keep the compatibility with existing documentation where the default parameters could be changed by overriding them by CFLAGS at the make command line?

When Kconfig is not used (it does not run by default) the CONFIG_DRIVER_PARAM_<NAME> value can also be injected via CFLAGS, so I think just a documentation update is enough, no mapping should be needed if I understood you correctly.

What about the following:

... config DRIVER_MODE_1_VAL hex default 0x10 ...

Hm, that would require coding enumerations again, which I think is error prone. In my approach I can use the named constants as they are already defined by the driver.

Personally I think many of those parameters are more a hardware configuration rather than a configuration of the driver itself, and would be better off left for other tools (e.g. the current driver_params.h or Device Tree).

I'm only talking about selections the user has to make. A typical example would be a sensor for which the desired output data rate has to be defined. The output data rate is configured using a register and all possible values are defined as an enumeration. For efficiency, the enumeration directly encodes the register values.

gschorcht · 2021-12-05T16:26:38Z

Since the review of the PR hasn't really started yet and I've changed a lot, I felt free to restructure the PR and force-push it.

mguetschow · 2024-06-11T09:40:09Z

Does anyone of the active @RIOT-OS/maintainers have hardware and time to test this? Seems like a worthwhile PR to me.

chrysn · 2024-06-11T11:11:20Z

Is there any supported board on which this is present?

crasbe · 2024-07-04T22:43:54Z

Does anyone of the active @RIOT-OS/maintainers have hardware and time to test this? Seems like a worthwhile PR to me.

I am not a maintainer, but I can test it in the near future (once the Mouser order arrives). Mikro-E makes breakout boards for both chips that are covered by this PR.
https://www.mouser.de/ProductDetail/932-MIKROE-951
https://www.mouser.de/ProductDetail/932-MIKROE-1838

Given that this is a driver, the potential impact on the rest of RIOT should be low.
This IO expander should work well in my binary clock. Using RIOT for it wasn't the plan, but why not 🤣

crasbe · 2024-07-09T12:45:23Z

tests/driver_mcp23x17/README.md

+
+Used MCP23x17 I/O expander or interface variants have to be defined by
+the variable `DRIVER` using the corresponding pseudomodules `mcp23017`,
+`mcp23s17`, `mcp23017_i2c` and/or `mcp23017_spi`, for example:


Suggested change

`mcp23s17`, `mcp23017_i2c` and/or `mcp23017_spi`, for example:

`mcp23s17`, `mcp23x17_i2c` and/or `mcp23x17_spi`, for example:

The generic pseudomodules have the 'x' instead of the '0' and 'S'. Just a typo.

crasbe · 2024-07-09T12:47:53Z

tests/driver_mcp23x17/Makefile

@@ -0,0 +1,10 @@
+include ../Makefile.tests_common


Suggested change

include ../Makefile.tests_common

include ../Makefile.drivers_common

The test have been restructured in the meantime and now this is the common Makefile for all tests of drivers.

crasbe · 2024-07-09T12:48:49Z

So... I'm not sure if we can reach @gschorcht, but the main thing that conflicts with a rebase to the current master branch is the location of the test in tests/drivers_mcp23x17 instead of the current folder structure tests/drivers/mcp23x17. (Well, the rebase doesn't care, but it doesn't make sense to merge it like that).

The drivers/Kconfig and drivers/Makefile.dep files couldn't be merged automatically, but that is just because some stuff from the Kconfig file was deleted in the meanwhile and git incorrectly detected the place where to put the additional lines in the Makefile.dep.
But the Kconfig stuff is obsolete now anyways, so it could be deleted entirely.

The only change that has to be made to compile the code is in the suggestion above.

So far I did some very basic tests with both chips and a NUCLEO-L452RE and they generally seem to work. I can run the benchmark tests, configure and read/write the GPIOs. I'll take a deeper look at everything and give it a more thorough test, but for now it's good that it can be rebased and compiles with the current master.

riot-ci · 2024-08-16T23:48:45Z

Murdock results

✔️ PASSED

39538ce fixup! drivers/mcp23x17: SAUL integration

Success	Failures	Total	Runtime
10210	0	10211	18m:21s

Artifacts

Documentation preview

gschorcht added Type: new feature The issue requests / The PR implemements a new feature for RIOT Area: drivers Area: Device drivers Area: SAUL Area: Sensor/Actuator Uber Layer labels Jan 2, 2019

gschorcht mentioned this pull request Jan 10, 2019

sys: single interrupt handler thread for interrupts in modules with blocking functions #10555

Merged

stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019

gschorcht mentioned this pull request Aug 13, 2019

periph/gpio: enable API usage for expanders #9690

Open

5 tasks

benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Sep 3, 2019

stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Sep 3, 2019

This was referenced Nov 7, 2019

periph/gpio: support for extension API #12333

Closed

[WIP, RFC] drivers/eeprom: Common API to access EEPROM memory #12091

Closed

gschorcht mentioned this pull request Dec 5, 2019

[POC/RFC/WIP] periph/gpio: Proposal for the change of the GPIO API #12877

Closed

stale bot added the State: stale State: The issue / PR has no activity for >185 days label Mar 10, 2020

gschorcht added State: don't stale State: Tell state-bot to ignore this issue State: waiting for other PR State: The PR requires another PR to be merged first labels Mar 10, 2020

stale bot removed State: stale State: The issue / PR has no activity for >185 days labels Mar 10, 2020

jeandudey reviewed Feb 27, 2021

View reviewed changes

MrKevinWeiss added this to the Release 2021.07 milestone Jun 22, 2021

MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021

gschorcht force-pushed the drivers_mcp23x17 branch from b7f0347 to ddaa3bf Compare October 27, 2021 10:52

gschorcht requested review from aabadie, fjmolinas, leandrolanzieri, MichelRottleuthner and smlng as code owners October 27, 2021 10:52

github-actions bot added the Area: doc Area: Documentation label Oct 27, 2021

gschorcht requested a review from jia200x as a code owner October 30, 2021 10:57

github-actions bot added the Area: Kconfig Area: Kconfig integration label Oct 30, 2021

gschorcht commented Oct 30, 2021

View reviewed changes

gschorcht removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 30, 2021

gschorcht added State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Dec 3, 2021

gschorcht force-pushed the drivers_mcp23x17 branch from 19cc415 to fc1cc09 Compare December 5, 2021 16:23

github-actions bot removed the Area: tools Area: Supplementary tools label Dec 5, 2021

gschorcht force-pushed the drivers_mcp23x17 branch from fc1cc09 to e7bc305 Compare December 5, 2021 16:35

gschorcht added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Dec 5, 2021

gschorcht added the State: waiting for maintainer State: Action by a maintainer is required label Feb 4, 2023

crasbe reviewed Jul 9, 2024

View reviewed changes

gschorcht added 6 commits August 16, 2024 14:55

drivers/mcp23x17: add support for MCP23x17 I/O expanders

f9f9934

tests/drivers/mcp23x17: test app for MCP23x17 driver

f7cce08

drivers/mcp23x17: SAUL integration

668f1a7

kconfig: add driver for MCP23x17 and test app

ffb6d44

fixup! tests/drivers/mcp23x17: test app for MCP23x17 driver

3754917

fixup! kconfig: add driver for MCP23x17 and test app

2a83edd

gschorcht force-pushed the drivers_mcp23x17 branch from e7bc305 to 2a83edd Compare August 16, 2024 23:40

gschorcht requested a review from MrKevinWeiss as a code owner August 16, 2024 23:40

gschorcht added 2 commits August 17, 2024 02:17

fixup! drivers/mcp23x17: add support for MCP23x17 I/O expanders

41820b2

fixup! drivers/mcp23x17: SAUL integration

39538ce

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

drivers: add MCP23x17 I/O expander support #10688

drivers: add MCP23x17 I/O expander support #10688

gschorcht commented Jan 2, 2019 •

edited

Loading

gschorcht commented Jan 2, 2019

stale bot commented Aug 10, 2019

stale bot commented Mar 10, 2020

jeandudey left a comment

jeandudey Feb 27, 2021

jeandudey Feb 27, 2021

jeandudey Feb 27, 2021

gschorcht Feb 27, 2021

gschorcht Oct 30, 2021 •

edited

Loading

leandrolanzieri Oct 30, 2021

gschorcht Oct 31, 2021 •

edited

Loading

leandrolanzieri Nov 1, 2021

gschorcht Nov 5, 2021

leandrolanzieri Nov 5, 2021

gschorcht Nov 5, 2021

gschorcht commented Dec 5, 2021

mguetschow commented Jun 11, 2024

chrysn commented Jun 11, 2024

crasbe commented Jul 4, 2024

crasbe Jul 9, 2024

crasbe Jul 9, 2024

crasbe commented Jul 9, 2024 •

edited

Loading

riot-ci commented Aug 16, 2024 •

edited

Loading

	if (params->reset_pin != GPIO_UNDEF) {
	if (gpio_is_valid(params->reset_pin)) {

	: ${TEST_KCONFIG_BOARDS_AVAILABLE:="
	dwm1001
	hifive1
	native
	nrf52840dk
	nucleo-f103rb
	remote-revb
	samr21-xpro
	seeedstudio-gd32

	`mcp23s17`, `mcp23017_i2c` and/or `mcp23017_spi`, for example:
	`mcp23s17`, `mcp23x17_i2c` and/or `mcp23x17_spi`, for example:

	include ../Makefile.tests_common
	include ../Makefile.drivers_common

drivers: add MCP23x17 I/O expander support #10688

Are you sure you want to change the base?

drivers: add MCP23x17 I/O expander support #10688

Conversation

gschorcht commented Jan 2, 2019 • edited Loading

Contribution description

Benchmarks

Testing procedure

Issues/PRs references

gschorcht commented Jan 2, 2019

stale bot commented Aug 10, 2019

stale bot commented Mar 10, 2020

jeandudey left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschorcht Oct 30, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschorcht Oct 31, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschorcht commented Dec 5, 2021

mguetschow commented Jun 11, 2024

chrysn commented Jun 11, 2024

crasbe commented Jul 4, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crasbe commented Jul 9, 2024 • edited Loading

riot-ci commented Aug 16, 2024 • edited Loading

Murdock results

Artifacts

gschorcht commented Jan 2, 2019 •

edited

Loading

gschorcht Oct 30, 2021 •

edited

Loading

gschorcht Oct 31, 2021 •

edited

Loading

crasbe commented Jul 9, 2024 •

edited

Loading

riot-ci commented Aug 16, 2024 •

edited

Loading