Digital write not working on PWM pins, Gen 2

Question

Digital write not working on PWM pins, Gen 2

ryoshu opened this issue 10 years ago · 80 comments

var Galileo = require("galileo-io");
var board = new Galileo();
var pin = 11; //use any PWM pin

board.on("ready", function() {
  var byte = 0;
  this.pinMode(pin, this.MODES.OUTPUT);

  setInterval(function() {
    board.digitalWrite(pin, (byte ^= 1));
  }, 500);
});

Expected behavior: Digital write should send HIGH on all digital pins.

rwaldron commented 10 years ago

ecafdc9

Answer 1 · 2014-09-26T15:36:10.000Z

Is this also on the latest IoT kit image? Can you provide the version? Really sorry all of these errors are getting in your way and I'll work on addressing them ASAP

Answer 2 · 2014-09-26T15:48:29.000Z

It's the latest version: http://software.intel.com/iot. Let me know if you need anything else. Thanks!

Answer 3 · 2014-09-26T17:56:37.000Z

I just updated the mraa bindings used by Galileo-IO to the latest release and tested digital pins 2 through 13 to confirm digital writes and all pins worked correctly. Please run the following and post back the output, thanks!

node -e 'console.log(require("mraa").getVersion());'

Answer 4 · 2014-09-28T10:56:08.000Z

I've hit this problem as well on both Galileo generations. Not sure how to debug this, but:

GALILEO GEN1 FW 1.0.3

This is while using a fresh install of the current IoT Devkit image 1.1 [1].

[1] http://iotdk.intel.com/images/1.1/iot-devkit-201409031152-mmcblkp0.direct.bz2

$ node -e 'console.log(require("mraa").getVersion());'
v0.5.0-12-g3898182

opkg info libmraa0

Package: libmraa0
Version: 0.5.0.12
Provides: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0
Replaces: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0
Conflicts: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0
Status: install user installed
Section: libs
Architecture: i586
Maintainer: Intel IoT-Devkit
MD5Sum: 473e2b3092bf293045acbebf640286dc
Size: 189072
Filename: libmraa0_0.5.0.12_i586.ipk
Source: https://github.com/intel-iot-devkit/mraa
Description: mraa built using CMake
Installed-Time: 1411900482

GALILEO GEN2 FW 1.0.2 (Not current!)

I'm not sure about the version of the IoT Devkit image version on this board, but judging by the libmraa(3) version I assume it's 1.0:

$ node -e 'console.log(require("mraa").getVersion());'
v0.4.4

opkg info libmraa0

Package: libmraa0
Version: 0.4.4-r0
Depends: libgcc1 (>= 4.8.2), python-core, libpython2.7-1.0 (>= 2.7.3), libstdc++6 (>= 4.8.2), libc6 (>= 2.19)
Status: install user installed
Architecture: i586
Installed-Time: 1408097108

...didn't need to sanitize any of that, it's the exact output of command line.

Answer 5 · 2014-09-28T15:19:20.000Z

An important clue is that while using the Intel XDK [1](latest version with IoT components) to upload and run a blink example similar to ryoshu's code, it actually works (the light blinks) on the Gen2 board with 1.0.2 firmware (the identical configuration as indicated in the previous comment [2].) Since the XDK uploads NodeJS projects to the Galileo, this clue could be useful in narrowing the problem scope.

[1] http://xdk-software.intel.com/
[2] #16 (comment)

Answer 6 · 2014-09-28T18:19:41.000Z

Sorry, but I've never used the XDK. When working directly on Galileo-IO or using it as an IO Plugin for Johnny-Five in projects, I just SSH to the board and use rsub to open files from the board for editting in Sublime Text.

Answer 7 · 2014-09-28T18:30:04.000Z

Despite the obviously negative tone of this deleted part of your comment, there were some valid questions:

If you're feeling generous, then please share how you fix these things so that we can learn and do it ourself,

SSH to board
touch test.js
rsub test.js
Write out the code in test.js that will hopefully produce the error. In best cases, the code has been provided in the bug report.
In terminal: node test.js
Make best possible assertion about observed behavior.

I have a script for files in galileo-io/lib/* that will scp the files to the board when changes are made locally.

If problems can be reproduced, write tests in test/* and work towards making them pass as well as observing the correct behavior of the original test case program.

Are most problems resembling this one in the bindings of libmraa(3)? Source file?

I'm not sure how to answer this since I haven't been able to reproduced the bug. It's still unclear to me how this bug was encountered—no one has provided an actual "steps to reproduce".

Answer 8 · 2014-09-28T18:48:20.000Z

As I mentioned in my email response, the following must be confirmed before a Galileo-IO version is published to npm

Blink an led on pins 2-13
Log a button's state on pins 2-13
Fade an led through 2hz phases (0-255, 255-0, 500ms each) on all PWM pins
Sweep a servo from 0-180, 180-0 on all PWM pins
Log sensor readings on all analog pins

Answer 9 · 2014-09-30T15:08:05.000Z

root@quark016d09:~/projects/coral-test# cat /etc/version
201409031130

root@quark016d09:~/projects/coral-test# node -e 'console.log(require("mraa").getVersion());' && node -v
v0.4.5
v0.10.28

Sorry about the delay!

Answer 10 · 2014-09-30T18:14:11.000Z

@ryoshu thanks! Can you update the libmraa0 bindings to the latest version (will be easier for us to coordinate)

echo "src mraa-upm http://iotdk.intel.com/repos/1.1/intelgalactic" > /etc/opkg/mraa-upm.conf
opkg update
opkg install libmraa0

Answer 11 · 2014-09-30T18:39:56.000Z

'# opkg upgrade'
Upgrading libmraa0 on root from 0.4.4-r0 to 0.5.0.12...
Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/libmraa0_0.5.0.12_i586.ipk.
Upgrading upm on root from 0.1.6-r0 to 0.1.8.28...
Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/upm_0.1.8.28_i586.ipk.

When I tried upgrading on Gen2 it didn't help.

And possibly related, setting GPIO pins manually seems to be defective:

Note: On Gen2, GPIO7 == Pin13

echo -n "7" >/sys/class/gpio/export

-sh: echo: write error: Device or resource busy

echo -n "out" >/sys/class/gpio/gpio7/direction

echo -n "1" >/sys/class/gpio/gpio7/value

echo -n "0" >/sys/class/gpio/gpio7/value

Note: Last two commands do not blink pin 13

Maybe the problem we're seeing is not even in user space?

Answer 12 · 2014-09-30T19:44:44.000Z

That looks like a pretty serious issue. As a software engineer, I've spent 15 years assuming that the code I wrote was the source of the bug and so I sometimes forget when dealing with hardware that this is not always the case.

Answer 13 · 2014-09-30T19:49:20.000Z

root@quark016d09:/projects/coral-test# echo "src mraa-upm http://iotdk.intel.com/repos/1.1/intelgalactic" > /etc/opkg/mraa-upm.conf
root@quark016d09:/projects/coral-test# opkg update
Downloading http://iotdk.intel.com/repos/1.1/iotdk/Packages.
Updated list of available packages in /var/lib/opkg/iotdk.
Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/Packages.
Updated list of available packages in /var/lib/opkg/mraa-upm.
root@quark016d09:/projects/coral-test# opkg install libmraa0
Upgrading libmraa0 on root from 0.4.5-r0 to 0.5.0.12...
Downloading http://iotdk.intel.com/repos/1.1/intelgalactic/libmraa0_0.5.0.12_i586.ipk.
Removing package libmraa-dev from root...
Removing package libmraa-doc from root...
Removing obsolete file /usr/lib/libmraa.so.0.4.5.
Configuring libmraa0.
root@quark016d09:/projects/coral-test# node -e 'console.log(require("mraa").getVersion());'
v0.5.0-12-g3898182

Same issue. PWM pins don't blink, but non-PWM pins do.

Let me reimage some another SD card with the default Yocto image, rather than the IoT Devkit. That could help isolate where the issue is.

Answer 14 · 2014-09-30T19:51:35.000Z

Side note: I've never been able to blink the on-board led by writing to pin 13's gpio via sysfs (on gen 1). I have a thread on the intel community forums that was never answered in any helpful way: pin 13 is not actually connected to the onboard led, so how does the gen 1 galileo know to control the onboard led when a user uploads the blink.ino program via the IDE (which uses pin 13)?

(Note, this is unrelated to our current issue)

Answer 15 · 2014-09-30T19:52:15.000Z

By any chance, do you have a sketch running?

Answer 16 · 2014-09-30T21:21:32.000Z

Not currently. I've had a sketch running before, but now I remove it and reboot, just in case there's some pin exporting strangeness (I've also killed the process before, but I haven't checked to see if that causes pin exporting weirdness).

Answer 17 · 2014-09-30T21:30:20.000Z

Let me reimage some another SD card with the default Yocto image

Just a heads up, this doesn't ship with the libmraa0 bindings and apparently cannot be installed either: eclipse/mraa#2 (comment), which means this bug can't actually exist there. Galileo-io will fall back to filesystem gpio/sysfs when libmraa0 isn't present, so your code will be in an entirely different path.

Answer 18 · 2014-09-30T21:52:03.000Z

Hrm. Thanks for the heads up. What OS/version are you using? I've tried a few Gen 2 boards now and two fresh installs of the latest IoT devkit.

Answer 19 · 2014-09-30T22:07:56.000Z

iot-devkit (Intel IoT Development Kit) 1.1

201409031130

Answer 20 · 2014-09-30T22:15:04.000Z

Very strange! I'll do a step-by-step unboxing tomorrow and post the steps + results using a brand new board and brand new download.

Answer 21 · 2014-10-01T23:27:26.000Z

I'm having similar issues with the PWM pins (digital works well). Using the latest IOTDK image and having updated with opkg

root@quark0171ae:~# node -e 'console.log(require("mraa").getVersion());'
v0.5.0-12-g3898182

I ran servo-write.js with a servo motor on pin 3 (power on 5v, and ground pin on ground) and then analog-write.js with an LED just to be sure.

It flickers for a second and then there is no output. I'm going to look at running the python examples that come with MRAA to help narrow down what the issue is next.

Answer 22 · 2014-10-02T00:00:12.000Z

I pulled the MRAA repo and went into the examples/python folder.

Both the cycle-pwm.py and blink-io8 examples are working well for me.

There are four javascript examples in the directory as well:

AioA0.js  Blink-IO.js  GPIO_DigitalRead.js  GPIO_DigitalWrite.js

I tested all four with my build and they work. Analog read from A0 and writing out to pin 5 which is a PWM pin - but there is no PWM examples included with MRAA - or servo examples as far as I can tell.

Answer 23 · 2014-10-02T15:02:30.000Z

@sethismyfriend thanks for doing this research, super helpful :) I'll focus my attention on PWM for Servo controlling

Answer 24 · 2014-10-02T16:05:15.000Z

Step-by-step from this morning - https://gist.github.com/ryoshu/b3a59142c46e5081704f

Answer 25 · 2014-10-02T17:40:21.000Z

@ryoshu - can you try running some of the examples in MRAA to confirm if they work?

Answer 26 · 2014-10-02T18:08:35.000Z

@sethismyfriend I have a big changeset coming, will ping when ready

Answer 27 · 2014-10-02T19:58:18.000Z

@sethismyfriend Blink on pin 9 and analog read on pin A0 confirmed in the MRAA examples.

Answer 28 · 2014-10-02T21:23:27.000Z

About to push this release, just waiting for new tests to run through travis

Answer 29 · 2014-10-02T21:26:33.000Z

@ryoshu @sethismyfriend v0.3.2 is now on npm

This is the most relevant commit: 389c91e

Answer 30 · 2014-10-02T21:30:45.000Z

Actually... v0.3.3

Answer 31 · 2014-10-02T21:59:41.000Z

sweet - will try this before the end of the day

Answer 32 · 2014-10-02T22:17:07.000Z

Servo example confirmed to work on my build!

Answer 33 · 2014-10-03T14:14:03.000Z

Digital write on PWM pins still not working for me. Confirmed digital write works through Arduino IDE. Confirmed still working using MRAA.

Answer 34 · 2014-10-03T14:39:16.000Z

Can you paste the JS code?

Answer 35 · 2014-10-03T15:17:26.000Z

var board = new Galileo();
var pin = 9;
board.on("ready", function() {
  console.log("ready");
  var byte = 0;
  this.pinMode(pin, this.MODES.OUTPUT);

  setInterval(function() {
    board.digitalWrite(pin, (byte ^= 1));
  }, 500);
});

Answer 36 · 2014-10-03T15:29:16.000Z

I'm going to assume that includes: var Galileo = require("galileo-io");?

I'm wondering how you are running this code? Specifically, do you ssh to the board, then type something like node file.js? Or is this controlled by some other means?

What is the output of the program run?

You mentioned trying sketches again, are you certain those sketches are properly removed after testing them?

What is the current installed version of Galileo-IO?

Answer 37 · 2014-10-03T16:59:12.000Z

The require is in there. Sorry about that!

I've used iTerm with screen, ssh from Terminal and Putty on Win 8.1. I use vi to create and edit the files while logged into the board.

The output of the program is "ready".

re: sketch, "kill -14 {pid}" of the sketch and rm'd it from /sketch. I've also rebooted after removing the sketch. kill left the pin high, so I used node and MRAA to turn it low.

I've tried running some examples in /eg. Still no luck. Version is 0.3.3 according to package.json.

I'll retest all pins on digital write (PWM and regular) as I only tested pin 9 and 13 this time. I'll also hook up another Gen 2 and go through the tests again. And I've got some Gen 1s lying around so I'll try one of those and let you know if any of them work.

Answer 38 · 2014-10-03T19:18:45.000Z

Are you in Brooklyn today?

Answer 39 · 2014-10-03T19:37:07.000Z

Alas, no. Sent you an email.

Answer 40 · 2014-10-03T19:46:09.000Z

I feel completely insane right now... I've using existing code that was "basically the same" as your examples, but operating on pin 3 (also PWM) and everything works correctly—I just tried your code exactly as is—on pin 9—and reproduced the issue. Hold off on testing until I ping back.

Answer 41 · 2014-10-03T20:02:40.000Z

Also, I created a scoping mistake when I introduced IS_TEST_MODE that was causing the fallback path to be taken.

Answer 42 · 2014-10-03T20:10:14.000Z

Here's what I think happened...

Hopefully I had fixed whatever issues existed previously.
I wrote some tests and added what I thought would be an innocuous global flag
The flag turned out to be throwing an exception inside of a try/catch that exists explicitly to do the mraa feature detection.

Answer 43 · 2014-10-03T20:14:16.000Z

@ryoshu can you try v0.3.4

Answer 44 · 2014-10-04T00:04:33.000Z

I had an issue where if I had another instance of node running somewhere else the servo example was not working.

BTW - @rwaldron the servo is humming that I am using, a HiTec HS-425BB. That means that the frequency calculation for the motor might not be right. I'll play around with the code a bit to see if I can reduce the humming.

Answer 45 · 2014-10-04T00:18:52.000Z

analog_write.js is working well.

I tried running analog_read and encountered this error on my board:

root@clanton:~/galileo-io/eg# node analog-read.js
READY

/home/root/galileo-io/lib/galileo.js:84
        processRead(board, report, board.pins[report.index].read());
                                                            ^
TypeError: Object #<Pin> has no method 'read'
    at /home/root/galileo-io/lib/galileo.js:84:61
    at Array.forEach (native)
    at Object.read [as _onImmediate] (/home/root/galileo-io/lib/galileo.js:82:15)
    at processImmediate [as _immediateCallback] (timers.js:336:15)

Answer 46 · 2014-10-04T01:10:05.000Z

I had an issue where if I had another instance of node running somewhere else the servo example was not working.

Are they both controlling pins? That's probably an issue with the mraa bindings—presumably the pin state management expects only one process to be controlling at a time. I'll look into this a little more, but I'd consider refactoring my system to run in one process...

BTW - @rwaldron the servo is humming that I am using, a HiTec HS-425BB. That means that the frequency calculation for the motor might not be right

Did you mean pulse width? There is no code changing the frequency. What kind of hum are you hearing? Light hum? Gear grind? Can you record the sound? The HS-425BB is a pretty low end servo (bottom of the barrel for Hi-Tec). I always experience a bit of hum with these:

Hi-Tec HS-311
Hi-Tec HS-322HB
Hi-Tec HS-485HB
Hi-Tec HS-422

Additionally, the HS-425BB is a 90° stock rotation, but can support a 180° modified rotation; since Firmata based systems default to the Servo.cpp's default of 0-180° degrees (mapped to 544-2400μs pulses), then external code is responsible for setting sub-180° ranges—which is why this is built in to Johnny-Five's Servo class:

// initialize a servo that has a physical limit of 90° (centered)
var servo = new five.Servo({ pin: 9, range: [ 45, 135 ] });

For Galileo-IO, I found that 544-2400μs range would result in the servo arm over extending past 0° to ~-5°, 90° to somewhere between 80-87° and 180° falling short at about 160° (measured with http://www.servocity.com/html/servo_protractor.html#.VC9HuyldVZM or plain protractor for models that don't fit). For continuous servos, the result was a stopping point that wasn't 90°.

For each μs range I worked through, the following was tested:

Standard Servos

0-180° in steps of 1°
0-180° in steps of 5°
0-180° in steps of 10°
0-180° in steps of 20°
0-180° in steps of 45°
0-180° in steps of 90°
0-180° in steps of 180° (one big step)

Models

Hi-Tec HS-55
Hi-Tec HS-311
Hi-Tec HS-322HB
Hi-Tec HS-485HB
Hi-Tec HS-422
Hi-Tec HS-645MG
Hi-Tec HS-755HB
Hi-Tec HS-805BB
Hi-Tec HS-5685MH
EMAX ES08A11 II
Futuba S3003
Tower Pro MG995
Power HD 1501MG

Continuous Servos

60-90°, 90-120° in steps of 1°
60-90°, 90-120° in steps of 2°
60-90°, 90-120° in steps of 3°
60-90°, 90-120° in steps of 4°
60-90°, 90-120° in steps of 5°
60-90°, 90-120° in steps of 10°
60-90°, 90-120° in steps of 30°
60-90°, 90-120° in steps of 60° (one big step)

Models

Hi-Tec HSR-1425CR
Parallax Continuous Rotation
Parallax High Speed Continuous Rotation

In the end, the most consistently accurate range was 600-2600μs. This was a lot of work ;)

If using analogWrite on it's own is resulting in gear grinding at the ends, then I suggest using Johnny-Five with Galileo-IO to have at least software-level control over the servo range. I never intended Galileo-IO to be used a stand-alone library—but only because that would make for a crummy programming experience. I strongly encourage the use of Johnny-Five, coupled with Galileo-IO (this is how I use it in my own projects).

Answer 47 · 2014-10-04T01:15:04.000Z

I tried running analog_read and encountered this error on my board:

This is a duplicate of #17

I just pushed a patch that should address this error, but if there is no read method there, then something is wrong with mraa bindings.

Answer 48 · 2014-10-06T13:38:49.000Z

Apparently the Intel XDK runs a node process on boot, so I killed that per @sethismyfriend. Now I get a different behavior after upgrading to v0.3.5.

I run blink.js sketch on pin 3 and it goes high, then never goes back to low. I retested all digital pins using the same script from above. Other than 3 going high and staying high, no other PWM pins blink. All non-PWM pins blink.

Running the Blink-IO.js example in MRAA works fine on pin 3.

MRAA Version: v0.5.0-12-g3898182

Answer 49 · 2014-10-06T15:35:23.000Z

Apparently the Intel XDK runs a node process on boot, so I killed that per @sethismyfriend.

What is the node process?
- What does it do?
- Where is the source?
Is this process only run when working from the XDK?

I have never used the XDK, which means that Galileo-IO has ever been tested under those circumstances. I'm concerned that it won't matter what I do, there is no way to account for this other node process in Galileo-IO (because there is now way to safely know about other processes).

I run blink.js sketch on pin 3 and it goes high, then never goes back to low.

Here are some demonstrations of the correct behavior, along with the code used to produce them...

Blink, all pins, Galileo-IO

https://www.youtube.com/watch?v=mihxl7DNJOY

var Galileo = require("galileo-io");
var board = new Galileo();

board.on("ready", function() {
  console.log("ready");
  var start = Date.now();
  var byte = 0;
  var pins = Array.from({ length: 12 }, function(_, i) {
    return i + 2;
  });
  var toOutput = function(pin) {
    this.pinMode(pin, this.MODES.OUTPUT);
  };
  var highOrLow = function(pin) {
    this.digitalWrite(pin, byte);
  };

  pins.forEach(toOutput, this);
  setInterval(function() {
    byte ^= 1;
    pins.forEach(highOrLow, this);
  }.bind(this), 500);
});

Fade in/out, 3-5-6 PWM pins, Johnny-Five + Galileo-IO: *

https://www.youtube.com/watch?v=Kn9dfdAJ9QM

var temporal = require("temporal");
var five = require("johnny-five");
var Galileo = require("galileo-io");
var board = new five.Board({
  io: new Galileo()
});

board.on("ready", function() {
  var leds = new five.Leds([ 3, 5, 6 ]);

  function fader() {
    temporal.queue([
      {
        wait: 1000,
        task: function() {
          leds.fadeIn(500);
        },
      },
      {
        wait: 1000,
        task: function() {
          leds.fadeOut(500);
        }
      },
      {
        wait: 1000,
        task: function() {
          fader();
        }
      }
    ]);
  }

  fader();
});

*Fade in/out, all PWM pins, Johnny-Five + Galileo-IO: *

https://www.youtube.com/watch?v=SdQr7RKZDow

var temporal = require("temporal");
var five = require("johnny-five");
var Galileo = require("galileo-io");
var board = new five.Board({
  io: new Galileo()
});

board.on("ready", function() {
  var leds = new five.Leds([ 3, 5, 6, 9, 10, 11 ]);

  function fader() {
    temporal.queue([
      {
        wait: 1000,
        task: function() {
          leds.fadeIn(500);
        },
      },
      {
        wait: 1000,
        task: function() {
          leds.fadeOut(500);
        }
      },
      {
        wait: 1000,
        task: function() {
          fader();
        }
      }
    ]);
  }

  fader();
});

Same: v0.5.0-12-g3898182

Answer 50 · 2014-10-06T19:48:50.000Z

root@quark016df6:~# ps | grep node
157 root 34656 S /usr/bin/node /opt/xdk-daemon/main.js
181 root 78244 S /usr/bin/node /opt/xdk-daemon/current/appDaemon.js
192 root 2488 S grep node

That's on the Gen 2 Galileo running the IoTDK latest. It loads on startup. Do you not have those processes running on your Galileo with the IoTDK build?

Answer 51 · 2014-10-06T20:17:37.000Z

Using your code for blink all: https://www.youtube.com/watch?v=Hk7H5HkWHQA

Answer 52 · 2014-10-06T21:35:03.000Z

What version of Galileo-IO is running in that video?

Answer 53 · 2014-10-06T21:37:46.000Z

So...

root@quark016c31:~# ps | grep node
  174 root     34656 S    /usr/bin/node /opt/xdk-daemon/main.js
  194 root     78244 S    /usr/bin/node /opt/xdk-daemon/current/appDaemon.js
  205 root      2488 S    grep node
root@quark016c31:~#

/me shrugs

Answer 54 · 2014-10-06T21:59:32.000Z

What does journalctl -f say?

Answer 55 · 2014-10-06T22:12:46.000Z

@rwaldron 0.3.6

@ashishdatta I'll pull that in the morning.

Answer 56 · 2014-10-07T07:54:22.000Z

Hey so I was having the same issue with pin 11 ... but all of a sudden it started working once I changed the code to:

  1 // Use require("galileo-io") when running from an npm installation
  2 var Galileo = require("../lib/galileo");
  3 var board = new Galileo();
  4
  5 board.on("ready", function() {
  6   console.log("READY");
  7   var byte = 0;
  8   var byte2 = 0;
  9
 10   setInterval(function() {
 11     board.digitalWrite(11, (byte ^= 1));
 12     board.digitalWrite(13, (byte2 ^= 1));
 13   }, 500);
 14 });

But based on your video you already did something similar ... so I am not sure. I just know now it works. Also just out of curiosity do you have anything in your /sketch folder?

Answer 57 · 2014-10-08T15:04:23.000Z

Just did this: https://www.youtube.com/watch?v=X6iaGVFIOhQ

Here's the MRAA based code:

var m = require('mraa');
console.log('MRAA Version: ' + m.getVersion());

var leds = [];

for(var i = 0; i < 14; ++i) {
  var pin = new m.Gpio(i);
  pin.dir(m.DIR_OUT);  
  leds.push(pin); 
}

var ledState = true;

periodicActivity();

function periodicActivity() {
  for(var i = 0; i < leds.length; ++i) {
    leds[i].write(ledState?1:0);
  }
  ledState = !ledState;
  setTimeout(periodicActivity,1000);
}

@ashishdatta journalctl -f doesn't show anything for the call to the Galileo-IO script and there's no sketch in the folder and no process running.

Answer 58 · 2014-10-08T16:41:02.000Z

btw Rick, I'm using your "Blink, all pins, Galileo-IO" code for the Galileo portion of the video.

Answer 59 · 2014-10-08T17:28:36.000Z

@ryoshu with the latest changes (v0.3.7), I tried both your code and then this:

var Galileo = require("galileo-io");
var board = new Galileo();

board.on("ready", function() {
  for (var i = 2; i < 14; i++) {
    this.pinMode(i, this.MODES.OUTPUT);
  }

  var state = 0;

  setInterval(function() {
    state ^= 1;
    for (var i = 2; i < 14; i++) {
      this.digitalWrite(i, state);
    }
  }.bind(this), 1000);
});

And they do exactly the same thing. I've also added a set of unit tests, based on this example, that verify the correct calls to mraa bindings are made.

Answer 60 · 2014-10-10T20:46:12.000Z

@ryoshu any updates?

Answer 61 · 2014-10-10T21:23:09.000Z

Apologies. Haven't had a chance to try 0.3.7 yet. Will try to do so on Monday and report back.

Answer 62 · 2014-10-10T21:45:59.000Z

Thanks! Just grab the latest, because that number is old now

Answer 63 · 2014-10-13T14:50:28.000Z

Just grabbed the latest (0.3.8) and tried running it again. Same results as last time, galileo-io only blinks non-PWM pins, mraa blinks all digital pins. I ran the tests and here's the output:

https://gist.github.com/ryoshu/a770f1cf0107f16564c1

It hangs on that last line for at least half an hour, so I'm going to assume something has gone sideways. I reboot and now... digital pins 0, 10, 12 are all high on boot. Do a shutdown on power back on, 0, 10, 12 are still high (this is the first time I've seen that behavior).

root@quark016df6:~# ls /sys/class/gpio
export gpiochip16 gpiochip32 gpiochip64 unexport
gpiochip0 gpiochip2 gpiochip48 gpiochip8

Is that what your pin export looks like on boot?

Answer 64 · 2014-10-13T15:27:57.000Z

This is very interesting. On boot:

root@quark016c31:~# ls /sys/class/gpio
export  gpio15  gpio23  gpio31  gpio39  gpio46  gpio54  gpio61  gpio74      gpiochip32
gpio0   gpio16  gpio24  gpio32  gpio4   gpio48  gpio55  gpio62  gpio76      gpiochip48
gpio1   gpio17  gpio25  gpio33  gpio40  gpio49  gpio56  gpio64  gpio77      gpiochip64
gpio10  gpio18  gpio26  gpio34  gpio41  gpio5   gpio57  gpio66  gpio78      gpiochip8
gpio11  gpio19  gpio27  gpio35  gpio42  gpio50  gpio58  gpio68  gpio79      unexport
gpio12  gpio20  gpio28  gpio36  gpio43  gpio51  gpio59  gpio7   gpiochip0
gpio13  gpio21  gpio29  gpio37  gpio44  gpio52  gpio6   gpio70  gpiochip16
gpio14  gpio22  gpio30  gpio38  gpio45  gpio53  gpio60  gpio72  gpiochip2

Answer 65 · 2014-10-13T15:35:20.000Z

I just popped the same SD card into a different Gen 2 and got the same output I did originally. Points to a possible software problem, but let me poke around some more.

Thanks!

Answer 66 · 2014-10-13T16:31:28.000Z

~~What if we just add a script, which exports all the gpios, that runs when galileo-io is npm installed?~~

Nevermind, I hate that idea and it shouldn't be necessary to do such a thing.

Answer 67 · 2014-10-13T16:58:33.000Z

I'm seeing the pins being exported when I run a script, but I'm still getting the wonky results. I tried a fresh install of IOTDK and I'm seeing the same issue with GPIO export on boot. Still poking around.

Can you dump the output of ps after a reboot so I can compare?

Answer 68 · 2014-10-13T18:40:08.000Z

 PID USER       VSZ STAT COMMAND
    1 root      4308 S    {systemd} /sbin/init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW<  [kworker/0:0H]
    6 root         0 SW   [kworker/u:0]
    7 root         0 SW<  [kworker/u:0H]
    8 root         0 SW<  [cpuset]
    9 root         0 SW<  [khelper]
   10 root         0 SW   [kdevtmpfs]
   11 root         0 SW<  [netns]
   12 root         0 SW   [bdi-default]
   13 root         0 SW<  [kblockd]
   14 root         0 SW   [kworker/0:1]
   15 root         0 SW   [kswapd0]
   16 root         0 SW   [fsnotify_mark]
   17 root         0 SW<  [crypto]
   21 root         0 SW   [kworker/u:1]
   22 root         0 SW<  [deferwq]
   23 root         0 SW   [kworker/u:2]
   24 root         0 DW   [mmcqd/0]
   25 root         0 SW<  [kworker/0:1H]
   26 root         0 SW   [kjournald]
   34 root         0 SW   [flush-179:0]
   39 root         0 SW   [kworker/0:2]
   58 root         0 SW   [irq/57-0-0027]
   64 root      6728 S    /lib/systemd/systemd-journald
   74 root         0 SW   [khubd]
   78 root         0 SW   [spi0]
   79 root         0 SW   [spi1]
   88 root      9360 S    /lib/systemd/systemd-udevd
  101 root         0 SW<  [cfg80211]
  104 root         0 SW   [file-storage]
  105 root         0 SW<  [iwlwifi]
  112 root         0 SW<  [hci0]
  113 root         0 SW<  [kworker/u:1H]
  136 root      4400 S    /usr/lib/bluez5/bluetooth/bluetoothd
  138 root      5284 S    /usr/sbin/ofonod -n
  140 root      3188 S    /bin/sh /opt/cln/galileo/launcher.sh
  141 root      2644 S    /lib/systemd/systemd-logind
  142 root      2216 S    /opt/cln/galileo/clloader --escape --binary --zmodem --disable
  143 avahi     3396 S    avahi-daemon: running [quark016c31.local]
  144 messageb  3012 S    /usr/bin/dbus-daemon --system --address=systemd: --nofork --no
  145 root     18388 R    /sketch/sketch.elf /dev/pts/0
  146 avahi     3240 S    avahi-daemon: chroot helper
  151 root      2472 S    /lib/systemd/systemd-networkd
  153 root      6156 S    /usr/sbin/connmand -n
  159 avahi-au  2208 S    avahi-autoipd: [enp0s20f6] sleeping
  160 root      1972 S    avahi-autoipd: [enp0s20f6] callout dispatcher
  162 root      2380 S    /lib/systemd/systemd-hostnamed
  164 root      3192 S    {xdk-daemon} /bin/sh /opt/xdk-daemon/xdk-daemon
  168 root      5592 S    /usr/sbin/tcf-agent -d -L- -l0
  173 root     34656 S    /usr/bin/node /opt/xdk-daemon/main.js
  176 root      2336 S    /usr/sbin/lighttpd -D -f /etc/lighttpd.conf
  180 root      5320 S    /usr/sbin/wpa_supplicant -u
  182 root      2188 S    /sbin/agetty -8 --keep-baud ttyS1 115200 xterm
  183 root      2188 S    /sbin/agetty --noclear tty1 linux
  187 root     19940 S    /usr/bin/redis-server /etc/redis/redis.conf
  188 root         0 SW<  [krfcommd]
  192 root     78244 S    /usr/bin/node /opt/xdk-daemon/current/appDaemon.js
  199 root      5248 R    sshd: root@pts/1
  201 root      3308 S    -sh
  202 root      2724 R    ps

Answer 69 · 2014-10-13T19:16:32.000Z

ps looks the same excect for PIDs. Here's my latest:

{boot}
root@quark016df6:~/projects/galileo-test# ls /sys/class/gpio
export     gpiochip16  gpiochip32  gpiochip64  unexport
gpiochip0  gpiochip2   gpiochip48  gpiochip8
root@quark016df6:~/projects/galileo-test# node blink-all.js 
ready
(blink does not work on all pins)
root@quark016df6:~/projects/galileo-test# ls /sys/class/gpio
export  gpio13  gpio22  gpio34  gpio44  gpio55  gpio7   gpio78      gpiochip48
gpio0   gpio14  gpio24  gpio36  gpio45  gpio6   gpio70  gpio79      gpiochip64
gpio1   gpio15  gpio26  gpio38  gpio46  gpio60  gpio72  gpiochip0   gpiochip8
gpio10  gpio16  gpio28  gpio4   gpio49  gpio64  gpio74  gpiochip16  unexport
gpio11  gpio18  gpio30  gpio40  gpio5   gpio66  gpio76  gpiochip2
gpio12  gpio20  gpio32  gpio42  gpio51  gpio68  gpio77  gpiochip32
root@quark016df6:~/projects/galileo-test# node mraa-blink-all.js 
MRAA Version: v0.5.0-12-g3898182
(blink works on all pins)
root@quark016df6:~/projects/galileo-test# ls /sys/class/gpio
export  gpio13  gpio22  gpio34  gpio44  gpio55  gpio7   gpio78      gpiochip48
gpio0   gpio14  gpio24  gpio36  gpio45  gpio6   gpio70  gpio79      gpiochip64
gpio1   gpio15  gpio26  gpio38  gpio46  gpio60  gpio72  gpiochip0   gpiochip8
gpio10  gpio16  gpio28  gpio4   gpio49  gpio64  gpio74  gpiochip16  unexport
gpio11  gpio18  gpio30  gpio40  gpio5   gpio66  gpio76  gpiochip2
gpio12  gpio20  gpio32  gpio42  gpio51  gpio68  gpio77  gpiochip32
{reboot}
pin 0, 12 high on shutdown, pin 10 also becomes high on reboot
root@quark016df6:~# ls /sys/class/gpio
export     gpiochip16  gpiochip32  gpiochip64  unexport
gpiochip0  gpiochip2   gpiochip48  gpiochip8
root@quark016df6:~/projects/galileo-test# node mraa-blink-all.js 
MRAA Version: v0.5.0-12-g3898182
(blink works on all pins)
root@quark016df6:~/projects/galileo-test# ls /sys/class/gpio
export  gpio13  gpio22  gpio34  gpio44  gpio66  gpio76      gpiochip48
gpio0   gpio14  gpio24  gpio36  gpio45  gpio68  gpio77      gpiochip64
gpio1   gpio15  gpio26  gpio38  gpio46  gpio7   gpiochip0   gpiochip8
gpio10  gpio16  gpio28  gpio4   gpio5   gpio70  gpiochip16  unexport
gpio11  gpio18  gpio30  gpio40  gpio6   gpio72  gpiochip2
gpio12  gpio20  gpio32  gpio42  gpio64  gpio74  gpiochip32
root@quark016df6:~/projects/galileo-test# node blink-all.js 
ready
root@quark016df6:~/projects/galileo-test# ls /sys/class/gpio
export  gpio13  gpio22  gpio34  gpio44  gpio55  gpio7   gpio78      gpiochip48
gpio0   gpio14  gpio24  gpio36  gpio45  gpio6   gpio70  gpio79      gpiochip64
gpio1   gpio15  gpio26  gpio38  gpio46  gpio60  gpio72  gpiochip0   gpiochip8
gpio10  gpio16  gpio28  gpio4   gpio49  gpio64  gpio74  gpiochip16  unexport
gpio11  gpio18  gpio30  gpio40  gpio5   gpio66  gpio76  gpiochip2
gpio12  gpio20  gpio32  gpio42  gpio51  gpio68  gpio77  gpiochip32
{reboot}
pin 0, 12 high on shutdown, pin 10 also becomes high on reboot

Export might be red herring. I'll continue to dig.

Answer 70 · 2014-10-27T14:33:43.000Z

Back in the saddle again. Apologies for the delay. I just unpacked a new Gen 2, installed a fresh copy of IoT DevKit, updated to the latest version of mraa (v0.5.1-18-ge5c3e49) and installed a fresh copy of galileo-io (v0.3.9). Blink sketch using galileo-io only blinks on non-pwm pins. Blink sketch using mraa blinks on all pins.

I dropped into the galileo-io module and tried running the unit tests with -d -v flags:

Testing galileo.js
Galileo - shape...OK
Galileo - readonly...OK
Galileo - emitter...OK
Galileo - connected...OK
Galileo - ready...OK
Galileo.prototype.analogRead - correctMode...OK
Galileo.prototype.analogRead - analogPin...

It hangs indefinitely on analogRead. Running journalctl -f while running the unit tests I see:

Sep 13 15:19:29 quark016e92 libmraa[276]: libmraa initialised for platform 1

So mraa is being invoked. Any ideas on where I should poke around next?

Thanks.

Answer 71 · 2014-10-27T15:39:03.000Z

Are you running the unit tests on the Galileo? mraa shouldn't actually be invoked for the tests, I'm using a mock.

Have we looked at write permissions yet?

Answer 72 · 2014-10-27T18:56:39.000Z

Hmm. Something appears(?) to call mraa when I run the unit test. Steps to reproduce:

Reboot Galileo Gen 2
iTerm serial running main window
ssh into Galileo once ip address is obtained
in ssh instance run > journalctl -f
in serial windwo cd into galileo-io lib
grunt -d -v nodeunit
when
Running tasks: nodeunit

Running "nodeunit" task
[D] Task source: /home/root/projects/node_modules/galileo-io/node_modules/grunt-contrib- nodeunit/tasks/nodeunit.js

Running "nodeunit:tests" (nodeunit) task
[D] Task source: /home/root/projects/node_modules/galileo-io/node_modules/grunt-contrib-nodeunit/tasks/nodeunit.js
Verifying property nodeunit.tests exists in config...OK
Files: test/galileo.js, test/galileo-mraa.js, test/pin.js, test/mraa.js, test/not-implemented.js -> tests

runs journalctl reports:

Sep 13 15:32:42 quark016e92 libmraa[217]: libmraa initialised for platform 1

Might be unrelated (another process?) but I can get it to happen after every reboot.

Answer 73 · 2014-10-27T23:40:13.000Z

Something appears(?) to call mraa when I run the unit test.

Right, I said "shouldn't" because they shouldn't—not that they don't. Which is why I asked if you were running these on the board itself, which would cause that. It's really beside the point though because the unit tests aren't integration tests, so the only thing I will do about that is make sure that real mraa absolutely never gets used in the tests (just the mock). Forgive me if that sounds curt, but the tests correctly report that mraa apis are called where expected, when run in a dev environment. The tests were never intended to run directly on the board (because there should be no reliance there) and this feels distracting.

Did you see this:

Have we looked at write permissions yet?

Answer 74 · 2014-10-28T00:26:05.000Z

I'll insert some debug statements and see where exactly it hangs. Totally understand they aren't integration tests.

I'm unsure what permissions I should be looking at. Everything runs as root on the Galileo and it's rare to have something a-w by default, but maybe it's possible on a fresh install?

Thanks.

Answer 75 · 2014-10-28T01:22:06.000Z

I'll insert some debug statements and see where exactly it hangs.

They don't hang when run correctly.

but maybe it's possible on a fresh install?

I have no idea, but there is also no obvious reason why this doesn't "just work".

Answer 76 · 2014-10-28T14:16:11.000Z

Okay, let's assume that mraa being invoked running the unit tests is a red herring. Where should I look for permission issues? The mraa example works with the same permissions from the same folder as the galileo-io example that doesn't work.

Thanks.

Answer 77 · 2014-10-28T15:23:20.000Z

I'm not sure, but it may be helpful at this point for me to get one of the boards + sd that's not working correctly. I'm all out of ideas :\

Can we arrange a hand off for later today? Shoot me an email.

Answer 78 · 2014-10-31T16:41:10.000Z

@ryoshu 💃 👯 🎉 v0.4.0

Answer 79 · 2014-10-31T17:43:18.000Z

I had issues getting the latest version to install, if 0.3.x gets stuck, clear the npm cache:

rm -rf ~/.npm; npm cache clear;