Does node.js not include packages in opkg yet?
-
It seems that depending on javascript to take care of file handle closing, especially with asynchronous calls, is a bit too much with the current state of this sample
I get, when I just try to run a blink example in an infinite loop, this error:
Error: EMFILE, too many open files '/sys/class/gpio/gpio0/direction' at Object.fs.openSync (fs.js:427:18) at Object.fs.writeFileSync (fs.js:966:15) at GPIOHelper.setPinDirectionSync (/mnt/sda1/scripts/js/gpiotest/gpiohelper.js:61:8) at GPIOHelper.setPinSync (/mnt/sda1/scripts/js/gpiotest/gpiohelper.js:65:10) at Object.<anonymous> (/mnt/sda1/scripts/js/gpiotest/test.js:15:23) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Function.Module.runMain (module.js:497:10)
I think that, perhaps it wouldn't be a bad idea to utilize a command line to fast-gpio, so that this stuff is taken care of for simple access. Until, that is, lower level and better syncing primitives are explored. This driver, I think, would best be implemented in C and wrapped up into a js lib, right? Heck, I'm not exactly well versed in getting the js side hooked up to the C low end drivers, so I wouldn't be the best person to ask.
In any case, this is a good start and proves that your system works. Of course, for pins, EBUSY doesn't make any sense for those coming from the arduino/avr world. But, having linux on your device is going to expose all the ugly embedded nonsense that makes it not that fun
-
@Dan-L. Cool! I'm honestly not really that great with Javascript yet, just knowledgeable enough to get myself into and out of trouble. However, the reason I bought the omega was the idea that we as the community could define node packages, have node.js on device, and just extend the capabilities for the device with npm.
The solution I stumbled upon did seem to have npm, and can be built with the script:
https://github.com/nneves/openwrt_mips_ar9331_nodejs/blob/master/npm_mips_ar9331.shSo, when I get time on Monday, I'll probably have to update the Dockerfile for nneve's scripts to build npm too. That should allow us to quickly iterate on stuff, push to npm, and then disseminate that way until official support for a slimmer node.js server comes from Onion, Inc.
Great stuff and great progress!
-
Hey @Theodore-Borromeo, can I see your blink code? I'm managing to write a bunch of things and not getting the
EMFILE, too many open files
message at any point. If you were usingsetPinSync
you shouldn't get that, but maybe with justsetPin
you might?
-
// test.js var GPIOHelper = require('./gpiohelper'); var helper = new GPIOHelper(); //blink LED hooked up to pin0 do { setTimeout(helper.setPinSync(0,true), 500); setTimeout(helper.setPinSync(1,false),500); } while (1)
As I don't have access to sleep() (haven't figured out how to do that yet in js), I may be hosing myself by using non-synchronized setTimeout. . . Again, js is not my forte.
I was thinking this would be better:
// test.js var GPIOHelper = require('./gpiohelper'); var helper = new GPIOHelper(); function toggle(value) { return value == true : false ? true; } //blink LED hooked up to pin0 var truthy = false; do { truthy = toggle(truthy); setInterval(helper.setPinSync(0,truthy), 2000); } while (1)
Though I left my omega at home so can't test right now
-
Also, as per https://github.com/paul99/v8m-rb/pull/19#issuecomment-24131056 , you can tune node via libv8 parameters via command line, which may help getting this tuned.
-
setTimeout(helper.setPinSync(0,true), 500);
will set the pin immediately. The first argument of setTimeout should be a function, but you're actually just passing in the return value ofsetPinSync
(which isundefined
). You probably meant to do this:setTimeout(function() { helper.setPinSync(0, true); }, 500);
BUT, doing that will still just delay that call by 0.5s. If you do that a bunch of times in an infinite while loop, you're actually just queueing an infinite amount of timers to run, but since the loop never ends, the timers never get a chance to run. An infinite while/for loop will halt all timers, due to the way V8's event loop works.
Instead you probably want to use
setInterval
, not in a loop:var lightState = false; setInterval(function() { // Toggle lightState = !lightState; // Set value helper.setPinSync(0, lightState); }, 500);
Or you could recursively call
setTimeout
. This one will toggle the light on/off at random intervals:var lightState = false; // Function which is triggered every 0+ to 1 seconds var next = function() { lightState = !lightState; helper.setPinSync(0, lightState); setTimeout(next, Math.random() * 1000); } next();
I also put some samples on GitHub
-
@Dan-L. Yeah, as soon as I posted the do-while loop that will continuously call a function some half a second into the future, I realized that I wasn't going to get far. In any case, the do while loop was a hold over from me sleeping for half a second and toggling on and off forever.
But I'll def take a look later and see your examples. Coincidentally, the newest firmware has a way to set the GPIO pins directly via the "GPIO Helper Tool" app! I hope that they reimplement their landing page as a webapp hosted by a node.js server running on device! That would be poetic
-
@Theodore-Borromeo About the Console, the front-end is implemented in HTML and Javascript, and the back-end uses the OpenWRT UBUS service, which is language independent.
Don't worry, we plan to release a detailed guide on how to implement your own apps and how to extend the UBUS service! No definite timeline for this guide but it's definitely on our list of priorities.
-
@Boken-Lin @Lazar-Demin
from borromeotlhs/onion-omega:v1is now available for use in a Dockerfile. it'll contain the entirety of the toolchain per your cross compile environment setup guide.
Regards,
TJ
-
@Theodore-Borromeo This is fantastic! We'll put it up on our website so that everyone can use it to compile their firmwares
-
@Boken-Lin That's fine, but I still haven't compiled a thing with it!! Can anyone test it to compile some drivers and stuff?
-
@Theodore-Borromeo I will test it out when we are doing our own compilation stuff. BTW, would you be able to write a simple tutorial in markdown showing the steps to get the image up and running on Docker? I think it can be a really useful thing to have on our wiki!
-
@Boken-Lin Assuming you know how to use docker, there are only a few ways to run it:
1.) Pull the image from docker hub and run an interactive console. e.g.:
docker pull borromeotlhs/onion-omega:v1
docker run -it 'borromeotlhs/onion-omega:v1' /bin/bash2.) Pull the image from docker hub, reference it in your own Dockerfile 'FROM' line, run resultant image built from that Dockerfile. e.g.:
docker pull borromeotlhs/onion-omega:v1<Dockerfile>
MAINTAINER joeschmoe@schmoenet.com
FROM borromeotlhs/onion-omega:v1RUN . . .
</Dockerfile>docker build -t 'my-new-image' .
docker run -it 'my-new-image' /bin/bashThere But yeah, let me know what repo you want me to write this out in Markdown, and I'll try to get to it.
PS
My vote for a package you all could try: https://github.com/OnionIoT/OpenWRT-Packages/tree/master/iojs
-
@Theodore-Borromeo Is this your published docker image - https://hub.docker.com/r/borromeotlhs/onion-omega/ Is it best to start with this then?
-
Has anyone had success building the iojs 2.x package?
-
@Theodore-Borromeo I got your docker container running. Is it supposed to have node compiled, or do I still need to follow that process. As soon as I got the bash prompt I tried to get the node version, but node is not found.
ā ~ docker run -it 'borromeotlhs/onion-omega:v1' /bin/bash onion@2af6d87347d6:/openwrt$ ls BSDmakefile LICENSE README config feeds feeds.conf.default package scripts target toolchain Config.in Makefile appendtoconfig docs feeds.conf include rules.mk staging_dir tmp tools onion@2af6d87347d6:/openwrt$ node --version bash: node: command not found
-
@Chris-Ward I compiled node from a completely different process than Onion's buildroot. It is also available at:
borromeotlhs/docker-onion-omega-nodejsThis image will contain the precompiled node and v8 binaries in them, I think in a folder called 'node_deploy'. That image will, I assume, have a working toolchain in it, though not entirely sure it was specifically suited to the onions hardware (tho node and v8 seem to work).
good luck!
-
@Theodore-Borromeo Great job Theodore!
-
-
@Theodore-Borromeo When I pull, I get a latest not found. Did you push this?