MPR121 Touch IC Based Keypad Input Module

[aussieklutz]

For an upcoming meshtastic project, this implements an input driver utilising the MPR121 Touch IC and is compatible with common MPR121 keypad PCB's.

• Implements a "candybar" phone style 12-key keypad
  • multiple taps to rotate through the character set
  • longpress for navigation keys
  • keymap to allow arbitrary routing of MPR121 pin to button configuration
  • extendable to other key functions
• Integrates with the existing kbI2cBase implementation
• Works with CannedMessageModule Freetext mode
• Can be used with common MPR121 boards, such as https://www.amazon.com/MPR121-Capacitive-Keyboard-Buttons-Sensitive/dp/B083R89CHB/ref=sr_1_6
  • Note: These boards have the MPR121 configured to address 5A, which conflicts with an existing sensor. I made some patches around the configuration.h to resolve this, but welcome advice on the best approach.
• Of use for PCB based radios, where some form of low surface area low component freetext input is required, but also without consuming too many IO pins.
• Tested on a T3S3 connected to Wire1 (Second) interface.
  • Demonstration of functionality: https://youtu.be/UI6QP6nGvhY

For testing, uncommented the MRP121_USE_5A define in configuration.h, and add #define CANNED_MESSAGE_MODULE_ENABLE 1 to variant.h. Again, I expect that this is not an ideal approach and looking for input as to the best way to move forward.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[fifieldt]

Hi and welcome! Thanks for proving a great write-up.

I see the conflict with the MLX90614. Question - is there a register in the keyboard we can query that reliably returns something we can use to identify it? "Chip ID"/"model number/ etc. That way we can better disambiguate whether we have the sensor or the keyboard at that address.

[aussieklutz]

And then write a special case scan, instead of using the simple scan macro, i.e instead of disambiguating in configuration.h, doing it in scani2c/scani2cwire?

[fifieldt]

Ayesir!

[fifieldt]

Couldn't see anything obvious in the data sheet. The 90614 appears to have an ID Number register so maybe we can search for that instead and make the keyboards the default :)

[fifieldt]

By the way, are you familiar with the trunk linting tool? We use it to keep forgetting consistent and it looks like the files changed here need to be run through it.

[aussieklutz]

I saw that. I'll lint it and give the detecttion approach a go. Cheers.

[aussieklutz]

This will take some more thought... the MLX90614 ir temp sensor datasheet doesn't document the canonical id value, and it may be more a serial number than product id... this reference treats it as a 64 bit value... https://github.com/jfitter/MLX90614/blob/master/src%2FMLX90614.cpp

[aussieklutz]

I think the most effective solution will be relying on the initial startup state of the MPR121:

Note: After completing power on reset (POR) or soft reset by command, MPR121 all registers are in default reset initial value (see Table 1). All the registers are cleared, except AFE Configuration Registers 0x5C (Default 0x10) and 0x5D (Default 0x24).

[Nestpebble]

Here's how the dual addresses are done for the INA3221:

firmware/src/configuration.h

Line 127 in 2ba72c1

#define INA3221_ADDR 0x42

is the same as

firmware/src/configuration.h

Line 145 in 2ba72c1

#define DFROBOT_LARK_ADDR 0x42

So:

firmware/src/detect/ScanI2CTwoWire.cpp

Lines 304 to 313 in 2ba72c1

	case INA3221_ADDR:
	registerValue = getRegisterValue(ScanI2CTwoWire::RegisterLocation(addr, 0xFE), 2);
	LOG_DEBUG("Register MFG_UID: 0x%x", registerValue);
	if (registerValue == 0x5449) {
	LOG_INFO("INA3221 sensor found at address 0x%x", (uint8_t)addr.address);
	type = INA3221;
	} else {
	LOG_INFO("DFRobot Lark weather station found at address 0x%x", (uint8_t)addr.address);
	type = DFROBOT_LARK;
	}

[aussieklutz]

I'll need to get someone with the IR temp sensor to test the detection when it's working, but I'll use the 0x5C (Default 0x10) value as I maintain that value in the setup. The other default value is changed to 0x20 during initialisation of the ic, so would be different on a warm reboot.

[aussieklutz]

Okay, looks like a more complex soft reset process would be needed before reading from the MPR121, Instead looking to read the bus address register 0x0E from the MLX90614, which will contain 0x5A.

[caveman99]

LGTM

[fifieldt]

Most excellent work

[fifieldt]

Garn