Digital write not working on PWM pins, Gen 2
ryoshu opened this issue · 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.
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
It's the latest version: http://software.intel.com/iot. Let me know if you need anything else. Thanks!
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());'
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.
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.
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.
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".
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
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!
@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
'# 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?
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.
root@quark016d09:/projects/coral-test# echo "src mraa-upm http://iotdk.intel.com/repos/1.1/intelgalactic" > /etc/opkg/mraa-upm.conf/projects/coral-test# opkg update
root@quark016d09:
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/projects/coral-test# node -e 'console.log(require("mraa").getVersion());'
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:
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.
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)
By any chance, do you have a sketch running?
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).
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.
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.
iot-devkit (Intel IoT Development Kit) 1.1
201409031130
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.
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.
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.
@sethismyfriend thanks for doing this research, super helpful :) I'll focus my attention on PWM for Servo controlling
Step-by-step from this morning - https://gist.github.com/ryoshu/b3a59142c46e5081704f
@ryoshu - can you try running some of the examples in MRAA to confirm if they work?
@sethismyfriend I have a big changeset coming, will ping when ready
@sethismyfriend Blink on pin 9 and analog read on pin A0 confirmed in the MRAA examples.
About to push this release, just waiting for new tests to run through travis
@ryoshu @sethismyfriend v0.3.2 is now on npm
This is the most relevant commit: 389c91e
Actually... v0.3.3
sweet - will try this before the end of the day
Servo example confirmed to work on my build!
Digital write on PWM pins still not working for me. Confirmed digital write works through Arduino IDE. Confirmed still working using MRAA.
Can you paste the JS code?
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);
});
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?
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.
Are you in Brooklyn today?
Alas, no. Sent you an email.
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.
Also, I created a scoping mistake when I introduced IS_TEST_MODE
that was causing the fallback path to be taken.
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.
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.
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)
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).
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.
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
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
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?
Using your code for blink all: https://www.youtube.com/watch?v=Hk7H5HkWHQA
What version of Galileo-IO is running in that video?
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
What does journalctl -f say?
@rwaldron 0.3.6
@ashishdatta I'll pull that in the morning.
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?
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.
btw Rick, I'm using your "Blink, all pins, Galileo-IO" code for the Galileo portion of the video.
@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.
Apologies. Haven't had a chance to try 0.3.7 yet. Will try to do so on Monday and report back.
Thanks! Just grab the latest, because that number is old now
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?
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
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!
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.
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?
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
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.
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.
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?
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: nodeunitRunning "nodeunit" task
[D] Task source: /home/root/projects/node_modules/galileo-io/node_modules/grunt-contrib- nodeunit/tasks/nodeunit.jsRunning "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.
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?
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.
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".
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.
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.
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;