mongoose-os-libs/core

Mongoose OS core lib

Core meta-library

core's Issues

Integrate GPIO extenders "seamlessly"

The following discussion ended with the idea to integrate a "pluggable" adapter/interface to access GPIO extenders directly form the GPIO_... API.

matrixbot @matrixbot 09:59
liberdiko @mamuesp Did you used a lib to interact with your GPIO expander over I2C?
liberdiko I'm looking for inspiration do make a lib for MCP23017 but I didn't find any in the official repos.

Manfred Müller-Späth @mamuesp 10:02
@matrixbot - Yes, the generic I2C lib - as the use of the expander is just read or write a byte (or, with 16 port versions, a word) to the module, it’s not worth the effort writing a specific library. Even if you use the interrupt pin for having an event for incoming data.

matrixbot @matrixbot 10:03
liberdiko Okay, thanks (;

Manfred Müller-Späth @mamuesp 10:07
I used the PCF8574 - and all you need is to read/write a byte as counterpart to reading/writing a GPIO pin. I have some MCP23017 too, but i didn’t use them yet.

matrixbot @matrixbot 10:13
liberdiko Yes exactly, I already managed that with the rpc-service i2c, wich is an awsome feature of mOS. I will follow your advice and just wrote functions related to my app, to abstract the IO expander, and not a generic lib.

Deomid Ryabkov @rojer 10:14
i like the idea of integrating expander into the gpio API though, so it's really seamless
would require a bit more work though

Manfred Müller-Späth @mamuesp 10:14
@rojer - May help in this matter …

Deomid Ryabkov @rojer 10:15
that would be appreciated!

matrixbot @matrixbot 10:16
liberdiko @rojer <3 I would love that!! And I'm willing to help to.

Manfred Müller-Späth @mamuesp 10:17
Yeah, well I use it in my project, and „seamless“ would be nice, so why not move my code into the GPIO lib? Let’s discuss where and how to put it, and what will be needed for bit manipualtaing functions (readingTwriting patterns, toggling only several bits etc.) and let’s go ...

Deomid Ryabkov @rojer 10:18
well, you are welcome to. but i have to warn that it's not a good "beginner" project, it'll need some finer grained understanding of the internals to do properly
basically, since gpio number is an int, we usually have spare upper bits that we can use to denote that the pin number (lower bits) lies on an expander
on STM32 we already use 24 bits (alternate function, port number, pin number), so we have 8 left

Manfred Müller-Späth @mamuesp 10:20
@rojer - I think bit fiddling is the main problem. But I have already prepared a library, we had already talked about that once.

Deomid Ryabkov @rojer 10:20
so mgos_gpio_* functions need to be taught about these new bits and then to delegate to driver implementations for expander to actually twiddle the bits

Deomid Ryabkov @rojer 10:21
handling interrupts will probably be the more intricate problem
another problem is that gpio is in core...
actually
i think we should extend gpio API to support "pluggable" expanders.

Manfred Müller-Späth @mamuesp 10:22
Well, if it is put into the GPIO_part, there could be use of the ISR context as well … right?

Deomid Ryabkov @rojer 10:23
so we create an api inside mgos_gpio_ to delegate read, write, toggle and interrupt stuff
and then expander library can register itself as GPIO extension and obtain a "namespace" (i.e. numeric prefix) withing the gpio space

Manfred Müller-Späth @mamuesp 10:24
@rojer - Yes, because these expanders are stackable up to 128 or even 256 GPIO pins, so the integer value wont suffice for a bit map, you will always need an address value as well. Ok, with a 32bit integer this might work - the upper word is the address, the lower the bit mask … might be discussable.

Deomid Ryabkov @rojer 10:24
@mamuesp if we do it as pluggable gpio extensions, then library will be responsible for catching the expander interurpt (via "normal" gpio, presumably), then determining which pin(s) toggled it and propagating it up to gpio library back
so yeah, i think it's doable, if a bit fiddly. would make for a very nice feature though.

Manfred Müller-Späth @mamuesp 10:26
@rojer - yeah, that will be a little tricky to „map“ this to a „normal“ interrupt handling.

Deomid Ryabkov @rojer 10:26
can i ask you to file a feature request issue for now? you can c/p this whole discussion

Manfred Müller-Späth @mamuesp 10:28
@rojer - So let’s see: I'm optimizing my library right now anyway, so I'll think about these points and present the result again later. It'll take a few days. Yeah, and a feature rewuest (in core lib?) might be a good remarker. You remember the FR for the interrupt quantity parameter in MJS?

Deomid Ryabkov @rojer 10:29
vaguely :)
basically, the proper way i think is add extension api to GPIO and then make expanders their own libs, as they should be, that register as GPIO extensions at init time
the question whether to assign static prefixes to extensions or dynamic at init time is somewhat open
depends on what will be more usable for user
mgos_gpio_write(MCP23017_GPIO(0, 1), 1) should be the result
and perhaps #define MCP23017_GPIO(unit, pin) MGOS_GPIO_EXT(MCP23017_GPIO_EXT, (unit << 8) | pin)
something of that sort
@mamuesp wdyt?

Manfred Müller-Späth @mamuesp 10:35
@rojer - Good idea, because so you may use also expanders which might be addressed in a different way.

Deomid Ryabkov @rojer 10:35
right
defining MCP23017_GPIO or OTHER_EXPANDER_GPIO would be up to the library
they basically get 24 bits of int to play with

Manfred Müller-Späth @mamuesp 10:36
@rojer - Yes, and the address handling and indivdial accessing is the libraries part and configuration. So it’s „pluggable seamless“ ...

Deomid Ryabkov @rojer 10:37
right

Manfred Müller-Späth @mamuesp 10:38
@rojer - And perhaps the prefix will be defined in the configuration, so you may generate the callbacks as in the configuration handling. I love code genrators … (wrote my thesis on one long time ago …)

Deomid Ryabkov @rojer 10:39
well, we shouldn't get too carried away here :)
GPIO api must be efficient

matrixbot @matrixbot 10:39
liberdiko Some GPIO functions like mgos_gpio_set_mode are platform specific. Does it mean the code for all the platforms need to be touched? Or wrapping thoses function at level of the generic mOS is better way?

Deomid Ryabkov @rojer 10:39
that's why i think we can start by just assigning MCP23017_GPIO_EXT statically
@matrixbot mgos_gpio_set_mode is actually the same on all platforms, but it then calls a platform-specific mgos_dev_gpio_set_mode

Manfred Müller-Späth @mamuesp 10:40
@rojer - Yeah, well, back to the bottom of the facts …

Deomid Ryabkov @rojer 10:40
that needs to be refactored a bit to make it more dynamic, and then platform's native GPIO implementation becomes "extension 0"
but platform code itself doesn't need to be touched, beyond maybe organising into a struct of fucntion pointers for registering
in an unrelated note, - god i hate govendor. just can't seem to figure out how to use it.

GPIO_LEVEL interrupts broken on ESP32

Hello, i am working on esp32 and tried to use this:

mgos_gpio_set_int_handler(MY_INTERRUPT_PIN, MGOS_GPIO_INT_LEVEL_LO, my_cb, NULL);

but callback is never called. when i use this, the callback is called properly:

mgos_gpio_set_int_handler(MY_INTERRUPT_PIN, MGOS_GPIO_INT_EDGE_NEG, my_cb, NULL);

Is there reason for this? I think that negative edge should trigger LEVEL_LO as well.. Am i right?

Problem with edge trigger is that when i miss the edge while interrupts are disabled, it will not get triggered afterwards while pin is still low. So i need to trigger on low-level instead, but it's broken :-/

Add mgos_invoke_cb() option to use xQueueSendToFront...()

I need to use relatively complex code in ESP32 GPIO ISR (to handle complex protocol in time).
But it turned out, i can't just tag everything IRAM_ATTR... It panics and i don't know why.

What is working for me is using mgos_invoke_cb to switch from ISR context to main context, where i can use complex libraries... But i feel like it's slow and other events and timers can mess me up. Is there way around this?

mgos_invoke_cb() currently uses xQueueSendToBackFromISR(). What if we used xQueueSendToFrontFromISR() instead? That way i probably can get more priority over other stuff to be able to handle my communication on time... And get executed ASAP after return from ISR...

https://www.freertos.org/xQueueSendToFront.html

IRAM bool mgos_invoke_cb(mgos_cb_t cb, void *arg, bool from_isr) {
  struct mgos_event e = {.cb = cb, .arg = arg};
  if (from_isr) {
    BaseType_t should_yield = false;
    if (!xQueueSendToBackFromISR(s_main_queue, &e, &should_yield)) {
      return false;
    }
    YIELD_FROM_ISR(should_yield);
    return true;
  } else {
    return xQueueSendToBack(s_main_queue, &e, 10);
  }
}