I have two container. One is triggered by 4 GPIO Pins if they are driven LOW. And one container which is triggered when one GPIO is driven HIGH. First of all: I think this is not possible at all. I can not have gpio high and low mixed as trigger. But besides that I receive a message in the log telling me:

[artemis.containers] INFO: triggered by pin {name: trigger, id: b9906bd7-9c7e-dce1-9a10-4ab91b230523, pin: 7, level: 0}

but if I check the

esp32.ext1-wakeup-status

and extract the pin which actually triggered this container to run I get 9 instead of 7. 9 is supposed to be the GPIO which starts a container when driven HIGH and it became LOW (thats why I assume it is not possible to have both setup). There is an option with "any high" or "any low" and I think it can only be that any of the GPIOs are low or any of the declared once are HIGH but not both. So - this is causing lots of chaos in my code now and I wonder if I can fix that somehow. Or if this is even fixable somehow anyway. I am using artemis right now with a container declaration like so:

containers:
  trigger:
    entrypoint: "../src/trigger.toit"
    triggers:
      - gpio:
        - pin: 6
          level: "low"
        - pin: 7
          level: "low"
        - pin: 18
          level: "low"
        - pin: 21
          level: "low"
  ble:
    entrypoint: "../src/ble/ble.toit"
    triggers:
      - gpio:
        - pin: 9
          level: "high"

I think the only option I have here is to always only run one container which then checks the cause and the pin numbers and also checkts the Pins and then runs the dedicated containers on there own. Is this possible? Can I skip artemis from running the container and leave it to me, when to run them? (I assume not)

You are right: the ESP32 doesn't support low and high triggers at the same time. While the device is running, Artemis will look for both, but it can't do that while in deep-sleep.

🤔 I can change the polarity of the sensor programmatically for the triggering I think. but I also added an external pull-up so I could remove this and make it all trigger on HIGH. That could work.

And I still need to check why the pin is 9 and not 7. Feel free to remind me so I don't forget.

but this has nothing to do with the mask I am passing, right?

No. https://github.com/toitlang/toit/blob/master/src/primitive_esp32.cc#L352

🤔

I never noticed it either. So I'm not completely sure what it does. Artemis starts by taking the status, so it probably automatically resets it this way.

I was in a train yesterday (embedded world) - so you do deinit the gpios in status. So it should be fine if I call it. But you mean you should just deinit ALL pins? Propably right.

I think so, but I have to read up. Not sure why we give users the option of passing in a mask, and not sure what happens if that call doesn't happen.

I swapped the interrupt from low to high and now it works for both. It is still not behaving perfectly but the interrupt of the sensors fires every time I am sending a command, so that is triggering every time as well

This is, how we do it:

triggered-pins := esp32.ext1-wakeup-status external-mask
      touch-wakeup-pin := esp32.touchpad-wakeup-status  // -1 if not triggered by touch.

      job-was-triggered := false
      // If the high_mask isn't 0, then it wins over the low mask.
      jobs.do: | job/ContainerJob |
        job.do --trigger-gpio-levels: | pin level/int |
          pin-mask := 1 << pin
          if (triggered-pins & pin-mask) != 0:
            is-triggered := false
            if level == 1:
              // Level 1 wins over level 0.
              is-triggered = true
            else if high-mask == 0:
              // Level 0 is only triggered if there is no level 1.
              is-triggered = true
            if is-triggered:
              job-was-triggered = true
              job.trigger (Trigger.encode-pin pin --level=level)
              tags := job.tags.copy
              tags["pin"] = pin
              tags["level"] = level
              logger_.info "triggered by pin" --tags=tags

@floitsch if I initialise a pin with

gpio.Pin.out

it says the default value is 0 - does it set this pin actively to be 0? The Pin has an external pull-up and it should stay on or at least not set the level to be 0 when I initialise it.

gpio.Pin --out

(equivalent to

gpio.Pin.out

) actively sets the pin to 0. Yes.

this will reset my sensor

If you don't want to output anything, then you shouldn't use

--out

.

hm.. the pin in always an output in my case I just don't want to change its state. maybe open-drain will work

Typically, when you say "the pin is now output", you have to say how (1 or 0). If you don't want to change it's value, then it's not really "output". You have 3 options: - keep the pin as non-output as long as you don't need to change the value. You can always use

configure

to change it. - make it

--open-drain

. Then the output is only "effective" if you go to 0. - only allocate the pin when you need to change the value.

thanks , thats what I do now. I kind of have to initialise it. But I go with open-drain now and I do change its config once I have to use it.

You don't need to change the config with open-drain. That should just work.

somehow the wakeup seems to be unreliable - at least it does not react for two of the 4 sensors. but this could be something different. I have no pull-down resistors on those pins now which could be a problem

Do they work if you don't go to deep-sleep?