Is BoneScript more trouble than its worth?

I’ve been playing with BBB and BBG at the “top level” that I’d expect a beginner to start with – plug it in the USB port and use the Cloud9 IDE stuff. My BBB is an old A5A revision and it seems to have some issues, so lets ignore it for now,

Seems most of the BoneScript stuff either throws apparently “harmless” errors (disconcerting to a newbie, and all I can do is wave my hands and say “it doesn’t matter”) or they throw apparently severe errors and just don’t work.

I’ve setup a virgin BBG and did apt-get update and apt-get upgrade to get the “latest” into the 4GB eMMC. Is this not enough?

I find it somewhat disconcerting that the page
Is still talking about Angstrom, and apparently hasn’t been updated since the original BBW. Is this the root of my BoneScript problems?

My BBG BoneScript is not totally FUBAR as the three “Run” buttons to turn on, off, and restore the usr leds seems to work:
But the link to analogWrite() is where things go wrong.

My system:
cat /etc/dogtag Debian Image 2015-03-01

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.9 (wheezy)
Release: 7.9
Codename: wheezy

uname -a
Linux beaglebone 3.8.13-bone71.1 #1 SMP Wed May 20 20:13:27 PDT 2015 armv7l GNU/Linux

In the webpage:

I get the expected message:
Your board is connected!
BeagleBone Green S/N BBG115091153 running BoneScript 0.2.4 at

Is this a “bad” version of Bone-script?

I was most interested in the analogWrite() bonescript because the node-red doesn’t offer access to the PWM yet, and I wanted to do an Arduino-like cyclic LED dimming demo.

When I click the “Run” button I get:
Bonescript: connected
Bonescript: initialized
x.value = true
x.err = undefined

And the voltage at J9_P14 stays 0V, instead of the expected ~2.2V for the 0.7 width output.

So then I opened up Cloud9 IDE and in the Workspace go to Cloud9->examples->Grove_BBG->blinkled.js
when I run it I get:
debugger listening on port 15454
error: Failed to find devicetree fragment: bspm_P9_14_f
info: 0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2

if(slot[0]) {
TypeError: Cannot read property ‘0’ of null
at Object.exports.load_dt (/usr/local/lib/node_modules/bonescript/my.js:57:20)
at exports.create_dt.handler (/usr/local/lib/node_modules/bonescript/my.js:93:21)
at ChildProcess.exithandler (child_process.js:656:7)
at ChildProcess.emit (events.js:98:17)
at maybeClose (child_process.js:766:16)
at Socket.ChildProcess.spawn.stdin (child_process.js:979:11)
at Socket.emit (events.js:95:17)
at Pipe.Socket._destroy._handle.onread [as close] (net.js:466:12)

I did set-up node-red again and it was uneventful, I see the BBB installation instructions have been updated from the last time I did it. Worked better since it now mentions mkdir -p ~/.node-red before doing npm install of the node-red-node-beaglebone. Node-red has a few rough edges (most notably saving & loading “nodes” that you’ve wired up, and no easy way to stop or “undeploy” a buggy one), but its easy to show a newbie how to get started and do basic stuff.

I was initially very enthusiastic about Bonescript when I first started with the BBB.

It should be a good starting point for a beginner, assuming it all works!

One of the concerns I eventually realized was the potential timing problems with Javascript based embedded devices.
It’s a function of how the language works.

After I got the book “Exploring Beaglebone” by Derek Molloy, I’ve abandoned Bonescript for C/C++.
The trade-off is a large learning curve required for the language(s) and associated tool chains.
I think it is inevitable if you want to get the most power from the BBB you will need to go in this direction.


The examples in have all be tested to work. Handling of corner cases is a bit wonky in 0.2.5, but I’m hopeful that moving to the 4.1 kernel and using pinmux helpers rather than dynamically creating device trees will reduce the complexity for newbies. That work is starting now.

What is a “pinmux helper”?

"pinmux helper" is a kernel module that exports control of the pinmux
settings to the sysfs filesystem where they can be manipulated by
user-mode programs after boot. This helper module is used extensively
by the "universal" cape I created which enables most of the AM335x
hardware modules and allows run-time switching of the pinmux values
(via the pinmux helper) to select the desired pin function.

What is the name of the kernel module?
Has this been deployed in the Debian 8.2 release?
I’ve been poking around in 8.2, and there are interesting differences compared to 7.9.

A bash script run after boot can set up the pins?

For 3.8 kernels it's "bone-pinmux-helper", found in:

./drivers/misc/cape/beaglebone/bone-pinmux-helper.c the kernel source tree.

Found your github repository:

Awesome! Much appreciated.


Is BoneScript more trouble than its worth?

Honestly, I really do not know what one would hope to achieve using bonescript. But here was my day one take on bonescript.

I pulled the BBB out of the box, plugged it in. Installed the USB gadget drivers, etc. Read the getting started web pages, and then proceeded to fool around with bonescript on the getting started web pages. I recall thinking it was pretty cool to turn an LED on from a web page, but shortly after that, the novelty wore off.

Since then, I’ve used Nodejs without bonescript, and libmongoose to do similar things. But my outlook on third party libraries is probably different than some. Generally I’d prefer to learn how to do something as close to scratch as possible, assuming I have to start fresh on a given subject.

So I suppose my point is that yes, perhaps bonescript is “worth the trouble”. But you can bet that someone who is very fluent in Javascript, and Nodejs will have much less of a problem than you’ve had. However, with that said, someone who is not very fluent with Nodejs might have a much easier time writing their own Nodejs app without bonescript, or completely bypassing Nodejs alltogether. Instead using C/C++, python, or maybe even plain old bash scripts. It really depends on what one is most comfortable with.

I guess my point is that it looks like I’m reporting a bug in the latest image, the beaglebone cookbook website says the examples were tested on image 2015-03-01 but on the “latest” 2015-11-12 image the analogWrite() function is broken and throws errors so the PWM (fade.js) example doesn’t work. The blinkled.js example throws errors, but these don’t prevent it from working. The analog2.js example appears to work correctly without any error messages.

Any quick fix?