Need .on('rise') and .on('fall') events for pins

[Frijol]

To maintain back-compatibility.
Relevant to tessel/hardware-modules#5

Is this best solved with a state variable?

[rwaldron]

I'm going to take a crack it this :)

[johnnyman727]

Adding some details from @kevinmehall on Slack, in case they're useful:

kevinmehall [11:38 PM]
You can do `.on('change')` to get rise and fall events, but you can't get separate callbacks for rise vs fall.

kevinmehall [11:38 PM]
These are limitations of the SAMD21 interrupt controller as represented in JS

[rwaldron]

That's definitely helpful—thanks!

[rwaldron]

@johnnyman727 @kevinmehall when you say

These are limitations of the SAMD21 interrupt controller as represented in JS

Do you specifically mean in t2-firmware/node/tessel.js?

I'm trying to understand how that plays with the documented capabilities: http://asf.atmel.com/docs/3.17.0/samd21/html/group__asfdoc__sam0__extint__group.html

[johnnyman727]

I believe what @kevinmehall was saying is that the SAMD21 has no notion of rise or fall events - only change and that firmware/node/tessel.js hasn't been written to parse the cause of the event (whether it was rise or fall) yet..

[rwaldron]

The latter is clear, but regarding the former—I'm confused, because the docs appear to contradict.

[kevinmehall]

The hardware can give you an interrupt on one of rise, fall or change, but it can't give you an interrupt for both rise and fall separately. Firmware could read the pin on the change interrupt to see if it was a rising or a falling edge, but this will give incorrect results if the pin has changed again while the interrupt was pending.

[rwaldron]

Got it, thanks for the clarification

[reconbot]

I take it the t1 could do both rise and fall at the same time? Did the t1 have a change event?

So what's the way forward? I see two fighting concerns.

1. Legacy compatibility
2. The ability to correctly bind to the events

With two different solutions

1. Fall back to using the change event to emulate rise and fall if more than one even is bound to
2. Do nothing and modify packages like button and pir to use change (possibly special casing the t2)

I'd lean towards 1 because it's more friendly to most users but I don't know how frustrating it would be people who wouldn't want the behavior

[Frijol]

This is a good summary, and I'd lean towards solution 1 for the same reasons. Thanks for looking into this!

[reconbot]

Rereading @kevinmehall's comments. I'm scared about missed events. If the change interrupt was pending and it changed again, would we get one or two change interrupts from the socket?

[Frijol]

checking back on this - do we have .rise and .fall events now? Lots of people asking for PIR support

[johnnyman727]

It looks like we do. I believe @dudleyjosh has already been using them.

[dudleyjosh]

There are .on('rise') and .on('fall') events, however I'm not sure how useful they are as-implemented?

It is my understanding that there is a limitation of one interrupt allowed per pin and only one of the events can be used at a time so most end use cases would probably call for an .on('change') event where the user then checks for the value from within the change event.

pin.on('change', function() {
    this.rawRead(function(err, val) {
        if ( val === 0 ) {
            console.log('fall', val);
        }
        else {
            console.log('rise', val);
        }
    });
});

There is also still an issue with doing a regular .read() instead of a .rawRead() within a change event. If you do a regular .read() it will only read once (once on a rise and once on a fall)... then nothing?

Starting with firmware v0.0.12 (thanks to @rwaldron), the pin val is provided with the change event .on('change', function(val){}) so you don't have to do a separate .rawRead(function(err, val){}) within... but I'm not sure it is working perfectly yet. See issue #164

pin.on('change', function(val) {
    if ( val === 0 ) {
        console.log('fall', val);
    }
    else {
        console.log('rise', val);
    }
});

Question: Even though there is a hardware limitation of one interrupt per pin, once the .on('change', function(val){}) is determined to work reliably why no just have it emit 'rise' or 'fall' from that point to achieve the same functionality as the T1 where the end user could then use both .on('rise') and .on('fall')?

[johnnyman727]

Question: Even though there is a hardware limitation of one interrupt per pin, once the .on('change', function(val){}) is determined to work reliably why no just have it emit 'rise' or 'fall' from that point to achieve the same functionality as the T1 where the end user could then use both .on('rise') and .on('fall')?

I think that's a totally reasonable idea. @dudleyjosh want to give a go at implementing it?

[dudleyjosh]

@johnnyman727 I will give it a shot over the weekend :)

[yesplease]

New to hardware hacking and just got a Tessel 2. Would love to figure out how to attach a button to it! Commenting here to say hello beautiful community hackers and so I can follow along in conversation.

I got one of these: https://www.sparkfun.com/products/11274

[reconbot]

@yesplease I'd take a look at http://johnny-five.io/api/button/ as it's works well with the tessel and gives you a lot of examples and circuit diagrams to follow.