[Feature Request] GPIO support in MeshCore

[helgeolav]

I need to access GPIO pins on my meshcore nodes. I guess that this is something that others also want, and I can write an implementation of this if the proposal is acceptable. The idea is that we expose new CLI commands that lets you set/retieve the values of a GPIO-pin. This is something that I want to implement on all roles.

I want to make some new defines:

GPIO_IN
GPIO_OUT
GPIO_DAC
GPIO_ADC

These defines is a comma-separated list of GPIO-pins that is accessible using the CLI. If a define is not present, then there will be no corresponding GPIO for that type.

Then I want to extend mesh::MainBoard in src/MeshCore.h with some new member functions. These should be overridden at the board type (ESP32 etc).

class MainBoard {
    public:
    virtual bool setGPIO(int pin, bool newState) = 0; // returns true if the pin was set
    virtual bool setDAC(int pin, float value) = 0; // returns true if the pin was set
    virtual bool getGPIO(int pin); // return the value, or false if the pin does not exist
    virutal float getADC(int pin); // returns the value, or 0
}

I know that getGpio() and setGpio() is defined in MainBoard already, and probably it would be a good idea to use them. I just don't know the consequence yet of using these.

I have not a GPIO-init function here. I think that can be handled by the MainBoard subclass own setup/begin() function.

Then change the common CLI, add some new commands.

set gpio 1 1
get gpio 1
set gpio 2 3.43

If the GPIO is analog, use float values, for digital use 0 or 1.

Any thoughts?

[Torisaz]

Hi i use gpio with my v4 for controlling stuff from the mesh and drive a stepper motor with it. Check out a datasheet the commands you are proposing may do more harm than good if you open them to random flipping. You also need to buffer the pins with electronics you can easy kill the pins if you don't...
from memory (so look em up before using..) On v4 theres 15 16 45 47 48 digi io free + a couple of the an ins + theres a couple more pins + if you resource steel eg f'off the gpsa few more . float for an in'' no you are reading in a whole number.. I use unsigned int. I dont use cli as i put them in companion (as its also a repeater on my roof) but instead send a encrypted chan message and decode it. the other boards are slim on spare pins too. you can use pin expansion by something like 3 to 8 encoder decoder ic

i use defines like

#define IO_15 15
#define IO_16 16

this is in somewhere too
pinMode(IO_15, OUTPUT);

only define the ones u know are safely available from the data sheet.
say you decide go with a v4 you then have the problem of pin changes from rev 4.2 to 4.3 which im thinking theres at least 2 i can remember.

Though i put the defines in the code it may have been better in the header

so an example of doing more harm than good is set gpio 1 1 which is used for battery reading so you should leave alone again from memory so might be wrong

[helgeolav]

Hi i use gpio with my v4 for controlling stuff from the mesh and drive a stepper motor with it. Check out a datasheet the commands you are proposing may do more harm than good if you open them to random flipping. You also need to buffer the pins with electronics you can easy kill the pins if you don't from memory (so look em up before using..)

What MCU are you referring to? Those that I have read the datasheets on have no impact on the number of writes to the pin. But for most electronics, the load on the pin may have other constraints.

The pins are also set only when the CLI command is run, so unless you run the CLi commands all the time this should not be an issue.

float for an in'' no.. I use unsigned int.

Thanks, I checked and Ardunios digitalWrite() uses uint8_t for pin. So I will stick with that.

I dont use cli as i put them in companion (as its also a repeater on my roof) but instead send a message and decode it.

For my usecase, the plan is operate the pins by automation (think Home Assistant) , so the CLI is more feasable. That way another node can send a CLI command to get/set a GPIO.

the other boards are slim on spare pins too.you can use pin expansion by something like 3 to 8 encoder decoder ic

At least for my first version I was just planning on getting support for the builtin pins. I see ways that we can extend that, but that will come later.

i use defines like
#define IO_15 15
#define IO_16 16

Using a define like #define GPIO_IN 3,14 lets me declare those values like const uint8_t gpio_input_pins[] = { GPIO_IN } and the values are parsed at compile-time. (Though you can specify pin 100, or any other number that is not valid for your platform, but that is another topic.)

so an example of doing more harm than good is set gpio 1 1 which is used for battery reading so you should leave alone again from memory so might be wrong

My plan is to restrict access to pins to what you have put into the defines. So unless pin 1 is in GPIO_OUT, you cannot set that pin. The idea is that the board developer (or firmware developer for that board) can preassign some pins for input or output by adding some lines into platformio.ini. Power users can also easily recompile a board to get some pins working. Then the rest of us can just consume those gpios remotely.

Pins used by the system or any sensors should not be exposed as gpio pins.

You mentioned the v4. I have the same board myself, and have built a custom firmware to handle gpio. Though not as extensive as this proposal, it gave me the one input and output I needed.

[Torisaz]

This arduino one works to drive Stepper Motor 28BYJ-48 + ULN2003 without even level shifting but it is a bit gutless
I havent sent a cli command from another mesh device as i send messages from a win 11 program via chrome connected via bluetooth to companion to another to control it, using progs written with borland bcb6 so way old school and havent thought about how cli companion to repeater would work. you planning on sending via rs232 >> companion >> repeater ?

heres an example of what i bluetooth to first companion which it then sends the message to second companion
PIO00.0 // action GOTO 0 + PROX WIDTH
PIO00.1 //action GOTO 1 OCLOCK
its an antenna rotator and masthead swithcher so home automation like

lol changed the commands a little so my mates on private channel dont remote in an f' with my rotator

Also you have to decide if you want it internal or external pullup pin

'What MCU are you referring to? Those that I have read the datasheets on have no impact on the number of writes to the pin'..... not writes .. pulling power thing, taking it down with over current'

• v4 is weedy .. do not forget if you interface to old cr*p >>>> V4 is not 5V tolerant <<<<<
  Its most likely the same with the other lora boards