Does apt-get upgrade not update BoneScript?

I’ve a pair of Beaglebone Greens, one running “latest” from beagleboard.org image 2015-11-12 kernel 3.8.13-bone79, the other running what came loaded in the eMMC: 2015-03-01 kernel 3.8.13-bone71.1

Both are “current” with apt-get update ; apt-get upgrade as of a day or two ago. I’m having some BoneScript/Node-RED issues and noticed the 2015-11-12 image has BoneScript 0.2.5, whereas the 2015-03-01 has BoneScript 0.2.4

Is BoneScript not part of the “normal” apt-get update/upgrade maintenance?

I just did apt-get update/upgrade on the BoneScript 0.2.4 system before I post this message and I get:
W: Size of file /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_main_binary-armhf_Packages.gz is not what the server reported 400377 400405
From the update, and the upgrade shows 5new packages, none of which appear to have anything to do with BoneScript.

The first BBG (with BS 0.2.5) I wanted to setup with an 8GB SD card and “standardize” with my BBW and BBB running Jessie, but I burned the “latest” Wheezy image to its eMMC when I tried some BoneScript stuff to help out a friend and had issues, and got an answer here that BoneScript was not working for 4.1 kernels yet so I should use 3.8 series if I want BoneScript.

I’m finding that most of the BoneScript examples have issues – throwing apparently harmless error messages, or just plain not working and throwing apparently fatal error messages. I’m beginning to doubt that BoneScript is a very useful starting point for a newbie (my friend).

For instance the blinkled.js example at: http://192.168.7.2:3000/ide.html
prints this in the examples/blinkled.js tab when I run it:

debugger listening on port 15454

/usr/local/lib/node_modules/bonescript/my.js:57
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 Object.exports.create_dt (/usr/local/lib/node_modules/bonescript/my.js:123:33)
at Object.exports.setPinMode (/usr/local/lib/node_modules/bonescript/hw_capemgr.js:83:12)
at Object.f.pinMode (/usr/local/lib/node_modules/bonescript/index.js:160:15)
at Object. (/var/lib/cloud9/examples/blinkled.js:6:7)
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 Module.runMain [as _onTimeout] (module.js:497:10)

Seems we could switch it over to the native Debian package system rather than npm.

That would be nice.

I’m not familar with npm beyond the cut and paste commands I used following the node-red installation instructions. So how do I use npm to update BoneScript?

The 0.2.5 system seems to mostly work although the fade.js example totally fails throwing undefined errors updating PWM freq, value, & duty,

The 0.2.4 system pretty much nothing works, even the simple blinkled.js totally fails as mentioned below.

What are the odds of BoneScript working better with Jessie? I’d prefer to have everything running Jessie.

Jessie wouldn’t make much difference. The kernel version has a bit impact. The location of cape manager and indexes of the device tree entries have hard dependencies.

It seems the problem is that something in 2015-11-12 “latest” image has broken b.analogWrite() function compared to 2015-03-01 which seems to be the last version the BoneScript examples have been tested on, but the 2015-03-01 image shipped in the eMMC of my BBG is broken, and comes with BoneScript 0.2.4. Doing apt-get update and apt-get upgrade doesn’t fix it and I’ve been unsuccessful at updating it to BoneScript 0.2.5.

So I downloaded and installed latest 2015-11-12 from beagleboard.org and while it has BoneScript 0.2.5 the b.analogWrite() function is still broken. The analog2.js example seems to work correctly without any error messages and the blinkled.js example runs but throws apparently harmless errors.

Any quick fix?

I’m finding the Google Groups topic filtering is giving me fits with following threads, so I apologize for saying basically the same thing in multiple threads, but it looks like the latest 2015-11-12 image has broken BoneScript.

My interest in BoneScript is only to help a friend get started, Jessie vs. Wheezy will make no difference to him for the foreseeable future. But I’d prefer to give him Jessie so I don’t need to maintain an old version to help him (he’s ~80 miles away so I’ll keep a duplicate system so I can write a few functions that’d be beyond him initially). But having Wheezy in my eMMC and booting Jessie from SD card (4GB is too small for me straight away) won’t be a terrible burden.

He’d seem to be the target user BoneScrip has in mind – experienced in electronics, having built several non-autonomous (radio controlled) robots, but no experience in programming. He’s got an off-grid hydroponic greenhouse automation project where a loop time of minutes will be fine so speed will not be an issue.

Hi Wally-

I’ve run into a similar problem whereby I downloaded the “Recommended” image from the beagleboard.org webpage,
only to find that “Recommended” is not necessarily the same as “good” or “working”.
Linux seems to change and move quickly.

For the cost of a microSD card and a few minutes of experimentation, you could try an image from here:

https://rcn-ee.com/rootfs/bb.org/testing/

I having good success (I’m not using Bonescript) with images in the 2016-01-24 folder.
Get the regular (not the flasher) image and you are ready to test.
One thing thing I have had problems with with these testing images is unreliable USB network connection. I’m transitioning to LAN anyway and that works great.

Regards,
Greg

I’ve been using the Jessie testing images, but they’ve all been broken for BoneScript.

I’m helping a non-programmer friend get started with a project idea and I’m 99.9% sure that BoneScript and Node-Red is about the best starting point for what he wants to accomplish. Having a reliable USB gadget is a must for this as I don’t want to add Linux-Windows network setup into the mix at the very start. Eventually he’s going to want WiFi so reliable USB functions is a must.

The other problem I’ve had with the testing images is that apt-get update ; apt-get upgrade has killed a couple of working systems, while its not hard to do, it still wastes several hours to reformat an SD card and start over :frowning:

I’ve been using the Jessie testing images, but they’ve all been broken for BoneScript.

I’m helping a non-programmer friend get started with a project idea and I’m 99.9% sure that BoneScript and Node-Red is about the best starting point for what he wants to

Add of this Sunday, node red will be installed by default…

Till then, as root…

https://gist.github.com/RobertCNelson/74ca34c860e522071317

accomplish. Having a reliable USB gadget is a must for this as I don’t want to add Linux-Windows network setup into the mix at the very start. Eventually he’s going to want WiFi so reliable USB functions is a must.

Not much has changed in the gadget driver since 3.8.13… Just lots of fixes in the musb driver…

The other problem I’ve had with the testing images is that apt-get update ; apt-get upgrade has killed a couple of working systems, while its not hard to do, it still wastes several hours to reformat an SD card and start over :frowning:

update/upgrade shouldn’t break anything, kernel didn’t get auto updated… We need more info…

Regards,

PS, use bmaptool, only takes 5 mins on a 4gb image…

Regards,

Great! I’ll be among the first to download Sunday’s new Jessie image! Do you know if the BoneScript PWM is now working?

Most of my hours wasted is re-installing and re-configuring the non-standard stuff I use, so I’m not sure how bmaptool (which I assume is a “better” SD card burner) would buy me much. I start dd and do something else – the dd is always done by the time I get back to it :slight_smile:

I know apt-get upgrade shouldn’t break anything, but I’d been using a Jessie testing image (I think 8.1 from about April or May 2015) on both my BBW and BBB I upgraded them both (after skipping several other image releases) before rebooting either, and neither would allow a login afterwards – no X on the BBB and no ssh on both. I could recover my files from the SD cards so it wasn’t a total loss. I posted a message about it shortly after it happened, but I think my Google Groups filters (which I find less than helpful) put it where nobody seemed to notice it.

I’ve come to the conclusion I’ve a hardware USB issue with my A5A BBB, it sometimes works, more often not :frowning:

Great! I’ll be among the first to download Sunday’s new Jessie image! Do you know if the BoneScript PWM is now working?

Bonescript is still only written for 3.8, it needs to be ported to the 4.1 config-pin interface.

Most of my hours wasted is re-installing and re-configuring the non-standard stuff I use, so I’m not sure how bmaptool (which I assume is a “better” SD card burner) would buy me much. I start dd and do something else – the dd is always done by the time I get back to it :slight_smile:

bmaptool does things like skipping writing zero’s which dd has to write. For each img.xz on the file server there is a matching .bmap file.

I know apt-get upgrade shouldn’t break anything, but I’d been using a Jessie testing image (I think 8.1 from about April or May 2015) on both my BBW and BBB I upgraded them both (after skipping several other image releases) before rebooting either, and neither would allow a login afterwards – no X on the BBB and no ssh on both. I could recover my files from the SD cards so it wasn’t a total loss. I posted a message about it shortly after it happened, but I think my Google Groups filters (which I find less than helpful) put it where nobody seemed to notice it.

From may 2015, there was a very big upgrade in lxqt, I tried to minimize the issue (upstream changed there c++ namespace in 0.10.0) I put out a note to this usergroup on how to upgrade with out the desktop breaking…

I’ve come to the conclusion I’ve a hardware USB issue with my A5A BBB, it sometimes works, more often not :frowning:

Regards,

So you are saying I will still need to stay with the 7.9 image series for BoneScript for the foreseeable future?

Will the image be 2016-01-31 or something else? I notice the beagleboard.org/latest-images page was last edited Jan 31, 2016 but the latest 8.3 image is 2016-01-24 and the latest 7.9 is the 2015-11-12 I’m currently using.

Can I get to 8.3 2016-01-24 from 8.2 2015-12-06 with apt-get updates and installs? or should I download the new image and start over?

The node-red I’ve installed for the 2015-11-12 image appears to use BoneScript for the “Beaglebone” nodes as I had to edit the config file to allow bonescript to get them to work. But there is no PWM node, although the GPIO nodes seem to throw the same errors in the terminal that ran the node-red-pi command to start everything as does the tab in Cloud9 that runs the BoneScript example programs. (I haven’t bothered with starting node-red automatically yet).

Thanks for explaining the bmap tool, I’d wondered what the *.bmap files were for, when I’ve downloaded images I’d just figured I didn’t need them :slight_smile:

I think the “top level” beaglebone.localhost web page needs some serious updating as the link:
http://192.168.7.2/bone101/Support/BoneScript/updates/
is still talking about Angstrom.

This is all someone like my friend would likely see if he’d just bought a board and hoped for the best. He’d quickly be terminally dead-in-the-water confused and either just give up on the idea or go back to trying to implement it by wiring up timers and relays. He’s in a rural area with only cell-phone service Internet access so hours of Googling and websurfing is just not practical. Books like the “Beaglebone Cookbook” and ""Exploring Beaglebone are great, but they are wrong in ways very disconcerting to a beginner by the time they are published.

While the link to beagleboard.org/latest-images is good, there is nothing there to give him a clue as to if he’ll need 7.9 8.3 or Angstrom. This is not helped by the fact that boards like the BBG seem to be shipping with completely broken images in the eMMC – there are other threads here about this.

So you are saying I will still need to stay with the 7.9 image series for
BoneScript for the foreseeable future?

or install the 3.8.x based kernel on jessie.

Will the image be 2016-01-31 or something else? I notice the
beagleboard.org/latest-images page was last edited Jan 31, 2016 but the
latest 8.3 image is 2016-01-24 and the latest 7.9 is the 2015-11-12 I'm
currently using.

I'm not in control of that page:

Watch:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

Can I get to 8.3 2016-01-24 from 8.2 2015-12-06 with apt-get updates and
installs? or should I download the new image and start over?

Yes/No

Yes, you will get the same packages..

No, you will not get the "extra" packages/things i added to "2016-01-24"...

The node-red I've installed for the 2015-11-12 image appears to use
BoneScript for the "Beaglebone" nodes as I had to edit the config file to
allow bonescript to get them to work. But there is no PWM node, although
the GPIO nodes seem to throw the same errors in the terminal that ran the
node-red-pi command to start everything as does the tab in Cloud9 that runs
the BoneScript example programs. (I haven't bothered with starting node-red
automatically yet).

Thanks for explaining the bmap tool, I'd wondered what the *.bmap files were
for, when I've downloaded images I'd just figured I didn't need them :slight_smile:

I think the "top level" beaglebone.localhost web page needs some serious
updating as the link:
http://192.168.7.2/bone101/Support/BoneScript/updates/
is still talking about Angstrom.

That repo is right here:

https://github.com/beagleboard/beaglebone-getting-started

go ahead fork it and submit pull requests.

This is all someone like my friend would likely see if he'd just bought a
board and hoped for the best. He'd quickly be terminally dead-in-the-water
confused and either just give up on the idea or go back to trying to
implement it by wiring up timers and relays. He's in a rural area with only
cell-phone service Internet access so hours of Googling and websurfing is
just not practical. Books like the "Beaglebone Cookbook" and ""Exploring
Beaglebone are great, but they are wrong in ways very disconcerting to a
beginner by the time they are published.

While the link to beagleboard.org/latest-images is good, there is nothing
there to give him a clue as to if he'll need 7.9 8.3 or Angstrom. This is
not helped by the fact that boards like the BBG seem to be shipping with
completely broken images in the eMMC -- there are other threads here about
this.

Angstrom is dead, it's maintainer left for a job at linaro, NO ONE has
stepped up since the fall of 2013 to pick up maintenance.

Regards,

So you are saying I will still need to stay with the 7.9 image series for
BoneScript for the foreseeable future?

or install the 3.8.x based kernel on jessie.

Other than the Bonescript PWM analogWrite() not working and the other “harmless” error messages thrown, its hard to see how either would make a difference to my friend. He is not in a position to do a lot of image downloading or apt-get updating for lack of adequate Internet bandwidth at his rural location (he’s actually “off-grid” running on solar power).

The fact remains I could not explain why anyone should use Jessie over Wheezy, or vice-versa, other than “Jessie is newer and is the future”. But if the 3.8.x kernel on Jessie fixed the PWM and error message nags I’d quickly install it before I give him the BBG and proto-plate setup I’ve made to get him started.

Can I get to 8.3 2016-01-24 from 8.2 2015-12-06 with apt-get updates and
installs? or should I download the new image and start over?

Yes/No

Yes, you will get the same packages…

No, you will not get the “extra” packages/things i added to “2016-01-24”…

If the extra stuff is all apt-get installable, a simple list of packages removed or added for the updated images would seem to save a lot of elinux.org download bandwidth. I assume that is also the reason for the *.bmap versions.

I think the “top level” beaglebone.localhost web page needs some serious
updating as the link:
http://192.168.7.2/bone101/Support/BoneScript/updates/
is still talking about Angstrom.

That repo is right here:

https://github.com/beagleboard/beaglebone-getting-started

go ahead fork it and submit pull requests.

I would if I actually knew what the answers and changes were. But it’d be ugly as I’ve never authored a webpage nor have I any experience with web authoring tools of any kind. Authoring a webpage is just not on my bucket list. Although writing some PRU code is :slight_smile:

I’ve had Beaglebones since the White, but this is the first time I’ve actually tried to do anything with Cloud9 and Bonescript. Pointing out the problems I’ve found was in the hope that someone in position to fix it would be made aware. I’m perfectly willing to accept that Beagleboard.org has given up on “beginners” instead focusing on near experts that want the PRU or DSP of the X-15. Other than not having on-board A/D and a much lesser number of GPIO pins my friend would otherwise likely be better served with a Raspberry Pi2.

Node-red is great, it’ll be awesome if a few issues get fixed, having it work in a downloaded image is a very good thing IMHO, although the installation instructions on the node-red website are very good.

Angstrom is dead, it’s maintainer left for a job at linaro, NO ONE has
stepped up since the fall of 2013 to pick up maintenance.

Re forking the above, I’m in no position to declare “Angstrom Dead” on a website or a forum post, although I’ve suspected it, given the lack of updates since about 2013. Although in my limited use of it and some of the recent Debian images with my A5A BBB HDMI it seemed Angstrom GUI was more responsive, although a lot more limited.

I’ve given up on BBB HDMI, as I’m finding the GUI apps I want to use mostly work better with ssh -X anyway, which is pretty neat when I run them on the BBG :slight_smile: Although it doesn’t take a lot of GUI app installations to overflow the 4GB eMMC.

I’m not sure that no one stepping up for Angstrom is such a bad thing, Debian is much better documented (probably the most complete of all distros) and all the really “minimal” Linux systems seem to be moving to Yacto project. I’ve always though there has been too much duplicated effort in Linux.

> So you are saying I will still need to stay with the 7.9 image series
> for
> BoneScript for the foreseeable future?

or install the 3.8.x based kernel on jessie.

Other than the Bonescript PWM analogWrite() not working and the other
"harmless" error messages thrown, its hard to see how either would make a
difference to my friend. He is not in a position to do a lot of image
downloading or apt-get updating for lack of adequate Internet bandwidth at
his rural location (he's actually "off-grid" running on solar power).

The fact remains I could not explain why anyone should use Jessie over
Wheezy, or vice-versa, other than "Jessie is newer and is the future". But
if the 3.8.x kernel on Jessie fixed the PWM and error message nags I'd
quickly install it before I give him the BBG and proto-plate setup I've made
to get him started.

> Can I get to 8.3 2016-01-24 from 8.2 2015-12-06 with apt-get updates and
> installs? or should I download the new image and start over?

Yes/No

Yes, you will get the same packages..

No, you will not get the "extra" packages/things i added to
"2016-01-24"...

If the extra stuff is all apt-get installable, a simple list of packages

It's in the commit log: "bb.org: jessie:"

https://github.com/beagleboard/image-builder/commits/master

removed or added for the updated images would seem to save a lot of
elinux.org download bandwidth. I assume that is also the reason for the
*.bmap versions.

bandwidth is cheap, only pushed out 1.5TB last month...

> I think the "top level" beaglebone.localhost web page needs some serious
> updating as the link:
> http://192.168.7.2/bone101/Support/BoneScript/updates/
> is still talking about Angstrom.

That repo is right here:

https://github.com/beagleboard/beaglebone-getting-started

go ahead fork it and submit pull requests.

I would if I actually knew what the answers and changes were. But it'd be
ugly as I've never authored a webpage nor have I any experience with web
authoring tools of any kind. Authoring a webpage is just not on my bucket
list. Although writing some PRU code is :slight_smile:

I've had Beaglebones since the White, but this is the first time I've
actually tried to do anything with Cloud9 and Bonescript. Pointing out the
problems I've found was in the hope that someone in position to fix it would
be made aware. I'm perfectly willing to accept that Beagleboard.org has
given up on "beginners" instead focusing on near experts that want the PRU
or DSP of the X-15. Other than not having on-board A/D and a much lesser
number of GPIO pins my friend would otherwise likely be better served with a
Raspberry Pi2.

Node-red is great, it'll be awesome if a few issues get fixed, having it
work in a downloaded image is a very good thing IMHO, although the
installation instructions on the node-red website are very good.

nah i have better ones today: (jessie/stretch rootfs)

sudo apt-get update
sudo apt-get install bb-node-red-installer

Angstrom is dead, it's maintainer left for a job at linaro, NO ONE has
stepped up since the fall of 2013 to pick up maintenance.

Re forking the above, I'm in no position to declare "Angstrom Dead" on a
website or a forum post, although I've suspected it, given the lack of
updates since about 2013. Although in my limited use of it and some of the
recent Debian images with my A5A BBB HDMI it seemed Angstrom GUI was more
responsive, although a lot more limited.

I've given up on BBB HDMI, as I'm finding the GUI apps I want to use mostly
work better with ssh -X anyway, which is pretty neat when I run them on the
BBG :slight_smile: Although it doesn't take a lot of GUI app installations to overflow
the 4GB eMMC.

I'm not sure that no one stepping up for Angstrom is such a bad thing,
Debian is much better documented (probably the most complete of all distros)
and all the really "minimal" Linux systems seem to be moving to Yacto
project. I've always though there has been too much duplicated effort in
Linux.

Regards,