How to know what sensors are plugged into which ports and pins?

[konacurrents]

Re: How to use multiple Units wired via GROVE? PbHub?

Following up on my earlier post. I have a single binary code base (same .ino) that needs to be configured at runtime based on which sensors are plugged into which ports and bus kind (UART, GPIO or I2C).

Question: How do others manage this plug-n-play vision?

For example, I currently send a MQTT or BLE message to my devices with configuration values when it cannot be determined at runtime.

Example M5 Atom

The M5 Atom has the PB port out the back. This has KEY pin 32 and DATA pin 26. I can plug in a push button sensor.

But if I plug in the same push button sensor into port PB of the
ATOMIC PortABC Extension Base - it uses keys: 23 and 33.

As mentioned in the PortABC reviews:

So useful in an M5 ecosystem where some sensors still use UART or GPIO for integration. With that extension base, your Atom ends up with so many integration ports (2 x I2C, 1 UART, 1 GPIO) using YH2.0-4P connectors in a very compact form.

Sensor Mapping

I envision a JSON file that defines this kind of mapping (sensor to pins and ports).

[ajb2k3]

@konacurrents Ports are colour coded.
UART devices have blue connectors,
I2C have Red connectors,
Analog have black connectors,
Generic device have white connectors.

There isn't a JSON file, that not how it works.

M5Stack devices use ESP32's so I suggest looking into the ESP32's GPIO matrix system,
The ports are often predefined in the code to simplify connection.
Also check out the documentation on the M5Stack web sites product page.

[konacurrents]

@ajb2k3 Thanks for reply. My question is what happens in the example stated when the M5Atom is using the ATOMIC PortABC Extension. In this case, there are 2 I2C ports.

So if my button is plugged into the M5Atom, it uses one set of pins, but if plugged into the Extension, it's a different pin set (and plugged into the red one as you state.)

I just did some testing and with an EPROM setting I can state which of the 2 plugs (and associated pins) to use. Next time it's powered on - the buttons work in the new plugin.

Unfortunately the changes won't work unless POWER is cycled (rebooting isn't enough). Actually after changing the pins, rebooting will start looking at the different pin, and it won't work (without the POWER cycle.)

So again, I was wondering what developers do with this plug-n-play vision without hardcoding all the devices and knowing where they are plugged in. I have the PBHub but haven't played with it yet (but I think it has a naming issue as well, eg. plug1 in slot1, etc).

This dynamic configuration is where a JSON (or equivalent) configuration could be specified and stored in EPROM.

Thanks.