lxqt-4gb and iot release candidates uploaded for beta testers

[Jason Kridner]

Robert's made a ton of improvements over the last several weeks/months and it makes some sense to try to update the promoted images. A GUI-less IoT image is now being produced to 

These are using a 4.4 Linux kernel.

LXQT-4GB for BeagleBoard-X15:

http://debian.beagleboard.org/images/bbx15-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz 

shat256sum: 69dc6b1daccc5fc0bb3050977d102706621ec0dd8bf14757f5ef0542e60ac72e

LXQT-4GB for BeagleBone Black and compatibles:

http://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz 

sha256sum: 28d67e877497fb9e52fe605f2cbefdbaedaff23e9fa82e9ed2076ae375aa777f 

IoT for BeagleBone Black and compatibles:

http://debian.beagleboard.org/images/bone-debian-8.4-iot-armhf-2016-05-13-4gb.img.xz 

sha256sum: 22fbba21cf294a92528b8a973e838f3cac801ce0e7d180b260a583f4bb0d1318 

There are associated bmap files in the directory for those using bmaptool. For others, I recommend using http://etcher.io. 

Reply with issues here or post to http://github.com/beagleboard/image-builder. 

[Dennis Lee Bieber]

On Sat, 14 May 2016 12:34:30 +0000, Jason Kridner
<jkri...@beagleboard.org> declaimed the following:

>Reply with issues here or post to
>http://github.com/beagleboard/image-builder.

Indirect issue...

http://beagleboard.org/latest-images

is producing

-=-=-=-=-
Error in application beagle

No space left on device
-=-=-=-=-
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Wally Bkg]

I'm downloading the 4GB lxqt image and will give it a go on my A5A BBB and a recent BBG.  I'll post any issues here.  I'm particularly testing the "newbie" out of the box experience starting with the Start.HTM web page link  to the bonescript examples, cloud9 IDE examples with some hardware "hello world" tests of digitalRead/Write() analogRead/Write() and attachInterrupt().  Finally onto node-red.

In the 2016-05-01 image it was really close to "great" only analogWrite()  was an issue in cloud9/bonescript and node-red wouldn't load node-red-node-beaglebone supplemental nodes.   If these two and config-pin all work without breaking anything else,  I'd say this might be a good  candidate for the "top level" beagleboard.org "latest Jessie".

I don't use the HDMI only the web interface and ssh -X

On Saturday, May 14, 2016 at 7:34:48 AM UTC-5, Jason Kridner wrote:

Robert's made a ton of improvements over the last several weeks/months and it makes some sense to try to update the promoted images. A GUI-less IoT image is now being produced to 

These are using a 4.4 Linux kernel.

[Wally Bkg]

The 2016-05-13 image does not get my "newbie ready" seal of approval, but its made some nice steps in the right direction.

Plugging in a fresh SD card image into my A5A BBB and connecting the USB cable into a Ubuntu-MATE 16.04 system, it  booted up and mounted the virtual MSDOS partition from which I ran START.htm in Firefox 46.0 and http://192.168.7.2/bone101/Support/bone101/ came up and seems to work fine.  Specifically the bonescript interactive example ran to flash the 4 user LEDs, and Cloud9 and node-red launched as expected.  Nice to see several images in a row without the boot-up flakiness I've experienced with most of the late 2015 and early 2016 images I've tried.

It was great to see that node-red by default includes the "extra" node-red-node-beaglebone and Grove sensor nodes as I've had issues getting the node-red-node-beaglebone node to build on previous images.  I've no way to test the Grove module nodes, but it was nice to see them installed by default (my newbie friend has a BBG and he might be interested in some of these modules)

Following the "this interactive guide" link, its examples worked as expected.  But then things deteriorated when I tried to dive a bit deeper under the "Functions" header.  These pages don't display correctly, for example the diditalWrite() link displays a page with this at the top:

--- layout: index title: digitalWrite scripts: [ '/Support/script/bonescript-demo.js' ] style: | #code { position: relative; width: 500px; padding-left: 0; border-radius: 4px; border-bottom-right-radius: 0px; border-bottom-left-radius: 0px; margin-bottom: 0px; margin-left: 30px; margin-right: 0px; align: left; } #console-output { margin-top: 0px; margin-left: 30px; width: 496px; border: 1px solid #cccccc; resize: vertical; } --- {% include side_menu.html title="BoneScript" %}

The text is readable but the Example "run" button doesn't work and there is a large empty box displayed in the lower right hand corner.  I tried it in Chrome and got the same result so its not likely a Firefox 46.0 issue.  Trying to follow a link form this page got me:

Cannot GET /Support/BoneScript/digitalWrite/%7B%7Bsite.baseurl%7D%7D/Support/BoneScript/demo_blinkled_external/



Cloud9 seems to work although the analogWrite()  (aka PWM) bonescript is still not working for this 4.4.9-ti-r25 kernel (known problem form 2016-05-01 image).  All my other "hello world" protoboard circuits seemed to work as expected.

 
I'll try to do daily apt-get upgrades and see if these issues get resolved, and I'll repeat these tests when the next testing Image is released.  I hope that  in some small way I can help make the Beaglebones become more appealing to newbies as an alternative to the Raspberry Pi -- especially for projects that need more I/O or A/D.

Its the possibility of "everything from a web browser" that could really give the Beaglebones a leg-up on the Pi for a newbie, although at present the advantage is clearly with the Pi because it comes from a educational project and has a deep and well organized set of tutorials and hand holding guides.

[Robert Nelson]

On Sun, May 15, 2016 at 4:08 PM, Wally Bkg <wb666...@gmail.com> wrote:

The 2016-05-13 image does not get my "newbie ready" seal of approval, but its made some nice steps in the right direction.

Plugging in a fresh SD card image into my A5A BBB and connecting the USB cable into a Ubuntu-MATE 16.04 system, it  booted up and mounted the virtual MSDOS partition from which I ran START.htm in Firefox 46.0 and http://192.168.7.2/bone101/Support/bone101/ came up and seems to work fine.  Specifically the bonescript interactive example ran to flash the 4 user LEDs, and Cloud9 and node-red launched as expected.  Nice to see several images in a row without the boot-up flakiness I've experienced with most of the late 2015 and early 2016 images I've tried.

It was great to see that node-red by default includes the "extra" node-red-node-beaglebone and Grove sensor nodes as I've had issues getting the node-red-node-beaglebone node to build on previous images.  I've no way to test the Grove module nodes, but it was nice to see them installed by default (my newbie friend has a BBG and he might be interested in some of these modules)

Following the "this interactive guide" link, its examples worked as expected.  But then things deteriorated when I tried to dive a bit deeper under the "Functions" header.  These pages don't display correctly, for example the diditalWrite() link displays a page with this at the top:

--- layout: index title: digitalWrite scripts: [ '/Support/script/bonescript-demo.js' ] style: | #code { position: relative; width: 500px; padding-left: 0; border-radius: 4px; border-bottom-right-radius: 0px; border-bottom-left-radius: 0px; margin-bottom: 0px; margin-left: 30px; margin-right: 0px; align: left; } #console-output { margin-top: 0px; margin-left: 30px; width: 496px; border: 1px solid #cccccc; resize: vertical; } --- {% include side_menu.html title="BoneScript" %}

The text is readable but the Example "run" button doesn't work and there is a large empty box displayed in the lower right hand corner.  I tried it in Chrome and got the same result so its not likely a Firefox 46.0 issue.  Trying to follow a link form this page got me:

Cannot GET /Support/BoneScript/digitalWrite/%7B%7Bsite.baseurl%7D%7D/Support/BoneScript/demo_blinkled_external/



Cloud9 seems to work although the analogWrite()  (aka PWM) bonescript is still not working for this 4.4.9-ti-r25 kernel (known problem form 2016-05-01 image).  All my other "hello world" protoboard circuits seemed to work as expected.

As the user that wants this feature, whey haven't you posted any patches that fix this yet?

Regards,

--

Robert Nelson
https://rcn-ee.com/

[Wally Bkg]

On Sunday, May 15, 2016 at 4:23:28 PM UTC-5, RobertCNelson wrote:

As the user that wants this feature, whey haven't you posted any patches that fix this yet?

Regards,

--

Robert Nelson
https://rcn-ee.com/

As I've said before, I'm ignorant and incompetent at web page authoring, and have no need or desire to learn for the foreseeable future.   

If I wanted some kind of "web interface" then I'd be motivated to learn, but my IOT system goal would be to have no user interface or configuration of any kind beyond the initial installation/setup.   OTOH node-red let me hack up a quick web interface to monitor the system status using a test/debug monitor program I'd written very early on with the only code change being adding a fflush(stdout) that I'd forgotten (and didn't matter when it was running in an xterm).  It was a neat trick and gave me a better appreciation for node-red, but ultimately is of no  real use beyond perhaps planting some seeds for future directions.

I think the "bonescript interactive guide" is a pretty neat trick and I would be studying it if I wanted some kind of web interface to trigger events or adjust parameters.  Cloud9 seems pretty solid (albeit slow), its just some of the examples don't work because newer kernels seem to break bonescript.  I'm sure any of the Python examples that use PWM would be broken as well, but I've not been looking at them.

My assumption is that beagleboard.org ultimately would like this stuff to work or it wouldn't be there.  While I've had little interest in this "newbie" stuff until recently, and certainly haven't tried all the images, my recollection is that this stuff hasn't been right since Angstrom was current.   If this assumption is wrong or its not helpful, I'll shut up about it. 

[Robert Nelson]

Oh my mistake, i thought getting the pwm sub-system working in v4.1.x/v4.4.x with bonescript was something you were personally interested in.

Thus i was more interested in helping push that developer to scratch their own itch.  (developers with their own itch to scratch are 10 X better, then a developer who's just fixing a bug report to fix it..)

pwm developer, we must export, X, Y, Z with feature A, B, C, and D, E, & F need to be adjustable in real time, and with the PRU ding G, H & I.....

me: it's blinks an led, ship it! ;)

Regards,

[Wally Bkg]

On Monday, May 16, 2016 at 10:59:33 AM UTC-5, RobertCNelson wrote:

Oh my mistake, i thought getting the pwm sub-system working in v4.1.x/v4.4.x with bonescript was something you were personally interested in.

 

Only  to the point that an LED and CdS photocell make a nice demo using the bone A/D and PWM to ramp up the LED as the photocell gets shaded.  Without the PWM is just switching on a light :)

Better certainly is the enemy of good enough, but  I won't argue against "better" until it starts breaking "good enough".

Thus i was more interested in helping push that developer to scratch their own itch.  (developers with their own itch to scratch are 10 X better, then a developer who's just fixing a bug report to fix it..)

pwm developer, we must export, X, Y, Z with feature A, B, C, and D, E, & F need to be adjustable in real time, and with the PRU ding G, H & I.....

me: it's blinks an led, ship it! ;)

I'm with you here :)  

While having Bonscript launch a PRU process would be impressive,  I'm not sure how someone needing the PRU timing would be looking at Bonescript in the first place.  

OTOH  if Bonescript, Python, C-library, or whatever had functions to upload the appropriate PRU code and stream data to or from the PRU functionality created by the uploaded code, it'd surely make the PRU become a building block instead of a project.   But is it even possible to do such a thing without ending up with something equally as complicated as uio_pruss or remoteproc?

[William Hermans]

Quite honestly, and with all due respect to Jason. I'm not quite sure of the need for bonescript period. Everything it does can be abstracted using Nodejs + the Nodejs fileSystem object. But I've been saying this for years, and some of you still haven't caught on yet . . .

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7bdf7b7a-bc28-463c-9f28-b8142dabb52e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Wally Bkg]

On Monday, May 16, 2016 at 2:39:43 PM UTC-5, William Hermans wrote:

Quite honestly, and with all due respect to Jason. I'm not quite sure of the need for bonescript period. Everything it does can be abstracted using Nodejs + the Nodejs fileSystem object. But I've been saying this for years, and some of you still haven't caught on yet . . .

IF Bonescript was updated in sync with the ongoing kernel changes you wouldn't need to modify your code as you do with Nodejs fileSystem object code as the file system interface to the GPIO changes, Bonescript would automatically handle it.  Unfortunately this promise is unfulfilled.  

IMHO there is too much of a good thing with kernel development -- do we really need four kernel versions under active development with seemingly no consideration of how changes break existing code and/or documentation?   It must be a nightmare for people actually selling capes.

In C a limited set of #define to deal with the path changes and open() read() write() close() calls is not too bad, and reasonably clear to understand now that newer kernels have made the export and unexport stuff unnecessary, I assume something similar works for nodejs.  Things like universal_io and config-pin are IMHO a giant step forward and reason enough alone to move to the 4.1.x kernel series.

Bonescript as I understand it, is just an extension (library?) for nodejs to handle the interface to BBX hardware -- I'm not much beyond the "cut and paste" playing around stage with nodejs, I find it powerful yet infuriating.   Much like Python, if there were an openCV interface to nodeJS I think I'd like it better than Python for getting an openCV project started, but there are so many good openCV tutorials and code samples on the Web its a pretty compelling way to get started with openCV.

[William Hermans]

IF Bonescript was updated in sync with the ongoing kernel changes you wouldn't need to modify your code as you do with Nodejs fileSystem object code as the file system interface to the GPIO changes, Bonescript would automatically handle it.  Unfortunately this promise is unfulfilled.  

This is false. If the file system path changes both would need a rewrite. Otherwise using the Nodejs filesystem object would not need to be refactored, ever. I can't speak for bonescript, because I have not cared to look and see what the underlying structure actually *is*. Because using the fileSystem object is so easy . . .

Also, when using a BBB as a production system it would be silly to do any major updates that could break compatibility with the currently working. So as far as that goes, at least for me is a moot point.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9e6a4d5d-e78f-4e1f-ac49-bc1f2d0435b3%40googlegroups.com.

[Jason Kridner]

On Sat, May 14, 2016 at 9:47 AM Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

On Sat, 14 May 2016 12:34:30 +0000, Jason Kridner
<jkri...@beagleboard.org> declaimed the following:


>Reply with issues here or post to
>http://github.com/beagleboard/image-builder.

        Indirect issue...

                http://beagleboard.org/latest-images

is producing

-=-=-=-=-
Error in application beagle

No space left on device
-=-=-=-=-

Thanks for notifying. I fixed this yesterday morning when I heard about it.

 

--
        Wulfraed                 Dennis Lee Bieber         AF6VN
    wlf...@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/svaejbhdnusokiamu3fas5g25vauff59lm%404ax.com.

[Jason Kridner]

On Mon, May 16, 2016 at 3:39 PM William Hermans <yyr...@gmail.com> wrote:

Quite honestly, and with all due respect to Jason. I'm not quite sure of the need for bonescript period. Everything it does can be abstracted using Nodejs + the Nodejs fileSystem object. But I've been saying this for years, and some of you still haven't caught on yet . . .

It doesn't get super heavy use, but it generally exposes new users to some of the hardware features before they have to take things to the next level. My hope is that it would provide some single point of documentation on the Linux file interfaces for these peripherals that would be reasonable to read. Unfortunately, not enough people in this community are interested in patching JavaScript code to document the Linux interfaces, so the out-of-box experience has remained a bit rough (though I'd argue still better than it would be without it).

Anyway, I'm still motivated to enable all the peripherals with it. octalbonescript is an interesting alternative, but they also haven't kept up with kernel updates and broke some interfaces I wasn't interested in breaking. The MRAA thing is hot to try right now, but it largely goes against the whole strategy of utilizing kernel drivers and advancing the state of Linux, so I'm not a big fan.

Anyway, if you aren't a big fan, I'd suggest offering alternatives to help newbies get started or simply leave-it-be.

 

On Mon, May 16, 2016 at 9:44 AM, Wally Bkg <wb666...@gmail.com> wrote:

On Monday, May 16, 2016 at 10:59:33 AM UTC-5, RobertCNelson wrote:

Oh my mistake, i thought getting the pwm sub-system working in v4.1.x/v4.4.x with bonescript was something you were personally interested in.

 

Only  to the point that an LED and CdS photocell make a nice demo using the bone A/D and PWM to ramp up the LED as the photocell gets shaded.  Without the PWM is just switching on a light :)

Better certainly is the enemy of good enough, but  I won't argue against "better" until it starts breaking "good enough".

Thus i was more interested in helping push that developer to scratch their own itch.  (developers with their own itch to scratch are 10 X better, then a developer who's just fixing a bug report to fix it..)

pwm developer, we must export, X, Y, Z with feature A, B, C, and D, E, & F need to be adjustable in real time, and with the PRU ding G, H & I.....

me: it's blinks an led, ship it! ;)

I'm with you here :)  

While having Bonscript launch a PRU process would be impressive,  I'm not sure how someone needing the PRU timing would be looking at Bonescript in the first place.  

OTOH  if Bonescript, Python, C-library, or whatever had functions to upload the appropriate PRU code and stream data to or from the PRU functionality created by the uploaded code, it'd surely make the PRU become a building block instead of a project.   But is it even possible to do such a thing without ending up with something equally as complicated as uio_pruss or remoteproc?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7bdf7b7a-bc28-463c-9f28-b8142dabb52e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORq4qbwNRHA_1WQbNxm-D%3DGYu3huojvxpOXQ7O0GuVPOfg%40mail.gmail.com.

[Jason Kridner]

On Mon, May 16, 2016 at 5:59 PM William Hermans <yyr...@gmail.com> wrote:

IF Bonescript was updated in sync with the ongoing kernel changes you wouldn't need to modify your code as you do with Nodejs fileSystem object code as the file system interface to the GPIO changes, Bonescript would automatically handle it.  Unfortunately this promise is unfulfilled.  

This is false. If the file system path changes both would need a rewrite. Otherwise using the Nodejs filesystem object would not need to be refactored, ever. I can't speak for bonescript, because I have not cared to look and see what the underlying structure actually *is*. Because using the fileSystem object is so easy . . .

BoneScript is just a library that provides some abstractions for the Linux sysfs file system interface. It is indeed the promise and I am working on fulfilling it.

 

Also, when using a BBB as a production system it would be silly to do any major updates that could break compatibility with the currently working. So as far as that goes, at least for me is a moot point.

But many people are just exploring and prototyping. For them, they'd like both reliable instructions as well as being able to take advantage of new examples to give them things to explore. It is worthwhile to try to maintain some layer of compatibility while interfaces underneath change to explore new features. I just haven't had the bandwidth to keep up with all the kernel changes. As more code lands more stably upstream (as it has over the last year), it should be easier for me to catch up.

Wally.... thank you very much for your feedback as it is very helpful for me and does save me a notable amount of time as most of the fixes can be pretty minor. Please don't be overly discouraged.

 

On Mon, May 16, 2016 at 2:15 PM, Wally Bkg <wb666...@gmail.com> wrote:

On Monday, May 16, 2016 at 2:39:43 PM UTC-5, William Hermans wrote:

Quite honestly, and with all due respect to Jason. I'm not quite sure of the need for bonescript period. Everything it does can be abstracted using Nodejs + the Nodejs fileSystem object. But I've been saying this for years, and some of you still haven't caught on yet . . .

IF Bonescript was updated in sync with the ongoing kernel changes you wouldn't need to modify your code as you do with Nodejs fileSystem object code as the file system interface to the GPIO changes, Bonescript would automatically handle it.  Unfortunately this promise is unfulfilled.  

IMHO there is too much of a good thing with kernel development -- do we really need four kernel versions under active development with seemingly no consideration of how changes break existing code and/or documentation?   It must be a nightmare for people actually selling capes.

In C a limited set of #define to deal with the path changes and open() read() write() close() calls is not too bad, and reasonably clear to understand now that newer kernels have made the export and unexport stuff unnecessary, I assume something similar works for nodejs.  Things like universal_io and config-pin are IMHO a giant step forward and reason enough alone to move to the 4.1.x kernel series.

Bonescript as I understand it, is just an extension (library?) for nodejs to handle the interface to BBX hardware -- I'm not much beyond the "cut and paste" playing around stage with nodejs, I find it powerful yet infuriating.   Much like Python, if there were an openCV interface to nodeJS I think I'd like it better than Python for getting an openCV project started, but there are so many good openCV tutorials and code samples on the Web its a pretty compelling way to get started with openCV.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9e6a4d5d-e78f-4e1f-ac49-bc1f2d0435b3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqh4CdSvOCO%2BVUewHBD2pS9%3D0qEL27Xu6NGyY8KGs1RYQ%40mail.gmail.com.

[Jason Kridner]

On Sat, May 14, 2016 at 8:34 AM Jason Kridner <jkri...@beagleboard.org> wrote:

Robert's made a ton of improvements over the last several weeks/months and it makes some sense to try to update the promoted images. A GUI-less IoT image is now being produced to 

These are using a 4.4 Linux kernel.

So far, feedback has been that these images are an improvement, but have some issues to be resolved. To that end, I've mirrored them and added them to 

http://beagleboard.org/latest-images

After Maker Faire Bay Area, we can put a concerted effort into cleaning up the remaining bugs.

[William Hermans]

It doesn't get super heavy use, but it generally exposes new users to some of the hardware features before they have to take things to the next level. My hope is that it would provide some single point of documentation on the Linux file interfaces for these peripherals that would be reasonable to read. Unfortunately, not enough people in this community are interested in patching JavaScript code to document the Linux interfaces, so the out-of-box experience has remained a bit rough (though I'd argue still better than it would be without it).

So here is the problem for me. I'm an experienced programmer of ~20 or so years. I do not know Nodejs well enough to just start ripping into your package and fix it. From my perspective, it's just as easy, and perhaps easier to just read the Nodejs documentation and create my own abstraction layer.

Anyway, I'm still motivated to enable all the peripherals with it. octalbonescript is an interesting alternative, but they also haven't kept up with kernel updates and broke some interfaces I wasn't interested in breaking. The MRAA thing is hot to try right now, but it largely goes against the whole strategy of utilizing kernel drivers and advancing the state of Linux, so I'm not a big fan.

Anyway, if you aren't a big fan, I'd suggest offering alternatives to help newbies get started or simply leave-it-be.

This is exactly my plan, eventually. I have a huge project of my own right now that includes creating a Nodejs back end, and I'm thinking an Angularjs front end for a project that is pretty much a web appliance that uses nearly every pin on the P8, and P9 headers. With this project though, I have a lot to learn myself. As I'm not really a web developer. Technically, I know I could do all of this in C, at least on the back end. But that does not exactly make much sense to me as Nodejs has a much better library infrastructure for this situation.

So I've never even toggled a GPIO with Nodejs yet, and haven't even seen any code yet either. However, I do know the peripheral sysfs stuff, and Nodejs BCL well enough to know that it can be done, and that doing so would be fairly trivial for an experienced developer. All I have to do is read up on the various libraries I need to know, and I'll be set.

So, when I do get around to writing code for this purpose. I will write up a blog post, and offer the information for all to see.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPk16RSwkhhAp1i3wcfxdBQ%3DZ_vOkZgV%2BYxcgbZfooBufA%40mail.gmail.com.

[Baozhu Zuo]

Thanks Jason, We are happy to work with you.

在 2016年5月17日星期二 UTC+8下午12:39:01，Jason Kridner写道：

[William Hermans]

Just dorking around for a few minutes to take a break from other things . . .

var base_path = "/sys/class/gpio/gpio";
var pin_number = "49";
var value = base_path + pin_number + "/value"
var direction = base_path + pin_number + "/direction"

read(value);
read(direction);
write(direction, 'high');
read(value);
read(direction);

function read(path){
    var fs = require('fs');
   
    var buf = fs.readFileSync(path, 'utf8');
    console.log(path + ': ' + buf);
}

function write(path, value){
    var fs = require('fs');
    fs.writeFileSync(path, value, 'utf8');
}

Output

william@beaglebone:~/dev$ echo 49 > /sys/class/gpio/unexport
william@beaglebone:~/dev$ echo 49 > /sys/class/gpio/export
william@beaglebone:~/dev$ node node-gpio.js
/sys/class/gpio/gpio49/value: 0

/sys/class/gpio/gpio49/direction: in

/sys/class/gpio/gpio49/value: 1

/sys/class/gpio/gpio49/direction: out

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2e914225-06e5-47b5-954e-959863087f72%40googlegroups.com.