Skip to content
This repository has been archived by the owner on Mar 3, 2018. It is now read-only.

More than 5 buttons kills callbacks #3

Closed
ril3y opened this issue Dec 16, 2015 · 9 comments
Closed

More than 5 buttons kills callbacks #3

ril3y opened this issue Dec 16, 2015 · 9 comments

Comments

@ril3y
Copy link
Contributor

ril3y commented Dec 16, 2015

I have found that if you issue something like 5 buttons............

button3 = new bot.Button(bot.pins.p9_13); button4 = new bot.Button(bot.pins.p9_14); button5 = new bot.Button(bot.pins.p9_15); button6 = new bot.Button(bot.pins.p9_16); button7 = new bot.Button(bot.pins.p9_18);

Then assign them all callbacks like:

`button3.on('pressed', function () {
console.log("#3 pressed");
});

button4.on('pressed', function () {
console.log("#4 pressed");
});

button5.on('pressed', function () {
console.log("#5 pressed");
});

button6.on('pressed', function () {
console.log("#6 pressed");
});

button7.on('pressed', function () {
console.log("#7 pressed");
});`

You must hit 1 button.. then hit a DIFFERENT button before that same button you hit initially will fire its callback again. I have not found the blocking issue as of yet. But I am hopeful someone might know.

To be clear... If I remove a button (say 3) and remove the callback for pressed for 3 as well. The next time I run the application I can spam button 4 over and over and it continues to say button 4 pressed.

The bug is that with greater than 4 buttons it introduces some type of blocking issue where you have to fire off a new buttons callback handler before you can repeat the previous button's handler.

Is that clear? I am in desperate need of some help here as I have a project that I am using your lib for and have had all boards all fabbed up and now am failing :) Any input on this would be awesome!

FYI: I have tried mapping different pins around etc and it's no change. The second I add a new button (going over 4 buttons) this behavior kicks in no matter what pin i map the button to.

Thanks!

@fivdi
Copy link
Owner

fivdi commented Dec 16, 2015

Lets say your app is called app.js. Does it work if the following commands are executed?

UV_THREADPOOL_SIZE=10
node app

@ril3y
Copy link
Contributor Author

ril3y commented Dec 17, 2015

@fivdi

Thanks for the reply. No increasing the threadpool had no effect. The only way to get a "repeat" button press to work is to limit the button inputs to 4 so far. Which i need 8 :) Any other thoughts? I can post my code if you like?

@fivdi
Copy link
Owner

fivdi commented Dec 17, 2015

Yes, post a simple example which can be used to reproduce the bug.

@fivdi
Copy link
Owner

fivdi commented Dec 17, 2015

The bug can be reproduced with the following code:

var bot = require('bot-io'),
  buttons = [
    new bot.Button(bot.pins.p9_23),
    new bot.Button(bot.pins.p9_24),
    new bot.Button(bot.pins.p8_07),
    new bot.Button(bot.pins.p8_08),
    new bot.Button(bot.pins.p8_09)
  ];

buttons.forEach(function (button) {
  button.on('pressed', function () {
    console.log('pressed: ' + button.name);
  });
  button.on('released', function () {
    console.log('released: ' + button.name);
  });
});

For some reason the data events for files corresponding to the buttons that are needed to detect button press and release are not being fired correctly. The JavaScript code for the data event handler is here.

What appears to be the same issue was also reported at nodejs/node-v0.x-archive#9132

@fivdi
Copy link
Owner

fivdi commented Dec 17, 2015

It turns out that this is related to the thread pool size. If the app is called app.js executing the following command should work (note that everything is on the same line):

UV_THREADPOOL_SIZE=10 node app

The following should also work:

export UV_THREADPOOL_SIZE=10
node app

@fivdi
Copy link
Owner

fivdi commented Dec 17, 2015

For more information about the thread pool see http://docs.libuv.org/en/latest/threadpool.html

@ril3y
Copy link
Contributor Author

ril3y commented Dec 18, 2015

@fivdi Thanks so much! I just got home and was going to upload some code for you. However looks like your code reproduces this bug just fine. I guess its not a bug but more of a configuration mismatch. I think we should close this and put this info int the docs? Agree?

@fivdi
Copy link
Owner

fivdi commented Dec 18, 2015

Agreed, this should be documented.

@fivdi
Copy link
Owner

fivdi commented Mar 29, 2016

Documentation updated with #4

@fivdi fivdi closed this as completed Mar 29, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants